Architecture Content Framework
The Architecture Content Framework uses the following three categories to describe the type of architectural work product within the context of use:
A deliverable is a work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders
An artifact is an architectural work product that describes an aspect of the architecture.catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things).
A building block represents a (potentially re-usable) component of enterprise capability that can be combined with other building blocks to deliver architectures and solutions
- Architecture Building Blocks (ABBs) typically describe required capability and shape the specification of Solution Building Blocks (SBBs)
- Solution Building Blocks (SBBs) represent components that will be used to implement the required capability
Architecture Content Framework
Content Metamodel
The content metamodel provides a definition of all the types of building blocks that may exist within an architecture, showing how these building blocks can be described and related to one another.
Core Metamodel Entities
■ Actor: a person, organization, or system that is outside the consideration of the architecture model, but interacts with it
■ Application Component: an encapsulation of application functionality that is aligned to implementation structure
■ Business Capability: a particular ability that a business may possess or exchange to achieve a specific purpose
■ Business Service: supports business capabilities through an explicitly defined interface and is explicitly governed by an organization
■ Course of Action: direction and focus provided by strategic goals and objectives, often to deliver the value proposition characterized in the business model
■ Data Entity: an encapsulation of data that is recognized by a business domain expert as a discrete concept Data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations.
■ Function: delivers business capabilities closely aligned to an organization, but not explicitly governed by the organization
■ Information System Service: the automated elements of a business service An information system service may deliver or support part or all of one or more business services. ■ Organization Unit:aself-contained unit of resources with goals, objectives, and measures Organization units may include external parties and business partner organizations. ■ Role: an actor assumes a role to perform a task ■ Technology Component: an encapsulation of technology infrastructure that represents a class of technology product or specific technology product ■ Technology Service:atechnical capability required to provide enabling infrastructure that supports the delivery of applications ■ Value Stream:arepresentation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end-user
Architecture Content Framework
Core Metamodel Entities
■ Information System Service: the automated elements of a business service An information system service may deliver or support part or all of one or more business services.
■ Organization Unit: a self-contained unit of resources with goals, objectives, and measures Organization units may include external parties and business partner organizations.
■ Role: an actor assumes a role to perform a task
■ Technology Component: an encapsulation of technology infrastructure that represents a class of technology product or specific technology product
■ Technology Service: a technical capability required to provide enabling infrastructure that supports the delivery of applications
■ Value Stream:arepresentation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end-user
Architectural Artifacts
The “environment” of a system is the context determining the setting and circumstances of all influences upon a system. The environment of a system includes developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological, and social influences.
A “system” is a combination of interacting elements organized to achieve one or more stated purposes.
The “architecture” of a system is the fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.
An “Architecture Description” is a work product used to express an architecture; a collection of architecture views and models that together document the architecture.
“Stakeholders” are individuals, teams, organizations, or classes thereof, having an interest in a system.
Architectural Artifacts
“Concerns” are interests in a system relevant to one or more of its stakeholders. Concerns may pertain to any aspect of the system’s functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability and may determine the acceptability of the system.
An “architecture view” is a representation of a system from the perspective of a related set of concerns. It consists of one or more architecture models of the system
An “Architecture Model” is a representation of a subject of interest. A model provides a smaller scale, simplified, and/or abstract representation of the subject matter.
An “architecture viewpoint” is a specification of the conventions for a particular kind of architecture view. It can also be called the definition or schema for that kind of architecture view.
A “Model Kind” establishes conventions for a type of modeling.
Architectural Artifacts
An architecture viewpoint references one or more model kinds; an architecture view incorporates one or more models. A “viewpoint library” is a collection of the specifications of architecture viewpoints contained in the Reference Library portion of the Architecture Repository
■ An architecture view is what you see; an architecture viewpoint is where you are looking from — the vantage point or perspective that determines what you see
■ Architecture viewpoints are generic, and can be stored in libraries for re-use; an architecture view is always specific to the architecture for which it is created
■ Every architecture view has an associated architecture viewpoint that describes it, at least implicitly .
Architectural Artifacts
Preliminary Phase → Principles Catalog
Phase A: Architecture Vision → Stakeholder Map Matrix,Value Chain Diagram,Solution Concept Diagram,Business Model Diagram,Business Capability Map,Value Stream Map
Phase B: Business Architecture→Organization/Actor Catalog,Driver/Goal/Objective Catalog,Role Catalog,Business Service/Function Catalog,Location Catalog,Process/Event/Control/Product Catalog,Contract/Measure Catalog,Business Capabilities Catalog,Value Stream Catalog,Value Stream Stages Catalog,Business Interaction Matrix,Actor/Role Matrix ,Value Stream/Capability Matrix,Strategy/Capability Matrix,Capability/Organization Matrix,Business Footprint Diagram,Business Service/Information Diagram,Functional Decomposition Diagram,Product Lifecycle Diagram,Goal/Objective/Service Diagram,Business Use-Case Diagram,Organization Decomposition Diagram,Process Flow Diagram,Event Diagram,Business Capability Map,Value Stream Map,Organization Map
Phase C: Data Architecture →Data Entity/Data Component Catalog,Data Entity/Business Function Matrix,Application/Data Matrix,,Conceptual Data Diagram,Logical Data Diagram,Data Dissemination Diagram,Data Security Diagram,Data Migration Diagram,Data Lifecycle Diagram
Architectural Artifacts
Phase C: Application Architecture → Application Portfolio Catalog,Interface Catalog,Application/Organization Matrix,Role/Application Matrix ,Application/Function Matrix,Application Interaction Matrix,Application Communication Diagram ,Application and User Location Diagram ,Application Use-Case Diagram,Enterprise Manageability Diagram,Process/Application Realization Diagram ,Software Engineering Diagram,Application Migration Diagram,Software Distribution Diagram
Phase D: Technology Architecture→ Technology Standards Catalog ,Technology Portfolio Catalog ,Application/Technology Matrix ,Environments and Locations Diagram ,Platform Decomposition Diagram , Processing Diagram,Networked Computing/Hardware Diagram,Network and Communications Diagram
Phase E: Opportunities and Solutions → Project Context Diagram,Benefits Diagram
Requirements Management → Requirements Catalog
Architectural Deliverables
Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture.
The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information.
Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.
The Architecture Repository acts as a holding area for all architecture-related projects within the enterprise.
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.
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
Architectural Deliverables
The Architecture Vision is created early on in the ADM cycle. It provides a summary of the changes to the enterprise that will accrue 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.
Capability Assessment
Change Request
Communications Plan
Compliance Assessment
Implementation and Migration Plan provides a schedule of the projects that will realize the Target Architecture.
The Implementation Governance Model ensures that a project transitioning into implementation also smoothly transitions into appropriate Architecture Governance
Organizational Model for Enterprise Architecture
Architectural Deliverables
Request for Architecture Work
Requirements Impact Assessment assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes.
Solution Building Blocks
The Statement of Architecture Work defines the scope and approach that will be used to complete an architecture development cycle.
Tailored Architecture Framework
Building Blocks
Building blocks have generic characteristics as follows:
- ■ A building block is a package of functionality defined to meet the business needs across an organization
- ■ A building block has a type that corresponds to the enterprise’s content metamodel (such as actor, business service, application, or data entity)
- ■ A building block has a defined boundary and is generally recognizable as “a thing” by domain experts
- ■ A building block may interoperate with other, inter-dependent building locks.
A good building block has the following characteristics:
- — It considers implementation and usage, and evolves to exploit technology and standards
- — It may be assembled from other building blocks
- — It may be a subassembly of other building blocks
- — Ideally a building block is re-usable and replaceable, and well specified
Building Blocks
Building blocks have generic characteristics as follows:
- ■ A building block is a package of functionality defined to meet the business needs across an organization
- ■ A building block has a type that corresponds to the enterprise’s content metamodel (such as actor, business service, application, or data entity)
- ■ A building block has a defined boundary and is generally recognizable as “a thing” by domain experts
- ■ A building block may interoperate with other, inter-dependent building locks.
A good building block has the following characteristics:
- — It considers implementation and usage, and evolves to exploit technology and standards
- — It may be assembled from other building blocks
- — It may be a subassembly of other building blocks
- — Ideally a building block is re-usable and replaceable, and well specified
Building Blocks
A building block’s boundary and specification should be loosely coupled to its implementation; i.e., it should be possible to realize a building block in several different ways without impacting the boundary or specification of the building block.
ABBs:
- ■ Capture architecture requirements; e.g., business, data, application, and technology requirements
- ■ Direct and guide the development of SBBs
SBBs:
- ■ Define what products and components will implement the functionality
- ■ Define the implementation
- ■ Fulfil business requirements
- ■ Are product or vendor-aware
Enterprise Continuum and Tools
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
The Enterprise Continuum provides methods for classifying architecture and solution artifacts, both internal and external to the Architecture Repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures.
Architecture Continuum 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 OrganizationSpecific Architecture is based on an industry or generic standard)
The Solutions Continuum provides a consistent way to describe and understand the implementation of the assets defined in the Architecture Continuum
Enterprise Continuum and Tools
A Foundation Architecture consists of generic components, inter-relationships, principles, and guidelines that provide a foundation on which more specific architectures can be built.TOGAF TRM is an example of a Foundation Architecture.
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., highly reusable) solutions across a wide number of relevant domains. Examples of Common Systems Architectures include: a security architecture, a management architecture, a network architecture, an operations architecture.TOGAF Integrated Information Infrastructure Reference Model (III-RM)
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.
Organization-Specific Architectures describe and guide the final deployment of solution components for a particular enterprise or extended network of connected enterprises.
Enterprise Continuum and Tools
Solutions Continuum represents the detailed specification and construction of the architectures at the corresponding levels of the Architecture Continuum.
Foundation Solutions are highly generic concepts, tools, products, services, and solution components that are the fundamental providers of capabilities.Example Foundation Solutions would include programming languages, operating systems, foundational data structures (such as EDIFACT), generic approaches to organization structuring, foundational structures for organizing IT operations (such as ITIL or the IT4IT Reference Architecture), etc.
A Common Systems Solution is an implementation of a Common Systems Architecture comprised of a set of products and services, which may be certified or branded.Computer systems vendors are the typical providers of technology-centric Common Systems Solutions. “Software as a service” vendors are typical providers of common application solutions. Business process outsourcing vendors are typical provides of business capabilitycentric Common Systems Solutions.
Industry Solution is an implementation of an Industry Architecture, which provides reusable packages of common components and services specific to an industry.
Organization-Specific Solution is an implementation of the Organization-Specific Architecture that provides the required business functions.
Architecture Compliance
Irrelevant: The implementation has no features in common with the architecture specification (so the question of conformance does not arise).
Consistent: The implementation has some features in common with the architecture specification, and those common features are implemented in accordance with the specification. However, some features in the architecture specification are not implemented, and the implementation has other features that are not covered by the specification.
Compliant: Some features in the architecture specification are not implemented, but all features implemented are covered by the specification, and in accordance with it.
Conformant: All the features in the architecture specification are implemented in accordance with the specification, but some more features are implemented that are not in accordance with it.
Fully Conformant: There is full correspondence between architecture specification and implementation. All specified features are implemented in accordance with the specification, and there are no features implemented that are not covered by the specification.
Non-conformant: Any of the above in which some features in the architecture specification are implemented not in accordance with the specification.
Architecture Governance
- Discipline All involved parties will have a commitment to adhere to procedures, processes, and authority structures established by the organization.
- Transparency All actions implemented and their decision support will be available for inspection by authorized organization and provider parties.
- Independence All processes, decision-making, and mechanisms used will be established so as to minimize or avoid potential conflicts of interest.
- Accountability Identifiable groups within the organization — e.g., governance boards who take actions or make decisions — are authorized and accountable for their actions.
- Responsibility Each contracted party is required to act responsibly to the organization and its stakeholders.
- Fairness All decisions taken, processes used, and their implementation will not be allowed to create unfair advantage to any one particular party.
Architecture Maturity Models
- Level 0: None No Enterprise Architecture program. No Enterprise Architecture to speak of.
- Level 1: Initial Informal Enterprise Architecture process underway.
- Processes are ad hoc and localized. Some Enterprise Architecture processes are defined. There is no unified architecture process across technologies or business processes. Success depends on individual efforts.
- Enterprise Architecture processes, documentation, and standards are established by a variety of ad hoc means and are localized or informal.
- Minimal, or implicit linkage to business strategies or business drivers.
- Limited management team awareness or involvement in the architecture process.
- Limited operating unit acceptance of the Enterprise Architecture process.
- The latest version of the operating unit’s Enterprise Architecture documentation is on the web. Little communication exists about the Enterprise Architecture process and possible process improvements.
- IT security considerations are ad hoc and localized.
- No explicit governance of architectural standards.
- Little or no involvement of strategic planning and acquisition personnel in the Enterprise Architecture process. Little or no adherence to existing standards.
Architecture Maturity Models
Level 2: Under Development Enterprise Architecture process is under development.
- Basic Enterprise Architecture process is documented based on OMB Circular A-130 and Department of Commerce Enterprise Architecture Guidance. The architecture process has developed clear roles and responsibilities.
- IT vision, principles, business linkages, Baseline, and Target Architecture are identified. Architecture standards exist, but not necessarily linked to Target Architecture. Technical Reference Model (TRM) and Standards Profile framework established.
- Explicit linkage to business strategies.
- Management awareness of architecture effort.
- Responsibilities are assigned and work is underway.
- The DoC and operating unit Enterprise Architecture web pages are updated periodically and are used to document architecture deliverables
- IT security architecture has defined clear roles and responsibilities.
- Governance of a few architectural standards and some adherence to existing Standards Profile.
- Little or no formal governance of IT investment and acquisition strategy. Operating unit demonstrates some adherence to existing Standards Profile.
Architecture Maturity Models
Level 3: Defined Defined Enterprise Architecture including detailed written procedures and TRM.
- The architecture is well defined and communicated to IT staff and business management with operating unit IT responsibilities. The process is largely followed.
- Gap analysis and Migration Plan are completed. Fully developed TRM and Standards Profile. IT goals and methods are identified.
- Enterprise Architecture is integrated with capital planning and investment control.
- Senior management team aware of and supportive of the enterprise-wide architecture process. Management actively supports architectural standards.
- Most elements of operating unit show acceptance of or are actively participating in the Enterprise Architecture process.
- Architecture documents updated regularly on DoC Enterprise Architecture web page.
- IT security architecture Standards Profile is fully developed and is integrated with Enterprise Architecture.
- Explicit documented governance of majority of IT investments.
- IT acquisition strategy exists and includes compliance measures to IT Enterprise Architecture. Cost benefits are considered in identifying projects.
Architecture Maturity Models
Level 4: Managed Managed and measured Enterprise Architecture process.
- Enterprise Architecture process is part of the culture. Quality metrics associated with the architecture process are captured.
- Enterprise Architecture documentation is updated on a regular cycle to reflect the updated Enterprise Architecture. Business, Data, Application, and Technology Architectures defined by appropriate de jure and de facto standards.
- Capital planning and investment control are adjusted based on the feedback received and lessons learned from updated Enterprise Architecture. Periodic re-examination of business drivers.
- Senior management team directly involved in the architecture review process.
- The entire operating unit accepts and actively participates in the Enterprise Architecture process.
- Architecture documents are updated regularly, and frequently reviewed for latest architecture developments/standards.
- Performance metrics associated with IT security architecture are captured.
- Explicit governance of all IT investments. Formal processes for managing variances feed back into Enterprise Architecture.
- All planned IT acquisitions and purchases are guided and governed by the Enterprise Architecture
Architecture Maturity Models
Level 5: Measured Continuous improvement of Enterprise Architecture process.
- Concerted efforts to optimize and continuously improve architecture process.
- A standards and waivers process is used to improve architecture development process.
- Architecture process metrics are used to optimize and drive business linkages. Business involved in the continuous process improvements of Enterprise Architecture.
- Senior management involvement in optimizing process improvements in architecture development and governance.
- Feedback on architecture process from all operating unit elements is used to drive architecture process improvements.
- Architecture documents are used by every decision-maker in the organization for every IT-related business decision.
- Feedback from IT security architecture metrics are used to drive architecture process improvements.
- Explicit governance of all IT investments. A standards and waivers process is used to make governance-process improvements.
- No unplanned IT investment or acquisition activity.
