This page is published under the terms
of the licence summarized in the footnote.
All
free-to-read materials on the Avancier web site are paid for out of income from
Avancier’s training courses and methods licences.
If
you find them helpful, please spread the word and link to the site in whichever
social media you use.
Contents
The
importance of abstract documentation
Solution
Architecture in TOGAF
TOGAF is
strongly service-oriented
Enterprise architecture is about architecting the enterprise, not architecting a tactical solution.
It is a strategic approach to cross-departmental integration and interoperability, with focus on “holistic enterprise change”, as the quotes from TOGAF 9 below indicate.
Chapter 1: the [enterprise] architecture crosses multiple systems, and multiple functional groups within the enterprise.
Chapter 1: The purpose of enterprise architecture 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.
Chapter 1: An enterprise architecture [provides] a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.
Chapter 2: [an advantage is] process, concept, and component re-use across all organizational business units
Chapter 6: The enterprise architecture provides a strategic, top-down view of an organization to enable executives, planners, architects, and engineers to coherently co-ordinate, integrate, and conduct their activities.
Chapter 16: The main purpose for the development of the enterprise architecture has been strategic direction and top-down architecture and project generation to achieve corporate capabilities.
Chapter 32: Enterprise architecture is … a horizontal function that looks at enterprise-level (as well as line of business-level) optimization and service delivery.
Chapter 42: [TOGAF’s] purpose … is to ensure that the various architecture descriptions… support the comparison and integration of architectures within and across architecture domains (business, data, application, technology), and relating to different business area scopes within the enterprise.
However, TOGAF blurs the distinction by hitching EA to use of its process for shorter-term business-driven work, so many of its readers now use the term EA for SA.
To this end, TOGAF borrows the operating model concept from Ross, Weill and Robertson.
Their book "EA as Strategy" prompts EAs to position an enterprise’s “operating model” in a quadrant of this grid.
|
An “operating model” for business processes and systems |
||
|
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 that conducting EA means
· “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 standardization.”
The “spectrum of change” covers all four architecture domains: business, IS (data + applications) and IT infrastructure.
TOGAF proposes a hierarchical, recursive approach to architecture development, suggesting two levels of decomposition.
· "Strategic Architecture: A summary formal description of the enterprise, providing an organizing framework for operational and change activity, and an executive-level, long-term view…."
· "Segment Architecture: A detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity."
· "Capability Architecture: A highly detailed description of the architectural approach to realize a particular solution or solution aspect..."
When EA gurus speak of “architecture”, they mean abstract architecture description, to be used in the management of enterprise systems.
Software systems are already documented in the form of executable program code, but this is unusable at an enterprise management level
John Zachman says: “If you are not building models, you are not doing Architecture. You are doing implementations.”
TOGAF says: “the EA is permanent and manages the EA artefacts delivered by projects.”
TOGAF includes many definitions that align architecture with system description, including these:
· "Enterprise: The highest level (typically) of description of an organization and typically covers all missions and functions."
· "Architecture: 1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation..."
· "Solution Architecture: A description of a discrete and focused business operation or activity and how IS/IT supports that operation, typically applies to a single project or project release..."
· "Application Architecture: A description of the structure and interaction of the applications as groups of capabilities that provide key business functions and manage the data assets."
Enterprise architects are expected typify an enterprise’s roles and processes in documentation.
EA favours abstract system descriptions - over very detailed documentation - to facilitate understanding and change management.
TOGAF says: "The Enterprise Architect has the responsibility for architectural design and documentation at a landscape and technical reference model level…
The primary output is an EA description that
is vendor-neutral and “considerably abstracted from solution architecture”.
Phase B says “Architecture Definition will not be intended to give detailed or comprehensive requirements for a solution.”
Even in Phase D, Technology Architecture, “Physical elements in an EA may still be considerably abstracted from Solution architecture”.
John Zachman's big point is this: if it ain’t documented, then the business doesn't know what it is and can't properly manage it.
You don’t need to be a fan of his framework to recognise John Zachman’s influence on EA today.
He was probably the first to publish papers on the need for enterprise-level and enterprise-wide analysis and documentation.
He set out to distinguish EA from the localised business process design and technical architecture that preceded EA.
In 1982, he wrote of the need for enterprise-level analysis.
In 1987, he introduced an enterprise-wide information system architecture framework.
In the mid-1990s, he converted his IS architecture framework into an EA framework
In 2003, he spoke of EA as “Enterprise Engineering”; and listed the 10 points he considers key to EA.
1. “If it gets so complex that you can’t remember everything… you have to write it down (Architecture).
2. Then, if you want to change it, you start with what you wrote down (Architecture), the baseline for managing change.
3. … The broader you define the analytical target, the better leverage you are going to get on integration, reusability, interoperability, etc…
4. If you draw the boundary more narrowly…, you will disintegrate your Enterprise, that is, you will build a “legacy.”
5. Once you get data … designed and implemented in a database, there is no way to change the meaning of the data.
6. You don’t have to build [all] models Enterprise-wide… However… whatever [models] you are not building… you are assuming risk of scrap and rework.
7. … you’d better pay attention to Enterprise-wide models in Columns 1, 3 and 6 [of his framework].
8. If you are not observing the engineering design principles…, you are not going to realize the objectives of alignment, integration, reusability, interoperability, flexibility, reduced time-to-market, etc.,
9. … you are never going to appreciably reduce time-to-market until you have something in inventory before you get the order.
10. If you are not building (and storing, managing and changing) primitive models, you are not doing Architecture. You are doing implementations.
From “The Zachman Framework For Enterprise Architecture: Primer
for Enterprise Engineering and Manufacturing.” By John A. Zachman. Copyright
2003 Zachman International
TOGAF has one phase (B) dedicated to Business Architecture.
It assumes knowledge of business architecture techniques and products.
(Structured analysis, business process models and business data models get less than one sentence each.)
In phases A to C, TOGAF expects business architects to play a solution-oriented role:
· identify stakeholders and their concerns
· define stakeholder viewpoints and value propositions.
· use business scenario analysis to define key business processes and roles.
· apply structured business analysis
· decompose business functions and business processes to elementary (OPOPOT) human activities.
· map activities to business roles, and roles to organisation units
· map activities to data entities and application components recorded in the architecture repository.
TOGAF is concerned more with the effective integration of human and computer activity systems.
And less with the most human aspects of an organisation: building facilities, management reporting structures, benefits packages, etc
Responsibility for designing the latter may lie with a parallel “business change" team, HR, business managers, etc.
Some have suggested a future version of TOGAF should present EA as independent of IT, even of information systems.
However, with 1,400 references to “application”, TOGAF’s implicit meta model is centred on the enterprise application portfolio.
TOGAF says this.
"Solution Architecture: A description of a discrete and focused business operation or activity and how IS/IT supports that operation, typically applies to a single project or project release..."
But says little more about solution architecture.
It says: "The Enterprise Architect .. often leads a group of the Segment Architects and/or Solution Architects related to a given program."
It indicates solution architecture starts in Phase E and is performed Phase G.
Phase E identifies “Solution Building Blocks which could potentially address one or more gaps and their associated architecture building blocks.”
Phase F plans the work to design and implement those solution building blocks.
Phase G says “Perform gap analysis on enterprise
architecture and solutions framework” which implies a clear EA/SA distinction
“The specific Solution Building Blocks required to fill these gaps will be the identified by the solutions architects.”
The EA/SA distinction became muddy in TOGAF version 9.
TOGAF 9 allowed that its process can be used at a project (or “capability”) level, and associated solution level artefacts with phases B to D.
In practice, many use TOGAF for project-level work, with little or no reference to a wider EA and leaving little or no EA documentation behind them.
Open system specifications are formed by defining the services a system should offer, leaving the structural organisation of components to the manufacturers.
A service encapsulates processes needed to
deliver the desired result, and is describable using a service
contract.
TOGAF considers the service-oriented view so fundamental that it places business and IS services in the Requirements Specification - outside of the Architecture Definition Document.
See this slide show for further details.