• Save
CBDI SAE Togaf V1 21072008
Upcoming SlideShare
Loading in...5
×
 

CBDI SAE Togaf V1 21072008

on

  • 5,756 views

A comparison between CBDI's Service Architecture and Engineering method and the Open Group's TOGAF (version 8.1.1)

A comparison between CBDI's Service Architecture and Engineering method and the Open Group's TOGAF (version 8.1.1)

Statistics

Views

Total Views
5,756
Views on SlideShare
5,620
Embed Views
136

Actions

Likes
10
Downloads
0
Comments
2

8 Embeds 136

http://cbdi.wikispaces.com 99
http://jisi.dreamblog.jp 12
http://www.slideshare.net 11
http://onlytekkie.blogspot.com 8
https://cbdi.wikispaces.com 3
http://onlytekkie.blogspot.co.nz 1
http://onlytekkie.blogspot.nl 1
http://www.docshut.com 1
More...

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • This has to be much more widely distributed. As Cloud becomes more prevalent, there will be a much greater battle between the systems engineers and software engineers as greater attention to modeling and architectural modeling for each comes to the forefront, causing the lines between the two begin to blur. This will be most on display as mid to senior level technologists fight over the use of public vs. private clouds, with Hybrid Clouds being the likely long-term winner. Clouds typically mean Virtualization and SOA, and Architects are fighting to get their heads around these two technologies. When ArchiMate & TOGAF are applied to methodologies like IBM's CCRA and SOMF [each already borrows from TOGAF in their present form, but I mean specific to each individual project] and you bring in CBDI's SoaML mapping, you can actually come up with an entire enterprise model framework that makes sense and allows your application and infrastructure/technology architects [respectively] create models and artifacts that map to the enterprise architecture model AND the business need.
    Are you sure you want to
    Your message goes here
    Processing…
  • soa
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

