O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

ACS EA-SIG - Bridging enterprise-architecture and systems-thinking

3.052 visualizações

Publicada em

Webinar for Australian Computer Society - Enterprise Architecture Special Interest Group, September 2015

A core aim in Enterprise Architecture (EA) and Systems-Thinking (ST): things work better when they work together on purpose. For this to happen, we need guided conversations that are actually everyone’s responsibility. What visual tools can we use to engage people in this?
This webinar introduces these concepts, and provides the tools and techniques need to bridge this gap. We will highlight some of the common approaches, frameworks and tools used in both of these highly related and important disciplines.
We will discuss how they can be used together and enhanced to deliver a common sense approach for everyday EA and ST practice. Included in this discussion is an introduction to the Enterprise Canvas, which is a powerful tool to enable visualisations of the enterprise by defining the services it offers and their relationships and interactions.

Publicada em: Negócios
  • Seja o primeiro a comentar

ACS EA-SIG - Bridging enterprise-architecture and systems-thinking

  1. 1. ACS EA-SIG Webinar Bridging enterprise-architecture and systems-thinking Tom Graves, Tetradian Consulting: September 2015
  2. 2. Hi there. This is me. I’m Tom Graves. (to provide a face to go with the voice…)
  3. 3. investor (money etc) customer (value) citizen (values) supplier relations value- proposition supplier channels value- creation customer channels customer relations value- outlay value- governance value- return supplier customer investor beneficiary coordinationdirectionvalidation before before during during after after investment dividend guidanceguidance mgmt-info Enterprise Service Canvas
  4. 4. Setting the scene…
  5. 5. What is architecture?
  6. 6. The aim of all architecture, and systems-thinking too: things work better when they work together on purpose
  7. 7. Two definitions… Enterprise “a shared purpose, a bold endeavour” (bounded by vision, values and commitments) Organisation “a structure and means to achieve ends” (bounded by rules, roles and responsibilities) Organisation and enterprise are not the same!
  8. 8. Where is architecture? A generic business-structure Contact Customer Manage the Business Support the Business Accept Orders Deliver Orders Process Orders Fulfil Orders
  9. 9. Where is architecture? The architecture is in the ‘between-spaces’ Contact Customer Manage the Business Support the Business Accept Orders Deliver Orders Process Orders Fulfil Orders analysts (inside the boxes) architects (between the boxes)
  10. 10. Solution architects (connect everything together within a project) Who are the architects? design-solutions will be needed wherever there’s some kind of change going on… - project, programme, portfolio, transformation - …and wherever a solution is being developed, we’ll need a solution-architect
  11. 11. Domain architects (connect everything across a discipline or domain) Who are the architects? these include: infrastructure-architect, data-architect, applications-architect, business-architect, security-architect, financial-architect, facilities-architect, brand-architect, organisation-architect, process-architect, skills/training architect, governance-architect, and many more
  12. 12. Enterprise architects (connect everything together) Who are the architects? that ‘everything’ will include: IT-infrastructure, data, applications, non-IT technologies, business-models, security, financials, facilities, brands, organisation- structures, processes, interactions, skills/training, governance, quality, environment, health-and-safety… - every distinct domain, and much, much more
  13. 13. What architects say… “I don’t know…” “(but I know how to find out)” “It depends…” “(and I know what it depends on)” “Just enough detail…” “(and I know the level of detail that it needs)”
  14. 14. For architecture to happen, we need guided-conversations that are everyone’s responsibility. What visual tools will engage people in this?
  15. 15. Where do we start?
  16. 16. Short answer: start with the tools we already have in our ideas-toolkit…
  17. 17. Exploring the toolkit
  18. 18. On one side, there’s enterprise-architecture…
  19. 19. Enterprise-architecture… Zachman Framework
  20. 20. Enterprise-architecture… The ‘BDAT stack’ Business Architecture Data Architecture Applications Architecture Technology Architecture (Information-Systems Architecture)
  21. 21. Enterprise-architecture… TOGAF (The Open Group Architecture Framework)
  22. 22. Enterprise-architecture… PRM (Performance Reference Model) from FEAF ([US] Federal Enterprise Architecture Framework)
  23. 23. Enterprise-architecture… Process-models (lots of them)
  24. 24. Enterprise-architecture… Capability-models (lots of them)
  25. 25. Enterprise-architecture… Information-models (lots of them)
  26. 26. Enterprise-architecture… Business-models (lots of them)
  27. 27. Enterprise-architecture… And computers, of course. (lots and lots and lots of them…)
  28. 28. Experience: mainstream ‘enterprise’-architecture may be too IT-centric, too fragmenting, too incomplete?
  29. 29. On the other side, there’s systems-thinking and other whole-context methods…
  30. 30. Systems-thinking… ISO9000 quality-system standards work-instruction procedure policy vision more concrete more abstract
  31. 31. Systems-thinking… ‘Tetradian’ dimensions – physical ‘things’, virtual information, relational links between people, aspirational purpose Shared-purpose (vision and values) Relationships (person-to-person) Transactions (products and services) Conversations (exchange of information) Integration (how the market links together)
  32. 32. Systems-thinking… Rotating between perspectives…
  33. 33. Systems-thinking… Modality – the MoSCoW set (“Must, Should, Could, can-Wait”) CC-BY-NC-SA thisisbossi via Flickr (or “Maybe, Sometimes, Could-be-possible, We-don’t-know”?)
  34. 34. Systems-thinking… SCAN – making sense of complexity…
  35. 35. Systems-thinking… Systems-interdependency maps
  36. 36. Systems-thinking… Stafford Beer’s ‘Viable System Model’
  37. 37. Systems-thinking… Recursion and fractality in natural systems CC-BY-NC-SA gjshepherd via Flickr
  38. 38. Systems-thinking… Extensions to Tuckman, and Five Element (wu-xing) Performance (adjourning) reporting etc Purpose (forming) strategy etc People (storming) HR etc Preparation (norming) scheduling etc Process (performing) production etc Operations (‘do’) Tactics (‘think’) Strategy (‘feel’)
  39. 39. Systems-thinking… Extensions to Five Element (wu-xing) on leadership, flow Performance Purpose People Preparation Process PoliciesValues Events Completions Success (start here) Trust / Commitment (Initiating-Events) (Completion-Events)
  40. 40. Systems-thinking… Extensions to SWOT for strategy and effectiveness
  41. 41. Systems-thinking… Worldviews, deep-metaphors and modes of operation… Scientist (‘outer truth’) Believer (‘inner truth’) Technologist (‘outer value’) Artist (‘inner value’) truth (thought) value (feeling) internalised (subjective) externalised (objective) uncharted swamp
  42. 42. Systems-thinking… Models of power-interactions between people… power-over power-with power-under power-from-within person A person B
  43. 43. Systems-thinking… An emphasis on people, and spaces… CC-BY-ND alanclarkdesign via Flickr
  44. 44. Systems-thinking… Include the people-story…
  45. 45. Systems-thinking… An emphasis on the system as a whole… CC-BY-ND Kecko via Flickr
  46. 46. Experience: systems-thinking tools can be very powerful, yet may be too ‘abstract’ for people to follow?
  47. 47. How do we link EA and ST together, into tools that can work and ‘make sense’ for everyday EA / ST practice?
  48. 48. Recursion: this process to develop tools for EA and systems-thinking is itself an application of EA and systems-thinking
  49. 49. investor (money etc) customer (value) citizen (values) supplier relations value- proposition supplier channels value- creation customer channels customer relations value- outlay value- governance value- return supplier customer investor beneficiary coordinationdirectionvalidation before before during during after after investment dividend guidanceguidance mgmt-info Enterprise Service Canvas…
  50. 50. About service
  51. 51. Start with an assertion: Everything in the enterprise is or represents a service. (If so, we can describe everything in the same consistent way.)
  52. 52. A tension exists between what is, and what we want. The vision describes the desired-ends for action; values guide action, describing how success would feel. Why anything happens
  53. 53. A service represents a means toward an end – ultimately, the desired-ends of the enterprise-vision. The nature of service
  54. 54. Services exchange value with each other, to help each service reach toward their respective vision and outcome. Relations between services
  55. 55. Services serve. (That’s why they’re called ‘services’…) What they serve is the story, via exchange of value. (And if we get that right, they can sometimes make money, too.)
  56. 56. Each service sits at an intersection of values (vertical) and exchanges of value (horizontal) Values and value
  57. 57. Value-flow is ‘horizontal’, but connection is first made by ‘vertical’ connection to shared-value and value-proposition How connection happens
  58. 58. Interactions during the main-transactions are preceded by set-up interactions (before), and typically followed by other wrap-up interactions such as payment (after). We can describe ‘child-services’ to support each of these. value-add (self) customer- facing supplier- facing In more detail
  59. 59. Crossmap between Business Model Canvas and Enterprise Canvas Business-model as service
  60. 60. Services link together in chains or webs, as structured and/or unstructured processes, to deliver more complex and versatile composite-services. Supply-chain as shared-service
  61. 61. Guidance for services
  62. 62. Use the Viable System Model (direction, coordination, validation) to describe service-relationships to keep this service on track to purpose and in sync with the whole. Keeping on track
  63. 63. Viable System Model, representing a fractal service Keeping on track: VSM
  64. 64. Viable System Model ‘systems’ are orthogonal to each other Keeping on track: VSM
  65. 65. Coordination and Validation don’t fit comfortably with Taylorism Keeping on track: VSM
  66. 66. This is the equivalents of VSM system-3, -4 and -5 Keeping on track: Direction management-services policy strategy direction
  67. 67. Interactions with delivery-services (system-1), and recursion Keeping on track: Direction management-services policy strategy direction policy strategy direction interaction with management-services in parent-service above interaction with management-services in child-services below
  68. 68. Extended functions for equivalent of VSM system-2 Keeping on track: Coordination delivery- service management-services policy strategy direction develop the business change the business run the business delivery- service delivery- service
  69. 69. The VSM algedonic links - ‘any-to-any’ connections - provide another kind of coordination. (Hard to show on diagrams, though.)
  70. 70. Major extensions / rethink for VSM system-3* Keeping on track: Validation
  71. 71. Validation-services: for each enterprise-value: - build awareness of the value - build capability to enact support - enact in practice at run-time - assess and review (for continual improvement)
  72. 72. Investors and beneficiaries
  73. 73. These flows (of which only some types are monetary) are separate and distinct from the main value-flows. Investor and beneficiary
  74. 74. Another useful assertion: Every enterprise is ‘for-profit’. (We need to think of ‘profit’ in a much broader sense than money alone.)
  75. 75. Investors and beneficiaries are often outside even of the market – yet are still part of the same shared-enterprise. Investor and beneficiary shared-enterprise includes community, government, non-clients, anti-clients, others market includes competitors, regulators, otherssupplier- prospects customer- prospects organisationsupplier customer includes investors, beneficiaries
  76. 76. We need to consider investments and returns of every applicable type, to and from every type of stakeholder. (‘Applicable type’ is determined by the shared-enterprise values.)
  77. 77. A stakeholder in the story is anyone who can wield a sharp-pointed stake in your direction… CC-BY-NC-SA evilpeacock via Flickr Stakeholders in the enterprise (Hint: there are a lot more of them than you might at first think…)
  78. 78. value-flow (‘how’, ‘with-what’) value-flow (‘how’, ‘with-what’) These are distinct flows – don’t mix them up! values (‘why’) values (‘why’) profit (money and more) profit (money and more) Values, value-flow, money
  79. 79. Values-first enables full connection with shared-enterprise Doing it right: values-first…
  80. 80. Money-first causes disconnect from shared-enterprise Doing it wrong: money-first…
  81. 81. If we focus on money, we lose track of value. If we focus on the ‘how’ of value, we lose track of the ‘why’ of values. Always start from the values. (Not the money.)
  82. 82. Layers of abstraction for service views
  83. 83. Row-numbering aligns with Zachman ‘Rows’ – layers of abstraction Enterprise Scope (context) Business- services Service- content Service- design Service- deployment Action- record other other other other supplier customer supplier customer supplier customer supplier customer Enterprise identity, vision and values Lists of key players and items in enterprise Roles / relations between / within key players / items Actions / transactions - implementation-independent Actions / transactions - implementation-specific Actions / transactions - operations-specific (action-plan) Actions / transactions - as actioned / completed (past) row-0 row-1 row-2 row-3 row-4 row-5 row-6
  84. 84. Each ‘row’ downward adds something more to the description. Example: row-3 is implementation-independent, row-4 is implementation-specific.
  85. 85. These are not layers… They’re related views into a shared scope Business Architecture Data Architecture Applications Architecture Technology Architecture (Information-Systems Architecture)
  86. 86. Layers in Enterprise Canvas are layers of abstraction within the same scope - not arbitrary views into different parts of the scope, with arbitrary interconnections!
  87. 87. Row-0 is solely the enterprise-vision and (optional) values Row-0 example - ZapaMex “making feet happy” enterprise-vision as identified by ZapaMex
  88. 88. Row-1 is simple lists from Zachman interrogatives, describing entities needed to make the enterprise happen Row-1 example - ZapaMex “making feet happy” Who What How Where When Why
  89. 89. Row-2 starts to show relationships across the enterprise Row-2 example - ZapaMex “making feet happy” leather supplier ZapaMex designer overseas market- partner shoe- buyer medical partner competitor
  90. 90. An overly-simplistic row-3, based on transactions only Row-3 example - ZapaMex receive materials to inventory make shoes store and ready shoes for shipment obtain materials deliver shoessupplier customer
  91. 91. Describe more of the row-3 detail for service-delivery Row-3 example - ZapaMex procurement product- development + marketing receive materials to inventory make shoes store and ready shoes for shipment sales and service accounts payable manage budget, operations accounts receivable identify and support suppliers obtain materials pay for materials identify and support customers deliver shoes be paid for shoes supplier customer
  92. 92. Expand row-3 modelling out to the full enterprise-context Row-3 example - ZapaMex shared-enterprise market procurement product- development + marketing receive materials to inventory make shoes store and ready shoes for shipment sales and service accounts payable manage budget, operations accounts receivable identify and support suppliers obtain materials pay for materials identify and support customers deliver shoes be paid for shoes supplier customer gain supplier respect gain customer respect verify supplier satisfaction verify customer satisfaction gain / maintain market respect gain / maintain enterprise reputation verify market satisfaction verify enterprise satisfaction
  93. 93. Rows 4, 5 and 6 add levels of implementation-detail. Row 4: all implementation types. Row 5: intended run-time set-up. Row 6: what was actually used.
  94. 94. Internal structures of services
  95. 95. We can view what services consist of in various ways - but eventually we’ll need the full detail Service-content
  96. 96. In rows 1 and 2 (lists, and basic relations between entities), we can get away with the simple Zachman-interrogatives Service-content What How Where Who When Why
  97. 97. For rows 2 and 3 (implementation-independent), we start to need to become more specific Service-content Capabilities Locations Functions Assets Events Decisions
  98. 98. Asset (‘What’) - a resource for which the organisation acknowledges responsibility Composition: any combination of asset-dimensions.
  99. 99. Function (external of ‘How’) - external-facing interface, responsible for service-contracts, protocols, SLAs, etc; accepts and returns assets Composition: any combination of asset-dimensions.
  100. 100. Location (‘Where’) - a position within the terms of a specific schema Composition: any combination of asset-dimensions, plus time-as-location.
  101. 101. Capability (‘Who’ / ‘How’ / ‘What’) - the ability to do something: - agent enacts the capability - action asset-type acted upon - skill-level competence of the agent Composition: agent / action: asset-dimensions skill-level: skills/decision dimensions (also recursively composed of other services)
  102. 102. Event (‘When’) - trigger for a function and underlying capability Composition: any combination of asset-dimensions.
  103. 103. Decision / Reason (‘Why’) - sensemaking / decision-making for the service, and/or its type of guidance or governance Composition: any combination of decision/skills dimensions.
  104. 104. Seen from outside, function and service may seem the same: service is the whole thing, function is just its external-interface Function, capability and service service capabilities function (interface)
  105. 105. Starting in row-3, and downward to the real-world, we must have the full detail of how all the elements intersect Service-content
  106. 106. Most entities will consist of any appropriate combination – e.g. book is physical ‘thing’, contains information, is valued Asset dimensions Assets Phys Virtual Reln Aspn physical object, machine, geographic location etc information, software-application, IP-address etc link between people and/or to other tangible 'things' person-to-virtual or virtual-to virtual link (brand etc) Physical Virtual Relational Aspirational WhatAsset-types
  107. 107. is when they are slaves… CC-BY-NC-ND littlejoncollection via Flickr A warning on relational-assets… - the only time that people are ‘assets’ “Our people are our greatest asset!” The asset is the relationship - not the person…
  108. 108. Most contexts will need to include combinations of these Decision/skills dimensions Decisions simple, linear, true/false or limited-quantitative complicated, linear but allow for delays, feedback complex, ambiguous, non-linear, 'wild-problems' uniqueness, extreme-uncertainty, 'chaotic' Rules Algor’m Guideln Princpl Rule-based (trainee) Algorithmic (apprentice) Guidelines (journeyman) Principle-based (master) WhyDecision/skill-types
  109. 109. Decision/skills dimensions Decisions simple, linear, true/false or limited-quantitative complicated, linear but allow for delays, feedback complex, ambiguous, non-linear, 'wild-problems' uniqueness, extreme-uncertainty, 'chaotic' Rules Algor’m Guideln Princpl Rule-based (trainee) Algorithmic (apprentice) Guidelines (journeyman) Principle-based (master) WhyDecision/skill-types IT not ITNote that IT can’t do everything…
  110. 110. Human decision/skills have a distinct development-pattern Decision/skills dimensions
  111. 111. Architects can use this as a graphical checklist to describe the content and structure of all services. (Also illustrates that Zachman needs an entire extra dimension…) Service-content
  112. 112. Products as exchanges between services
  113. 113. Products are exchanged between services Exchanges Service Product Service
  114. 114. A product is an outcome of service and the promise of future service or self-service.
  115. 115. Products / exchanges are always (sets of) assets, composed of combinations of the asset-dimensions. Exchanges as assets Assets Phys Virtual Reln Aspn physical object, machine, geographic location etc information, software-application, IP-address etc link between people and/or to other tangible 'things' person-to-virtual or virtual-to virtual link (brand etc) Physical Virtual Relational Aspirational WhatAsset-types
  116. 116. Views across service-boundary • Outside-out: Big-picture ‘world’, beyond even the market • Outside-in: View from ‘outside’ into organisation • Journey: Touchpoints between ‘outsider’ and organisation • Inside-out: View from the organisation’s perspective • Inside-in: View of the organisation to inside itself
  117. 117. Cycles of interaction between services
  118. 118. Overall flow of service and exchange follows a consistent cycle The service-cycle boundary of ‘market’ in conventional business-models Shared-purpose defines the service-context Reputation / trust Respect / relations Attention / conversation Transaction / exchange (profit / value-return) Completion Reaffirmed trust
  119. 119. Much the same themes apply to shared-enterprise and market Enterprise and service-cycle shared-enterprise includes community, government, non-clients, anti-clients, others market includes prospects, competitors, regulators, others transaction organisationsupplier customer Reputation / trust Respect / relations Attention / conversation Transaction / exchange (profit / value-return) (completion) (reaffirmed trust)
  120. 120. The service-cycle applies across all of these connections Enterprise and service-cycles shared-enterprise market procurement product- development + marketing receive materials to inventory make shoes store and ready shoes for shipment sales and service accounts payable manage budget, operations accounts receivable identify and support suppliers obtain materials pay for materials identify and support customers deliver shoes be paid for shoes supplier customer gain supplier respect gain customer respect verify supplier satisfaction verify customer satisfaction gain / maintain market respect gain / maintain enterprise reputation verify market satisfaction verify enterprise satisfaction
  121. 121. Different stages of the cycle emphasise different asset-types (overall cycle needs to complete for trust to be maintained) Asset-dimensions and service-cycle shared-purpose (aspirational) relationship (relational) conversation (virtual) transaction (physical) (delivery of service) (completion of actions) (completion for provider) (completion for customer) (completion for enterprise) (reaffirmed trust)
  122. 122. Every instance of service is also a project in its own right Project-cycle and service-cycle Performance (adjourning) reporting etc Purpose (forming) strategy etc People (storming) HR etc Preparation (norming) scheduling etc Process (performing) production etc
  123. 123. An adaptation of Five Elements describes service-lifecycles Five Elements and enterprise
  124. 124. Identify the elements that help to pull from one phase to next Five Elements and service-cycle Performance Purpose People Preparation Process PoliciesValues Events Completions Success (start here) Trust / Commitment (Initiating-Events) (Completion-Events)
  125. 125. ‘Inside’ child-services of Enterprise Canvas shown to left; ‘outward-facing’ child-services shown to right. Service-cycle and Enterprise Canvas value- proposition value- creation supplier / customer channels supplier / customer relations value- governance value- outlay / return Purpose Preparation Performance Values Events Success Process People Policies Completions Values Events Completions Success Policies Perform ance Purpose People Prepara tion Process enterprise vision Trust Trust
  126. 126. Similar exchanges apply across every interchange and flow Exchanges everywhere…
  127. 127. Wrapping-up…
  128. 128. Restate that assertion: Everything in the enterprise is or represents a service. (If so, we can describe anything in the shared-enterprise with Enterprise Canvas.)
  129. 129. Remember, though, that architecture is always about more than structure, or IT…
  130. 130. …it’s always about people… …making sense of the enterprise, together.Photo © Michael Smith Castillo
  131. 131. The aim of all architecture: things work better when they work together on purpose
  132. 132. What will you do to help make that happen?
  133. 133. Thank you!
  134. 134. Contact: Tom Graves Company: Tetradian Consulting Twitter: @tetradian ( http://twitter.com/tetradian ) Weblog: http://weblog.tetradian.com Slidedecks: http://www.slideshare.net/tetradian Publications: http://tetradianbooks.com and http://leanpub.com/u/tetradian Books: • Mapping the enterprise: modelling the enterprise as services with the Enterprise Canvas (2010) • The service-oriented enterprise: enterprise architecture and viable services (2009) • Doing enterprise-architecture: process and practice in the real enterprise (2009) Courses: See post ‘Upcoming EA tour in Australia’ for details on workshops, masterclasses and other events in Sydney, Perth and Melbourne, October-November 2015 Further information:

×