The Enterprise Architecture Definition Collection - Part II

This is Part II of my collection of enterprise architecture definitions. Part I can be viewed here.

It's interesting, at least to me, to get a sense for all the different definitions of enterprise architecture out there. So, over time, I will post other people's definitions of enterprise architecture (and their sources) as I run across them in the literature, blogs, and websites. Updated May 4, 2009.

----------------------------------------------------------------------------------------------------------------------

TOGAF defines "enterprise" as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.

The term "enterprise" in the context of "enterprise architecture" can be used to denote both an entire enterprise - encompassing all of its information and technology services, processes, and infrastructure - and a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise.

Confusion often arises from the evolving nature of the term "enterprise". An extended enterprise nowadays frequently includes partners, suppliers, and customers. If the goal is to integrate an extended enterprise, then the enterprise comprises the partners, suppliers, and customers, as well as internal business units.

The business operating model concept is useful to determine the nature and scope of the enterprise architecture within an organization. Large corporations and government agencies may comprise multiple enterprises, and may develop and maintain a number of independent enterprise architectures to address each one. However, there is often much in common about the information systems in each enterprise, and there is usually great potential for gain in the use of a common architecture framework. For example, a common framework can provide a basis for the development of an Architecture Repository for the integration and re-use of models, designs, and baseline data.

The Open Group, TOGAF Version 9 Enterprise Edition Overview. Full text can be viewed here. Thanks to Richard Veryard for the tip to include this. Posted May 4, 2009.

----------------------------------------------------------------------------------------------------------------------

One of the main differences between Enterprise Architecture and IT Architecture is the Business Architecture. The diagram below explains at a high level the purpose of each layer.

Among other activities, an Enterprise Architect will drive, supervise and review technology diagnosis and assessment activities. He will be an active member for the IT Strategy development, identify opportunities for technology-related improvement based on benchmark data and doing high-level cost benefit analysis-(Contribution to the overall alignment of IT delivery to the needs of the business). He will develop the enterprise architecture artifacts including current state architecture, target state architecture, architectural roadmaps, referential architecture patterns and technology standard. Also I recommend he acts as a solution architect during the pre-project and development phases of an IT program or oversight of future state designs including technology, solution, information and business architecture. Other activities are related to the access to the future state architecture for adherence to target state direction, or validate deviation justification and recovery plans.He may develop and implement training and documentation for enterprise architecture processes, procedures and framework, work with a team, coordinate, review and integrate the deliverables of information and technology architects into cohesive solutions architecture, taking into account the user requirements, technical requirements, etc.

Serge Thorn, in his blog, April 21, 2008. I suggest reading the entire excellent post for the complete context of his remarks. Tip of the hat to Mike Walker for the reference. Posted May 3, 2009.

----------------------------------------------------------------------------------------------------------------------

Enterprise Architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model.  Practitioners are called enterprise architects.

Definition of enterprise architecture from Wikipedia. Full citation can be viewed here. This definition originated from the MIT Center for Information Systems Research, Peter Weill, Director, as presented at the Sixth e-Business Conference, Barcelona Spain, 27 March 2007. Thanks to Nick Malik for suggesting this inclusion. Posted June 6, 2008.

----------------------------------------------------------------------------------------------------------------------

An enterprise architecture (EA) is a blueprint that describes an organization’s or a functional area’s current and desired state in both logical and technical terms, as well as a plan for transitioning between the two states. As such, it is a recognized tenet of organizational transformation and IT management in public and private organizations. Without an EA, it is unlikely that an organization will be able to transform business processes and modernize supporting systems to minimize overlap and maximize interoperability.

...

An enterprise can be viewed as either a single organization or a functional area that transcends more than one organization (e.g., financial management or homeland security). An architecture can be viewed as the structure (or structural description) of any activity. Thus, EAs are systematically derived and captured descriptions depicted in models, diagrams, and narratives.
More specifically, an architecture describes the enterprise in logical terms (such as interrelated business processes and business rules, information needs and flows, and work locations and users) as well as in technical terms (such as hardware, software, data, communications, security attributes, and performance standards). It provides these perspectives both for the enterprise’s current, or “as-is,” environment, and for its target, or “to-be,” environment, and it provides a transition plan for moving from the “as-is” to the “to-be” environment.

The importance of EAs is a basic tenet of both organizational transformation and IT management, and their effective use is a recognized hallmark of successful public and private organizations. For over a decade, we have promoted the use of architectures, recognizing them as a crucial means to a challenging end: optimized agency operations and performance. The alternative, as our work has shown, is the perpetuation of the kinds of operational environments that saddle many agencies today, in which the lack of integration among business operations and the IT resources that support them leads to systems that are duplicative, not well integrated, and unnecessarily costly to maintain and interface. Employed in concert with other important IT management controls (such as portfolio-based capital planning and investment control practices), architectures can greatly increase the chances that organizations’ operational and IT environments will be configured to optimize mission performance.

