TOGAF 9 - Architecture Partitioning

1. Spring - 2010

2.  We need to partition architectures because:
◦ Addressing all problems within a single architecture is too complex.
◦ Different architectures conflict with one another (e.g., the state of the
enterprise changes over time and an architecture from one time period will
conflict with an architecture for a different time period).
◦ Different people need to work on different elements of architecture at the
same time and partitions allow for specific groups of architects to own
and develop specific segments of the architecture.
◦ Effective architecture re-use requires modular architecture segments that
can be taken and incorporated into broader architectures and solutions.
 However, it is difficult to present a definitive partitioning
model for architecture, as each enter prise is likely to
adopt a partitioning model that reflects its own operating
model

3.  Subject Matter:
◦ The most obvious way to describe a solution is to examine its content, structure, and function
(i.e., its subject matter).
◦ Additionally, the solution may be described by examining the boundary of the solution and all
the external factors that interact with the solution at the solution boundary (e.g., pre-
conditions, post-conditions, consumers, suppliers, ownership, operation, influencing factors).
 Time:
◦ All solutions exist for a period of time. The subject matter and environment of a solution are
likely to fundamentally change over time, so identifying the time period of a solution is a key
contextual factor to consider. Additionally, when future solutions are being described, often the
time period of the solution represents a target realization date and is used to plan and organize
change activity.
 Maturity/Volatility:
◦ The extent to which the subject matter and environment of a solution are likely to change over
time. Highly volatile or immature solutions are likely to be managed and valued very differently
to very stable or mature solutions (e.g., flexible solutions are more valuable in volatile
environments).

4.  Subject Matter:
◦ Architectures describe specific solutions and consequently inherit the objective characteristics
of the solution that they represent (i.e., the subject matter, environment, time, and volatility).
 Viewpoint:
◦ The architectural domains considered and specific artifacts produced will provide a partial
representation of the solution based on the needs of stakeholders.
◦ This viewpoint may be general, or specific to a particular architecture domain (i.e., business,
data, application, and technology) or other consideration (i.e., Security, Operational
Management, Integration, Construction, etc.).
 Level of Detail:
◦ The level of detail used to represent a solution has a strong influence on how an architecture
can be used. Generally, less detailed architectures are more effective in communicating an
overall solution approach, but less effective in supporting its realization.
 Level of Abstraction:
◦ A consideration for architecture characterization is how abstracted the architecture is from the
solutions that it represents. For example, some architectures provide a direct description of a
solution and others may describe an approach or pattern that is used across many solutions.
 Accuracy:
◦ Any architecture is a representation of reality and is not necessarily a completely accurate
description of the intended solution. Typically, the level and quality of resource invested in the
creation of an architecture will determine the accuracy of the result.

5.  Subject Matter:
◦ The subject matter area is generally the primary organizing characteristic for describing an
Architecture Landscape. Architectures are functionally decomposed into a hierarchy of specific
subject areas or segments.
 Level of Detail:
◦ With broader subject areas, less detail is needed to ensure that the architecture has a
manageable size and complexity. More specific subject matter areas will generally permit (and
require) more detailed architectures.
 Time Period:
◦ For a specific subject matter and level of detail an enterprise can create a Baseline Architecture
and a set of Target Architectures that stretch into the future. Broader and less detailed
architectures will generally be valid for longer periods of time and can provide a vision for the
enterprise that stretches further into the future.
 Viewpoint:
◦ For a particular subject area, level of detail, and time period the stakeholders for architecture
will have requirements to see architectures that address particular issues or viewpoints.
 Accuracy:
◦ Finally, each architecture view will progress through a development cycle where it increases in
accuracy until finally approved. After approval, an architecture will begin to decrease in accuracy
if not actively maintained. In some cases recency may be used as an organizing factor for
historic architectures.

8.  Level of Abstraction:
◦ Because reference models aim to be abstract, re-usable solution approaches that
can be adopted in many circumstances, the level of abstraction is generally a good
starting place for organizing reference models. Highly abstracted models may be
applicable to all enterprises. As these models become more specific they may only
be relevant to certain types of system, certain industries, or even be specific to a
single enter prise or line of business.
 Subject Matter:
◦ Within a particular level of abstraction several related models may address a
particular theme or topic and therefore partitioning according to subject matter
allows for ease-of-reference.
 Viewpoint:
◦ For any given subject, a number of reference models may address that subject from
different complementary viewpoints. Related viewpoints can be grouped together to
provide a richer understanding of the desired approach.

9. 1. Foundation Architectures are very abstract reference models that could be applied to all enter
prise architectures or solutions.
2. Common Systems Architectures show patterns and approaches for common systems that
occur across many enter prises and industries, such as Enterprise Resource Planning (ERP)
systems.
3. Industry Architectures provide shared blueprints that can apply to many partners or
competitors within a single industry.
4. Organization-Specific Architectures provide common reference models that are specific to
the enterprise, but still can apply across several business areas.

10. 1. Business Standards relate to standard practice in the Business Architecture domain, including
standard processes, roles, responsibilities, organization models, etc.
2. Data Standards relate to standard practice in the Data Architecture domain, including standard
data models, data governance models, etc.
3. Application Standards relate to standard practice in the Application Architecture domain,
including standard applications, application types, and application functionality.
4. Technology Standards relate to standard practice in the Technology Architecture domain,
including standard products, product types, and proper usage constraints for technologies.

13. Content aggregation and integration can
be addressed from a number of
dimensions:
1. Integration across the architectural
domains provides a cross-domain
view of the state of a segment of the
enterprise for a point in time.
2. Integration across the organizational
scope of the business provides a
cross-segment view of the enterprise.
3. The Architecture Vision provides an
integrated summary of Architecture
Definitions, which provide an
integrated summary of Transition
Architectures.

14.  TOGAF Version 9, The Open Group
Architecture Framework (TOGAF), 2009

15. If you have one last breath
use it to say...