In Defense of the Enterprise Architect

Lawson: But back then they promised to do what people are now saying that EA will do.  Do you see what I’m saying? Why do you think EA would be any different?
Morgenthal: EA can be different. One of the things I do (is the) Director of Apprenticeship and Mentorship for the CAEAP, which is the Center for Advancement and Enterprise Architecture Profession. We’re focusing on apprenticeship as a way to ensure that people who are going into that role have both the breadth and depth necessary in order to deliver on the needs.

In order to do alignment, you have to understand not just the requirements of the position, but you have to understand the business. You have to get it. You have to understand where the profit is made. You have to understand where margin is made. Or, if you're government you have to understand the key value proposition, why does your agency exist and what is the role of your agency? And that’s what I see is lacking in all of these people. I’ve talked to CIOs who don’t understand what the heck the company does. I worked with a CTO who doesn’t understand what the hell B2B is in a B2B company.

Lawson: So, maybe IT is trying to solve something that the business actually needs to solve first?
Morgenthal: I totally believe that. See, technology is a means to an end, not an end unto itself. And stop trying to get IT to solve all your problems. You know? They're your problems. All IT does is automate them. So if you automate garbage, guess what? It’s faster garbage.

Lawson: How does your organization define enterprise architects? How do they see that role?
Morgenthal: Actually, there’s a work stream right now to help better define that -- what is an EA -- and we’re working through that right now. We don’t want to make the mistake that a lot of other people made, which is these certifications in any way, shape or form indicate that somebody actually has the right skills to holistically design an entire organization.

And here’s the other thing: It depends whom you hear EA from, right? One of the issues that I have around enterprise architecture as a whole is the lack of focus on that it’s the enterprise and not just IT. It seems like a lot of the stuff I read all falls back to everything has to have an IT bend and everything relates back to the IT systems as if IT is the center of the universe. IT is not the center of the universe. IT is on the outskirts of the universe.

Let me give you a supply chain example. It’s the easiest way for me to explain it. I go into an a retail organization and I talk to the CEO, and the CEO tells me, “I want to be able to distribute my goods from my warehouse to my stores in a much more efficient manner. I’m currently using 10 trucks when I know I could be using eight. I’m not getting the right goods to the right store at the right time. And I have an antiquated IT system that is managing this for me.”

A lot of things that consultants would immediately do is focus on, “Oh, inadequate IT system. Let’s put in a new warehouse management system, you’ll be good to go.” Wrong. That’s the last of your problems. Technology is always the easiest (part).

What organically has gone on in this organization that has led to this point? And if you follow the trail, what you’ll find is it started with five stores and grew to 10 and then 50 and then 100 and we never stopped to reinvent ourselves every time we went through a major scalability change. We never really bothered to improve the system as we went along, we just let the existing system ride and enhance it as needed, but now we’ve gotten to the point of saturation and the entire process doesn’t scale at 100 stores.

So you have to, at some point, reinvest, go back, think about what the goal of the organization are and then say, “OK, relative to where you are and relative to what you want to achieve, these processes need to change. These people need to start talking. These people who aren’t talking to each other directly need to start talking.”

There’s like four or five maps: It’s the people map, who is talking to who; it’s the system map, what systems are talking to each other; it’s the people machine map, what people are using what systems to get their work done; it’s the machine-to-machine map, what systems are sending data to other systems in order to make things occur. You look at those four or five maps next to each other as a CEO and you go, “That ain’t right. I don’t want him talking to him and I don’t want -- why should I be entering that data there? That’s silly.”

A CEO can get it if you give them the pictures. The EA's job is to go draw those pictures. The only reason they can get to those pictures is because they understand the right questions to ask.

And you can’t just script it. It’s not a call center. I can’t give you a script. It’s understanding, watching the person do their job and having the understanding of how a retail organization works and how it should optimally work and saying, “I’m watching this person, this doesn’t make sense to me. OK, let me ask this person why they're doing it this way.” And doing that for six months and coming back with a map and saying, “Here’s what I found out.” So you have enough knowledge about what could be done, you have enough knowledge about what systems look like in a supply chain environment, you have enough knowledge about supply chain management and retail management as a whole in distribution and then you apply that breadth and that depth to the problem domain. You map it out.

Lawson: The kind of breadth that you're talking about, IT hasn’t traditionally been known for that. And I know you're talking about the enterprise architect as coming in with some business know-how, but aren't enterprise architecture's roots in IT?
Morgenthal: Yeah, unfortunately. It should have been a business hire to begin with, with somebody with an information technology background that has built systems in the past.

Lawson: So they're bringing more depth on the technology side than, say, a business analyst might have?
Morgenthal: Exactly. I mean, I can tell you consistently now in five different places I found the same problem with business analysts (BA) and SOA, just as a side note -- where there is a complete mismatch between traditional BAs and how they like to gather requirements and how they’ve been taught to gather requirements and what’s needed for an SOA. If you send a traditional BA in to do gathering requirements for an SOA you will end up with an impedance mismatch and a failure.

In fact, we were having this discussion yesterday with a potential client and it was a really great conversation because I said that basically there is no role for the BA in the future world of SOA. You have business process engineers and you have SOA architects. And if you want to use a BA, it’s really around collecting UI requirements and screen flow.

And the next question they had for me after I said that was, “We agree with you, but where are we going to get trained SOA people?”  And I said, “My good friends Ron and Jason would like to answer that question.”

Previous Page Next Page