United States Government, Government Accountability Office, "DOD Business Systems Modernization:  Military Departments Need to Strengthen Management of Enterprise Architecture Programs" GAO-08-519, May 12, 2008. PDF abstract can be downloaded here, and the full version can be downloaded here.

----------------------------------------------------------------------------------------------------------------------

The problem is that sometimes its hard to spot the difference between the prat who doesn't understand and is diminishing the importance of technology and the superlative architect who is diminishing the importance of technology because he knows what needs to be delivered but has to get everyone else bought in.

Steve Jones, in his blog, April 4, 2008

----------------------------------------------------------------------------------------------------------------------

An Enterprise Architecture consists of the vision, principles, standards and processes that guide the purchase, design and deployment of technology within an enterprise. An Enterprise Architecture describes the interrelationships between business processes, information, applications and underlying infrastructure for that enterprise, and provides best practices for technology purchase, design and deployment.

Enterprise Architecture structures and processes govern adherence to an organization’s technology strategy and provide a managed environment for the introduction of new technology.

CoBiT Expert, September 11, 2007

----------------------------------------------------------------------------------------------------------------------

In user-centric EA, the impact of mechanistic organizations and bureaucracy is recognized as an impediment to change and growth of the enterprise, the ability of the organization to meet its full operating potential, and the valuation of its people as its greatest asset. EA is dedicated though to unleashing human capability and building a better organization for the future.

How does EA do this? By capturing and analyzing the as-is environment, and formulating a to-be environment and transition plan, EA not only shows the organization where its gaps, redundancies and inefficiencies are, but also facilitates a proactive solution to resolving them.

Further, EA provides two valuable assets to facilitate organizational change. The first is that EA provides business and technical information to all levels of the organization. This information can be used to enable decision-making by all. Secondly, EA provides a mechanism for governance, so that there is a structure and process for enterprise decisions to get made across traditional stovepipes.

By envisioning what could be, rather than just what is, EA challenges the status quo (even a highly mechanistic one) and continues to chip away at it, slowly but surely—working to eliminate stovepipes, build integration, interoperability, information sharing, and an open environment where people can innovate, create, and truly contribute to its success.

Andy Blumenthal, in his blog, August 10, 2007

----------------------------------------------------------------------------------------------------------------------

...The final point of discussion was around the role of education in Enterprise Architecture. The panelists all agreed that experience was a critical factor, and that you can’t teach experience, however there are aspects that can be taught. One panelist gave the example of a course on TOGAF. The one subject that didn’t come up in this or the discussion around the career path to EA was the ability to be a big picture thinker. For me, this is a must have for anyone in the EA role. Enterprise architecture is about the enterprise.  If you can’t see the forest for the trees, you’re going to struggle.

Todd Biske, in his blog, June 12, 2007.

----------------------------------------------------------------------------------------------------------------------

An enterprise architecture is a blueprint that describes the current and desired state of an organization or functional area in both logical and technical terms, as well as a plan for transitioning between the two states. Enterprise architectures are a recognized tenet of organizational transformation and IT management in public and private organizations. Without an enterprise architecture, it is unlikely that an organization will be able to transform business processes and modernize supporting systems to minimize overlap and maximize interoperability.

United States Government, Government Accountability Office, "Enterprise Architecture: Leadership Remains Key to Establishing and Leveraging Architectures for Organizational Transformation," August 2006. An abstract of the work (with links to the full version) can be viewed and/or downloaded here. Posted February 10, 2007.

----------------------------------------------------------------------------------------------------------------------

Enterprise Architecture should never be the goal, it should aim to guide and steer and help to select the good from the bad. This should not be done against some grand IT or technology vision but should be done against the business value that elements will derive. The reality is that this will change significantly over a 5 year period, let alone more, and so any decisions that are made today on the basis of progression towards the mythical enterprise architecture are going to be an increased burden which is done to achieve something that won't happen.

Note here I'm talking about enterprise architecture. If you have a 5 year programme of work to deliver against a new business area or goal than that is fine, because that isn't an enterprise thing, its a solution thing.

Enterprise Architecture isn't a goal, in the same way as IT strategy isn't a goal, the point is that the business changes and IT needs to adapt in line with the business and someone needs to herd the cats to make things consistent. This is why the key skills in EA are not the creation of big documents that try and define some vague future but the ability to influence people and to help them reach the right choice for their current solution that also makes sure that the next thing down the line isn't going to be screwed.

Steve Jones in his blog, January 31, 2007. Updated January 31.2007.

----------------------------------------------------------------------------------------------------------------------

Comments

[John Wu]

I like to add a definition of EA. The Light Enterprise Architecture www.liteea.com suggest that EA is the effort to see the holistic enterprise and understand how it works. EA is the effort to enable agile and simple automation solution. Read the following link for more detail on

http://blogs.ittoolbox.com/cio/lea/archives/another-round-of-what-is-ea-19727