Modeling TOGAF with ArchiMate
61 likes15,999 views
The document discusses a case study on modeling TOGAF with ArchiMate, focusing on a company's adoption of methodologies to improve enterprise architecture. It outlines the challenges faced due to complex legacy systems and the necessity for collaboration among different methods, revealing efforts to pilot TOGAF and ArchiMate diagramming within current projects. Key lessons learned include the need for standardized guidelines and enhancements to ArchiMate to better support enterprise modeling initiatives.
Modeling TOGAF with ArchiMate
- 1. January 25, 2011Case Study: Modeling TOGAF™ with ArchiMate®Iver BandOpen Group Conference, San Diego, California, USA
- 2. BackgroundChoosing and Adopting a MethodologyModeling with TOGAF and ArchiMateLearnings and SuggestionsAgendaJanuary 25, 20112
- 3. Founded in 1906 in Portland, Oregon and still based thereWent public in 1999 as Stancorp Financial Group (NYSE: SFG)3,200 employees in 55 offices across the United StatesLargest business is insurance for 26,000 groups with 6.5 million individualsProvides 4,000 group retirement plans for 500,000 participantsAlso offers commercial mortgages, individual disability and annuity, and personal financial adviceInsurance and retirement plans sold through a broad broker networkVisit www.standard.comRecession Layoffs, foreclosures, loss of investments and savingsImpact on disposable incomeIncreased risk of stress-induced health concernsDepression Anxiety Compulsive behaviors (over-easting; excessive gambling and/or spending)Substance abuse About The StandardJanuary 25, 20113
- 4. 4IT at The StandardJanuary 25, 2011
- 5. 5Enterprise Architecture at The StandardSmall EA team with strong business relationships leads broader “Architecture Community”Community-based “Architecture Assurance” process governs major projectsReviews and approves Architecture Notebook rooted in OpenUP software development process Evaluates enterprise implications of proposed architecture Sample initiatives CRMContact Center Master Data ManagementIdentity ManagementLegacy Application Assessment January 25, 2011
- 6. 6EA Challenges and AssetsChallenges
- 8. Demanding business initiatives leave little capacity for tool and methodology development
- 9. Lots of complexity and change to manage relative to available resources
- 10. Assets
- 14. Current and future state application architectures with asset lifecycle states
- 15. Core infrastructure strategy, architecture, roadmaps
- 16. Data center facilities and disaster recovery
- 17. Network
- 18. Server platforms
- 19. Casewise Corporate Modeler and Corporate Exchange
- 20. “Archipedia” SharePoint site collectionJanuary 25, 2011
- 21. 1. Architecture guidance and methods were difficult to use 2. Diversity of methods hindered collaboration7Methodology ChallengesJanuary 25, 2011SlidesPapersERDLandscapesCapabilityMapsArchitectureNotebooksUML 4+1ExecutionArchitecturesPhysicalLifecycle MgmtDiagramsRoadmapsEA Planning
- 22. Desire forMulti-year business-driven technology strategyBusiness service cost transparencyIncreasing importance of SaaS, PaaS, offshore software engineering and on-site consultantsInternal proposals“IT Information Management ““Model-Based Architecture”Enterprise-wide initiatives such as CRM and Contact CenterRealization that we were not getting the full benefit of our Casewise enterprise modeling toolset investmentPast difficulties with proprietary methodologies8Methodology Selection TriggersJanuary 25, 2011
- 23. 9Methodology RequirementsJanuary 25, 2011
- 24. 10Methodology ComparisonJanuary 25, 2011
- 25. 11“Model-Based Architecture” Implementation ApproachMost IT architecture at The Standard is project-driven, so the easiest approach was to pilot within those effortsEncourage TOGAF/ArchiMate diagramming using Visio stencilEnable TOGAF/ArchiMate diagramming in CasewiseShow benefits with major initiative deliverablesBuild enterprise model in Casewise from existing assets (in progress)Then, implement broader TOGAF concepts (just beginning)ADM, repository, content model and reference modelsJanuary 25, 2011
- 26. 12Evolving The Standard’s “Architecture Notebook” towards TOGAF, ArchiMate and Casewise
- 27. 13Expressing Solution and Landscape Information with Annotated ArchiMateJanuary 25, 2011Architecturally SignificantRequirementKeyArchitecture DecisionDependencyGoal or ConstraintFeatureOption
- 28. 14Moving from Internal “Logical View” to…January 25, 2011
- 29. 15ArchiMate Layered View of Major SolutionJanuary 25, 2011
- 30. Moving from Overloaded “Data View” to TOGAF Data Dissemination Diagram
- 31. Moving from Overloaded “Data View” toTOGAF Application Communication Diagram
- 32. 18Moving from Overloaded “Physical View” to…January 25, 2011
- 33. 19TOGAF Platform Decomposition Diagram of Major SolutionJanuary 25, 2011
- 34. Methodology and tools are the infrastructure of architectureMaintaining them requires an ongoing investmentEvery project can either strengthen or weaken themIT professionals prefer standard methodologies and the tools that enable themTOGAF and ArchiMate are based on a broad consensusExperienced architects find them familiar and can adopt them quicklyStandard languages and methods are increasingly valuable as collaboration across organizations, cultures and geographies becomes ubiquitous20Lessons LearnedJanuary 25, 2011
- 35. Reconcile ArchiMate viewpoints and TOGAF Architecture Content FrameworkDevelop a set of quick start guidelines for organizations that want to use TOGAF for different purposesDevelop TOGAF-based annotation conventions for ArchiMate symbolsAdd representation of motivations to ArchiMateAdd a compact service bus representation to ArchiMateDevelop explicit mappings between ArchiMate and UMLAllow placement of ArchiMate group name on inside of dashed rectangle for more efficient space usage21Suggestions for TOGAF and ArchiMateJanuary 25, 2011
Editor's Notes
- #3: InsuranceLife, Accidental Death and Dismemberment, Disability, Dental, Vision and AnnuitiesRetirement plansPublic and private-sectorDefined benefit (pension) and defined contribution
- #4: MethodologyCommentsZachman:Pioneering, comprehensive frameworkModel-Driven Architecture: Focused on portable application and service developmentSOA Reference Model: Focused on distributed software designIDEF:Family of 14 separate methods used primarily in defense and government work.IEEE 1471-2000:Defines fundamental EA conceptsExtended EA Framework: Framework based on ZachmanEnterprise Architecture Planning:Focuses on Zachman owner and planner views. Apparently defined primarily in Spewak book.TOGAF: Comprehensive, focused on EA, broadly sponsored and accepted, updated regularly.
- #5: The purpose of the Data Dissemination diagram is to show the relationship between data entity, business service, and application components. The diagram shows how the logical entities are to be physically realized by application components. This allows effective sizing to be carried out and the IT footprint to be refined. Moreover, by assigning business value to data, an indication of the business criticality of application components can be gained.Additionally, the diagram may show data replication and system ownership of the master reference for data. In this instance, it can show two copies and the master-copy relationship between them. This diagram can include services; that is, services encapsulate data and they reside in an application, or services that reside on an application and access data encapsulated within the application.
- #6: The purpose of the Application Communication diagram is to depict all models and mappings related to communication between applications in the metamodel entity.It shows application components and interfaces between components. Interfaces may be associated with data entities where appropriate. Applications may be associated with business services where appropriate. Communication should be logical and should only show intermediary technology where it is architecturally relevant.
- #7: The Platform Decomposition diagram depicts the technology platform that supports the operations of the Information Systems Architecture. The diagram covers all aspects of the infrastructure platform and provides an overview of the enterprise's technology platform. The diagram can be expanded to map the technology platform to appropriate application components within a specific functional or process area. This diagram may show details of specification, such as product versions, number of CPUs, etc. or simply could be an informal "eye-chart" providing an overview of the technical environment.