| You are here: | ||
| <<< Previous | Home | Next >>> |
This chapter describes a framework for architecture re-use.
There is a continuum of architectures, Architecture Building Blocks (ABBs), and architectural models that are relevant to the task of constructing an enterprise-specific architecture.
The Architecture Continuum, and the relative positioning of different types of architectures within it, is illustrated in The Architecture Continuum
.
The Architecture Continuum
illustrates how architectures are developed across a continuum ranging from Foundation Architectures such as TOGAF's, through
common systems architectures, and industry-specific architectures, to an enterprise's own individual
architectures.
The arrows in The Architecture
Continuum represent the bi-directional relationship that exists between the different architectures in the Architecture
Continuum. The leftwards direction focuses on meeting enterprise needs and business requirements, while the rightwards direction
focuses on leveraging architectural components and building blocks.
The enterprise needs and business requirements are addressed in increasing detail from left to right. The architect will typically look to find re-usable architectural elements toward the left of the continuum. When elements are not found, the requirements for the missing elements are passed to the left of the continuum for incorporation. Those implementing architectures within their own organizations can use the same continuum models specialized for their business.
The four particular architectures illustrated in The Architecture Continuum are intended to indicate the range of different types of architecture that may be
developed at different points in the continuum; they are not fixed stages in a process. Many different types of architecture may
occur at points in-between those illustrated in The Architecture Continuum .
Although the continuum illustrated in The Architecture Continuum does not represent a formal process, it does represent a progression, which occurs at
several levels:
At each point in the continuum, an architecture is designed in terms of the design concepts and building blocks available and relevant to that point.
The four architectures illustrated in The Architecture Continuum represent main classifications of potential architectures, and will be relevant and
familiar to many architects. They are analyzed in detail in the following subsections.
A Foundation Architecture is an architecture of building blocks and corresponding standards that supports all the common systems architectures and, therefore, the complete computing environment.
For The Open Group, this Foundation Architecture is the Technical Reference Model (TRM) and Standards Information Base (SIB). The TOGAF ADM explains how to get from that Foundation Architecture to an enterprise-specific one.
The TOGAF TRM and SIB describe a fundamental architecture upon which other, more specific architectures can be based. The TOGAF Foundation Architecture contains many alternatives in each of the ABBs. Other characteristics of the TOGAF Foundation Architecture include the following:
Common Systems Architectures guide the selection and integration of specific services from the Foundation Architecture to create an architecture useful for building common (i.e., re-usable) solutions across a wide number of relevant domains.
Examples of Common Systems Architectures include: a Security Architecture, a Management Architecture, a Network Architecture, etc. Each is incomplete in terms of overall information system functionality, but is complete in terms of a particular problem domain (security, manageability, networking, etc.), so that solutions implementing the architecture constitute re-usable building blocks for the creation of functionally complete information systems.
Other characteristics of Common Systems Architectures include:
The TOGAF Integrated Information Infrastructure Reference Model (III-RM; see Integrated Information Infrastructure Reference Model) is a Common Systems Architecture that focuses on the requirements, building blocks, and standards relating to the vision of Boundaryless Information Flow.
Industry Architectures guide the integration of common systems components with industry-specific components, and guide the creation of industry solutions for targeted customer problems within a particular industry.
A typical example of an industry-specific component is a data model representing the business functions and processes specific to a particular vertical industry, such as the Retail industry's "Active Store" architecture, or an Industry Architecture that incorporates the Petrotechnical Open Software Corporation (POSC) (www.posc.org) data model.
Other characteristics of Industry Architectures include the following:
Enterprise architectures are the most relevant to the IT customer community, since they describe and guide the final deployment of user-written or third-party components that constitute effective solutions for a particular enterprise or enterprises that have a need to share information.
IEEE Std 1003.23, Guide for Developing User Organization Open System Environment (OSE) Profiles, 1 provides a method for identifying and documenting an organization's operational requirements, the IT and IS services needed to support those requirements, and the standards, standards options, interim solutions, and products that will provide the needed services.
There may be a continuum of enterprise architectures that are needed to effectively cover the organization's requirements by defining the enterprise architecture in increasing levels of detail. Alternatively, this might result in several more detailed enterprise architectures for specific entities within the global enterprise.
The enterprise architecture guides the final customization of the solution, and has the following characteristics:
The Solutions Continuum represents the implementations of the architectures at the corresponding levels of the Architecture Continuum. At each level, the Solutions Continuum is a population of the architecture with reference building blocks - either purchased products or built components - that represent a solution to the enterprise's business need expressed at that level. A populated Solutions Continuum can be regarded as a solutions inventory or re-use library, which can add significant value to the task of managing and implementing improvements to the IT environment.
The Solutions Continuum is illustrated in The Solutions Continuum .
In the Architecture Continuum in The Architecture Continuum , the arrows represent bi-directional relationships that exist between the different
architectures in the Architecture Continuum (the leftwards direction focused on meeting customer needs and business requirements,
the rightwards direction on leveraging architectural components and building blocks).
A similar concept applies to the bi-directional arrows underlying the Solutions Continuum in The Solutions Continuum . The rightwards direction of the arrows is
focused on providing solutions value (i.e., Products and Services provide value in creating systems solutions; systems solutions
value is used to create industry solutions; and industry solutions are used to create customer solutions). The leftwards direction
is focused on addressing enterprise needs.
These two viewpoints are significant for a company attempting to focus on its needs while maximizing the use of its internal resources through leverage.
The following subsections describe each of the solution types within the Solutions Continuum.
Products are separately procurable hardware, software, or service entities. Products are the fundamental providers of capabilities.
Services include professional services - such as training and consulting services - that ensure the maximum investment value from solutions in the shortest possible time; and support services - such as Help Desk - that ensure the maximum possible value from solutions (services that ensure timely updates and upgrades to the products and systems).
A "system solution" is an implementation of a Common Systems Architecture comprised of a set of products and services, which may be certified or branded. It represents the highest common denominator for one or more solutions in the industry segments that the system solution supports.
System solutions represent collections of common requirements and capabilities, rather than those specific to a particular customer or industry. System solutions provide organizations with operating environments specific to operational and informational needs, such as high availability transaction processing and scaleable data warehousing systems. Examples of systems solutions include: an enterprise management system product or a security system product.
Computer systems vendors are the primary provider of systems solutions.
An "industry solution" is an implementation of an Industry Architecture, which provides re-usable packages of common components and services specific to an industry.
Fundamental components are provided by system solutions and/or products and services, and are augmented with industry-specific components. Examples include: a physical database schema or an industry-specific point-of-service device.
Industry solutions are industry-specific, aggregate procurements that are ready to be tailored to an individual organization's requirements.
In some cases an industry solution may include not only an implementation of the Industry Architecture, but also other solution elements, such as specific products, services, and systems solutions that are appropriate to that industry.
An "enterprise solution" is an implementation of the enterprise architecture that provides the required business functions. Because solutions are designed for specific business operations, they contain the highest amount of unique content in order to accommodate the varying people and processes of specific organizations.
Building enterprise solutions on industry solutions, systems solutions, and products and services is the primary purpose of connecting the Architecture Continuum to the Solutions Continuum, as guided by the architects within an enterprise.
The preceding sections have described both the Architecture Continuum and the Solutions Continuum. As explained in Introduction to the Enterprise Continuum , the combination of these two complementary concepts
constitutes the Enterprise Continuum, illustrated in The Enterprise Continuum .
The relationship between the Architecture Continuum and the Solutions Continuum is one of guidance, direction, and support.
For example, the Foundation Architecture guides the creation or selection of products and services. The products and services support the Foundation Architecture by helping to realize the architecture defined in the Architecture Continuum. The Foundation Architecture also guides development of products and services, by providing descriptions of required functions to build open computing systems, and the rationale for those functions. A similar relationship exists between the other elements of the Enterprise Continuum.
The Enterprise Continuum presents mechanisms to help improve productivity through leverage. The Solutions Continuum offers a consistent way to understand the different products, systems, services, and solutions required. The Architecture Continuum offers a consistent way to understand the different architectures and their components.
The Enterprise Continuum should not be interpreted as representing strictly chained relationships. Enterprise Architectures
could have components from a Common Systems Architecture, and enterprise solutions could contain a product or service. The
relationships depicted in The
Enterprise Continuum are a best case for the ideal leveraging of architecture and solution
components.
Finally, it is worth emphasizing that the beginning and the end of the Enterprise Continuum lie in a Foundation Architecture, which serves as a tool chest or repository of re-usable guidelines and standards. For The Open Group, this Foundation Architecture is the Technical Reference Model (TRM) and Standards Information Base (SIB).
TOGAF provides a method for you to "architect" the IT systems in your enterprise. Your architecture organization will have to deal with each type of architecture described above. For example, it is recommended that you have your own Foundation Architecture that governs all of your IT systems. You should also have your own Common Systems Architectures that govern major shared infrastructure systems - such as the networking system or management system. You may have your own industry-specific architectures that govern the way your IT systems must behave within your industry. Finally, any given department or organization within your business may need its own individual enterprise architecture to govern the IT systems within that department. All-in-all this implies that your architecture organization is responsible for maintaining your business' Architecture Continuum.
Your architecture organization will either adopt or adapt existing architectures, or will develop its own architectures from ground up. In either case, TOGAF represents a tool to help. It provides a method to assist you in generating/maintaining any type of architecture within the Architecture Continuum while leveraging architecture assets already defined, internal or external to your organization. The TOGAF Architecture Development Method (ADM) helps you to re-use architecture assets, making your architecture organization more efficient and effective.
The TOGAF document set is designed for use with frames. To navigate around the document:
Downloads of the TOGAF documentation, are available under license from the TOGAF information web site . The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063 .