jonka A A 11 vuotta sitten
4258
Lisää tämän kaltaisia
It is usually impossible to create a single unified architecture that meets all requirements of all stakeholders for all time. Therefore, the enterpr ise architect will need to deal not just with a single enterpr ise architecture, but with many related enterpr ise architectures.
Each architecture will have a different purpose and architectures will relate to one another.
Effectively bounding the scope of an architecture is therefore a critical success factor in allowing architects to break down a complex problem space into manageable components that can be individually addressed.
The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical.
This part of TOGAF discusses the Enterprise Continuum; including the Architecture Continuum and the Solutions Continuum. It describes how architectures can be partitioned and organized within a repository. It also describes tools for architecture development.
The Enterpr ise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts, both internal and exter nal to the Architecture Repositor y, as they evolve from generic Foundation Architectures to Organization-Specific Architectures.The Enterprise Continuum is an important aid to communication and understanding, both within individual enterpr ises, and between customer enterpr ises and vendor organizations. Without an understanding of ‘‘where in the continuum you are’’, people discussing architecture can often talk
at cross-purposes because they are referencing different points in the continuum at the same
time, without realizing it. Any architecture is context-specific; for example, there are architectures that are specific to individual customers, industries, subsystems, products, and services. Architects, on both the buy side and supply side, must have at their disposal a consistent language to effectively communicate the differences between architectures. Such a language will enable engineering efficiency and the effective leveraging of Commercial Off-The-Shelf (COTS) product functionality. The Enterpr ise Continuum provides that consistent language. Not only does the Enterpr ise Continuum represent an aid to communication, it represents an aid to organizing re-usable architecture and solution assets. This is explained further in the following sections.
Provides a consistent way to describe and understand the implementation of the assets defined in the Architecture Continuum. The Solutions Continuum defines what is available in the organizational environment as reusable Solution Building Blocks(SBBs). The solutions are the results of agreements
between customers and business partners that implement the rules and relationships defined in the architecture space. The Solutions Continuum addresses the commonalities and differences among the products, systems, and services of implemented systems.
Offers a consistent way to define and understand the generic rules, representations, and relationships in an architecture, including traceability and derivation relationships (e.g., to show that an Organization-
Specific Architecture is based on an industry or gener ic standard). The Architecture Continuum represents a structuring of Architecture Building Blocks (ABBs) which are reusable architecture assets. ABBs evolve through their development lifecycle from abstract
and generic entities to fully expressed Organization-Specific Architecture assets. The Architecture Continuum assets will be used to guide and select the elements in the Solutions Continuum (see below). The Architecture Continuum shows the relationships
among foundational frameworks (such as TOGAF), common system architectures (such as the III-RM), industry architectures, and enterpr ise architectures. The Architecture Continuum is a useful tool to discover commonality and eliminate unnecessary redundancy.
Is the outermost continuum and classifies assets related to the context of the overall enterprise architecture. The Enterprise Continuum classes of assets may influence architectures, but are not directly used during the ADM architecture development. The Enterprise Continuum classifies contextual assets
used to develop architectures, such as policies, standards, strategic initiatives, organizational structures, and enterprise-level capabilities. The Enterprise Continuum can also classify solutions (as opposed to descriptions or specifications of solutions). Finally, the Enterprise Continuum contains two specializations, namely the Architecture and Solutions Continua.
Describes the Technical Reference Model (TRM), including core taxonomy, graphical representation, and the detailed platform taxonomy
Integrated Information Infrastructure Reference Model
The III-RM is a subset of the TOGAF TRM in terms of its overall scope, but it also expands certain parts of the TRM - in particular, the business applications and infrastructure applications parts — in order to provide help in addressing one of the key challenges facing the
enterprise architect today: the need to design an integrated information infrastructure to enable
Boundaryless Information Flow.
Like the TOGAF TRM, the III-RM has two main components:
1. A taxonomy, which defines terminology, and provides a coherent description of the components and conceptual structure of an integrated information infrastructure
2. An associated III-RM graphic, which provides a visual representation of the taxonomy, and the inter-relationship of the components, as an aid to understanding The model assumes the underlying existence of a computing and networ k platfor m, as described in the TRM; these are not depicted in the model.
The TOGAF Foundation Architecture is an architecture of generic services and functions that provides a foundation on which more specific architectures and architectural components can be built. This Foundation Architecture is embodied within the Technical Reference Model (TRM), which provides a model and taxonomy of generic platform services.
The TRM is universally applicable and, therefore, can be used to build any system architecture.
Any TRM has two main components:
1. A taxonomy, which defines terminology, and provides a coherent description of the components and conceptual structure of an infor mation system
2. An associated TRM graphic, which provides a visual representation of the taxonomy, as an aid to understanding
In order to successfully operate an architecture function within an enterpr ise, it is necessar y to
put in place appropriate organization structures, processes, roles, responsibilities, and skills to
realize the architecture capability.
Architecture Capability Framework provides a set of reference materials for how to establish such an architecture function.
Implementing any capability within an organization would require the design of the four domain architectures: Business, Data, Application, and Technology. Establishing the architecture practice within an organization would therefore require the design of:
1- The Business Architecture of the architecture practice that will highlight the architecture governance, architecture processes, architecture organizational structure, architecture infor mation requirements, architecture products, etc.
2- The Data Architecture that would define the structure of the organization’s Enterprise Continuum and Architecture Repository
3- The Application Architecture specifying the functionality and/or applications services required to enable the architecture practice
4- The Technology Architecture that depicts the architecture practice’s infrastructure
requirements and deployment in support of the architecture applications and Enterpr ise
Continuum
The Architecture Development Method (ADM) process can be adapted to deal with a number of different usage scenarios, including different process styles (e.g., the use of iteration) and also specific specialist architectures (such as security). Guidelines included within this part of TOGAF are as follows:
- Applying Iteration to the ADM discusses the concept of iteration and shows potential strategies for applying iterative concepts to the ADM.
- Applying the ADM at Different Enterprise Levels discusses the different types of architecture engagement that may occur at different levels of the enterpr ise. This section then also discusses how the ADM process can be focused to support different types of engagement.
- Security Architecture and the ADM provides an overview of specific security considerations that should be considered during different phases of the ADM.
- Using TOGAF to Define & Govern SOAs shows how SOA concepts can be supported by the TOGAF framework and the specific SOA considerations for different phases of the ADM.
-
Architects executing the Architecture Development Method (ADM) will produce a number of outputs as a result of their efforts, such as process flows, architectural requirements, project plans, project compliance assessments, etc. The content framework provides a structural model for architectural content that allows the major work products that an architect creates to be consistently defined, structured, and presented. The content framework provided here is intended to allow TOGAF to be used as a stand-alone
framework for architecture within an enterprise.
-
A Detailed model of architure work products, including deliverables, artifacts within deliverables, and the architecture Building Blocks (ABBs) that deliverables represent.
The Architecture Content Framework uses the following three categories to describe the type of architectural work product within the context of use:
Solution Building Blocks (SBBs)
Represent components that will be used to implement the required capability.
For example, a networ k is a building block that can be described through complementary artifacts and then put to use to realize solutions for the enterpr ise.
Architecture Building Blocks (ABBs)
Typically describe required capability and shape the specification of Solution Building Blocks (SBBs).
For example, a customer services capability may be required within an enterprise, supported by many SBBs, such as processes, data, and application software.
The TOGAF ADM is the result of continuous contributions from a large number of architecture ractitioners. It describes a method for developing an enterprise architecture, and forms the core of TOGAF. It integrates elements of TOGAF described in this document as well as other vailable architectural assets, to meet the business and IT needs of an organization
Understanding and managing the requirements for the architecture practice is crucial.
Requirements should be clearly articulated and align to the architecture practice vision
Changes to the architecture of the architecture practice should be managed by this phase.
These changes are usually triggered during the execution of architecture projects. A typical change would be the requirement for a new architecture deliverable. This would impact on all the architecture domains of the architecture practice
The implementation of the Business Architecture of the architecture practice should be the focus of this phase. Changing practices within the organization to adopt a more structured and disciplined approach will be a challenge and should be addressed by the appropriate
organizational change techniques.
The focus should not only be on the Information Systems Architecture components in this phase, but include the Business Architecture. The adoption of the architecture process and framework will have a major impact on the overall establishment of the architecture practice in the
organization.
A critical factor to consider during this phase of planning the establishment of the architecture practice is the organizational change that is required and how this will be achieved.
The Technology Architecture of the architecture practice should define technology infrastr ucture
suppor ting the architecture practice
The Data Architecture of the architecture practice would specify and govern the structure of the organization’s Enter prise Continuum and Architecture Repository. The Data Architecture should be defined based on the architecture framework. The Data Architecture is sometimes referred to as the metamodel of the architecture practice.
The Application Architecture of the architecture practice defines the functionality required to generate, maintain, publish, distribute, and govern the architecture deliverables as defined in the architecture framework.
A key focus should be on the modeling toolsets required for modeling, but it should not be the only focus.
Key areas of focus during this phase of establishing or refining the Business Architecture of the architecture practice are:
* An Architecture Ontology defining the architectural terms and definitions that will be used in the organization in order to establish a common understanding of these terms.
* The Architecture Process where the ADM would form the base of the process and need to be customized to meet the organization’s requirements and architecture practice vision. The required architecture governance processes should be included in the overall architecture process.
* The Architecture Viewpoints and Views that lists all the viewpoints and views that should be addressed by the architecture practice. The identified architecture practice stakeholders would guide the development of this definition. One of the viewpoints to be included is the architecture governance viewpoint.
* The Architecture Framework descr ibing the various architecture deliverables that will be generated by the architecture practice, the inter-relationships and dependencies between the architecture deliverables, as well as the rules and guidelines governing the design of these deliverables. The defined architecture viewpoints and views should be used to guide the definition of the architecture framework.
* The Architecture Accountability Matrix defining the roles in the architecture practice and allocating accountability of the roles to architecture deliverables and processes. This matrix would include the required architecture governance structures and roles.
* The Architecture Performance Metrics identifying and describing the metrics that will be used to monitor the perfor mance of the architecture practice against its stated architecture practice vision and objectives.
* The Architecture Governance Framework which is a specific view of the defined architecture process and Architecture Accountability Matrix.
The purpose of this phase within the context of establishing an architecture practice is to define or review the vision, stakeholders, and principles of the architecture practice. The focus in this phase would be on the architecture practice as a whole and not on a particular architecture project.
The following should be considered in terms of understanding the steps in the context of establishing an architecture practice:
* Establish the Project: This step should focus on defining the stakeholders in the architecture practice. The stakeholders would include the roles and organization units par ticipating in the architecture practice, as well as those that will benefit from the
deliverables generated by the architecture practice that can therefore be defined as customers of the architecture practice.
* Identify Stakeholders and Concerns, Business Requirements, and Architecture Vision: This step generates the first, ver y high-level definitions of the baseline and target environments, from a business infor mation systems and technology perspective for the architecture practice.
* Identify Business Goals and Business Drivers: This would be more relevant for the architecture practice than for a particular architecture project. An understanding of the business goals and drivers is essential to align the architecture practice to the business.
* Define Scope: Defining the scope of the architecture practice would be a high-level project
plan of what should be addressed in terms of architecture for the next period.
* Define Constraints: The focus in this step should be on the enterpr ise-wide constraints
that would impact on all architecture projects.
* Review Architecture Principles, including Business Principles: The intent in this step should be to define the principles that would govern and guide the running of the architecture practice. Where architecture principles usually govern the architecture deliverables, the architecture practice principles would address the architecture practice organization, content, tools, and process.
* Develop Statement of Architecture Work and Secure Approval: This step should
generate the architecture practice vision and scope.
