Enterprise Architecture: Why is it Important?
The Enterprise Architecture practice has been there for decades but in last
few years it is regaining popularity as it is one of the key initiatives
driven by CxOs. So, why is it important for an Enterprise? Here are some of the key rationale:
1. Holistic Approach
Individual divisions across the enterprise only address business problems in their vicinity; but the EA team will have holistic point-of-view and work towards addressing the problems across the enterprise.
For example, having a Credit Card Loan Processing System for a London division is addressing locale specific business demands but the EA team can align this solution at an enterprise level & might provide inputs to make it generic for making it reusable across the enterprise.
2. Consistency in Delivering Solutions to Business Problem
Once we have EA in place, a business solution can be delivered in more structured & consistent way. Established Reference Models for Business Demands
For example, if there is need to develop a Credit Check System, then enterprise reference model (if not available, then Industry Reference Model) will help in establishing consistent architecture for this solution.
3. Building Enterprise-wide Repository
Repository created in the process of establishing EA in an organization like Tools Repository, Architectural Artifacts Repository will encourage reuse & standardization across the enterprise.
4. IT Governance
EA goes hand-in-hand with IT Governance & collaboratively helps in establishing governance across the enterprise, which helps in building controlled & directed corporation. It acts like a framework for leadership, organizational structure, business processes, standards, practices, etc.
5. Defined Business/Technical/Information System Architecture:
Last but not least, as part of EA establishment in the organization, a clearly defined business, technical and information system architecture gets developed during the process. This also creates opportunity to business & IT people to come together & re-validate them.
Some of the popular EA frameworks are TOGAF, Zachman, FEA, Gartner, DoDAF & I have seen most of time there is a custom EA architecture extracting best of the practices/standards/tools from all of them.
Feel free to discuss it further in more detail.
Published at DZone with permission of Ankur Kumar, author and DZone MVB.1. Holistic Approach
Individual divisions across the enterprise only address business problems in their vicinity; but the EA team will have holistic point-of-view and work towards addressing the problems across the enterprise.
For example, having a Credit Card Loan Processing System for a London division is addressing locale specific business demands but the EA team can align this solution at an enterprise level & might provide inputs to make it generic for making it reusable across the enterprise.
2. Consistency in Delivering Solutions to Business Problem
Once we have EA in place, a business solution can be delivered in more structured & consistent way. Established Reference Models for Business Demands
For example, if there is need to develop a Credit Check System, then enterprise reference model (if not available, then Industry Reference Model) will help in establishing consistent architecture for this solution.
3. Building Enterprise-wide Repository
Repository created in the process of establishing EA in an organization like Tools Repository, Architectural Artifacts Repository will encourage reuse & standardization across the enterprise.
4. IT Governance
EA goes hand-in-hand with IT Governance & collaboratively helps in establishing governance across the enterprise, which helps in building controlled & directed corporation. It acts like a framework for leadership, organizational structure, business processes, standards, practices, etc.
5. Defined Business/Technical/Information System Architecture:
Last but not least, as part of EA establishment in the organization, a clearly defined business, technical and information system architecture gets developed during the process. This also creates opportunity to business & IT people to come together & re-validate them.
Some of the popular EA frameworks are TOGAF, Zachman, FEA, Gartner, DoDAF & I have seen most of time there is a custom EA architecture extracting best of the practices/standards/tools from all of them.
Feel free to discuss it further in more detail.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Josh Marotti replied on Thu, 2010/07/08 - 9:03am
I have no issue with Enterprise Architecture and see it's place in an enterprise corporation. I do have an issue that most companies believe that Enterprise Architects and Software Architects are the same person, or can BE the same person. I completely disagree.
Enterprise architects are much 'bigger picture' people that work in word and how systems work together. Software architects work in code and visio to diagram and plan a specific software system. Software architects need to be in the code as much as possible, and enterprise architects need to be out of the code as much as possible.
Ali Syed replied on Thu, 2010/07/08 - 11:56pm
Good Article..
But Josh Marotti is true, I also encountered such situations where people will think that Enterprise Architects are same as Software architects they are not considering the big picture.
Andy Leung replied on Fri, 2010/07/09 - 7:14am
in response to:
Josh Marotti
However, I would not say "enterprise architects need to be out of the code as much as possible" because coding is just too low level in this sense. I would say Enterprise Architect should stay out of the idea of software specific, platform specific, and tools specific. Because when it comes down to how the architecture that can build dynamic business model, one cannot stuck in thinking about "should it be .NET or Java" or "Ajax is the way rather than Flash". Eventually, Enterprise Architect should be thinking in such a high level that "systems communicate" instead of "using web services to exchange data".
Just my 2 cents.
Ankur Kumar replied on Tue, 2010/07/13 - 11:54pm
in response to:
Andy Leung
I concur with you all!!
EA is a generic enterprise-level practice driven by individual on the top of the hierarchy (reporting to CTO or CIO) whereas architects (software/technical/application) are individuals limited to specific areas.
EA is also largely responsible to establish processes/guidelines/framework around which IT division will evolve in the right direction.