I am working as a Senior Architect having 13+ experience in IT Industry with core competencies in Web-oriented Solutions/Architecture (Primarily: Java/J2EE, RDBMS) with experience in architecture, design, development and deployment on heterogeneous platforms (Sun Solaris/Ultrasparc, Linux/Unix, Intel/AMD x86) and Application Servers (Websphere, WebLogic, JBOSS, Tomcat, Terracotta). Also, having diverse experience in numerous JEE Web Frameworks (Struts, Spring, Wicket, JSF, Custom frameworks), open-source technologies (based on multiple languages like PHP, Scala, .NET) and COTS (Commercial off-the-shelf) solutions (e.g. CA SiteMinder, Wily Introscope, Websphere DynaCache, WebLogic Portal). Ankur is a DZone MVB and is not an employee of DZone and has posted 7 posts at DZone. You can read more from them at their website. View Full User Profile

Enterprise Architecture: Why is it Important?

07.08.2010
| 9803 views |
  • submit to reddit
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.

(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

Agree.

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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.