JP Morgenthal, the Tech Evangelist blogger and a principal architect, explains to IT Business Edge's Loraine Lawson why and how the enterprise architect role should be different from previous positions that promised to transform the business and align IT with business goals. Read the first part of the interview, too: "Is Strategy the Key Characteristic of SOA?"

Lawson: I've been reading about how the enterprise architect can solve the IT/business alignment problem – be able to talk to the business, understand business process and so on. It strikes me that we saw the same promises made with the CIO, the CTO, business analysts and so many other IT roles. Why should the business believe it now? Do you see what I'm saying?
Morgenthal: Why should the business buy into enterprise architecture? Why should they buy into any of this stuff is my question. It’s like "fool me once, shame on me, fool me twice ...," well it’s not nice to fool people, you know?

That’s IT in a nutshell, circa a George Bushism. It’s the truth though, isn’t it, though? Its almost like IT has been selling these concepts over and over and over again, and they never succeed.  And actually, I think I wrote in one of my blog entries that it’s both of their faults. The blog entry was on IT people getting treated badly.  Did you see that one?

Lawson: I saw the title, but I haven't read it.
Morgenthal: That’s what it’s really all about. You know, IT people take the brunt of all of this stuff -- like you failed. And, you know, I can only succeed to the degree you allow me to succeed. In that blog piece I say, “But wait a minute, it’s not all their fault.”

That doesn’t relieve IT -- they're not supporting the business. They don’t put the business first. I talk to these people on a daily basis that build systems. They don’t put themselves in the position of the user. They don’t put themselves in the position of the business, where they think things through. And they have these arguments among themselves, you know, "Is it better to use Spring or Hibernate?" What does it make a difference?

What does the customer need? Once we understand what the customer needs, we should back it all the way down and say, "OK, let’s assume that this is what the customer needs today." We can see that this customer also needed this and this in the past. So we see a pattern forming, and this pattern indicates that this customer operates a particular way, so we can bet that in the future they’ll probably want to do similar things. Let’s not build this monolithic; let’s make this a reusable entity.

That’s, to me, with the whole concept of service -- let’s build it once and only once and have it be the gold standard, the authoritative way for doing something and, in the same vein, identify a pattern of a business function that is constantly used within the business domain. To me, it's a very logical process and it really doesn’t matter at the end of the day what technology domain you apply to it unless you want to think about it as an asset and how am I going to manage it and maintain it over time.

I mean, Java, .NET -- really, who cares? They're both going to exist for a really long time and there are really equal numbers of people who get it on both sides. So really, what’s the difference? I’ve got to pay for a Microsoft operating system on one hand and I can do the other one on free Linux, which really isn’t free.

If I run HR, all I want to do is be able to determine the entire lifecycle of an employee from the minute they come until the minute they leave; or even after they leave for their COBRA benefits. Do I really care how you do that? No. Are you providing me the features I need? No. Of course I’m pissed at you.

Lawson: Still... what bothered me about this EA conversation is that it's been suggested the enterprise architect should report to the CEO. How many IT positions need to report to the CEO?
Morgenthal: The problem is from a domain responsibility. If the EA isn’t reporting to the CEO, you then have somebody else’s agenda getting in the way. And I’ve seen that first hand.

Lawson: Well, is that bad?
Morgenthal: Yes.

Lawson: Why is that bad?
Morgenthal: Because everyone else’s agenda doesn’t really take into a holistic view of the enterprise.

Lawson: Wasn’t the CIO supposed to do that?
Morgenthal: No, the CIO doesn’t. Typically the background and requirements via CIO are not sophisticated -- they don’t have enough breadth and depth in both the business and the technology in order to deliver on that.

Lawson: What about the CTO?
Morgenthal: CTO worries too much about the technology and doesn’t have enough experience in the business. Most CTO positions I even see listed today want the person to understand how to do Perl, PHP, so I mean I think CTO is completely gone as far as a real position. No one understands the role of the CTO as an evangelist for how to apply technology to their business domain problems. The CIO is supposed to be managing the information domain, the entire volume and set of information is used to manage the business. They're both cockamamie positions that have grown up without any full comprehension of what this market would look like where we are now from 20 years ago when it first started being created.

Previous Page Next Page