SearchSOA.com recently spoke with Mike Rosen, who provides an interesting view on trends in enterprise architecture today. Rosen is Director of Cutter Consortium's Enterprise Architecture Practice and Senior Consultant with its Business-IT Strategies Practice. He has more than 25 years of technical leadership experience and currently provides expert consulting services in the areas of EA and SOA. This is part one of a three-part interview.
Jack Vaughan: Mike, EA [Enterprise Architecture], as a term at least, arose around 2000. Can you say where it came from, where it is, and where it is going?
Mike Rosen: I think some companies that were pretty advanced started looking at enterprise architecture around 2000. Those are about the earliest EA programs. Some of those companies were pretty successful, actually at doing architecture. A lot of them were not; architecture is difficult to do.
But some of them were very successful at rationalizing the proliferation of servers and databases and networks and really getting control over the complexity of their infrastructure. Technology has advanced over the last ten years, almost every company now has so much technology and it is so important to their everyday business, that even smaller companies are starting to look at architecture as something they need to do to get a handle on the complexity.
Without architecture - if you don't in effect think ahead - then you end up building a lot of redundancy and fragility into your IT systems and your ability to respond to the business slows down. So, I see a lot of companies starting to look at enterprise architecture as something they really need to do.
But most of them don't really know how. And that's the challenge.
There are a lot of different approaches and proposals – if you sort of boil it down, there are three different approaches.
One is the big architecture approach, like the federal enterprise architecture, or big architecture approaches that were pretty common ten years ago. Bit top-down approaches By in large, those kinds of approaches don't seem to work very well. By the time you get anywhere, business has moved on, upi don't really care.
A second is a framework based approaches and really, I see, especially in the last year, a lot of momentum behind TOGAF - The Open Group Architecture Framework. There are other architecture frameworks out there, but TOGAF is the only one that could be called an industry standard. Certainly, the Zachman framework has a lot of popularity, but it's not backed by a consortium or an industry standards organization. A lot of people have been certified. These frameworks are large and the challenge is to whittle it down to something that makes sense to your organization. A practitioner has to understand how to apply it judiciously.
The third approach is what I will call an Agile Enterprise Architecture. This is a 'let's start small and look at specific business challenges' type of plan. You then craft an Enterprise Architecture program that starts by addressing those challenges. And as we address one challenge we will look for the next. And go and go and go - all along building up the Enterprise Architecture. In my opinion, that is the approach that seems to be working the best. But the practitioners that can do that are in high demand. There is a shortage of that kind of Enterprise Architect.
Jack Vaughan: So, does the Agile Enterprise Architecture come out of Agile development? Is it more oriented to developers than TOGAF or some of these federal architectures?
Mike Rosen: Well, it doesn't come from the agile development movement, but it follows the same principles, which is to understand your requirements, look for a small incremental approach at addressing those requirements, get continuous feedback from your sponsors and look for some way to prove the value. Where it probably differs the most from Agile development methodologies is in terms of the test first philosophy. That's pretty hard to implement into an Enterprise Architecture program. So, it's the same ideas, but in general, there is still somewhat of a schism between architecture and development.