1. Certification program
1.1. L1 Foundation (close book, 40 MCQ)
1.1.1. Basic Concepts x3
1.1.2. Core concepts x3
1.1.3. Introduction to ADM x3
1.1.4. Enterprise Continuum and Tools x4
1.1.5. ADM phases x9
1.1.6. ADM guideline and technique x6
1.1.7. Architecture Governance x4
1.1.8. Architecture Views, Viewpoints, Stakeholders x2
1.1.9. Building blocks x2
1.1.10. ADM deliverables x2
1.1.11. TOGAF reference models x2
1.2. L2 Certified
2. Basic Concepts (3)
2.1. TOGAF standard
2.1.1. “an architecture framework. It provides the methods and tools for assisting in the acceptance, production, use, and maintenance of Enterprise Architectures. It is based on an iterative process model supported by best practices and a re-usable set of existing architectural assets.”
2.1.2. “can be used for developing a broad range of different Enterprise Architectures. It complements, and can be used in conjunction with, other frameworks that are more focused on specific deliverables”
2.2. Enterprise
2.2.1. “any collection of organizations that has common goals”
2.2.2. “An extended enterprise frequently includes partners, suppliers, and customers”
2.3. Architecture
2.3.1. “The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model.” -- MIT
2.3.2. “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.”
2.3.2.1. “More effective and efficient business operations”
2.3.2.2. “More effective and efficient Digital Transformation and IT operations”
2.3.2.3. “Better return on existing investment, reduced risk for future investment”
2.3.2.4. “Faster, simpler, and cheaper procurement”
2.4. Architecture Framework
2.4.1. “foundational structure, or set of structures, that can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together.”
2.5. Domains
2.5.1. Business Architecture
2.5.1.1. The business strategy, governance, organization, and key business processes.
2.5.2. Data Architecture
2.5.2.1. The structure of an organization’s logical and physical data assets and data management resources.
2.5.3. Application Architecture
2.5.3.1. A blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
2.5.4. Technology Architecture
2.5.4.1. The software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.
2.6. ADM
2.6.1. The main guideline is to focus on what creates value to the enterprise, and to select horizontal and vertical scope, and time periods
2.6.2. It provides a number of architecture development phases in a cycle, as an overall process template for architecture development activity
2.6.3. It provides a narrative of each architecture phase, describing the phase in terms of objectives, approach, inputs, steps, and outputs
2.6.4. The inputs and outputs sections provide a definition of the architecture content structure and deliverables.
2.6.5. It provides cross-phase summaries that cover requirements management
2.7. Enterprise Continuum
2.7.1. “provides a model for structuring a virtual repository and provides methods for classifying architecture and solution artifacts, showing how the different types of artifacts evolve, and how they can be leveraged and re-used. ”
2.8. Deliverables
2.8.1. deliverables that will be consumed and produced across the TOGAF ADM cycle. The deliverable set provided is intended to provide a typical baseline of architecture deliverables in order to better define the activities required in the ADM and act as a starting point for tailoring within a specific organization.”
3. Core Concepts (3)
3.1. Architecture Repository
3.1.1. Architecture Metamodel
3.1.1.1. describes the organizationally tailored application of an architecture framework, including a metamodel for architecture content
3.1.2. Architecture Landscape
3.1.2.1. shows an architectural view of the building blocks that are in use within the organization today (e.g., a list of the live applications); the landscape is likely to exist at multiple levels of abstraction to suit different architecture objectives”
3.1.3. Solutions Landscape
3.1.3.1. presents an architectural representation of the SBBs supporting the Architecture Landscape which have been planned or deployed by the enterprise”
3.1.4. Reference Library
3.1.4.1. provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise
3.1.5. The Standards Information Base (SIB)
3.1.5.1. captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization
3.1.6. Governance Log
3.1.6.1. provides a record of governance activity across the enterprise
3.1.7. Architecture Capability
3.1.7.1. defines the parameters, structures, and processes that support governance of the Architecture Repository
3.1.8. Architecture Requirements Repository
3.1.8.1. provides a view of all authorized architecture requirements which have been agreed with the Architecture Board
3.2. Architecture Capability
3.2.1. put in place appropriate organization structures, processes, roles, responsibilities, and skills to realize the Architecture Capability.
3.2.2. “Financial Management
3.2.3. Performance Management
3.2.4. Service Management
3.2.5. Risk Management
3.2.6. Resource Management
3.2.7. Communications and Stakeholder Management
3.2.8. Quality Management
3.2.9. Supplier Management
3.2.10. Configuration Management
3.2.11. Environment Management”
3.3. Document Categorization Model
3.3.1. TOGAF Core consists of the fundamental concepts that form the essence of TOGAF.
3.3.2. TOGAF Mandated consists of the normative parts of the TOGAF specification. These elements of TOGAF are central to its usage and without them the framework would not be recognizably TOGAF. Strong consideration must be given to these elements when applying TOGAF.
3.3.3. TOGAF Recommended consists of a pool of resources that are specifically referenced in TOGAF as ways in which the TOGAF Core and Mandated processes can be accomplished (e.g., the SEI Architecture Trade-Off Analysis Method or business scenarios).
3.3.4. TOGAF Supporting consists of additional resources that are not referenced in the other three TOGAF categories itself but provide valuable assistance.
3.4. Building Blocks (2)
3.4.1. 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.”
3.4.1.1. “It considers implementation and usage, and evolves to exploit technology and standards
3.4.1.2. It may be assembled from other building blocks
3.4.1.3. It may be a subassembly of other building blocks
3.4.1.4. Ideally, a building block is re-usable and replaceable, and well specified with stable interfaces
3.4.1.5. Its specification should be loosely coupled to its implementation, so that it can be realized in several ways without impacting the building block specification”
3.4.2. ABB
3.4.2.1. “architecture documentation and models from the enterprise’s Architecture Repository classified according to the Architecture Continuum - phase ABCD
3.4.3. SBB
3.4.3.1. “They are implementations of the architectures identified in the enterprise’s Architecture Continuum and may be either procured or developed - phase E
3.5. Architecture views and viewpoints, stakeholders (2)
3.5.1. Concepts
3.5.1.1. “A system is a combination of interacting elements organized to achieve one or more stated purposes.”
3.5.1.2. Stakeholders are individuals, teams, organizations, or classes thereof, having an interest in a system. They are people who have key roles in, or concerns about, the system; for example, users, developers, etc.”
3.5.1.2.1. Sample
3.5.1.3. Architecture view is a representation of a system from the perspective of a related set of concerns. An architecture view is what you see (or what a stakeholder sees).
3.5.1.4. Architecture viewpoint is the specification of the conventions for a particular kind of architecture view. It establishes the conventions for constructing, interpreting, and using an architecture view to address a specific concern (or set of concerns) about a system-of-interest. It effectively defines the perspective from which an architecture view is taken.”
3.5.1.4.1. “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 (an architecture viewpoint can also be thought of as a schema).
3.5.1.4.2. “An architecture view is what a stakeholder sees.”
3.5.1.4.3. Architecture viewpoints are generic, and can be stored in libraries for re-use, known as a viewpoint library.
3.5.1.4.4. An architecture view is always specific to the architecture for which it is created.”
3.6. Reference models (2)
3.6.1. Technical Reference Model (TRM) - Foundation Architecture
3.6.1.1. First considered in phase D - TA
3.6.1.2. 1. A taxonomy that defines terminology, and provides a coherent description of the components and conceptual structure of an information system
3.6.1.3. 2. A model, with an associated TRM graphic, that provides a visual representation of the taxonomy, as an aid to understanding”
3.6.2. Integrated Information Infrastructure Reference Model (III-RM)
3.6.2.1. Phase C - Common System Architecture - Boundaryless Information Flow
3.6.2.2. 1. A taxonomy, which defines terminology, and provides a coherent description of the components and conceptual structure of an integrated information infrastructure
3.6.2.3. 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
4. ADM (3+9)
4.1. The Preliminary Phase
4.1.1. describes the preparation and initiation activities required to create an Architecture Capability, including the customization of the TOGAF framework, and the definition of Architecture Principles.
4.1.1.1. Determine the Architecture Capability
4.1.1.1.1. Review the organizational context for conducting Enterprise Architecture
4.1.1.1.2. Identify and scope the elements of the enterprise organizations affected by the Architecture Capability
4.1.1.1.3. Identify the established frameworks, methods, and processes that intersect with the Architecture Capability
4.1.1.1.4. Establish Capability Maturity target
4.1.1.2. Establish the Architecture Capability
4.1.1.2.1. Define and establish the Organizational Model for Enterprise Architecture
4.1.1.2.2. Define and establish the detailed process and resources for Architecture Governance
4.1.1.2.3. Select and implement tools that support the Architecture Capability
4.1.1.2.4. Define the Architecture Principles
4.1.2. Approach
4.1.2.1. Defining the enterprise
4.1.2.2. Identifying key drivers and elements in the organizational context
4.1.2.3. Defining the requirements for architecture work
4.1.2.3.1. “Business requirements
4.1.2.3.2. Cultural aspirations
4.1.2.3.3. Organization intents
4.1.2.3.4. Strategic intent
4.1.2.3.5. Forecast financial requirements”
4.1.2.4. Defining the Architecture Principles that will inform any architecture work
4.1.2.5. Defining the framework to be used
4.1.2.6. Defining the relationships between management frameworks
4.1.2.7. Evaluating the Enterprise Architecture maturity
4.2. Phase A: Architecture Vision - Initial phase
4.2.1. “Set the scope, constraints, and expectations for a TOGAF project. Create the Architecture Vision. Identify stakeholders. Validate the business context and create the Statement of Architecture Work. Obtain approvals.”
4.2.2. Approach
4.2.2.1. Creating the Architecture Vision
4.2.2.2. Business Transformation Readiness Assess
4.2.2.2.1. evaluate and quantify the organization's readiness to undergo a change
4.2.2.3. Business Scenarios
4.2.2.3.1. useful technique to discover and document business requirements, and to articulate an Architecture Vision that responds to those requirements.
4.3. Phase B: Business Architecture
4.3.1. describes the development of a Business Architecture to support an agreed Architecture Vision.
4.3.2. “Business Architecture is a representation of holistic, multi-dimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders. In summary, the Business Architecture relates business elements to business goals and elements of other domains.”
4.3.3. Approach
4.3.3.1. “Developing the Baseline Description”
4.3.3.2. Applying Business Capabilities
4.3.3.3. Applying Value Streams (ITIL)
4.3.3.4. “Applying the Organization Map”
4.3.3.5. Applying Business Modeling
4.3.3.6. “Using the Architecture Repository”
4.4. Phase C: Information Systems Architectures
4.4.1. describes the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures.
4.4.2. Approach
4.4.2.1. Data Architecture
4.4.2.1.1. Data Management
4.4.2.1.2. Data Migration
4.4.2.1.3. Data Governance
4.4.2.2. Application Architecture
4.4.2.2.1. Reference Model - Integrated Information Infrastructure (III-RM)
4.5. Phase D: Technology Architecture
4.5.1. describes the development of the Technology Architecture for an architecture project.
4.5.2. Approach
4.5.2.1. Emerging Technologies: “Technology Architecture needs to capture the transformation opportunities available to the enterprise through the adoption of new technology”
4.6. Phase E: Opportunities and Solutions
4.6.1. describes the process of identifying major implementation projects and grouping them into work packages that deliver the Target Architecture defined in the previous phases.
4.6.1.1. “Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D
4.6.1.2. Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value
4.6.1.3. Define the overall Solution Building Blocks (SBBs) to finalize the Target Architecture based on the Architecture Building Blocks (ABBs)”
4.6.2. Approach
4.6.2.1. Architecture Roadmap - lists individual work packages in a timeline
4.6.2.2. Work Packages - logical group of changes necessary to realize the Target Architecture
4.6.2.3. Transition Architectures - an architecturally significant state between the Baseline and Target Architectures
4.6.2.4. Implementation and Migration Plan - Creation
4.7. Phase F: Migration Planning
4.7.1. describes the development of a detailed Implementation and Migration Plan that addresses how to move from the Baseline to the Target Architecture.
4.7.1.1. Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan
4.7.1.2. Ensure that the Implementation and Migration Plan is coordinated with the enterprise’s approach to managing and implementing change in the enterprise’s overall change portfolio
4.7.1.3. Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholder
4.7.2. Approach
4.7.2.1. For work packages and projects identified, perform a cost/benefit analysis and a risk assessment
4.7.2.2. Finalize a detailed Implementation and Migration Plan
4.8. Phase G: Implementation & Governance
4.8.1. “Provide architectural oversight for the implementation. Prepare and issue Architecture Contracts. Ensure that the implementation project conforms to the architecture.”
4.8.2. Approach
4.8.2.1. Establish an implementation program that will enable the delivery of the agreed Transition Architectures
4.8.2.2. Adopt a phased deployment schedule that reflects the business priorities embodied in the Architecture Roadmap
4.8.2.3. Follow the organization’s standard for corporate, IT, and Architecture Governance
4.8.2.4. Use the organization’s established portfolio/program management approach, where this exists
4.8.2.5. Define an operations framework to ensure the effective long life of the deployed solution
4.9. Phase H: Architecture Change Management
4.9.1. “Provide continual monitoring and a change management process to ensure that the architecture responds to the needs of the enterprise and maximizes the value of the architecture to the business.”
4.9.2. Approach
4.9.2.1. Drivers for Change
4.9.2.1.1. 1. Strategic, top-down directed change to enhance or create new capability (capital)
4.9.2.1.2. 2. Bottom-up changes to correct or enhance capability (operations and maintenance) for infrastructure under operations management
4.9.2.1.3. 3. Experiences with the previously delivered project increments in the care of operations management, but still being delivered by ongoing projects
4.9.2.1.4. 4. Technology-related drivers
4.9.2.2. Change Management Process
4.9.2.2.1. Simplification change: a simplification change can normally be handled via change management techniques -- a requirement to reduce investment
4.9.2.2.2. Incremental change: an incremental change may be capable of being handled via change management techniques, or it may require partial re-architecting, depending on the nature of the change -- a requirement to derive additional value from existing investment
4.9.2.2.3. Re-architecting change: a re-architecting change requires putting the whole architecture through the Architecture Development Cycle again -- a requirement to increase investment in order to create new value for exploitation
4.9.2.3. Refreshment cycle (partial or complete re-architecting) may be required if:
4.9.2.3.1. The Foundation Architecture needs to be re-aligned with the business strategy
4.9.2.3.2. Substantial change is required to components and guidelines for use in deployment of the architecture
4.9.2.3.3. Significant standards used in the product architecture are changed which have significant end-user impact; e.g., regulatory changes
4.10. Requirements Management
4.10.1. Examines the process of managing architecture requirements throughout the ADM
4.10.2. Every stage of a TOGAF project is based on and validates business requirements (Business Scenarios).
4.10.3. “The ability to deal with changes in requirements is crucial, as architecture by its nature deals with uncertainty and change, bridging the divide between the aspirations of the stakeholders and what can be delivered as a practical solution”
4.10.4. Itself does not dispose of, address, or prioritize any requirements; this is done within the relevant phase of the ADM
4.11. Scoping the Architecture
5. ADM Guidelines and Techniques (6)
5.1. The main guideline is to focus on what creates value to the enterprise, and to select horizontal and vertical scope, and time periods, accordingly.
5.2. Architecture Landscape
5.2.1. Strategic Architecture provides an organizing framework for operational and change activity and allows for direction setting at an executive level.
5.2.2. Segment Architecture provides an organizing framework for operational and change activity and allows for direction setting and the development of effective architecture roadmaps at a program or portfolio level.
5.2.3. Capability Architecture provides an organizing framework for change activity and the development of effective architecture roadmaps realizing capability increments.
5.3. Architecture Principles (BDAT)
5.3.1. “ideas that collectively define and guide the organization, from values through to actions and results.
5.3.2. “Enterprise Principles provide a basis for decision-making throughout an enterprise and dictate how the organization fulfills its mission”
5.3.3. They reflect consensus across the enterprise, and embody the spirit of the Enterprise Architecture. Architecture Principles govern the architecture process, affecting the development, maintenance, and use of the Enterprise Architecture.”
5.3.4. Template
5.3.4.1. Statement-Rationale-Implications
5.3.5. Quality
5.3.5.1. “Understandability - The underlying tenets of a principle can be quickly grasped and understood by individuals throughout the organization. The intention of the principle is clear and unambiguous, so that violations, whether intentional or not, are minimized.
5.3.5.2. Robustness - Principles should enable good quality decisions about architectures and plans to be made, and enforceable policies and standards to be created. Each principle should be sufficiently definitive and precise to support consistent decision-making in complex, potentially controversial situations.”
5.3.5.3. “Completeness - Every potentially important principle governing the management of information and technology for the organization is defined. The principles cover every situation perceived.
5.3.5.4. Consistency - Strict adherence to one principle may require a loose interpretation of another principle. The set of principles must be expressed in a way that allows a balance of interpretations. Principles should not be contradictory to the point where adhering to one principle would violate the spirit of another. Every word in a principle statement should be carefully chosen to allow consistent yet flexible interpretation.
5.3.5.5. Stability - Principles should be enduring, yet able to accommodate changes. An amendment process should be established for adding, removing, or altering principles after they are ratified initially.”
5.4. Stakeholder Managment
5.4.1. Phase A - Indentify
5.5. Business Scenarios
5.5.1. “A key factor in the success of any other major project is the extent to which it is linked to business requirements, and demonstrably supports and enables the enterprise to achieve its business objectives. Business scenarios are a technique used to help identify and understand the business requirements that an architecture must address”
5.5.2. Phase Vision to BA-Requirements
5.5.3. SMART
5.5.3.1. Specific, by defining what needs to be done
5.5.3.2. Measurable, through clear metrics for success
5.5.3.3. Actionable, by clearly segmenting the problem and providing the basis for a solution
5.5.3.4. Realistic, in that the problem can be solved within the bounds of physical reality, time, and cost constraints
5.5.3.5. Time-bound, in that there is a clear statement of when the opportunity expires”
5.6. Gap Analysis
5.6.1. “The most critical source of gaps that should be considered is stakeholder concerns that have not been addressed in prior architectural work.”
5.6.2. To highlight a shortfall between the Baseline Architecture and the Target Architecture; that is, items that have been deliberately omitted, accidentally left out, or not yet defined.
5.6.3. Phase E - Solution
5.6.4. Gaps
5.6.4.1. Business domain gaps
5.6.4.1.1. “People gaps (e.g., cross-training requirements)
5.6.4.1.2. — Process gaps (e.g., process inefficiencies)
5.6.4.1.3. — Tools gaps (e.g., duplicate or missing tool functionality)
5.6.4.1.4. — Information gaps
5.6.4.1.5. — Measurement gaps
5.6.4.1.6. — Financial gaps
5.6.4.1.7. — Facilities gaps (buildings, office space, etc.)”
5.6.4.2. Data domain gaps
5.6.4.2.1. “Data not of sufficient currency
5.6.4.2.2. — Data not located where it is needed
5.6.4.2.3. — Not the data that is needed
5.6.4.2.4. — Data not available when needed
5.6.4.2.5. — Data not created
5.6.4.2.6. — Data not consumed
5.6.4.2.7. — Data relationship gaps”
5.6.5. Steps
5.7. Interoperability
5.7.1. “the ability to share information and services”
5.7.2. Operational or Business Interoperability defines how business processes are to be shared
5.7.3. Information Interoperability defines how information is to be shared
5.7.4. Technical Interoperability defines how technical services are to be shared or at least connect to one another”
5.8. Business Transformation Readiness Assessment
5.8.1. “provides a technique for understanding the readiness of an organization to accept change, identifying the issues, and dealing with them in the Implementation and Migration Plan.”
5.8.2. First assessed in Phase A - Vision
5.8.3. Activity
5.8.3.1. “Determine the readiness factors that will impact the organization
5.8.3.2. Present the readiness factors using maturity models
5.8.3.3. Assess the readiness factors, and determine the readiness factor ratings
5.8.3.4. Assess the risks for each readiness factor and identify improvement actions to mitigate the risk
5.8.3.5. Document the findings into the Capability Assessment and later incorporate the actions into the Implementation and Migration Plan in Phases E and F”
5.8.4. Maturity Model
5.9. Risk Management
5.9.1. Initial Level of Risk: Risk categorization prior to determining and implementing mitigating actions.
5.9.2. Residual Level of Risk: Risk categorization after implementation of mitigating actions.
5.9.3. Risk is pervasive in any Enterprise Architecture activity and is present in all phases within ADM
5.10. Capability-Based Planning
5.10.1. business planning technique focuses on business outcomes.
5.10.2. It is business-driven and business-led and combines the requisite efforts of all lines of business to achieve the desired capability. It accommodates most, if not all, of the corporate business models and is especially useful in organizations where a latent capability to respond (e.g., an emergency preparedness unit) is required and the same resources are involved in multiple capabilities.
5.10.3. Dimensions
6. Part IV Architecture Content Framework
6.1. Provides a structural model for architectural content that allows the major work products that an architect creates to be consistently defined, structured, and presented
6.2. Deliverable
6.2.1. Work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders
6.2.2. Deliverables represent the output of projects and those deliverables that are in documentation form will typically be archived at completion of a project, or transitioned into an Architecture Repository as a reference model, standard, or snapshot of the Architecture Landscape at a point in time.
6.2.3. Input&Output
6.2.4. Samples
6.2.4.1. Architecture Requirements Specification
6.2.4.1.1. provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture.
6.2.4.2. Architecture Definition Document
6.2.4.2.1. 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).
6.3. Artifact
6.3.1. is an architectural work product that describes an aspect of the architecture
6.3.2. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things).
6.4. Building Block
6.4.1. Represents a (potentially re-usable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions
6.4.1.1. a package of functionality defined to meet the business needs across an organization
6.4.1.2. has a type that corresponds to the enterprise's content metamodel (such as actor, business service, application, or data entity)
6.4.1.3. has a defined boundary and is generally recognizable as "a thing" by domain experts
6.4.1.4. may interoperate with other, inter-dependent building blocks.
6.4.2. Good when
6.4.2.1. Ideally a building block is re-usable and replaceable, and well specified
6.4.2.2. It considers implementation and usage, and evolves to exploit technology and standards
6.4.2.3. It may be assembled from other building blocks
6.4.2.4. It may be a subassembly of other building blocks
6.4.3. ABB
6.4.3.1. Capture architecture requirements; e.g., business, data, application, and technology requirements
6.4.3.2. Direct and guide the development of SBBs
6.4.4. SBB - may be either procured or developed.
6.4.4.1. Define what products and components will implement the functionality
6.4.4.2. Define the implementation
6.4.4.3. Fulfil business requirements
6.4.4.4. Are product or vendor-aware
6.4.5. Process with ADM
6.5. Metamodel
7. Part V Enterprise Continuum (4)
7.1. 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.
7.1.1. Architecture Continuum offers a consistent way to define and understand the generic rules, representations, and relationships in an architecture, including traceability and derivation relationships
7.1.2. Solutions Continuum provides a consistent way to describe and understand the implementation of the assets defined in the Architecture Continuum
7.1.2.1. The Solutions Continuum represents the detailed specification and construction 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.
7.1.3. The relationship between the Architecture Continuum and the Solutions Continuum is one of guidance, direction, and support.
8. Part VI Architecture Governance (4)
8.1. Governance is about ensuring that business is conducted properly. It is less about overt control and strict adherence to rules, and more about effective usage of resources to ensure sustainability of an organization’s strategic objectives.
8.1.1. Implementing a system of controls over the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization
8.1.2. Implementing a system to ensure compliance with internal and external standards and regulatory obligations
8.1.3. Establishing processes that support effective management of the above processes within agreed parameters
8.1.4. Developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization
8.2. Conceptual Structure
8.3. Organizational Structure
8.3.1. Architecture Board
8.3.1.1. Providing the basis for all decision-making with regard to changes to the architectures
8.3.1.2. Consistency between sub-architectures
8.3.1.3. Establishing targets for re-use of components
8.3.1.4. Flexibility of Enterprise Architecture; to meet business needs and utilize new technologies
8.3.1.5. Enforcement of Architecture Compliance
8.3.1.6. Improving the maturity level of architecture discipline within the organization
8.3.1.7. Ensuring that the discipline of architecture-based development is adopted
8.3.1.8. Supporting a visible escalation capability for out-of-bounds decisions
8.4. Architecture Contracts
8.4.1. Joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture.
8.5. Architecture Compliance
8.5.1. Conformance
8.5.2. Purpose
8.5.2.1. To catch errors in the project architecture early, and thereby reduce the cost and risk of changes required later in the lifecycle; this in turn means that the overall project time is shortened, and that the business gets the bottom-line benefit of the architecture development faster
8.5.2.2. To ensure the application of best practices to architecture work
8.5.2.3. To provide an overview of the compliance of an architecture to mandated enterprise standards
8.5.2.4. To identify where the standards themselves may require modification
8.5.2.5. To identify services that are currently application-specific but might be provided as part of the enterprise infrastructure
8.5.2.6. To document strategies for collaboration, resource sharing, and other synergies across multiple architecture teams
8.5.2.7. To take advantage of advances in technology
8.5.2.8. To communicate to management the status of technical readiness of the project
8.5.2.9. To identify key criteria for procurement activities (e.g., for inclusion in Commercial Off-The-Shelf (COTS) product RFI/RFP documents)
8.5.2.10. To identify and communicate significant architectural gaps to product and service providers
8.5.3. Review process
8.6. Benifits
8.6.1. Links IT processes, resources, and information to organizational strategies and objectives
8.6.2. Integrates and institutionalizes IT best practices
8.6.3. Aligns with industry frameworks such as COBIT (planning and organizing, acquiring and implementing, delivering and supporting, and monitoring IT performance)
8.6.4. Enables the organization to take full advantage of its information, infrastructure, and hardware/software assets
8.6.5. Protects the underlying digital assets of the organization
8.6.6. Supports regulatory and best practice requirements such as auditability, security, responsibility, and accountability
8.6.7. Promotes visible risk management