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 12, 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.
----------------------------------------------------------------------------------------------------------------------
