How TOGAF
defines Enterprise Architecture (EA)
This page is
published under the terms of the licence
summarized in the footnote.
This is one of a pair of papers:
· How TOGAF define Enterprise Architecture
· What TOGAF says about architecture as description
Abstract
TOGAF is a management framework that features and promotes the role of architects.
It makes clear that its purpose is to support and enable EA.
However, it is often treated as a general purpose analysis and design method, and put to uses other than EA.
And so, people have come to confuse using being an analyst or designer with being an enterprise architect.
In practice, only a minority of TOGAF users are well-called enterprise architects.
EA defines enterprise-level principles, standards, patterns and high-level designs so as to do the things listed in the contents list below.
This paper is supported by other industry sources in the slide show above, and in this EA reference list.
Contents
TOGAF
positions EA as much more abstract than Solution Architecture
Enable
cross-organisational systemisation of a business
Encourage
integration and standardisation (reuse) of business processes
Align
information systems to business needs across the four primary architecture
domains
Define
a strategic context for business system changes
Abstract
architecture description from implementation
Organise
and maintain architecture descriptions for future understanding and change
impact analysis
The final chapter of TOGAF positions the enterprise architect as working at a much higher level than the solution architect working on one system.
It goes so far as to position “segment architects” between enterprise and solution levels.
|
|
has responsibility for
architectural design and documentation |
Often or may |
Focuses on |
|
Enterprise
Architect |
At a landscape and technical reference model level. |
lead a group of the Segment Architects and/or Solution Architects related to a given program. |
enterprise-level business functions required. |
|
Segment Architect |
For specific business problems or organizations. |
re-use the output from all other architects, joining detailed technical solutions to the overall architectural landscape. |
enterprise-level business solutions in a given domain, such as finance, human resources, sales, etc. |
|
Solution Architect |
At a system or subsystem level, such as management or security. |
shield the Enterprise/Segment Architect from the unnecessary details of the systems, products, and/or technologies. |
focus on system technology solutions; for example, a component of a solution such as enterprise data warehousing.” |
In practice, few enterprises are big enough to employ more than two levels of architect – often called enterprise and solution architects, sometimes given other titles.
Bear in mind that below the level of solution architect are various kinds of technical subject matter experts and detailed designer.
The TOGAF glossary distances EA from Solution Architecture.
“Physical elements in an enterprise architecture may still be considerably abstracted from Solution Architecture, design, or implementation views.”
And it defines Solution Architecture in relation to one business process or one project.
“A description of a discrete and focused business operation or activity and how IS/IT supports that operation.
A Solution Architecture typically applies to:
· a single project or project release,
· assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and
· a portfolio of implementation tasks.”
Phase H of TOGAF distances EA-level documentation from solution architecture change, even whole scale replacement.
“Some Solution Architectures may not lend themselves to be scalable by a large factor — say 10 — or alternative solutions may be more economic when scaled up.
While the architecture specifications may not change, the solutions or their operational context may change.”
EA emerged at the beginning of the information age in the 1970s.
Ross, Weill and Robertson say "companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes”.
Zachman says: “EA is the determinant of survival in the Information Age.”
EA has grown alongside the increasing digitisation and distribution of business systems, and the increasing need to integrate these systems.
It defines enterprise-level principles, standards, patterns, high-level designs and plans so as to do the following:
· Enable cross-organisational systemisation of a business
· Encourage integration and standardisation (reuse) of business processes
· Align information systems to business needs across the four primary architecture domains
· Define a strategic context for business system changes
· Abstract architecture description from implementation
· Organise and maintain architecture descriptions for future understanding and change impact analysis.
Zachman says EA is about cross-organisational integration and reuse.
TOGAF says: “EA regards the enterprise as a system, or system of systems.”
“the architecture crosses multiple systems, and multiple functional groups within the enterprise.”
“The purpose of EA is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated)
into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.”
Ross, Weill and Robertson (in "EA as Strategy") prompt EAs to position an enterprise’s “operating model” in a quadrant of a standardisation/integration grid.
|
“Operating model” types |
Low standardisation |
High standardisation |
|
High integration
|
Coordinated processes and systems |
Unified processes
and systems |
|
Low integration |
Diversified processes and systems |
Replicated processes
and systems |
TOGAF says: “The business operating model concept is useful to determine the nature and scope of the EA within an organization”…
“Conducting
EA [can be defined as] managing the spectrum
of change required to transform an enterprise towards a target operating model
[defined by] the necessary level of business process integration and business process standardization for delivering goods and services to customers.”
Given a target operating model, TOGAF says it is about “Holistic Enterprise Change” towards that target.
“Enterprise Architecture…can be considered as a superset of Business, Data, Application, and Technology Architecture.” (TOGAF)
“TOGAF has … become a framework for managing the entire spectrum of change required to transform an enterprise towards a target operating model.”
The “spectrum of change” spans the four primary architecture domains, business, data, applications and infrastructure technology.
It is common to divide architecture into four domains or views and three or four levels.
The four primary architecture domains have appeared in popular architecture frameworks since the PRISM paper of 1986.
Three levels are shown below, though TOGAF inserts a segment level between enterprise and solution.
|
Architecture Work Space |
||||
|
Domain/view Level |
Business |
Information Data |
Applications |
Infrastructure Platform |
|
Enterprise |
|
|
|
|
|
Solution |
|
|
|
|
|
Software/technology |
|
|
|
|
|
Operations |
|
|
|
|
EA has always been about optimisation of business system planning.
TOGAF says: “An EA [defines] a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.”
“An EA” is the enterprise’s architecture description, recorded some kind of architecture repository.
EA can be seen as general system theory to business systems.
A purposeful man-made activity system may be found in two forms, as a descriptive thing and as a described thing.
At design time, it is a system description that defines orderly process steps to be performed by performers cooperating in defined roles.
At run-time, it is an operational system, a collection of actors or performers that cooperate to perform transient process steps in an orderly fashion.
Grady Booch says “All architecture is design but not all design is architecture.
Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.”
In TOGAF, architecture definition is system description at an abstract level, capturing the essential design decisions that shape a system.
The thing described is not an "architecture" per se, it is an operational system (real or envisaged).
All operational systems have a structure and behaviour; but not all have an architecture.
If there are no architects, no decisions or high-level designs, then there is no architecture.
With no architecture description (not even a mental model), there is no architecture.
With no documented architecture description, there is no agreed architecture that can be used in governance and impact analysis.
Zachman says: “If you are not building (and storing, managing and changing) primitive models, you are not doing Architecture. You are doing implementations.”
TOGAF says: “The Architecture Landscape presents an architectural representation of assets in use, or planned, by the enterprise at particular points in time.”
“the architect is not the builder, and must remain at a level of abstraction necessary to ensure that they do not get in the way of practical implementation.”
“Physical elements in an enterprise architecture may still be considerably abstracted from Solution Architecture, design, or implementation views.”
“It is the responsibility of the architect to know and concentrate on the critical few details and interfaces that really matter, and not to become overloaded with the rest.”
“Service Orientation: A way of thinking in terms of services and service-based development and the outcomes of services.”
TOGAF’s development method concludes with “Architecture change management”.
This ensures that changes to operational systems are governed and recorded in abstract architecture definitions (or else rejected).
“A TOGAF architecture is based on:
· defining a number of architectural building blocks within architecture catalogs,
· specifying the relationships between those building blocks in architecture matrices, and then
· presenting communication diagrams that show in a precise and concise way what the architecture is.”
“It is necessary to provide a fully featured enterprise architecture metamodel for content.”
“Operating a mature Architecture Capability within a large enterprise creates a huge volume of architectural output. Effective management and leverage of these architectural work products require a formal taxonomy for different types of architectural asset alongside dedicated processes and tools for architectural content storage.”
EA is about holistically architecting the systems that support an enterprise’s business processes (not architecting one software or technology system).
It is about systemisation of business roles and processes, and business system planning.
It is about using information systems to standardise and integrate core business processes that cross business divisions.
EA aims for enterprise-wide alignment of business, data, information systems and infrastructure technology.
So, what is the EA manager accountable for?
Governance of the business systems portfolio, meaning:
· the business processes, the business data they create and use, and the systems that support them.
· the functional and non-functional qualities of those systems.
· more and better exploitation of information gathered by systems during business processes
· enterprise-wide optimisation of those business systems.
Also: principles, standards, patterns and high-level designs that
· enable cross-organisational systemisation of a business,
· encourage integration and reuse
· align the four primary architecture domains
· define a strategic context for business system changes.
Finally, the paper What is EA not? discusses what is an EA team not responsible for.
Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0 06/03/2015 16:34
Attribution: You may copy, distribute and display this copyrighted work
only if you clearly credit “Avancier Limited: avancier.website ” before the start and
include this footnote at the end.
No Derivative Works: You may copy, distribute, display only complete and verbatim
copies of this page, not derivative works based upon it.
For more information about the
licence, see http://creativecommons.org