CEA-C01 cheat sheet

Enterprise architecture (EA) is the organizing logic for business processes and IT infrastructure, reflecting the integration and standardization requirements of the company's operating model.

EA is distinct from solution architecture (single system scope) and segment architecture (a business line or program scope); EA spans the whole enterprise and provides the context those narrower efforts fit into.

Core EA deliverables: current-state (as-is) description, future-state (to-be) description, transition plan, and architecture roadmap.

Architecture building blocks (ABBs) describe required capability and are technology-neutral; solution building blocks (SBBs) are the concrete components that realize ABBs.

Architecture principles are enduring, rarely changed statements of belief that guide decision-making; they differ from policies (mandatory rules) and standards (specific required technologies).

An architecture principle statement typically contains: name, statement, rationale, and implications.

Stakeholders are individuals or groups with concerns about the architecture; a concern is an interest in the system relevant to one or more stakeholders.

A view is a representation of a set of concerns held by a stakeholder; a viewpoint is the template/convention from which a view is constructed.

Architecture governance provides oversight, decision rights, and compliance mechanisms so that architecture decisions are enforced and exceptions are managed.

Zachman Framework is a 6x6 ontology: six interrogatives (What, How, Where, Who, When, Why) crossed with six perspectives (Planner, Owner, Designer, Builder, Subcontractor, Functioning enterprise).

Zachman is a classification/taxonomy schema, not a methodology; it prescribes no sequence of steps, only cells to populate.

TOGAF Architecture Development Method (ADM) phases in order: Preliminary, A (Architecture Vision), B (Business Architecture), C (Information Systems Architecture), D (Technology Architecture), E (Opportunities & Solutions), F (Migration Planning), G (Implementation Governance), H (Architecture Change Management).

TOGAF Requirements Management sits at the center of the ADM and is continuous across all phases rather than being a sequential phase.

TOGAF Enterprise Continuum runs from Foundation Architectures to Common Systems Architectures to Industry Architectures to Organization-Specific Architectures.

TOGAF Architecture Repository holds the Architecture Metamodel, Architecture Capability, Architecture Landscape, Standards Information Base, Reference Library, and Governance Log.

FEAF (US Federal Enterprise Architecture Framework) organizes around reference models: Performance, Business, Data, Application, Infrastructure/Security; FEAF v2 adds a collaborative, segment-oriented approach.

DoDAF organizes architecture descriptions into viewpoints (e.g., Capability, Operational, Systems, Data & Information, Project) built from a defined set of models.

A framework provides structure for describing architectures; a methodology provides the process; a metamodel defines the entities and relationships allowed in the description.

Viewpoint selection rule: choose viewpoints driven by stakeholder concerns, not by framework completeness; every view must trace to a stated concern.

Consistency rule: the same element appearing in multiple views must have the same name, definition, and relationships across those views (cross-view consistency).

Complementarity rule: views should overlap enough to be reconcilable but not duplicate each other's content.

A model is an abstraction of a subject; a view is a model seen from one perspective; a visualization is the rendering (diagram) of a view.

Architecture implementation follows the gap analysis: baseline architecture → target architecture → gap identification → work packages → transition architectures → roadmap.

A work package is a set of logically grouped change activities; a transition architecture is a formally defined intermediate state between baseline and target.

Implementation governance (TOGAF Phase G) uses architecture contracts between the architecture function and the implementation team to enforce conformance.

Architecture compliance review checks a project's deliverables against the defined architecture; deviations are handled through an architecture dispensation/waiver process.

A capability increment or building block is reusable only if it is documented with its interface, dependencies, and quality attributes in the repository.

Preliminary phase outputs: Architecture Principles, Architecture Capability definition, tailored ADM, and the Architecture Governance framework.

Architecture maturity is commonly assessed with CMMI-style levels (0–5); a maturity assessment precedes capability planning.

Scope rule: define breadth (organizational units), depth (level of detail), and time horizon before committing to an architecture engagement.

Architecture work is prioritized by business value and risk; a stakeholder map plus a concerns/requirements catalog drives the engagement plan.

The Architecture Charter or request for architecture work defines objectives, scope, constraints, budget, and acceptance criteria.

Capacity planning for the architecture practice covers skills (business, data, application, technology), roles (chief architect, domain architects), and tooling.

A communication plan maps each stakeholder group to the views, cadence, and channel used to deliver architecture information.

Architecture metrics should be outcome-based (e.g., reduction in integration points, reuse rate, time-to-decision) rather than activity counts.

Risk in architecture planning is treated with a risk register: likelihood × impact, owner, mitigation, and review date.

Modeling languages: ArchiMate covers business, application, and technology layers plus motivation, strategy, and implementation; UML covers structural and behavioral software models; BPMN covers process flow.

ArchiMate core relationship types include composition, aggregation, realization, serving, access, and association; specialization and triggering are also defined.

ArchiMate layers: Strategy, Business, Application, Technology, Physical, Implementation & Migration, plus cross-cutting Motivation and Composite elements.

A metamodel defines valid element types and legal relationships; models that violate the metamodel are structurally invalid regardless of visual appearance.

Abstraction level rule: model at the level required to answer the stakeholder's question; over-modeling increases cost without adding decision value.

Naming convention rule: use business-meaningful nouns for business elements and verb phrases for behaviors; avoid technology names in business-layer models.

Traceability: requirements should trace to architecture elements, and architecture elements to downstream designs and test cases.

Model repositories should enforce versioning and baselines so that a transition architecture can be reconstructed as of a given date.

Gap analysis compares baseline and target architectures element by element and classifies each difference as eliminated, added, changed, or unchanged.

Impact analysis traces a proposed change through dependency relationships to identify affected applications, data, and processes.

Integration analysis identifies interfaces between building blocks and classifies them by coupling type and data flow direction.

Quality-attribute analysis (e.g., ATAM-style) evaluates an architecture against scenarios for performance, availability, security, and modifiability.

Architecture trade-off analysis makes explicit the cost of a decision: improving one quality attribute often degrades another (e.g., security vs. usability).

Reuse analysis compares candidate building blocks against requirements; a mismatch in non-functional requirements can make reuse more costly than building.

Consolidation analysis identifies duplicate or overlapping capabilities across the portfolio to support rationalization decisions.

Architecture debt is tracked like technical debt: record the deviation, its business impact, and the remediation option with cost estimate.

Portfolio integration aligns the architecture roadmap with program/project portfolios and the annual investment cycle.