CBDI SAE Togaf V1 21072008 CBDI SAE Togaf V1 21072008 Presentation Transcript

  • TOGAF and CBDI Service Architecture & Engineering TM
  • Agenda
    • Executive Summary Comparison
    • TOGAF Baseline
    • CBDI Service Architecture & Engineering SAE TM Baseline
      • Scope of Frameworks and models
      • Knowledgebase/Methodology structure
    • Type of Architecture?
    • CBDI-SAE TM Process Framework and TOGAF
      • ADM Phases compared to SAE Process Units
    • Summary
    Caveat Emptor: Discussion of TOGAF is based on publicly available materials and this analysis would benefit from TOGAF practitioner input and feedback
  • Creating full service life cycle integration from business to execution TOGAF CBDI SAE Architecture method Business Architecture Architecture Views Inputs Deliverables Governance Organization Contracts Patterns Skills SO Model SOA Maturity & Adoption SO Business Modeling SO Business Improvement SO Architecture Methodology SO Solution Architecture Method SO Provisioning SO Delivery SO Assembly SO Platform Design SO Platform Delivery SO Governance SO Organization ITIL, FEAC, MoDAF, DoDAF, Zachman, Archimate, Prince EA Development Methodology Requirements Management Enterprise Continuum EA Scoping Methodology Technical Reference Architecture Platform Taxonomy Standards Information Base Integrated Information Infrastructure Reference Model EA Board Architecture Compliance Architecture Contracts Architecture Governance Architecture Maturity Models EA Patterns EA Principles EA Skills OTHER FRAMEWORKS
  • TOGAF and CBDI-SAE Compared Mature, federated SOA organization with managed service assets delivering improved ROI. The right balance between IT efficiency and innovation. Integrated IT strategy across the extended enterprise. Better return on ROI. Outcomes Enterprise and solution architects; business analysts, project and program managers, designers, asset managers, test managers, version managers. Enterprise Architects Users Defined process to integrate with other frameworks and methods Designed to integrate with other frameworks and methodologies Openness Based on detailed SOA meta concept model. Tasks, techniques and deliverable templates etc link to meta model for consistency. UML Profile guides architecture & design asset management. Reference models for: - technical reference model - Integrated Information Integration Reference Model Integrity SOA, SO Broad set of application styles Application style Business driven SOA Boundaryless information flow Vision SOA Adoption, Business design, Enterprise architecture, solution architecture, provisioning, legacy planning, delivery, governance, delivery management Enterprise Architecture and delivery governance Life cycle Detailed guidance on process, task, technique, deliverable, templates, model formats, and meta data for service architecture to delivery Detailed guidance on inputs, outputs, steps in EA Depth in technical reference architecture Detail Full service life cycle methodology for services, service based solutions and service based organizations Enterprise Architecture and delivery governance Scope CBDI SAE TOGAF Comparative criteria
  • TOGAF Baseline
    • TOGAF is an Architecture Development Method (ADM):
      • An enterprise architecture framework
      • Covers Business, Data, Applications and Technology architecture
      • Iterative method
      • Variable coverage of enterprise
      • Variable time horizon
      • Intended to be used with other frameworks
      • Generic, designed to be adapted
    • TOGAF does not prescribe:
      • A specific set of architecture views
      • Any specific set of enterprise architecture deliverables
  • TOGAF Versions
    • TOGAF 8.1.1
      • Published April 2007
      • Does not explicitly support SOA
    • TOGAF 9
      • Work in progress
      • Intended to support SOA
  • Service Architecture & Engineering TM (SAE) Baseline
    • SAE is:
      • A methodology for SOA
      • A set of frameworks
      • Addresses service architecture and engineering
      • Covers full life cycle of service from adoption to business design to operations and management
      • Detailed deliverables, techniques, guidance
      • Designed to be integrated with other frameworks
    • CBDI:
      • Plan to undertake detailed mapping to TOGAF 9 and provide a framework overlay for TOGAF users
      • Are currently mapping the Open Group’s Archimate language to SAE TM
    CBDI-SAE TM SOA Reference Framework Model SOA Principles Service Life Cycle SOA Meta Model Glossary Architecture Business Deployment Patterns Policy Techniques SOA Views Organization Roles & Structure Funding Models Project Profiles Models Deliverables SOA Best Practice Process Enable Consume Manage Provide Technology Standards Implementation Specification
  • CBDI-SAE TM Frameworks and Models Business View Service Perspective Service Catalog Logical Specification of Software Services Service = Service Specification Service = Software Service Impl. Service Packaging into Automation Units Deployment of Automation Units Service = Run-Time Software Service Business Service = Services offered by Organizational Units Business Service, Context for Software Services Sample Artifacts Specification Implementation Deployment Infrastructure e.g. Network Layout, ESB Infrastructure Service = Run-Time Platform Logical Network Services Physical Network Automation Unit Specification Service Platform Design Specification SO Business Plan Service Implementation Architecture Service Deployment Architecture Service Specification Architecture Technical Architecture Service Specification Service Level Agreement SO Business Model Service Implementation SO Security Architecture Service Portfolio Plan SO Reference Architecture Model SOA Principles Service Life Cycle SOA Meta Model Glossary Architecture Business Deployment Patterns Policy Techniques SOA Views Organization Roles & Structure Funding Models Project Profiles Models Deliverables SOA Best Practice Process Enable Consume Manage Provide Technology Standards Implementation Specification SAE Meta Model PROJECT & SYSTEM OUTCOMES SERVICE OUTCOMES BUSINESS OUTCOMES SERVICE ARCHITECTURE & ENGINEERING PROCESS LEADERSHIP & GOVERNANCE SOA PERFORMANCE MANAGEMENT CAPABILITY ARCHITECTURAL CAPABILITY PROCESS / LIFECYCLE CAPABILITY INFRASTRUCTURE CAPABILITY PEOPLE & ORGANIZATION SOA Adoption & Excellence SO Process Coordinated Architecture Scope Solution Assembly/ Implementation Solution Design, Specification & Coordination SO Business Requirements Planning Legacy Transition Planning Service Implementation Solution/Service Deployment Solution/Service Platform Design & Installation Consume Provide Enable [Business Strategy & Architecture] [SOA Adoption Plan] [IT inventory] [IT Strategy & Architecture] [Solution Project Justification, Project Requirements [Deployed Services, Service Discovery Artifacts, Service Access Procs] [Guidelines (e.g. ITIL)] [IT Strategy & Architecture] [Legacy Transition Plan] [Project Charter] [Service Descriptions (part of Project Service Plan/SPP)] [Tested AU Units] [Service Deployment Instructions, Tested AU Units] [Solution Architecture, Component Descriptions, Solution Design Scope] SO Business Improvement [SOA Reference Framework] [Service Platform Design, Tested Service Platform, Installed Service Platform] Solution Certification [Solution Imp Design, Tested Software Solution (deployed)] Solution Provisioning Service Oriented Architecture & Design Solution/Services Platform Architecture [Solution/ Services Platform Architecture] [Project Service Architecture/SPP, SO Security Arch] [Business Models, Business Case for SOA, SO Business Design, Business Solution Requirements] Solution Architecture & Design [Service Specs, Usage SLA] [Solution Deployment Instructions, Tested Software Solution] [Solution Deployment Authorization/(Certified), Solution OLA] Solution/Service Operations & Measurement [Solution & Service Execution Metrics] [Deployed Software Solution] [SO Business Improvement Plan] [Business Results] SOA Adoption Plan Governance & Management Framework Manage [Project Service Plan/ SPP Fragment (approved)] Service Certification Service Provisioning Service Design, Specification & Coordination [Service Specs (approved) , AU Descriptions (approved)] [ Services (published)] [Business Process Execution Metrics] [ SPP, SO Security Architecture] [Project Service Plan] [Solution Design, Solution Test Plans, Component Specs Service Requirements SPP Fragment [Installed Service Platform] [Service Deployment Authorization/ Services (certified) , Service OLA] [(Service Catalog (updated)]] SOA Governance SOA Policy Hierarchy SOA Governance Process SOA Governance Maturity SOA Governance Infrastructure SOA Governance Organization Service Life Cycle Planned Specified Certified Published Operational Retired Being Provisioned Provisioned Archived CBDI-SAE TM SOA Reference Framework
  • CBDI-SAE Knowledgebase Structure - 1 Document Libraries Lists Web Part Pages Menu Model Process Disciplines Architecture Concept Meta Model Type Glossary Service Life Cycle State Discipline Process Unit Task SOA View SOA Best Practice Policy Standard Artifact Technique Pattern Principle Meta Model Package Process Pattern Service Classification
  • CBDI-SAE Knowledgebase Structure - 2 Document Libraries Lists Web Part Pages Menu SOA Adoption & Excellence SOA Governance Roadmap Phase Roadmap Stream SOA Capability SOA Scenarios Governance Capability Governance Framework View Governance Maturity View Capability Dependency Model SOA Policy Category SOA Policy Strategy Area SOA Policy Types SOA Meta Model Service Life Cycle Service Architecture Service Architecture Layer
  • CBDI-SAE Knowledgebase Structure - 3 Document Libraries Lists Web Part Pages Menu Resources Deliverable Templates Project Management Templates Models Capability Dependency Templates Organization Role Project Project Profile Funding Model Presentation Materials Policy Examples Guidance Start Here eLearning Materials
  • Type of Architecture?
    • TOGAF (Types of Architecture)
      • Business (or Business Process) Architecture – business strategy, governance, organization and key business processes
      • Data Architecture – logical and physical data assets
      • Applications Architecture – blueprint for individual application systems to be deployed
      • Technology Architecture – logical software and hardware capabilities required to support deployment
    • SAE (View)
      • Business - business needs and how the business operates in terms of goals and objectives, organizational structure, processes, information
      • Specification - software services from a platform independent perspective. Logical services and their interrelationships
      • Implementation - services packaged into automation units, dependencies between the automation units, implementation constraints that will govern the internal design and deployment of these units.
      • Deployment - deployment choices for run time services. Implementation view services mapped to deployment units and defined optimum configuration on the computing infrastructure.
      • Technology - technologies to enable the service lifecycle at all levels – from planning through specification, design and execution to retirement.
    Information Systems Architecture Comment: A key aspect of SOA is the clear separation of logical services from implementation or the application architecture by contract based interface. TOGAF 8.1.1 does not define “service” as a first order concept, and it would be expected that this will change in TOGAF 9
  • CBDI-SAE TM Process Framework and TOGAF Solution Assembly/ Implementation SO Business Modeling Legacy to Service Transition Planning Service Provisioning Service Implementation Solution/Service Deployment Solution/Service Platform Design & Installation Consume Provide Enable SO Business Improvement Solution Provisioning Service Oriented Architecture & Design Solution/Service Platform Architecture Solution Architecture & Design Solution/Service Operations & Management SOA Adoption & Excellence SOA Governance Manage SOA Delivery Management
    • SAE will complement TOGAF in development of architecture. Specifically in the Disciplines:
      • SO Architecture & Design
      • Solution Architecture & Design
      • Solution & Service Platform Architecture
    • Providing detailed process guidance, deliverable specifications, techniques, templates . . . and governance
    • SAE provides an holistic framework covering the entire service life cycle
    TOGAF
  • SAE Extends TOGAF in core areas of Architecture TOGAF ADM PHASE Objectives Approach Inputs Outputs SAE DISCIPLINE Process Unit Task Technique Pattern Policy Model Deliverable . . .
  • ADM Phase – Preliminary: Framework and Principles
    • TOGAF
    • Objectives:
      • Define process, principles, scope, organization, framework and methodologies, tools requirements
    • Principles
      • Define underlying rules and guidelines – link to business objectives
    • SAE
    • Process Units:
      • Design & Evolve Reference Framework
    • Assets and resources:
      • Service architecture framework including candidate policies
      • Candidate principles
      • Defined deliverables
      • Guidance on integration with existing frameworks including project mgt, EA, ITIL
    • Comment: highly complementary – provides detailed reference framework task structure and descriptions, specifically focused on the service architecture.
  • ADM Phase – A: Architecture Vision
    • TOGAF
    • Objectives
      • Ensure recognition and endorsement, validate business principles and goals, define scope, define stakeholders, key business requirements,
      • Articulate architecture vision, secure formal approval
      • Understand impact on other architecture dev cycles
    • SAE
    • Process Units
      • Prepare and evolve Service Portfolio Plan
    • Assets and Resources
      • Detailed task and technique structure
      • Defined deliverables
    • Comment: Focus on architecture scope
  • ADM Phase – B: Business Architecture
    • TOGAF
    • Objectives
      • Describe baseline and target business architecture, analyze gaps, demonstrate how stakeholder concerns will be addressed, select relevant tools
    • Outputs
      • Validated business principles
      • Org structure
      • Business goals and objectives
      • Business functions
      • Business services
      • Business processes
      • Business roles
      • Business Data model
      • Correlation of organization and function
      • Gap analysis
    • SAE
    • Process Units
      • Discover and describe AS IS business
      • Specify TO BE business
      • Produce business case
    • Assets and Resources
      • Detailed task and technique structure specific to service identification:
        • Business Triage Strategy Modleing
        • Business Domain Modeling
        • Business Process Modeling
        • Business Capability Modeling
        • Business Concept Modeling
        • See next 2 slides for details
    • Comment: Focus on creating business models that drive out high quality service architectire
  • SAE: Key Business View Artifacts - I Rich pictures complemented by matrices that map domains to business concepts and business processes Separation of core concepts and processes into logical subdivisions of the business. May or may not mirror current organization Business Domains Key Artifact Focus Typical Format Ecosystem/Business Context Model (Part of SO Business Model) Products or Services offered by a Business or Organizational Unit and the use of those products or services by their customers and suppliers. BPMN diagrams, UML models including structure diagrams (e.g., package, class, component), behavior diagrams (e.g., Activity or Interaction Diagrams) other proprietary formats Business Goals (Part of SO Business Model) High-level goals of the business and the sub-goals they comprise. UML Object Diagram, other proprietary formats such as Hierarchy Diagram Event Response (Part of SO Business Model) Major business events and the organization’s response to them. BPMN Diagrams, or Activity Diagrams, other proprietary formats Business Process (Part of SO Business Model) Business processes that realize the services offered by the business. BPMN Diagrams, UML Activity Diagrams, other proprietary formats Business Rules A statement that constrains how the business operates. A textual table. More formal rule models use UML Class Diagrams with Constraints (in text or in OCL (Object Constraint Language)) or other proprietary formats Business Concept Model (Part of SO Business Model) High-level information entities that are important at a business level. UML Class Diagrams, ERDs, other proprietary formats with restricted detail
  • SAE: Key Business View Artifacts - II Key Artifact Focus Typical Format Organizational Structure (Often part of SO Business Model) Organizational units and roles therein that comprise a business or enterprise. Organizational Charts, UML Object Diagrams, other proprietary formats Business Case for SOA Justification for migrating to SOA. Key influence over SOA approach and architecture policy. E.g forecast cost and cycle time of delivery and adaptation by class of component and service Textual documents and spreadsheets SO Business Improvement Plan Plan for improving business operations by incorporating services Key driver of architecture decisions that enable agility E.g forecast change cycle time for classes of components and services Textual documents, project schedules, and spreadsheets Business Solution Requirements Solution requirements from a business perspective Textual documents and requirements models SO Business Plan Overall plan for moving the business forward including SO perspectives Composite artifact including SO Business Models, Business Case for SOA, and Business Solution Requirements SO Security Policies (part of SO Security Architecture) Detailed business rules and policies concerning security Textual document(s)
  • ADM Phase – C: Information Systems Architecture
    • TOGAF
    • Objectives
      • Develop target architectures covering either or both data and application system domains
    • Outputs
      • Baseline and target data architecture
      • Baseline and target application architecture
      • Data architecture views
      • Application architecture views
      • Gap analysis
      • Impact analysis
      • Updated business requirements
    • SAE
    • Process Units
      • Prepare and Evolve Service Portfolio Plan
      • Create Project Service Plan
      • Design and Evolve SO Security Architecture
      • Survey existing assets for Potential Services
    • Assets and Resources
      • Detailed task and technique structure specific to service architecture:
        • Service Portfolio Plan
        • Service Domains
        • Service Specification Architecture
        • Service Implementation Architecture
        • Service Deployment Architecture
        • See next slides for details . . .
    • Comment: Focus on creating service specification, implementation and deployment architecture
  • SAE - Key Specification View Artifacts Key Artifact Focus Typical Format Service Specification Architecture Complete logical model of the software services and their relationships to solutions, legacy applications and other 3 rd party applications. UML Model including structural diagrams (e.g., package, class, component) and behavioral diagrams (e.g., communication, sequence, state). Service Dependency Diagram (part of Service Specification Model) Architectural layers at a logical level and the structural relationships between the services in these layers. UML Package and Class Diagrams Service Orchestration Diagram (part of Service Specification Architecture ) Interactions between services that collaborate to provide services at a higher level. UML Interaction Diagrams (Communication and/or Sequence Diagrams) Service Information Model (part of Service Specification) Structure of the information used by services at a logical level. UML Class Diagrams or ERD Diagrams Service Description Overview of a service Textual document Service Specification Detailed specification of a particular service including both functional and non-functional requirements Textual document and UML models SO Security Specifications (part of SO Security Architecture) Specifications for security services/mechanisms and how they are used by other services in the architecture Textual documents and UML models
  • Key Implementation View Artifacts Key Artifact Focus Typical Format Service Implementation Architecture Structure of Automation Units and software modules that realize logic services UML model containing structural diagrams (e.g., package, component and class) and behavioral diagrams (e.g., communication and sequence) Solution Implementation Design Structure and orchestration of services that comprise composite applications UML model containing package, class and/or component diagrams Physical Data Model (often part of the Service Implementation Architecture) Physical structure of the data used by the service or set of services UML model containing package and class diagrams Service Message Structure (often part of the Service Implementation Architecture) Structure of messages transferred back and forth during service interactions UML model containing package and class diagrams Service Message Patterns (often part of the Service Implementation Architecture) Typical patterns of messages exchanged during service interactions UML interaction diagrams (communication and/or sequence diagrams) Automation Unit Description Overview description of a particular Automation Unit Textual document Automation Unit Specification Detailed Specification of an Automation Unit Textual document and UML models Solution Implementation Actual software that implements a solution Source code Service Implementation Actual software that implements a service Source code
  • Key Deployment View Artifacts Key Artifact Focus Typical Format Service Deployment Architecture Static structure and interactions of the Automation Units and their deployment to the Nodes on which they will run UML model containing deployment diagrams Runtime Communication Channels (part of the Service Deployment Architecture Communications Channels between the Nodes on which the Automation Units run UML model containing deployment diagrams Service Platform Design Specification (for example ESB) Detailed specification of the Service Platform including the infrastructure services provided by the platform Textual document and UML models
  • ADM Phase – D: Technology Architecture
    • TOGAF
    • Objectives
      • Develop the technology architecture
    • Outputs
      • Baseline technical architecture
      • Validated technology principles, or new technology principles
      • Technology Architecture report
      • Technology Architecture Gap report
      • Viewpoints and Views for Stakeholder concerns
    • SAE
    • Process Units
      • Design Service Platform
    • Assets and Resources
        • Detailed guidance on service technology architecture planning, management and selection
        • See next slide for details . . .
    • Comment: Focus on creating service technology architecture
  • Key Technology View Artifacts Key Artifact Focus Typical Format Logical Network and Platform Services Design Model Logical network layout including processing nodes and network nodes, as well as communication channels between them and the services that run thereon. UML models containing class and object diagrams, UML deployment diagrams Technology Dependency Dependencies between technologies used to implement the SOA Textual documents, UML models containing class diagrams (showing dependencies), or other proprietary formats Physical Network Design (part of the Logical Network and Platform Services Design Model) Physical layout of the network Network diagrams in Visio or other proprietary notations, UML models containing class and object diagrams
  • ADM Phase – E: Opportunities and Solutions and F: Migration Planning
    • TOGAF
    • Objectives
      • Evaluate and select amongst implementation options (build vs buy vs reuse)
      • Identify top level work packages
      • Asses dependencies, costs and benefits
      • Generate overall implementation and migration strategy
      • Sort implementation projects into priority order.
    • Outputs
      • Implementation and migration strategy
      • High level implementation plan
      • Impact analysis
    • SAE
    • Process Units
      • Plan SOA Adoption
      • Prepare and evolve service portfolio plan (migration plan; service description)
      • Create Service Project Plan (implementation plan and service description)
      • Design Service Platform
      • Plan Service Provisioning
      • Solution Provisioning
    • Comment: Identification of options is undertaken progressively across adoption planning, architecture development and specific service provisioning. It seems likely the best match to TOGAF Phase E is the Process Unit Prepare and evolve service portfolio plan and or create Service Project Plan; but the broader list is included for context and completeness. .
    • Assets and Resources
      • At the planning level the Service Description provides outline metadata on the planned service. This is a subset of the full service specification, and will include assumptions or decisions on implementation options.
  • ADM Phase – G: Implementation Governance
    • TOGAF
    • Objectives
      • Formulate recommendations for each implementation project
      • Construct an architecture contract to govern the implementation and deployment process
      • Perform governance functions
      • Ensure conformance
    • Outputs
      • Impact analysis
      • Architecture Contract
      • Architecture compliant system
    • SAE
    • Process Units
      • Set and Maintain SOA Policy
      • Set SOA Governance Framework Strategy
      • Monitor SOA Policy Compliance
      • Evolve SOA Governance Framework
    • Comment: Detailed guidance on set up and execution of SOA specific governance
    • Assets and Resources
      • SOA Governance Framework
      • SOA Policy Instance (candidates)
      • SOA Policy Instance Template
      • SOA Policy Type (detailed)
      • SOA Policy Type Hierarchy (candidates)
      • SOA Policy Type Template
      • SOA Governance Plan
      • SOA Governance Maturity Assessment (candidate)
  • ADM Phase – H: Architecture Change Management
    • TOGAF
    • Objectives
      • Establish architecture change management process
    • Outputs
      • Architecture updates
      • Changes to framework and principles
      • New requests
    • SAE
    • Process Units
      • Prepare and Evolve Service Portfolio Plan
      • Design and Evolve Security Architecture
    • Comment: The Service Portfolio Plan is a mechanism for continuous evolution of the service assets, and a basis for coordination across disparate projects and organization units (providers and consumers)
    • Assets and Resources
      • Service Portfolio Plan
  • ADM Phase: Requirements Management
    • TOGAF
    • Objectives
      • Define a process whereby requirements for enterprise architecture are identified . . .
    • Outputs
      • Architecture updates
      • Changes to framework and principles
      • New requests
    • SAE
    • Process Units
      • Not explicitly addressed
  • Summary
    • TOGAF
      • Is an EA Methodology Framework
      • It provides a process with checklists of identified inputs and outputs.
      • TOGAF provides a framework into which the detailed SAE process and task and technique guidance can be integrated
    • SAE:
      • Is an SOA methodology
      • Does not claim to be an EA methodology
      • Provides broader scope that purely architecture.
      • Narrow path scope focused on guiding planning to delivery of services.
      • In this area provides more detailed guidance than TOGAF, based on full life cycle meta concept model that better integrates architecture and delivery, supports iterative architecture development etc. Provides:
        • detailed process and task and technique guidance
        • a meta model
        • templates and worked examples
      • Intended to be integrated with other frameworks that manage other application styles, enterprise architecture, and other concerns such as ITSM, project management etc
  • Independent Guidance for Service Architecture and Engineering www.cbdiforum.com www.everware-cbdi.com