Spring - 2010

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

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).

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.

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.

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.

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.

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.

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.

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

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