Archsight is a Ruby-based enterprise architecture documentation tool that uses a complementary combination of TOGAF and ArchiMate standards:
TOGAF's Role - Conceptual Foundation: TOGAF provides the enterprise architecture framework and metamodel - defining what architecture elements exist, how they relate, and why they matter. It establishes:
- The content metamodel (entity types and their relationships)
- Architecture domains (Business, Data, Application, Technology)
- Governance and lifecycle concepts (baseline, target, transition architectures)
- Strategic alignment principles (drivers → goals → objectives → capabilities)
ArchiMate's Role - Visual Communication: ArchiMate provides the modeling language and notation - defining how to visually represent and communicate architecture. Archsight uses ArchiMate concepts for:
- Visual notation and diagram syntax
- GraphViz-based visualizations
- Standardized representation of resource relationships
- Communication with stakeholders
Archsight's Implementation:
- YAML Resources implement TOGAF's content metamodel entities (Business Actor, Application Component, Technology Service, etc.)
- Resource Relations capture TOGAF's entity relationships for traceability and impact analysis
- Directory Structure follows TOGAF's four architecture domains
- Visualizations use ArchiMate-inspired notation to communicate these TOGAF-based resources
In Summary: TOGAF defines what to document and why, ArchiMate defines how to visualize it, and Archsight provides the tool to manage and render both as YAML-based architecture documentation.
This reference helps Archsight users understand the TOGAF concepts underlying their architecture resources, while recognizing that visual communication follows ArchiMate conventions.
TOGAF (The Open Group Architecture Framework) is a comprehensive framework for enterprise architecture that provides an approach for designing, planning, implementing, and governing enterprise information technology architecture. TOGAF is developed and maintained by The Open Group.
The ADM is TOGAF's core - a step-by-step iterative approach to developing enterprise architecture:
- Preliminary Phase - Preparation and initiation
- Phase A: Architecture Vision - Define scope, stakeholders, create vision
- Phase B: Business Architecture - Business strategy, processes, capabilities
- Phase C: Information Systems - Application and Data Architectures
- Phase D: Technology Architecture - Infrastructure and platforms
- Phase E: Opportunities & Solutions - Initial implementation planning
- Phase F: Migration Planning - Detailed migration plans
- Phase G: Implementation Governance - Oversight of implementation
- Phase H: Architecture Change Management - Manage ongoing change
- Requirements Management - Central hub managing requirements
The ADM is iterative, adaptable to organizational needs, and stakeholder-driven.
TOGAF organizes architecture into four interconnected domains:
Strategy, governance, organization, and business processes.
Elements: Business capabilities, value streams, processes, functions, services, organizational structure
Logical and physical data assets and management.
Elements: Data entities, models, quality, governance, master data
Application systems, interactions, and business process relationships.
Elements: Application components, services, interfaces, functions
Software and hardware capabilities supporting business, data, and applications.
Elements: Platforms, infrastructure, network, hardware, middleware, technology services
The metamodel defines architectural entities and their relationships across all domains. Understanding these connections is essential for comprehensive architecture documentation.
Motivation Layer:
- Driver → Goal → Objective → Course of Action
- Measures track objectives; value streams deliver capabilities
Organizational:
- Organization Unit contains Actors performing Roles
- Actors and roles participate in business functions and processes
Business Behavior:
- Business Capability realized by Business Functions and Processes
- Business Service uses functions/processes, automates application services
- Value Stream enabled by capabilities, operationalized through processes
- Events trigger processes; Products result from them
Data Architecture:
- Data Entity → Logical Data Component → Physical Data Component
- Data entities accessed by business/application services
Application Architecture:
- Application Service → Logical Application Component → Physical Application Component
- Application services automate business services, use data components
Technology Architecture:
- Technology Service → Logical Technology Component → Physical Technology Component
- Technology services support application services and components
Cross-Cutting:
- Principle, Constraint, Requirement, Location
- Stakeholder:
MotivationStakeholder, with its concerns (hasConcern); the organisation unit or actor behind it is linked withrepresentedBy(BusinessActor,BusinessRole). The stakeholder that has the concern is the source of a requirement, as recorded in the requirements repository - Gap, Work Package, Deliverable, Plateau, Implementation Event: the Implementation & Migration layer (
ImplementationGap,ImplementationWorkPackage,ImplementationDeliverable,ImplementationPlateau,ImplementationEvent)
Governance:
- Control: a decision-making step with accountability and authority, applied to a process or function. ArchiMate has no element for it; Archsight models it as
BusinessControl, which aBusinessProcessisguidedBy
Risk and security: the Open Group overlay (Modeling Enterprise Risk Management and Security with the ArchiMate Language) maps threats to Driver (MotivationDriver), threat and loss events to Business/Application/Technology Event, risks and vulnerabilities to Assessment (MotivationAssessment), control objectives to Goal, control measures to Requirement and policies to Principle (MotivationPrinciple), each with a type annotation. See Modeling Guide. How relations are directed (top-down, DAG) is described under Direction of Relations. Which of capability, product, service and component an element is follows the questions in Choosing the Kind.
- Traceability: Drivers → Goals → Objectives → Course of Action → Business Elements → Applications → Technology
- Service Layers: Business Services → Application Services → Technology Services
- Logical-Physical: All domains separate logical design from physical implementation
- Value Chain: Value Stream → Business Capability → Business Service → Application Service
- Data Flow: Business Process → Data Entity → Logical Component → Physical Component
Artifacts (work products describing architecture):
- Catalogs - Lists of building blocks
- Matrices - Relationship mappings
- Diagrams - Visual representations
Deliverables (contractual work products):
- Architecture Vision, Definition Document, Requirements Specification
- Architecture Roadmap, Capability Assessment
- Implementation and Migration Plan, Transition Architecture
Define what functionality is required - architecture entities, relationships, and requirements that guide solution development.
Define how functionality is implemented - specific implementations mapping to actual products and technologies.
Characteristics: Well-defined interfaces and functionality, interoperable, replaceable, reusable
- Rapid Change - Fast iterations, minimal governance, focus on innovation
- Functional Change - Balanced approach, standard governance (most common)
- Robust Change - Rigorous governance, high assurance, compliance-critical
- Architecture Board and contracts
- Compliance reviews at project milestones
- Configuration and version management
- Dispensations and exception handling
- Baseline Architecture - Current state
- Target Architecture - Desired future state
- Transition Architectures - Intermediate states
- Gap Analysis - Compare baseline to target, identify changes needed
- Architecture Repository - Central storage for metamodel, capability, landscape, standards
- TOGAF provides the process (ADM) and content framework
- ArchiMate provides the modeling language and notation
- Complementary: ArchiMate is TOGAF's recommended modeling language
- ADM adapts to agile delivery through iterations
- Architecture vision provides guardrails
- Continuous architecture refinement supports rapid change
- COBIT - IT governance alignment
- ITIL - Service management integration
General rules guiding IT resource use and deployment:
Structure: Name, Statement, Rationale, Implications
Examples:
- Business Continuity - Ensure operations continue
- Data is an Asset - Manage strategically
- Data is Shared - Eliminate redundancy
- Technology Independence - Avoid vendor lock-in
- Interoperability - Enable seamless integration
- Requirements Based Change - Justify all changes
Specification for constructing views - defines stakeholders, concerns, models, techniques, and notations. Reusable across projects.
Representation of the system from specific stakeholder perspectives, addressing their concerns using models defined by viewpoints.
Common Viewpoints: Enterprise, Information System, Computing Platform, Communications, Security, Business Process, Application
- Standardization - Common language and framework across the enterprise
- Efficiency - Reusable processes and proven patterns
- Risk Reduction - Proven approach minimizes project failures
- Better Decisions - Holistic view enables informed strategic choices
- Alignment - Ensures business and IT work toward common goals
- Flexibility - Adaptable to various industries and organizational contexts
- Enterprise - Collection of organizations with common goals
- Architecture - Fundamental concepts/properties of a system in its environment
- Building Block - Component of business or IT capability (reusable architectural component)
- Artifact - Architectural work product (catalog, matrix, diagram)
- Deliverable - Contractually specified work product
- Viewpoint - Perspective from which a view is taken
- View - System representation addressing specific concerns
- Baseline - Current architecture state
- Target - Desired future architecture state
- Gap - Difference between baseline and target requiring action
Reference: The TOGAF® Standard, 10th Edition - The Open Group Architecture Framework Copyright © The Open Group
