Enterprise Architecture – Vision and Reality on the Same Page
•Download as PPTX, PDF•
6 likes•4,106 views
This presentation describes the underlying conceptual structure of enterprise architecture, and its relevance to enterprises across the whole spectrum
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (9)
Similar to Enterprise Architecture – Vision and Reality on the Same Page
Similar to Enterprise Architecture – Vision and Reality on the Same Page (20)
Recently uploaded
Recently uploaded (20)
Enterprise Architecture – Vision and Reality on the Same Page
- 1. Enterprise Architecture – Vision and Reality on the Same Page Dr Simon Polovina LEAD Certified Enterprise Architecture eXpert TOGAF Foundation Certified SAP Certified Associate Enterprise Architect Conceptual Structures Research Group
- 2. Overview • History of EA • Why EA • What is EA • EAFs – Zachman, TOGAF, LEAD and others • Metamodels, Ontology and Semantics • Essential Tool as an Exemplar • Relevance to Your Organisation • Glimpse into the future • Summary, and References October 2014 EA Vision & Reality 2
- 3. Where did EA come from? • EA essentially began in 1987, with the publication of "A Framework for Information Systems Architecture," by J.A. Zachman (IBM Systems Journal), in which: – He stated that “The cost involved and the success of the business depending increasingly on its information systems require a disciplined approach to the management of those systems.” – Laid out both the challenge and the vision of enterprise architectures that continue to guide the field today – Gave a vision was that business value and agility could best be realised by a holistic approach to systems architecture that explicitly looked at every important issue from every important perspective – Was originally described as an information systems architectural framework, soon renamed as an enterprise architecture framework Zachman (1987), Sessions (2007) October 2014 EA Vision & Reality 3
- 4. v1 October 2014 EA Vision & Reality 4 Sowa & Zachman (1992)
- 5. October 2014 EA Vision & Reality 5 AndToday…
- 6. TOGAF • In 1995, TOGAF 1.0 mainly based on TAFIM, developed since the late 1980s by the US DoD • Today, TOGAF 9.1 has a formal Content Metamodel, and many more examples and templates October 2014 EA Vision & Reality 6
- 7. Why do we need it? • Originally (reactive): – System complexity—Organisations were spending more and more money building IT systems; and – Poor business alignment—Organisations were finding it more and more difficult to keep those increasingly expensive IT systems aligned with business need – Even More Cost, Even Less Value (Sessions, 2007) October 2014 EA Vision & Reality 7
- 8. Why do we need it? • Today (proactive, too): – Fragmented to Integrated—optimise across the enterprise the often fragmented legacy of processes (both manual and automated), into an integrated environment that is responsive to change and supportive of the delivery of the business strategy – IT and business success—effective management and exploitation of information through IT is a key factor to business success, and an indispensable means to achieving competitive advantage – Achieving the right balance between IT efficiency and business innovation (TOGAF, 2011) October 2014 EA Vision & Reality 8
- 9. The scope of EA • Understanding the knows and don’t knows of the Enterprise that it needs to know to survive and to succeed: – “... there are known knowns; there are things we know that we know. There are known unknowns; that is to say, there are things that we now know we don't know. But there are also unknown unknowns – there are things we do not know we don't know.” (United States Secretary of Defense, Donald Rumsfeld, 2002) • Complex Problems; Simple Solutions – “Everything should be made as simple as possible, but no simpler than that” (attributed to Einstein) October 2014 EA Vision & Reality 9
- 10. The Semiotic Ladder (Organisational Semiotics, after Stamper 1997) PHYSICAL WORLD signals, traces, physical dimensions, hardware, component density, speed, economics EMPIRICS patterns, variety, noise, entropy, channel capacity, redundancy, efficiency, codes, ... SYNTACTICS formal structure, language, logic, data, records, deduction, software, files, ... SEMANTICS meanings, propositions, validity, truth, signification, denotations, ... PRAGMATICS intentions, communication, conversations, negotiations, ... SOCIAL WORLD beliefs, expectations, commitments, contracts, law, culture, ... HumanInformationFunctions VALUEPRODUCING TheTechnologyPlatform COSTIMPOSING EnterpriseArchitecture TheComputerWorld The Real World? more like a semiotic snake to me October 2014 EA Vision & Reality 10
- 11. What is EA? • Enterprise • Architecture • Models October 2014 EA Vision & Reality 11
- 12. Enterprise • “Space: the final frontier. These are the voyages of the starship Enterprise. Its five-year mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no man has gone before.” (Star Trek, quotes) • Origin: late Middle English: from Old French, 'something undertaken', feminine past participle (used as a noun) of entreprendre, based on Latin prendere, prehendere 'to take‘ (OED) • An undertaking, especially one of some scope, complication, and risk (thefreedictionary.com) • A business organisation (thefreedictionary.com) • You and me October 2014 EA Vision & Reality 12
- 13. Architecture • The art or practice of designing and constructing buildings (OED) • The complex or carefully designed structure of something (OED) • The conceptual structure and logical organization of a computer or computer-based system (OED) • Winchester Mystery House • “From the blank piece of paper to the last nail in the wall” October 2014 EA Vision & Reality 13
- 14. Models • Can’t touch an enterprise, but it’s very real • Only see through models • “All Models are Wrong, But Some are Useful” (Box, 1987) Sowa, 2002 October 2014 EA Vision & Reality 14
- 15. Enterprise Architecture Frameworks • The Two Representative Frameworks: – Of the many… – Zachman, TOGAF • What they offer – Artefact vs. Process – Reference Content – Metamodels – Ontology – Semantics • Tools October 2014 EA Vision & Reality 15
- 16. Artefact vs. Process • The Zachman Framework for Enterprise Architectures – Originally self-described as a framework – But more accurately defined as a taxonomy – And now Enterprise Ontology – A declarative grid of objects and relationships, not process (directly) – You populate the grid with your EA • It’s thus artefact-driven October 2014 EA Vision & Reality 16
- 17. Artefact vs. Process • The Open Group Architectural Framework (TOGAF) – Also called a framework – Central to TOGAF is its Architecture Development Method (ADM) – It’s thus process-driven October 2014 EA Vision & Reality 17
- 18. October 2014 18
- 19. EA Vision & Reality 19
- 20. Some Others • The Federal Enterprise Architecture (FEA) – Can be viewed as either a) an implemented enterprise architecture, or b) a proscriptive methodology for creating an EA – Was FEAF • Framework dropped accordingly… – Segments • EA in Organisational units • Technical, Business and Data architectures October 2014 EA Vision & Reality 20 Sessions (2007)
- 21. Some Others • Gartner – Can be best described as a enterprise architectural practice – proprietary, by the respected Gartner Group • LEAD – Layered Enterprise Architecture Development (now simply LEADing Practice) – again practice, but open source – with a developing ecosystem across industry and academic expertise October 2014 EA Vision & Reality 21
- 22. LEAD • Overview diagram • & more about (in notes) October 2014 EA Vision & Reality 22
- 23. October 2014 EA Vision & Reality 23 LEAD’sStructuralWay
- 24. October 2014 EA Vision & Reality 24 LEAD’s Structural Way • As a detailed view
- 25. In all levels of detail… • One for LEADing Practice Framework Concepts, Enterprise Modelling & Enterprise Architecture Artifacts, Value Reference, Service Reference, Process Reference, Maturity Reference, Architecture and Modelling Skills Mapping October 2014 EA Vision & Reality 25
- 26. Metamodels • Meta = ‘about’ • White entities are “core” and not to be omitted • Red/Blue/Green entities are “extensions” and can be omitted • Entity renaming is possible • Modification and removal of entities is not recommended • It’s the base template for your EA October 2014 EA Vision & Reality 26
- 27. SAPEAF 27Infrastructure Consolidation Extension Governance Extension Process Modelling Extension Data Modelling Extension Business / IT Alignment Extension Core Content ARCHITECTURE VISION, CONTEXT AND ROADMAP BUSINESS ARCHITECTURE TECHNOLOGY ARCHITECTURE APPLICATION ARCHITECTUREDATA ARCHITECTURE Associated With All Objects Organisation Unit Goal Objective Measure Governance Extension (Business , Information System ) Service Services are Contained in Core , Business / IS split supports the Business / IT Alignment Extension Function Process Actor Role Control Process Extension Event Process Extension Product Process Extension Data Entity Logical Information Component Data Extension Location Infrastructure Consolidation Extension Physical Information Component Data Extension Logical Application Component Physical Application Component Infrastructure Consolidation Extension Logical Technology Component Infrastructure Consolidation Extension Physical Technology Component Principle Constraint Requirement Contract Governance Extension Gap Work Package Driver Platform Service Owns and governs Operates in Operates in Is Hosted in Is Hosted in Is Hosted inEncapsulates Encapsulates Resides within Supplies Is Supplied By Is Realised by Realises Operates on Is processed by Provides , consumes Is accessed and updated through Resides within Is implemented on Provides platform forImplements Is realised through Contains Contains Contains Contains Contains Contains Belongs to Consumes Participates in Interacts with , Performs Performs task in Generates , Resolves Produces Is Produced byIs owned by Owns Supports , Is performed by Accesses Can be accessed by Orchestrates , decomposes Supports , Is realised by Is bounded by Provides governed interface to access Produces Is Produced by Involves Participates in Involves Is Resolved by , Is Generated by Generates , Resolves Is Resolved by Is Resolved by , Is Generated by Resolves Supports , Is realised by Orchestrates, decomposes Ensures correct operation of Isguided by Governs , Measures Is governed and measured byIs Provided to Is owned and governed by Is tracked against Sets performance criteria for Sets performance criteria for Is tracked against Is motivated by Motivates Creates Addresses Is realised through Realises Service Quality Governance Extension Applies to Meets Applies to Meets Is Performed by Is Supplied or Consumed by Supplies or Consumes
- 28. BEEST October 2014 EA Vision & Reality 28 BUSINESS ARCHITECTURE TECHNOLOGY ARCHITECTURE APPLICATION ARCHITECTUREDATA ARCHITECTURE BEEST Production and Logistics Organization Unit Lower Working Capital / Facilitate Supplier Collaboration Improve Visibility of Leipzig Inventory to Suppliers during 2005 Receiving and Material Storage Costs KPI Source Supplier Products for Operations Supplier Collaboration and Operational Procurement Manage Warehouse and Storage Leipzig Production Manager MRP Controller Inventory falls below forecast production demand Inventory replenishment triggered BEEST 911 GT 3 Sports Car Stock Item Inventory Records Leipzig Assembly Factory Purchsoft Stock Master E-Procurement , Ordering and Payments BEEST Purchsoft Procurement Software Suite Purchsoft E - Procurement for Oracle 8i Version 3.1 Leoni -BEEST DriveTrain Supply Contract Global trend for customization and increased efficiency of production EDI /Bank Payments Engine Daily Replenishment, Daily response to replenish trigger
- 29. “Infinity”High-Tech October 2014 EA Vision & Reality 29 BUSINESS ARCHITECTURE TECHNOLOGY ARCHITECTURE APPLICATION ARCHITECTUREDATA ARCHITECTURE “Infinity” Manufacturing Unit Increase Revenue Improve Capacity Utilisation by 25% in 2007 Capacity Utilisation KPI Capacity load / Resource Capacity * 100 Repetitive Manufacturing Planning Business Service Make-to-Order Manufacturing Production Planning Head of Home Computer Product Manufacturing Production Planner Confirmed Sales Order Received and Product current and not <200 items Sales Order Arrives Infinity Personal Computer Model xxx Product Product Stock Records Infinity Chicago Production Centre SAP Product Master Data Supply Planning Enterprise Service SAP Query Supply Planning Area Enterprise Service Database Server HP Integrity Superdome (Productiion Instance - Npar 12) Manufacturing - Sales Contract Deliver Shareholder Value Transaction Processing Plan must be updated each hour on a 24 x7x 365 basis Outsourced Austin Data Centre
- 30. MappingTOGAFtoSAPEAF Preliminary Business Architecture Data Architecture Application Architecture Technology Architecture Architecture Vision Organisation Unit Function Business Service Location Actor Role Event Control Data Entity Architecture Building Block Process Strategy Goal Objective Measure User Interface Principle Scope Constraint Vision Stakeholder Map Deliverable Architecture Framework Cross-Aspect Requirement Gap Analysis Project Implementation Roadmap Contract Candidate Solutions Application Technology Component Platform Service Architecture Vision, Context and Roadmap Business Architecture Technology Architecture Application Architecture Data Architecture Principle Constraint Requirement Gap Work Package Organisation Unit Goal Objective Measure Function Process Actor Role Control Event Product Location Contract Driver Service Quality Business Service Data Entity Logical Information Component Physical Information Component Logical Application Component Physical Application Component Logical Technology Component Physical Technology Component Platform Service Information System Service Architecture Building Block Not within the scope of structured modelling Moved Phase. Goals and Objectives in the Vision phase would be collected in SAP EAF, but not formally modelled. Changed to a more generic name. Contract term in TOGAF equates to a terms of reference. SAP EAF extends concept to include service contracts Candidate solutions are shown as an architecture and don’t require metamodel entities An implementation roadmap is a view of work packages. User Interface is not considered to be architecturally significant for Enterprise Architecture and is not formally included in SAP EAF Changed to a more generic name. SAP EAF extends applications and technology to be both logical and physical SAP EAF adds an information component concept to allow segmentation and bounding of data SAP EAF allows independent views of services from a business and IS perspective SAP EAF extends service governance to allow service qualities and contracts to be applied to services SAP EAF adds the concept of a Driver that motivates business to achieve objectives Direct TOGAF– SAP EAF Mapping Indirect TOGAF– SAP EAF Mapping Not taken from TOGAF to SAP EAF SAP EAF extension to TOGAF TOGAF concept not relevant to structured modelling Assumption SAP EAF adds the concept of Assumptions EA Vision & Reality 30
- 31. Synonyms etc… October 2014 EA Vision & Reality 31
- 32. Ontology • In Philosophy: – A theory of being – “does truth exist?” or “does energy exist?” • In Computer Science – Gruber “In the context of knowledge sharing, I use the term ontology to mean a specification of a conceptualization. That is, an ontology is a description (like a formal specification of a program) of the concepts and relationships that can exist for an agent or a community of agents. This definition is consistent with the usage of ontology as set-of-concept-definitions, but more general. And it is certainly a different sense of the word than its use in philosophy.” (emphasis added).” (Malik, 2009) October 2014 EA Vision & Reality 32
- 33. Context Semantics Rule of 3: October 2014 EA Vision & Reality 33 Object Object relation
- 34. Some triples... Laurier & Poels (2012) w3c.org Value-Performance Meta Model, leadingpractice.com October 2014 EA Vision & Reality 34
- 35. w3c.org leadingpractice.com Laurier & Poels (2012) Some contexts… October 2014 EA Vision & Reality 35
- 36. Lanir (2012) Also, Peirce's Triadic Objects Create Signs October 2014 EA Vision & Reality 36
- 37. Tools • From Visio to Essential Project – Capturing and structuring what’s in our heads, gut instinct, pen & paper, unstructured records… • Picking one – Visio, ARIS, Sparx, iGrafx, … • How well do they handle the semantics? – Rule of 3 • To what extent do they create signs from objects? – So you optimise the object not the sign • An illustration: Essential Project October 2014 EA Vision & Reality 37
- 38. Essential Essential Import Utility Essential Modeller in Protégé Essential Viewer Semantic Mapping How spreadsheet maps to EMM Knowledge Base Classes and Instances of EMM Views Dynamically rendered from knowledge base snapshot UpdateUpload Publish EMM = Essential Meta Model Render 38October 2014 EA Vision & Reality
- 39. Essential Architecture Manager (EAM) A means to capture, view and analyse an Enterprise Architecture using the Essential Meta-Model Domain experts and architects capture and publish enterprise architecture information Business and IT stakeholders view and analyse reports to support decision making 39October 2014 EA Vision & Reality
- 40. Making it/IT relevant to You • EA as a foundation for execution • “From Concept to the last network cable we fit” • What kind of business are we? • Aligning our Vision with our (IT) Reality • Moore’s Core-Context • Four Operating Models October 2014 EA Vision & Reality 40
- 41. Moore’score-context October 2014 EA Vision & Reality 41
- 42. The Four Operating ModelsWhereisyourorganisation? Coordinated,Diversified,ReplicatedorUnified? October 2014 EA Vision & Reality 42Ross et al. (2006)
- 43. Stakeholders • Power Grid • RACI • Pragmatics October 2014 EA Vision & Reality 43
- 44. The Baseline to Target Phases • ‘As-Is’ to ‘To-Be’ Phases i.e.: – Business Architecture – Information Systems Architecture – Technology Architecture • Populating the Architecture Definition Document (ADD) October 2014 EA Vision & Reality 44
- 45. Measuring EA • Reducing Cost and Risk • Vs. Increasing Profit and Value • KPI & PPI – Key ‘vs’ Process Performance Indicators • “If it can’t be measured, it can’t be evaluated, if it can’t be evaluated it can’t be managed” • Measuring the objects not the signs • Useful Models October 2014 EA Vision & Reality 45
- 46. EA Maturity October 2014 EA Vision & Reality 46
- 47. ‘Other’ Management Aspects • Enterprise Architecture and… – Project Management – Change Management – Service Management – Governance • The Baseline to Target Loop – Solutions or Better Questions? October 2014 EA Vision & Reality 47
- 48. From Projects to Enterprise • Think BIG; start small • Capability, Segment and Strategic EA – The same vision and reality across the enterprise at different levels (Chapter 20 in TOGAF, 2011) • Enterprise-wide Governance – Across all the levels (projects) thus the enterprise as a whole – Thus governing the overall EA, not just the EAs that make it up October 2014 EA Vision & Reality 48
- 49. A possible future glimpse • Process Oriented Architecture (POA) – Given that BPM and SOA are not Application and Data as given in the ‘classic’ EAFs, but much in common? – e.g. Information Systems Architecture – Data/Application in TOGAF – LEAD’s integration of Enterprise Architecture with Enterprise Modelling and Enterprise Engineering – How would the TOGAF ADM and the Zachman grid look with POA? • Transaction Oriented Architecture – Transactions as a strategic-level concept as well as an operational concept (Polovina, 2013) October 2014 EA Vision & Reality 49
- 50. A Mindset and Toolset for EA October 2014 EA Vision & Reality 50
- 51. Summary • Overview • History of EA • Why EA • What is EA • EAFs – Zachman, TOGAF, LEAD and others • Metamodels, Ontology and Semantics • Essential Tool as an Exemplar • Relevance to your org incl. outline exercises • Glimpse into the future (POA, TOA) • Below: References October 2014 EA Vision & Reality 51
- 52. References • See the notes to this slide October 2014 EA Vision & Reality 52
Editor's Notes
- The Title page
- An overview of the session content, plus associated activities
- A Brief History of Enterprise Architecture (Sessions, 2007) : The field of enterprise architecture essentially started in 1987, with the publication in the IBM Systems Journal of an article titled "A Framework for Information Systems Architecture," by J.A. Zachman. In that paper, Zachman laid out both the challenge and the vision of enterprise architectures that would guide the field for the next 20 years. The challenge was to manage the complexity of increasingly distributed systems. As Zachman said: The cost involved and the success of the business depending increasingly on its information systems require a disciplined approach to the management of those systems. Zachman's vision was that business value and agility could best be realized by a holistic approach to systems architecture that explicitly looked at every important issue from every important perspective. His multiperspective approach to architecting systems is what Zachman originally described as an information systems architectural framework and soon renamed to be an enterprise-architecture framework.
- Zachman’s original ISA Framework, first shown in Sowa & Zachman (1992)
- For more info refer to http://www.zachman.com/about-the-zachman-framework © 2008 John A. Zachman, CEO Zachman International®, Inc.
- TOGAF was initiated early 1990s as methodology for the development of technical architecture, and has been developed by The Open Group into an extensive enterprise architecture framework. In 1995, the first version of TOGAF (TOGAF 1.0) was presented. This version was mainly based on the Technical Architecture Framework for Information Management (TAFIM), developed since the late 1980s by the US Department of Defense In December 2001 TOGAF 7, the "Technical Edition", was published. TOGAF 8 ("Enterprise Edition") was first published in December 2002 and republished in updated form as TOGAF 8.1 in December 2003. Around 2005 TOGAFTM became a registered trademark of The Open Group. In November 2006 the Open Group released TOGAF 8.1.1. According to The Open Group, as of February 2011, over 15,000 individuals are TOGAF Certified. As of September 2012 the official register has over 20,000 certified individuals. The latest version is TOGAF 9.1, launched on 1 December 2011. An evolutionary development from TOGAF 8, TOGAF 9 includes many new features including: Increased rigor, including a formal Content Metamodel that links the artifacts of TOGAF together Elimination of unnecessary differences Many more examples and templates (http://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework)
- Twenty years ago, a new field was born that soon came to be known as enterprise architecture. The field initially began to address two problems: System complexity—Organizations were spending more and more money building IT systems; and Poor business alignment—Organizations were finding it more and more difficult to keep those increasingly expensive IT systems aligned with business need. The bottom line: more cost, less value. These problems, first recognized 20 years ago, have today reached a crisis point. The cost and complexity of IT systems have exponentially increased, while the chances of deriving real value from those systems have dramatically decreased. Today's bottom line: even more cost, even less value. Large organizations can no longer afford to ignore these problems. The field of enterprise architecture that 20 years ago seemed quaintly quixotic today seems powerfully prophetic (Sessions, 2007)
- The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy. Today's CEOs know that the effective management and exploitation of information through IT is a key factor to business success, and an indispensable means to achieving competitive advantage. An enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment. Furthermore, a good enterprise architecture enables you to achieve the right balance between IT efficiency and business innovation. It allows individual business units to innovate safely in their pursuit of competitive advantage. At the same time, it ensures the needs of the organization for an integrated IT strategy are met, permitting the closest possible synergy across the extended enterprise. (TOGAF, 2011)
- Donald Rumsfeld’s statement was actually insightful as it highlights the extent of Enterprise Architecture’s (EA’s) scope as we shall explore…
- Enterprise Architecture has to capture the Value Producing (VP) as well as the Cost Imposing (CI) to effect “an integrated environment that is responsive to change and supportive of the delivery of the business strategy” -- Further considerations: Core Differentiating Competencies are VP? Non-Core Competencies are CI? The ladder refers to ‘computers vs. humans’, but we could highlight that semantic technologies (e.g. Semantic Web) address VP?
- What is EA? Elaborated on the following slides…
- Definitions of Enterprise, from Star Trek to us as individuals as well as business organisations (e.g. Shell). All thus are enterprises, incurring cost and risk for some higher overall benefit that be that profit or some other form of achievement.
- Enterprises are not like buildings etc. as you can’t actually touch them, but they are very real! Assets are burdens, involve cost and risk and need to add benefit (“sweat the assets”) Is Winchester Mystery House an example of _good_ architecture as it was to a defined specification, however strange?
- We don’t reiterate definitions of models here; just point to dictionary.com etc. Rather let’s focus on the above pertinent comments!
- We now elaborate on Enterprise Architecture Frameworks, with some examples, what they (should) offer, and tools to support their use in your organisation. An Enterprise Architecture Framework (using Zachman and TOGAF as the two key representations) is a template, reference content and body of knowledge that your organisation can explicate its Enterprise Architecture (EA), using an EA tool to help you. -- The image gives a historical overview of Enterprise Architecture Frameworks evolution (1987–2003). On the left: The Zachman Framework 1987, NIST Enterprise Architecture 1989, EAP 1992, TISAF 1997, FEAF 1999 and TEAF 2000. On the right: TAFIM influenced by POSIX, JTA, JTAA, TOGAF 1995, DoD TRM and C4ISR 1996, and DoDAF 2003 (in http://en.wikipedia.org/wiki/Enterprise_architecture_framework)
- Here we outline the Zachman EAF, why it is artefact-driven, and process is added into it (by the enterprise) as required
- Now we outline the Open Group’s EAF i.e. TOGAF, why it is process-driven through the ADM in its Architecture Capability Framework that also draws on reference content and artifacts for each of the ADM’s phases NB the ADM shown here is slightly updated as http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap19.html Figure 19-1: Iteration Cycles, shows for the suggested iterations. The ADM shown in the earlier slide reflects SAP’s significant introduction of iterations into TOGAF 9 in 2009 (http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/media/streamingmedia/developer-areas/service-oriented-architecture/Starter%20Kit%20for%20SOA/assets/Journey/update/TOGAF_9.pdf or Google “Steve Kirby OG SAP EAF TOGAF 9 2009”). The image in the above slide essentially reflects TOGAF’s current terminology…
- The diagram describes TOGAF’s Architecture Capability Framework referred to in the notes for the previous slide.
- The diagram describes TOGAF’s (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html, Figure 34-3: Interactions between Metamodel, Building Blocks, Diagrams, and Stakeholders). It illustrates TOGAF’s broader perspective, driven by its ADM. We will be covering the Metamodel later. As you can see all the flows pass through it…
- We have stated that we can understand EAF’s through focussing comparatively on Zachman & TOGAF, but it is worth considering three others – FEA, Gartner and LEAD – to highlight the comparison. We will also be looking at LEAD in more detail, as it also brings forward the state of the art in EA set by Zachman, TOGAF and the other EAFs. Here we start with Federal Enterprise Architecture (FEA) -- Federal Enterprise Architecture (FEA, formerly FEAF…), http://www.whitehouse.gov/omb/e-gov/fea, http://msdn.microsoft.com/en-us/library/bb466232.aspx#eacompar_topic7 (Sessions, 2007) -- Diagram is “Figure 8. Segment map of the federal government” in FEA (Sessions, 2007) to illustrate segments Having the wider notion of organisational Enterprise Services, rather than just the technical notion of services in service-oriented architectures alone An analogy in esworkplace.sap.com with Enterprise Services as connecting Industry-wide solutions maps in Solution Composer right down to the individual service operations (WSDL files), with the organisational units along the way Figure 40-1: Allocation of Teams to Architecture Scope and Figure 40-1: Allocation of Teams to Architecture Scope in http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap46.html (40. Architecture Partitioning) denotes segments analogous to those in FEA, with TOGAF’s being in between an organisation’s enterprise-wide architectures and project-wide capability architectures
- Here we next refer to Gartner, http://www.gartner.com/technology/core/products/research/topics/enterpriseArchitecture.jsp, and LEAD , http://www.leadingpractice.com/, which we will explore further as indicated on the previous slide And even more (that we just mention in passing): IBM Enterprise Architecture - http://www.ibm.com/software/info/itsolutions/enterprisearchitecture/ The DoDAF Architecture Framework Version 2.02, http://dodcio.defense.gov/dodaf20.aspx MODAF, https://www.gov.uk/mod-architecture-framework Not an exhaustive list (and others you may know about too); essentially through Zachman, TOGAF and later on in LEAD we will have outlined EA such that you can relate to these frameworks for yourself.
- About LEAD: Founded in 2004, LEAD was originally an acronym for Layered Enterprise Architecture Development but now simply refers to itself as the LEADing Practice Enterprise Standards. This is because it now includes Enterprise Modelling (including Business Process Management) and Enterprise Engineering as well as Enterprise Architecture (as the figure shows). LEAD describes itself as: “LEADing Practice represents a new breed of Enterprise Standards and is recognized as a paradigm shift by the global business and IT community to empower through its Reference Content a structured way of thinking, working and modelling enabling organizations to innovate, transform and deliver value” LEAD further describes itself as a set of open standards concepts and adopted by most of the Fortune 500 and public organizations and is integrated into software solutions such as SAP (ASAP Methodology), IBM Rational, IBM System Architect, iGrafx and Software AG (ARIS). Today, LEADing Practice is the fastest growing open source standard development community, supported by the 2nd largest certified community of 3100+ industry practitioners. LEAD has developed 55 different Enterprise Standards with detailed reference content as well as over 51 different Industry User Group Committees that provides a global platform for industry executives, experts, academics, thought-leaders, practitioners and researchers to develop, use and apply. The LEADing Practice Frameworks, Methods & Approaches connects to all the major existing enterprise architecture and other frameworks, methods and approaches (such as TOGAF, Zachman, FEAF, ITIL, Prince2, COBIT, DNEAF, and others). The LEGO group, famous for its Lego bricks, provides a lucid exposition of one of LEAD’s greatest commercial successes, and there as many others as well as non-commercial organisations, and government bodies such as the Government of Canada. To assist its industry practitioners and the development of the discipline as whole, LEAD provides a multitude of Repository, Templates and Hands-On Modelling tools. LEADing Practice's Enterprise Standards are developed by a) Researching and analysing industry best practice & leading practices, b) Identifying common and repeatable patterns (the basis of LEAD's standards), c) Developing the Enterprise Standards that increase the level of re-usability and replication, and d) Build industry accelerators within the standards, enabling to adopt and reproduce the best & leading practices. LEAD is therefore practically oriented, but based on a strong theoretical base that it gathers from its research partner, the Global University Alliance (www.globaluniversityalliance.net).
- In outline, LEAD is structured as a “Way of Thinking, Way of Working, Way of Modelling, Way of Implementation and Way of Governance”, with each way setting the context of the next one in this list. It reflects the architectural principle of capturing the very purpose of an enterprise (its vision and mission) right down to the individual assets (e.g. purchases, sales, employees, IT support systems) that fulfil that purpose.
- LEAD’s structural way, detailed in a familiar form to EA i.e. associated to the entities (objects) in each layer (business, application, technology), across the conceptual, logical and physical dimensions of the value context.
- As you can see it has brought a lot together on single posters! -- www.leadingpractice.com » Tools » Hands-on Modelling (http://www.leadingpractice.com/tools/hands-on-modelling/): The LEADing Practice Reference Framework wallpapers are designed as a hands-on modelling template that guides the practitioner in a step-by-step how to: identify and relate the right LEAD objects and artifacts in a way of thinking, way of working and way of modelling across business-, application- and technology layers; apply the LEAD methods and to structure the practitioner’s way of working in specific area with supporting techniques, tools, principles, rules, procedures and practices; link strategy, business models, reporting, process and services with information architecture, data architecture, platform architecture and infrastructure architecture; and model from the perspective of roles. The recent LEADing Practice Reference Framework hands-on modelling templates are available as downloads. The posters are often requested as real-size posters for office decorations and as project work tools. To order a real-size poster for your offices or teams, please use the contact form (http://www.leadingpractice.com/about/contact/).
- Metamodel is the model about the model; the diagram shown is TOGAF’s content metamodel (you saw it earlier). Specifically, it’s Figure 34-8: Relationships between Entities in the Full Metamodel (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html#tagfcjh_64 in chapter “34. Content Metamodel”) -- The metamodel content is signified by the viewpoints that http://www.togaf.info/togaf9/togafSlides9/TOGAF-V9-Sample-Catalogs-Matrics-Diagrams-v2.pdf illustrates -- Key Entities: DRIVER: An external or internal condition that motivates the organisation to meet or redefine its goals e.g.: Global banking crisis giving reduced access to external capital GOAL: A high-level statement of intent or direction for an organisation. Typically used to measure success of an organisation e.g.: Deliver the best customer service in our industry OBJECTIVE: A time-bounded milestone for an organisation used to demonstrate progress towards a goal e.g.: Increase capacity utilization by 30% by the end of 2014 ORGANISATION: A self-contained unit of resources with line management responsibility, goals, objectives and measures. Organisations may include external parties and business partner organisations. e.g.: Shell plc (or one of its brands…) ACTOR: A person, organisation or system that has a role that initiates or interacts with activities. Actors may be internal or external to an organisation. e.g.: A Sales representative who travels to visit customers ROLE: The usual or expected function of an actor, or the part somebody plans in a particular action or event. An actor may have a number of roles. e.g.: Warehouse Supervisor FUNCTION: Delivers business capabilities closely aligned to an organisation, but not explicitly governed by the organisation. e.g.: Make-to-Order Manufacturing BUSINESS SERVICE: Supports business capabilities through an explicitly defined interface and is explicitly governed by an organisation. e.g.: Credit Checking PROCESS: Represents flow of control between functions and/or services. e.g.: A process flow describing the Purchase Request Processing function, showing controls and events APPLICATION COMPONENT: An encapsulation of application functionality that is aligned to implementation structuring. e.g.: Purchasing Application DATA ENTITY: An encapsulation of data that is recognised by a business domain expert as a thing e.g.: Purchase Order TECHNOLOGY COMPONENT: An encapsulation of technology infrastructure that represents a class of technology product or specific technology product. e.g.: A bought-in vendor's Supply Chain Management technology PLATFORM SERVICE: A technical capability required to provide enabling infrastructure that supports the delivery of applications. e.g.: A bought-in vendor's Business Process Management platform
- SAP was a key contributor to TOGAF 9. Here is their metamodel for interest. Note some of the terminology (e.g. Business Information Service) is different and the Motivation extension (Red entities) in TOGAF is white (i.e. core) in SAP EAF, but its metamodel conforms to TOGAF as it ‘has not taken anything away’. We’ll use the SAP EAF in the next to illustrate the population of the metamodel with its case study, the BEEST motor manufacturer (based on Porsche…)
- This is BEEST ‘as-is’ (baseline), in comparison to ‘to-be’ (target). So where BEEST is where it is today (as shown above) as opposed to where it wants to be (not shown). The difference is the gap.
- Another SAP EAF example, a High-Tech Manufacturer called “Infinity”
- This slide is included to illustrate how it is possible to map between frameworks (e.g. Entity renaming); in that sense SAP EAF is simply one such illustration -- The Blue boxes are those concepts added to TOGAF in the SAP EAF The Grey boxes are those where formal structured modeling is not required during Enterprise Architecture
- Challenges in Pragmatics (refer Stamper’s Semiotic Ladder earlier) – sharing meaning despite the semiotic indexing (i.e. words) we use to name those meanings (e.g. objects or relations). At a simpler level, we can sense the challenges in naming things from this diagram! Source of diagram: http://en.wiktionary.org/wiki/File:Homograph_homophone_venn_diagram.svg
- Malik (2009) argues that the Zachman Framework is not an ontology, essentially as there are no implicit relationships between terms in an ontology as Zachman suggests in his grid. However we see these in the TOGAF metamodel, and others have them too e.g. LEAD (being a development of the TOGAF metamodel). We could counter-argue that the grid structure gives those relations; however what is pertinent is that for ontology we have concepts (or entities or objects) and relations.
- Semantics – making meaning; Pragmatics – sharing meaning as we saw in Stamper’s Semiotic Ladder earlier and helping enterprises connect their IT with the real world -- With the above understanding of ontology, we have a definition of semantics – objects (concepts, entities) related to each other through relations, all set in context -- NB not to be confused with Moore’s Core-Context, which we’ll look at shortly.
- Example of objects/concepts/entities linked by relations
- Contexts can be represented through domains (e.g. Business Architecture), categorisations, classifications, schemas, namespaces, Peirce’s cuts (the bottom right example from Polovina, 2007), … And there is Moore’s core-context, where everything else is context…
- STOP is a piece of metal cut into a hexagonal shape with red painted middle and white borders and S T O P written on it, but it means more to us! Objects create signs so we need to KPI the objects not the signs!
- There are many EA and related software tools on the market – http://www.enterprise-architecture.info/EA_Tools.htm provides a comprehensive, comparative coverage (arguably not complete but key tools are in there). Gartner has a magic quadrant for tools – http://www.gartner.com/technology/reprints.do?id=1-1MXD4M1&ct=131113&st=sb – and a Google search for “Enterprise repository tools for TOGAF 9, PM, BPM, GRC” reveals another report for example. The questions in these slides centre however on the fundamental question do they create signs from objects so we are pointing at the thing that matters not just how it looks (refer Peirce’s triadic earlier). For this purpose we will refer to the Essential Project tool (www.enterprise-architecture.org) to illustrate…
- From spreadsheet to knowledge base to Views – objects creating signs
- Then displaying the results from the consequently interrelated objects (remember semantics, the ‘rule of 3’)
- Time to relate it (as in general) and IT (as in IT) to your particular enterprise. Listed are some starting points to consider…
- Let’s begin with Moore’s Core-Context -- Core is in your namespace (e.g. myenterprise.com); Context is using someone else’s (e.g. sap.com) hence differentiation as your namespace is what is distinctive to you and the rest is context as Moore refers to it. And you try and (re)use context as much as you can as it is not core differentiating but non-core! Also remember how we defined context earlier in semantics? -- How does this map to your organisation?
- Ross et al. (2006) describe these 4 operating models. Using my kindle copy of this text let’s try and tease out initially the operating model for your organisation…
- Chapter “24. Stakeholder Management” (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap24.html) includes “Figure 24-2: Stakeholder Power Grid” shown above. Where might you place the relevant stakeholders (allowing for any sensitivities of course… ) and where might you start – project (capability), segment (organisational) or strategic (enterprise)? -- Key responsibility roles (In http://en.wikipedia.org/wiki/Responsibility_assignment_matrix): Responsible: Those who do the work to achieve the task. There is at least one role with a participation type of responsible, although others can be delegated to assist in the work required (see also RASCI for separately identifying those who participate in a supporting role) Accountable (also approver or final approving authority):The one ultimately answerable for the correct and thorough completion of the deliverable or task, and the one who delegates the work to those responsible. In other words, an accountable must sign off (approve) on work that responsible provides. There must be only one accountable specified for each task or deliverable. Consulted (sometimes counsel): Those whose opinions are sought, typically subject matter experts; and with whom there is two-way communication. Informed: Those who are kept up-to-date on progress, often only on completion of the task or deliverable; and with whom there is just one-way communication. Very often the role that is accountable for a task or deliverable may also be responsible for completing it (indicated on the matrix by the task or deliverable having a role accountable for it, but no role responsible for its completion, i.e. it is implied). Outside of this exception, it is generally recommended that each role in the project or process for each task receive, at most, just one of the participation types. Where more than one participation type is shown, this generally implies that participation has not yet been fully resolved, which can impede the value of this technique in clarifying the participation of each role on each task. -- Last but not least – how do you go about agreeing on terminology in your organisation? How do you manage any diversity of opinion e.g. solve it or manage it? (http://en.wikipedia.org/wiki/Wicked_problem)
- In TOGAF, Chapter “36. Architecture Deliverables” (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap36.html) refers. At a high-level, rough cut to begin with, how you can you populate the ADD template doc (www.togaf.biz/TOGAFWebsitefiles/template_arch_def.doc) for your organisation?
- Refer to Posted by Dirk Neudert’s blog “Process Performance Indicators – From process analysis to reporting/cockpit” (http://scn.sap.com/people/dirk.neudert/blog/2007/11/05/process-performance-indicators-from-process-analysis-to-reportingcockpit) and consider the following questions: To what extent can you distinguish between KPIs and PPI’s for some representative part of your organisation? How and where do you distinguish between those measures that reduce cost and risk ‘vs’ those that increase profit and value? How do you distinguish between the objects and the signs in your measures? To what extent are the existing (or potential) models that you have (and you might have to be creative here) useful? Lastly, refer to the LEAD-Value-Reference-Framework-Value-Management-Lifecycle diagram (LEAD-Value-Reference-Framework-Value-Management-Lifecycle.pdf) and try to instantiate with examples relevant to your organisation
- From EAS (Essential Project): EAvaluator (http://www.enterprise-architecture.com/EAvaluator/) - the EAS Enterprise Architecture maturity assessor - will evaluate the answers you give to a comprehensive set of sixteen questions and will provide an assessment of the level of maturity of your organisation’s Enterprise Architecture. Based on the assessment, it will also provide suggestions regarding how you may improve your Enterprise Architecture. The test will take approximately five minutes. This complex, rule-driven assessment is based on both our extensive experience of delivering global enterprise architectures and on the ACMM (Architecture Capability Maturity Model) produced by the US Department of Commerce. -- Also, Gartner (as another example): ITScore for Enterprise Architecture Gartner's ITScore maturity assessment for enterprise architecture assesses EA maturity at five levels, based on eight major dimensions of an EA practice. This research examines our five-level framework for enterprise architecture teams to use in determining EA maturity. (in http://www.gartner.com/it-glossary/enterprise-architecture-ea/)
- How might EA relate to each of the other management activities in your organisation, given other approaches such as these can be integrated with EA? And remembering Pragmatics, we seek solutions but can expect to find better questions that we can then iterate to find even better questions thus (more) useful models.
- Some ‘takeaway’ thoughts… NB At http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap20.html is Chapter 20 in TOGAF (2011)
- TOA, and its high-level relationships with SOA and POA are described in Polovina (2013)
- i.e. should be at 1!
- An summary of the session content, and any associated activities
- Box, G. (1987, p.424) In: Box, G. & Draper, N.R. (1987) . Empirical Model-Building and Response Surfaces, Wiley Series in Probability and Statistics Lanir, L. (2012) Charles Sanders Peirce’s Semiotics – The Triadic Model, http://www.decodedscience.com/charles-sanders-peirces-semiotics-the-triadic-model/22974/2 Malik, N. (2009), Why the Zachman Framework is not an ontology, http://blogs.msdn.com/b/nickmalik/archive/2009/12/18/why-the-zachman-framework-is-not-an-ontology.aspx Moore, G. A. (2002), Living on the Fault Line, Harper Business Polovina, Simon (2007) "An Introduction to Conceptual Graphs", Proceedings of the 15th International Conference on Conceptual Structures (ICCS 2007): Conceptual Structures: Knowledge Architectures for Smart Applications, July 2007, Sheffield, UK; Priss, Uta; Polovina, Simon; Hill, Richard (Eds.); Lecture Notes in Artificial Intelligence (LNAI 4604), Springer, 1-15, http://www.Polovina.me.uk/publications/46040001-SP-Intro-to-CG.pdf Polovina, S. (2013) "A Transaction-Oriented Architecture for Enterprise Systems, IJIIT, October-December 2013, Vol. 9, No. 4, pp.69-79, http://www.igi-global.com/article/a-transaction-oriented-architecture-for-enterprise-systems/103880 Ross, J. W; Weill P; David C. Robertson, D. C. (2006) Enterprise Architecture As Strategy: Creating a Foundation for Business Execution Harvard Business School Press Sessions, R. (2007) A Comparison of the Top Four Enterprise-Architecture Methodologies, http://msdn.microsoft.com/en-us/library/bb466232.aspx Sowa, J. F. (2002). Representing Knowledge Soup in Language and Logic, http://www.jfsowa.com/talks/souprepr.htm Sowa, J. F. & Zachman, J. A. (1992). Extending and formalizing the framework for information systems architecture, IBM Systems Journal 31(3), 590-616 TOGAF (2011) TOGAF® 9.1, http://pubs.opengroup.org/architecture/togaf9-doc/arch/ Zachman, J.A. (1987) A Framework for Information Systems Architecture, IBM Systems Journal, 26(3), 276-292