Recently, I have been reading / discussing a lot about what people name “Enterprise Architecture”. This could be a never-end discussion, but, for the time being at least I feel like I need to make a stand point.
Lot of passionate discussions on EA networks are dealing with Enterprise Architecture and who is/should be leading it. Behind these ideological discussions, stand two very different approaches:
One which is more “conceptual” that we often call top-down approach and its mirrored: the so called bottom-up approach. I don’t want to argue about which approach is better than the other, as always, the truth is not black or white, it’s in the middle. To me, these two approaches are not conflicting, they are complementary and needed.
Then, what is the problem will you ask me? The problem is more when people say they are doing “Enterprise Architecture” while, in fact, they are performing “Enterprise IT Architecture”. Then, the situation becomes confuse and this confusion brings misunderstanding / mistrust. It is also question of people skills and background. Lot of architects have a IT background. Sometime, I feel that part of architecture profession (having a strong IT background) is trying to re-define the term “business architecture” to suit itself. This should be a term owned by the business, and business architecture has to do with money first and data second, and yet the “business architecture” defined by IT architects seldom mentions money. This is very dysfunctional.
Here is my attempt to give my vision of what “Enterprise Architecture” is and what “Enterprise IT Architecture” is.
To get the mindmap version, follow the link: http://www.biggerplate.com/viewMapImage.asp?ID=816
- Reporting to the CEO/MD and CIO
- Focus – Strategic
- Working with strategic planning
- Working closely with strategy and planning group/function.
- Unless EA has the resources to take up job of strategic plan development
- Handle both Macro / Micro views
- Working at an enterprise level giving direction to all projects. (holistic view)
- Working closely with PMO to provide guidance to individual projects (detail view)
- Working with the entire Enterprise
- Working with the entire enterprise (all functions and all cross-functional process owners)
- Business mission, business vision, business drivers, business objectives, business goals, business tactics, strategy, Customers, Products, Activities, Departments, Functions, Locations , Services, Applications, Databases, Technologies
- Working mainly at the logical level. (Projects develop the physical expressions of the logical)
- Helping in integration efforts at a logical level and avoiding redundancies in business processes, applications, data and technology, for example.
- Working with HR on motivation models
- Maintaining an EA repository/database containing information about elements of business, applications, data, and technology.
- Able to provide gap-analysis between as-is and to-be states to help both the strategic planning and PMO
- Able to help the management in making “informed” decisions by providing reports from the EA repository
- Making the whole organization “flexible” to “changes” as per the business/customer requirements
- Bringing the business-side closer to IT-side
Enterprise IT Architecture
- Talking only to the CIO
- Concerned with design and implementation
- Working at individual project level
- Working with project planning
- Working with the IT of the enterprise (Processes, Services, Applications, Databases, Technologies, Networks)
- Working largely at a physical level
- Working with HR on Technical role definition.
- Focus – Operational
As a conclusion (so far)
As shown on the previous mindmap, to me, both approaches are needed. If we want to categorize them, I would say that Enterprise Architecture contains Enterprise IT Architecture. But, the second one (IT) can live by itself too. It is all depend on what goals the enterprise targets. Consciousness needs to be there and conscious decision has to be taken. One should not fool the other.