[¤3] Overview ADM Cycle Adapting the ADM Architecture Scope Architecture Integration Infrastructure Architecture Summary
(w_stahlecker) Append: 'The ADM is the result of continuous contributions
from a large number of architecture practitioners.'
(hd_trestini) Replace sentence with:
'The TOGAF Architecture Development Method (ADM) is the
result of continuous contributions from a large number of
architecture practitioners. It describes a methodology
for developing an enterprise architecture, and
forms the core of TOGAF. It integrates elements of TOGAF
as well as other available architectural assets, to meet
the business and information technology needs of an
organization.
[¤5] The TOGAF Architecture Development Method (ADM) forms the core of TOGAF. It is a
method for developing an enterprise architecture to meet the business and information
technology needs of an organization, utilizing the other
elements of TOGAF described in this document, and other architectural assets available to
the organization.
(a_bodor) Removve the title line
[¤7] TOGAF consists of three main parts:
(m_iacob) Remove this part. Instead a 'The ADM and the Resource base'
would be more than welcome.
[¤8] TOGAF consists of three main parts:
(hd_trestini) Re-write:
'The ADM describes the process of moving from the TOGAF
Foundation Architecture to an enterprise-specific
architecture (or set of architectures). It leverages the
elements of the TOGAF Foundation Architecture, as well as
other relevant architectural assets, components, and
building blocks along the way.'
[¤15] The TOGAF ADM describes the process of moving from the TOGAF Foundation Architecture to
an enterprise-specific architecture (or set of architectures), leveraging the elements of
the TOGAF Foundation Architecture and other relevant architectural assets, components, and
building blocks along the way.
(hd_trestini) Re-write:
'The TOGAF Foundation Architecture is not the only
resource available to an architect in using the ADM. There
is a wide range of architectural models, components, and
building blocks (relating to different technology
domains), that an architect will seek to leverage. This
much wider context is referred to in TOGAF as the
Enterprise Architecture Continuum, and is explained in
detail in Part III.'
[¤16] The TOGAF Foundation Architecture is not the only resource available to the architect
in using the ADM. There is a wide range of architectural models, components, and building
blocks relating to different architecture domains that the architect will seek to
leverage. This much wider context is referred to in TOGAF as the Enterprise
Architecture Continuum, and is explained in detail in Part III.
(hd_trestini) Re-write:
'The practical implementation of the Enterprise
Architecture Continuum will often take the form of a
repository that includes reference architectures, models,
as well as patterns that have been accepted for use within
the enterprise, and/or actual architectural work done
previously within the enterprise. The architect would seek
to reuse as much as possible from the Continuum that was
relevant to the project at hand. In addition to the
collection of architecture source material, the repository
would also contain architecture development work currently
in-progress.
[¤17] The practical implementation of the Enterprise Architecture Continuum
will often take the form of a repository that includes reference architectures, models and
patterns that have been accepted for use within the enterprise, and actual architectural
work done previously within the enterprise. The architect would seek to reuse as much as
possible from the Continuum that was relevant to the project at hand. (In addition to the
collection of architecture source material, the repository would also contain architecture
development work-in-progress.)
[¤18] The criteria for including source materials in an organization's Enterprise Architecture Continuum will typically form part of the organization's IT governance process.
(hd_trestini) Remove ',if you like'.
[¤19] The Enterprise Architecture Continuum is thus a framework (a
"framework-within-a-framework", if you like) for categorizing architectural
source material – both the contents of the architecture working repository, and the
set of relevant, available reference models in the industry.
(hd_trestini) Remove:
'-- including, but not limited to, the resultant
enterprise-specific architecture'.
[¤20] In executing the ADM, the architect is not only developing the end result of an
organization-specific architecture, s/he is also populating the organization's own
Enterprise Architecture Continuum, with all the architectural assets identified and
leveraged along the way -- including, but not limited to, the resultant
enterprise-specific architecture.
[¤21] Architecture development is an iterative, on-going process, and in executing the ADM repeatedly over time, the architect gradually populates more and more of the organization's Enterprise Continuum. Although the primary focus of the ADM is on the development of the enterprise-specific architecture, in this wider context the ADM can also be viewed as the process of populating the enterprise's own Enterprise Continuum with relevant reusable building blocks.
(hd_trestini) Add to end of the previous paragraph and re-write:
'In fact, the first execution of the ADM will often be the
hardest, since the architectural assets available for re-
use will be relatively few. Even at this stage of
development however, there will be architecture assets
available from external sources such as TOGAF, as well as
the IT industry at large that could be leveraged in
support of the effort.
Subsequent executions will be easier, as more and more
architecture assets become identified; are used to
populate the organization's Enterprise Continuum; and are
thus available for future re-use.'
[¤22] In fact, the first execution of the ADM will often be the hardest, since the
architectural assets available for re-use will be relatively few. (Even in the first
execution, however, there will be architecture assets available, from external sources
such as TOGAF and the IT industry at large.) Subsequent executions will be easier, as more
and more architecture assets become identified, are used to populate the organization's
Enterprise Continuum, and are thus available for re-use.
(hd_trestini) Re-write:
'The ADM is also useful to populate the Foundation
Architecture of an enterprise. Business requirements may
identify the necessary definitions and selections in the
Foundation Architecture, including: a set of re-usable
common models; policy and governance definitions; or even
as specific as overriding technology selections (e.g. if
mandated by law). Population of the Foundation
Architecture follows similar principles as for an
Enterprise Architecture, with the difference that
requirements for a whole enterprise are restricted to the
overall concerns of the organization, and as such, are
less complete than those for a specific enterprise.'
[¤23] The ADM is also useful to populate the Foundation Architecture of an enterprise.
Business requirements of an enterprise may be used to identify the necessary definitions
and selections in the Foundation Architecture. This could be a set of re-usable common
models, policy and governance definitions, or even as specific as overriding technology
selections (e.g. if mandated by law). Population of the Foundation Architecture follows
similar principles as for an Enterprise Architecture, with the difference that
requirements for a whole enterprise are restricted to the overall concerns and thus less
complete than for a specific enterprise.
[¤24] It is important to recognize that existing models from these various sources may not necessarily be integratable into a coherent enterprise architecture. "Integratability" of architecture descriptions is considered below, under Architecture Integration.
[¤27] The following are the key points about the ADM:
[¤40] These issues are considered in detail under Adapting the ADM below.
[¤41] In addition to the method itself being iterative, there is also iteration within the ADM cycle, both among the individual phases and among the steps within each phase.
[¤43] The basic structure of the ADM is shown in Figure 1.
(hd_trestini) Re-write:
'Throughout the ADM cycle, there needs to be frequent
validation of gained results, against the original
expectations for a particular phase of the process. This
continuous validation against requirements, as depicted in
Figure 1, assures that the architecture is meeting the
needs of the business.'
[¤44] Throughout the cycle there needs to be frequent validation of the results against the
original motivation to take the architecture through a new cycle. This continuous
validation against requirements, as depicted in Figure 1, assures that the architecture is
meeting the needs of the business.
(chris_blake) make bubbles bigger and change font for readability
(kirank) 1. The iterative nature of the process should be emphasized
by showing birectional arrows between the bubbles.
2. Make bubbles clickable leading to the appropriate phase
of ADM.
(c_greenslade) Name of Phase H in the diagram should be Architecture
Change Management. This comment applies to almost every
occurrence of the ADM diagram.
[¤45] 
[¤46] Figure 1: Architecture Development Cycle
(hd_trestini) Re-write:
'The phases of the ADM cycle shown in Figure 1, are
further divided into steps, such as the ones depicted by
the expansion of the Technology Architecture phase in
Figure 2.'
[¤47] The phases of the cycle shown in Figure 1 are further divided into steps, such as
depicted in the expansion of the Technology Architecture phase in Figure
2.
[¤49] Figure 2: Architecture Development Cycle - Expansion
[¤50] The phases of the cycle are described in detail in the following subsections. Phase D, the creation of a Technology Architecture, is described in even greater detail in a separate section, Target Architecture - Detailed Description.
[¤51] Note that output is generated throughout the process, and that the output in an early phase may be modified in a later phase. The versioning of output is managed through version numbers.
(hd_trestini) Re-write:
'The ADM is a generic method for architecture development
which was designed to deal with most system and
organizational requirements. However, it will often be
necessary to modify or extend the ADM, to suit specific
organizational needs. One of the tasks before applying the
ADM to a specific situation is to review its components
for applicability, and then tailor them as appropriate to
the circumstances of the individual enterprise. This
activity may well produce an 'enterprise-specific' ADM.'
[¤53] The ADM is a generic method for architecture development, which is designed to deal
with most system and organizational requirements. However, it will often be necessary to
modify or extend the ADM to suit specific needs. One of the tasks before applying the ADM
to a specific situation will be to review the ADM and tailor it if necessary to the
circumstances of the enterprise concerned. This activity may well produce an
enterprise-specific ADM.
(hd_trestini) Re-wite:
'One reason for wanting to adapt the ADM, which it is
important to stress, is that the order of the phases in
the ADM is to some extent dependent on the maturity of the
architecture discipline within the enterprise concerned.
For example, if the business case for creating an
architecture in the first place is not well recognized,
then creating an Architecture Vision first, is almost
always essential. In this case, a detailed Business
Architecture often needs to come next, in order to
underpin the Architecture Vision; detail the business case
for remaining architecture work; and secure the active
participation of key stakeholders in that work. In other
cases, a slightly different order may be preferred. For
example, a detailed inventory of the baseline environment
may be done before undertaking the Business Architecture.'
[¤54] One reason for wanting to adapt the ADM, which it is important to stress, is that the
order of the phases in the ADM is to some extent dependent on the maturity of the
architecture discipline within the enterprise concerned. For example, if the business case
for doing architecture at all is not well recognized, then creating an Architecture Vision
is almost always essential; and a detailed Business Architecture often needs to come next,
in order to underpin the Architecture Vision, detail the business case for remaining
architecture work, and secure the active participation of key stakeholders in that work.
In other cases a slightly different order may be preferred: for example, a detailed
inventory of the baseline environment may be done before undertaking the Business
Architecture.
(chris_blake) .... Business Architecture (or at least the completion of
it) may well follow completion of the Information Systems
Architecture or Technology Architecture
(hd_trestini) Re-write:
'The order of phases may also be defined by the business
and architectural principles of an enterprise. For
example, the business principles may dictate that the
enterprise be prepared to adjust its business processes to
meet the needs of a packaged solution, so that it can be
implemented quickly to enable fast response to market
changes. In such a case, the Business Architecture (or at
least the completion of it) may well follow completion of
the Information Systems Architecture or the Technology
Architecture.'
[¤55] The order of phases may also be dictated by the business and architectural principles
of the enterprise: for example, the business principles may say that the enterprise is
prepared to adjust its business processes to the needs of a packaged solution that can be
implemented quickly to enable fast response to market change; and in such a case the
Business Architecture (or at least the completion of it) may well follow completion of the
Technology Architecture.
(hd_trestini) Re-write:
'Another reason for wanting to adapt the ADM is when TOGAF
would have to be integrated with another enterprise
framework (as explained in Part I, TOGAF in the
Enterprise). For example, an enterprise may wish to use
TOGAF and its generic ADM in conjunction with the well-
known Zachman Framework, or similar enterprise
architecture framework that has a defined set of
deliverables specific to a particular vertical sector:
Government, Defense, e-Business, Telecommunications, etc.
The ADM has been specifically designed with this potential
integration in mind.'
[¤56] Another reason for wanting to adapt the ADM is if TOGAF and its ADM are to be
integrated with another enterprise framework, as explained in Part I, TOGAF in the Enterprise. For example, an
enterprise may wish to use TOGAF and its generic ADM in conjunction with the well-known
Zachman Framework, or another enterprise architecture framework with a defined set of
deliverables specific to a particular vertical sector, such as Government, Defense,
e-Business, Telecommunications, etc. The ADM has been specifically designed with this
potential combinative use in mind.
[¤57] Other possible reasons for wanting to adapt the ADM include:
(kirank) There are several key issues here:
[¤68] There are four key issues here:
[¤75] These aspects are explored in detail below. In each case, particularly in large-scale environments where architectures are necessarily developed in a federated manner, there is a danger of architects optimizing within their own scope of activity, instead of at the level of the overall enterprise. It is often necessary to sub-optimize in a particular area, in order to optimize at the entrprise level. The aim should always be to seek the highest level of commonality and focus on scalable and reusable modules in order to maximize re-use at the enterprise level.
[¤77] One of the key decisions is the focus of the architecture effort, in terms of the breadth of overall enterprise activity to be covered (which specific business sectors, functions, organizations, geographical areas, etc.).
(chris_blake) One important factor in this context is the increasing
tendency for large-scale architecture developments to be
undertaken in the form of 'federated architectures' -
independently developed, maintained and managed
architectures that are subsequiently integrated within a
meta architectural framework that specifies the principles
for interoperablity, migration and conformance thereby
allowing specific business units to have architectures
developed and governed as stand-alone architecture
projects.
[¤78] One important factor in this context is the increasing tendency for large-scale
architecture developments to be undertaken in the form of "federated
architectures" - independent development and subsequent integration of architectures
in projects that individually address less than all four domains of the enterprise
architecture space, and are developed and approved as stand-alone architecture projects,
possibly by different architecture personnel, and are then integrated as a separate
activity.
[¤79] Complex architectures are extremely hard to manage, not only in terms of the architecture development process itself, but also in terms of getting buy-in from large numbers of stakeholders. This in turn requires a very disciplined approach to identifying common architectural components, and management of the commonalities between federated components – deciding how to integrate, what to integrate, etc.
[¤80] There are two basic approaches to federated architecture development:
[¤83] The US government, and in particular the US Department of Defense, has undertaken and published leading work in the field of federated architectures, emphasizing the need for integrated repositories and metamodels to aid integration and ensure interoperability. This work is very much at the leading edge of the state of the art, however, and what works in practice is still very much a matter of debate.
[¤84] The Introduction section in the Federal Enterprise Architecture Framework published by the US Federal CIO Council explains the choices in approach that faced the US government in the development of the Federal Enterprise Architecture Framework (FEAF):
[¤85] "In developing the Federal Enterprise Architecture Framework, the CIO Council evaluated three approaches.
- [¤86] Conventional Approach - Requires a substantial initial investment in time and dollars. First, a framework must be developed that shows how to prepare an architecture description. Second, the current baseline must be described. Finally, a target architecture must be described. Only after these activities are completed, implementing needed architecture changes through design, development, and acquisition of systems can begin. Although this approach appears to be sound, it may result in "paralysis by analysis," because of the complexity of the Federal effort.
- [¤87] Segment Approach - Promotes the incremental development of architecture segments within a structured enterprise architecture framework. This approach focuses on major business areas (e.g., grants or common financial systems) and is more likely to succeed because the effort is limited to common functions or specific enterprises.
- [¤88] Status Quo Approach - Represents business as usual resulting in continued failure to share information and cope with the rapidly changing environment. This approach would result in business rework, decreased productivity, and lost and missed opportunities, as well as failure to comply with Clinger-Cohen Act requirements.
[¤89] .....To mitigate the risk of overreaching with minimal returns, curtail startup costs for a conventional architecture, and realize returns quickly, the CIO Council selected the segment approach.......
[¤90] The Federal Enterprise Architecture Framework allows critical parts of the overall Federal Enterprise, called architectural segments, to be developed individually, while integrating these segments into the larger Enterprise Architecture."
[¤91] The FEAF approach thus seeks to do a "complete" enterprise architecture across a succession of selected individual business domains (or segments), and then to integrate these into a more comprehensive, overarching enterprise architecture.
[¤92] Conversely, the "Practical Guide to Federal Architecture", also issued by the US Federal CIO Council, highlights the dangers of selecting too narrow an enterprise scope, particularly at the higher business levels:
[¤93] It is critically important that EA development be approached in a top-down, incremental manner, consistent with the hierarchical architectural views that are the building blocks of proven EA frameworks.... In doing so, it is equally important that the scope of the higher level business views of the EA span the entire enterprise or agency. By developing this enterprise-wide understanding of business processes and rules, and information needs, flows, and locations, the agency will be positioned to make good decisions about whether the enterprise, and thus the EA, can be appropriately compartmentalized. Without doing so, scoping decisions about the EA run the risk of promoting "stove-piped" operations and systems environments, and ultimately sub-optimizing enterprise performance and accountability. "A Practical Guide to Federal Architecture", Chief Information Officer Council, Version 1.0, February 2001.
[¤94] Current experience does seem to indicate that, in order to cope with the increasingly broad focus and ubiquity of architectures, it is often necessary to have a number of different architectures existing across an enterprise, focused on particular time frames, business functions, or business requirements; and this phenomenon would seem to call into question the feasibility of a single enterprise-wide architecture for every business function or purpose. In such cases, the paramount need is to manage and exploit the 'federations' of architecture. A good starting point is to adopt a publish-and-subscribe model that allows Architecture to be brought under a governance framework. In such a model, architecture developers and architecture consumers in projects (the supply and demand sides of Architecture work) sign up to a mutually beneficial framework of governance that ensures that:
[¤95] 1. architectural material is of good quality, up to date, fit for purpose, and published (reviewed and agreed to be made public).
[¤96] 2. usage of architecture material can be monitored, and compliance with standards, models, and principles can be exhibited, via
[¤99] Publish and subscribe techniques are being developed as part of general IT governance and specifically for the Defense sphere."
[¤101] A complete enterprise architecture should address all four architecture domains (business, data, applications, technology), but the realities of resource and time constraints often mean there is not enough time, funding, or resources to build a top-down, all-inclusive architecture description encompassing all four architecture domains.
[¤102] Architecture descriptions will normally be built with a specific purpose in mind - a specific set of business drivers that drive the architecture development - and clarifying the specific issue(s) that the architecture description is intended to help explore, and the questions it is expected to help answer, is an important part of the initial phase of the ADM.
[¤103] For example, if the purpose of a particular architecture effort is to define and examine technology options for achieving a particular capability, and the fundamental business processes are not open to modification, then a full business architecture well may not be warranted. However, because the data, applications and infrastructure architectures build on the business architecture, the business architecture still needs to be thought through and understood.
(chris_blake) While circumstances may sometimes dictate building an
architecture description not containing all four
architecture domains, it should be understood that such an
architecture can not, by definition, be complete. The
risks and trade-offs involved in not developing a complete
architecture need to be articulated by the architect, and
communicated to and understood by the enterrpise
management.
[¤104] While circumstances may sometimes dictate building an architecture description not
containing all four architecture domains, it should be understood that such an
architecture can not, by definition, be an integrated architecture. Integration either
needs to come later, with its own costs and risks, or the risks and trade-offs involved in
not developing an integrated architecture need to be articulated by the architect, and
communicated to and understood by the enterrpise management.
[¤106] Care should be taken to judge the appropriate level of detail to be captured, based on the intended use of the Enterprise Architecture and the decisions to be made based on it. It is important that a consistent and equal level of depth be completed in each architecture domain (business, data, applications, infrastructure) included in the architecture effort. If pertinent detail is omitted, the architecture may not be useful. If unnecessary detail is included, the architecture effort may exceed the time and resources available, and/or the resultant architecture may be confusing or cluttered.
[¤107] It is also important to predict the future uses of the architecture so that, within resource limitations, the architecture can be structured to accommodate future tailoring, extension, or reuse. The depth and detail of the Enterrpise Architecture needs to be sufficient for its purpose, and no more.
[¤108] John Zachman advocates developing enterprise-wide architecture at an enormous level of detail, in the same way as an aerospace company needs blueprints for everything down to nuts and bolts. Some regard this is an extreme position in terms of vertical scope, but it can certainly be justified when compared with the lifetime costs of alternatives. Zachman’s argument is that information systems are not special. In other industries where very expensive, complex things are built, and where there is an expectation of repair or change, models are kept at an enormous level of detail, with concurrent expense. Aeroplanes, buildings, and cars are built this way. Why are information systems different?
[¤109] However, it is not necessary to aim to complete a detailed architecture description at the first attempt. Future iterations of the Architecture Development Method, in a further architecture life-cycle, will build on the artefacts and the comptencies created during the current iteration.
[¤110] The bottom line is: there is a need to document all the models in an enterprise, to whatever level of detail is affordable, within an assessment of the likelihood of change and the concomitant risk, and bearing in mind the need to integrate the components of the different architecture domains (business / data / applications / infrastructure). The key is to understand the status of the enterprise's architecture work, and what can realistically be achieved with the resources and competences available, and then focus on identifying and delivering the value that is achievable. Stakeholder value is a key focus: too broad a scope may deter some stakeholders (no RoI).
[¤112] The ADM is described in terms of a single cycle of architecture vision, and a set of target architectures (business, data, applications, technology) that enable the implementation of the vision.
[¤113] However, when the enterprise scope is large, and/or the target architectures particualrly complex, the development of target architecture descriptions may encounter major difficulties, or indeed prove "mission impossible", especially if being undertaken from scratch.
[¤114] In such cases, a wider view may be taken, whereby an enterprise is represented by several different architecture instances, each representing the enterprise at a particular point in time. One architecture instance will represent the current enterprise state (the "as-is", or baseline). Another architecture instance, perhaps defined only partially, will represent the ultimate target end-state (the "vision"). Inbetween, intermediate or "transitional" architecture instances may be defined, each comprising its own set of target architecture descriptions.
[¤115] By this approach, the target architecture work is split into two or more discrete stages:
[¤118] In such an approach, the Target Architectures are evolutionary in nature, and require periodic review and update according to evolving business requirements and developments in technology, whereas the Transitional Architectures are (by design) incremental in nature, and in principle should not evolve during the implementation phase of the increment, in order to avoid the "moving target" syndrome. This of course is only possible if the implementation schedule is under tight control and relatively short (typically less than two years).
[¤119] The Target Architectures remain relatively generic, and because of that are less vulnerable than the Transitional Architectures to obsolescence. They embody only the key strategic architectural decisions, which should be blessed by the stakeholders from the outset, whereas the detailed architectural decisions in the Transitional Architectures are deliberately postponed as far as possible (i.e. just before implementation) in order to improve responsiveness vis-à-vis new technologies and products.
[¤120] The enterprise evolves by migrating to each of these Transitional Architectures in turn. As each Transitional Architecture is implemented, the enterprise achieves a consistent, operational state on the way to the ultimate vision. However, this vision itself is periodically updated to reflect changes in the business and technology environment, and in effect may never actually be achieved, as originally described. The whole process continues for as long as the enterprise exists and continues to change.
[¤121] Such a breakdown of the architecture description into a family of related architecture products of course requires effective management of the set and their relationships.
[¤123] As described above, a significant number of scoping decisions need to be taken, in terms of enterprise focus, architecture scope, level of detail, and time horizon and choice of transitional archiectures, any one of which may result in less than a complete, integrated architecture description being developed.
[¤124] It is important to realize that any such decision has as a corollary in the need to address "integratability" - the readiness of the architecture description for integration with other, related architecture descriptions.
[¤125] There are varying degrees of architecture description “integratability.” At the low end, integratability means that different architecture descriptions (whether prepared by one organizational unit or many) should have a “look and feel” that is sufficiently similar to enable critical relationships between the descriptions to be identified, thereby at least indicating the need for further investigation. At the high end, integratability means that different descriptions should be capable of being combined into a single logical and physical representation.
[¤126] For the immediately foreseeable future, the state of the art is such that architecture integration can probably be accomplished only at the lower end of the integratability spectrum.
[¤127] As organizations address common themes (such as web services, and integrated information infrastructure), and universal data models and standard data structures emerge, integration toward the high end of the spectrum will be facilitated. However, it is debatable whether “plug-and-play” integration will ever be achievable without the need for some level of manual coordination and “deconfliction,” simply because different organizations tend to have unique understandings of how they interact with each other.
[¤130] Infrastructure is a term commonly encountered in the architecture field, but it is a term that means different things to different people.
[¤131] For many people, the term infrastructure architecture connotes the architecture of the low level hardware, networks, and system software (sometimes called "middleware") that supports the applications software and business systems of an enterprise. This connotation also holds true in TOGAF, but in TOGAF, infrastructure has a wider connotation. In particular, it denotes that part of an overall enterprise architecture that is common, or shared, across the enterprise, as opposed to being specific to particular organizational units (e.g., business departments).
(w_stahlecker) Prepend paragraph: 'In this sense the Infrastructure
Architecture is an essential definition in
achieving 'boundaryless information flow' across an
enterprise's scope. With progress towards aggregation of e-
services the content of an Infrastructure will expand above
today's delineation'
[¤132] These common or shared elements typically include a lot of the low level hardware,
networks, and system software in an enterprise; but they also increasingly include
software at the applications level that provides application-level services across the
enterprise. These "infrastructure applications" are distinct from business
applications in that they are primarily concerned with providing common services rather
than directly executing business application logic. Web services (something of a misnomer)
are an example of infrastructure applications that are attracting increasing attention,
and represent the main focus of enterprise architecture effort for many enterprises today.
[¤133] In addition to "infrastructure applications", the infrastructure may also include data that is common or shared, and also elements of the Business Architecture that are common across the enterprise - common business principles, standards for performing common business processes, etc.
[¤134] An Infrastructure Architecture in TOGAF terms is thus something orthogonal to the main architecture domains addessed by TOGAF's Architecture Development Method - Business Architecture, Data Architecture, Applications Architecture, and Technology Architecture. The description of the ADM does not specifically call out the stages at which an infrastructure architecture is defined. However, the ADM is perfectly compatible with such an approach. The development of an Infrastructure Architecture using the ADM is summarized briefly below.
[¤136] The previous sections have explained how in practice an enterprise architecture may need to have a scope that is less than that of the entire enterprise, both because of the sheer scale of some enterprises, and because of the need to limit the scope of the architecture effort to something that is achievable and will return value to the enterprise within the timescales, resources, and competencies available to the Architecture function.
[¤137] What this means in practice is that many large enterprise architecture efforts will not seek to cover every single organizational unit / department in the logical enterprise, but will focus initially on a small number of key organizational units / departments. This ususally means prioritizing the business units within an enterprise, and addressing only the high-priority units when undertaking the enterprise architecture initially. The intent would be for later iterations of the enterpise architecture to expand the scope of enterprise coverage, reusing architecture assets from the enterprise's Enterprise Continnuum that had been developed in previous iterations of the architecture development cycle.
[¤138] The enterprise architecture would then be developed primarily by ADM phase (e.g., Business Architecture first, Information Systems Architecture next, etc.); and within each phase, by organizational unit / department, in priority order.
[¤139] For example, the Business Architecture (baseline plus target) for the Manufacturing Department might come first, if Manufacturing were deemed the highest priority, followed by the Business Architecture for the Finance Department, if that were deemed next highest priority, followed by the Business Architecture for the Human Resources Department, ....etc. Next would come the Data Architecture (baseline plus target) for the Manufacturing Department, followed by the Data Architecture for the Finance Department, ....etc. (The order of Data and Applications Architecture may be reversed, depending on the approach preferred.)
[¤140] In executing the ADM for each organizational unit within each Phase, the Architect would distinguish between those elements that are specific to the organizational unit concerned, and those that are enterprise-wide or "infrastructure".
[¤141] In this approach to enterprise architecture, the "infrastructure architecture" is not developed as an "architecture" in its own right, like the Business Architecture or the Data Architecture, but emerges from all four architecture domains as a statement of what in each domain is common or shared across the enterprise.
[¤142] The following graphic is intended to clarify this approach.
[¤144] Figure 3: Developing an Infrastructure Architecture Using the ADM
[¤146] The TOGAF ADM defines a recommended sequence for the various phases and steps involved in developing an architecture, but it cannot recommend a scope: this has to be determined by the orgnization itself, bearing in mind that the recommended sequence of development in the ADM process is an iterative one, with the depth and breadth of scope and deliverables increasing with each iteration. Each iteration will add resources to the organization's Architecture Continuum.
[¤147] The choice of scope is critical to the success of the architecting effort. The key factor here is the sheer complexity of a complete, horizontally and vertically integrated enterprise architecture, as represented by a fully populated instantiation of the Zachman Framework. Very few enterprise architecture developments today actually undertake such an effort in a single development project, simply because it is widely recognized to be at the limits of the state of the art, a fact that John Zachman himself recognizes:
[¤148] "Some day, you are going to wish you had all these models ... However, I am not so altruistic to think that we have to have them all today ... or even that we understand how to build and manage them all today. But the very fact that we can identify conceptually where we want to get SOME day, makes us think more about what we are doing in the current time frame that might prevent us from getting to where we want to go in the future." John Zachman, in email correspondence to George Brundage.
(chris_blake) John Zachman himself likes to point out the alternatives
available to those who can't countenance the amount of
work implied in developing the all models required in his
framework. There are only three choices: trial and error
starting from new; or reverse engineering the architecture
from the existing systems; all of which are risky and/or
hugely expensive. What is necessary due to the pace of
change is to have a set of readily deployable artifacts
and a process for assembling them swiftly.
[¤149] John Zachman himself likes to point out the alternatives available to those who can't
countenance the amount of work implied in developing the all models required in his
framework. There are only three choices: trial and error ("knocking down the
walls"); starting from new; or reverse engineering the architecture from the existing
systems; all of which are risky and/or hugely expensive. What is necessary due to the pace
of change is to have a set of readily deployable artifacts and a process for assembling
them swiftly.
[¤150] While such a complete framework is useful (indeed, essential) to have in mind as the ultimate long-term goal, in practice there is a key decision to be made as to the scope of a specific enterprise architecture effort. This being the case, it is vital to understand the basis on which scoping decisions are being made, and to set expectations aright for what is the goal of the effort.
[¤151] The main guideline is to focus on what creates value to the enterprise, and to select horizontal and vertical scope, and time horizons, accordingly. Whether or not this is the first time around, understand that this exercise will be repeated, and that future iterations will build on what is being created in the current effort, adding greater width and depth.
[¤152] Copyright © The Open Group, 1998, 1999, 2001, 2002
