An IBM view on EA

The following is based on my analysis of:
- http://www.it-director.com/technology/sys_mgmt/content.php?cid=11379&page=1
- http://download.boulder.ibm.com/ibmdl/pub/software/dw/wes/bpmjournal/0812_jensen/SOA_BPM_EA.pdf

The following is what I understand IBM's position to be. Comments in square brackets [] are mine (not IBM's). It is amazing when one looks at IBM's position one can only conclude that the tooling they offer is unsuited to the purpose.

EA models defines a context in which may be elaborated in more detailed models e g. ER Diagramming, UML, BP Modeller etc. EA needs to understand processes [and presumably rules/policies, information, services, etc.] irrespective of how they are implemented (by what, who, where and how). EA information needs to be able to used to lead to technology implementations. In the integrated scenario Architecture Plans (in EA) are handed downstream, either between companies in the supply chain or within a single entity, to the Build team that continues putting meat on the bones with eye towards product development" [and presumably we must allow that these implementation will be done in technologies from a variety of vendors i.e. so we will need a open way of transition for EA to technology specific tools].

• EA is about "Architecture for Planning"
• EA provides the ability to clearly communication strategies and objectives to the entire organization; and records how technology assets are used to run an enterprise.
• EA's real value comes with the ability to investigate multiple future architecture scenarios and understanding the impacts to assets, organization and process before making the changes.
[so an ability to deal with Iniatives, Scenarios and multiple possible futures is key].
• Enterprise Architect deals in abstractions and things that are always changing, use a generalised tool and are comfortable with "knowing something about everything" vs. Solution Architects (designers) who deal in specialist areas (BPM, SOA etc.) and use specialised tools oriented at engineering design (UML modellers, ER modeller, etc.) and are only happy when knowing "everything about something".
• EA is about "doing the right things", BPM is about "doing things right".

EA, SOA, BPM and are all of value, using all three together can produce the most value. To succeed in you must
• 1st and foremost: establish a collaborative platform supporting the critical dynamic interaction across the enterprise. [presumably this requires many different ways of communication to many in the enterprise]
• have a holistic approach shared by all involved roles, tailored to the culture and environment
• establish awareness amongst key stakeholders across the organization, and particularly look at how to engage the with the business people [which typically not mean forcing them to at technical oriented abstractions of complex models. Rather they will want interfaces, views, reports and visualisations that address their issues and interests]
• think through the lifecycle and how to execute your architectural framework
• be specific about your objectives and have an explicit and accepted governance model, recognise this will often require significant cultural shifts to ensure buy-in to a shared effective process of decision making [so focusing on decision making early would make sense e.g. what questions to be answered]
• enable collaboration through good communication and a sharing of work products, based on a common language, with an understanding of and empathy for roles other than your own
[create artefacts,interfaces, views, reports and visualisations suited to the audience]
• enable integration between enterprise planning and solution delivery across all planes of architecture [using open standards to avoid lock-ins and ensure transparency]

IBM now has one real EA modelling tools - System Architect. Rhapsody is about "Architecture for Building" and is about model-based systems and software design and development. [There are many other tools in with more detailed orientations (SPARX) and one should not see these as EA tools]

On EA in Government - also see:
http://www.govtech.com/gt/articles/698252?id=698252&full=1&story_pg=2

CIOs perform a balancing act between the need for new technology versus the need to contain costs, security versus collaborative processes and accessible data versus the need for business with IT strategies. To achieve this they must close the gap between business and IT by becoming a business executive first and a technologist second. They need to build a hybrid skill set that enables IT professionals to understand the business's needs [and one would have thought communicating effectively with the business i.e. not using abstract technical languages and frameworks].

EA addresses this balancing of business and IT strategies when properly implemented:
- achieve stronger alignment between IT strategy and business goals;
- align various platforms and technologies that have resulted in excessive complexity and cost;
- implement IT standards and governance that enable greater technology efficiencies;
- improve performance, availability, scalability and management of existing architectures and applications;
- support new business processes with new technologies; and
- adopt reusable assets to drive greater efficiencies and faster time to market.