Chapter 11 Building Blocks

• A building block is a package of functionality defined to meet business needs across an organization. A building block has published interfaces to access functionality. A building block may interoperate with other, possibly inter-dependent building blocks.
• An architecture is a composition of:
  • A set of building blocks depicted in an architectural model
  • A specification of how those building blocks are connected to meet the overall requirements of an information system
• Architecture Building Blocks (ABBs) are architecture documentation and models from the enterprise’s Architecture Repository classified according to the Architecture Continuum.
• The characteristics of ABBs are as follows:
  • They define what functionality will be implemented.
  • They capture architecture requirements; e.g., Business, Data, Application, and Technology requirements.
  • They direct and guide the development of Solution Building Blocks
• The characteristics of ABBs are as follows:
  • They define what functionality will be implemented.
  • They capture architecture requirements; e.g., Business, Data, Application, and Technology requirements.
  • They direct and guide the development of Solution Building Blocks

  

• Building blocks are what you use; patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing that. Patterns offer the promise of helping the architect to identify combinations of Architecture and/or Solution Building Blocks (ABBs/SBBs) that have been proven to deliver effective solutions in the past and may provide the basis for effective solutions in the future.

Chapter 12 ADM Deliverables

• Architecture Building Blocks (ABBs): ABBs are architecture documentation and models from the enterprise’s Architecture Repository.
• Architecture Contract: Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. They are produced in Phase G: Architecture Governance. Successful implementation of these agreements will be delivered through effective Architecture Governance.
• Architecture Definition Document: The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information. The Architecture Definition Document spans all architecture domains (Business, Data, Application, and Technology) and also examines all relevant states of the architecture (baseline, transition, and target).
• Architecture Definition Document versus Architecture Requirements Specification The Architecture Definition Document is a companion to the Architecture Requirements Specification, with a complementary objective: The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architects. The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture.
• Architecture Requirements Specification: The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or a contract for more detailed Architecture Definition.
• Architecture Roadmap: The Architecture Roadmap lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture. The Architecture Roadmap highlights individual work packages’ business value at each stage. Transition Architectures necessary to effectively realize the Target Architecture are identified as intermediate steps. The Architecture Roadmap is incrementally developed throughout Phases E and F, and informed by the roadmap components developed in Phases B, C, and D.
• The Architecture Vision is created in Phase A and provides a high-level summary of the changes to the enterprise that will follow from successful deployment of the Target Architecture.
• Business principles, business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise. These will have usually been defined elsewhere in the enterprise prior to the architecture activity. Many factors that lie outside the consideration of architecture discipline may have significant implications for the way that architecture is developed.

Chapter 13 TOGAF Reference Models

• Major characteristics of a Foundation Architecture include the following:
  • It reflects general computing requirements.
  • It reflects general building blocks.
  • It defines technology standards for implementing these building blocks. It provides direction for products and services.
  • It reflects the function of a complete, robust computing environment that can be used as a foundation.
  • It provides open system standards, directions, and recommendations.
  • It reflects directions and strategies.
• The TRM has two main components:
  • 1. A taxonomy that defines terminology, and provides a coherent description of the components and conceptual structure of an information system
  • 2. A model, with an associated TRM graphic, that provides a visual representation of the taxonomy, as an aid to understanding

  

  

• The Integrated Information Infrastructure Reference Model: The III-RM is a reference model that focuses on the Application Software space, and is a “Common Systems Architecture” in Enterprise Continuum terms. 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.

  

• Boundaryless Information Flow 1. A trademark of The Open Group. 2. A shorthand representation of “access to integrated information to support business process improvements” representing a desired state of an enterprise’s infrastructure specific to the business needs of the organization. An infrastructure that provides Boundaryless Information Flow has open standard components that provide services in a customer’s extended enterprise that:  Combine multiple sources of information  Securely deliver the information whenever and wherever it is needed, in the right context for the people or systems using that information