Successfully reported this slideshow.
Your SlideShare is downloading. ×

Backbone and edge - architecting the balance between continuity and change

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 80 Ad
Advertisement

More Related Content

Slideshows for you (14)

Similar to Backbone and edge - architecting the balance between continuity and change (20)

Advertisement

More from Tetradian Consulting (14)

Recently uploaded (20)

Advertisement

Backbone and edge - architecting the balance between continuity and change

  1. 1. Backbone and edge architecting the balance between continuity and change Tom Graves, Tetradian Consulting IASA Architecture Summit, London, April 2013
  2. 2. Hi. I’m Tom. (That’s all of the PR stuff out of the way...)
  3. 3. Governance. (Okay, it’s not a popular word... but we do have to face it, otherwise nothing works...)
  4. 4. Waterfall? or Agile? or what? (the only thing that’s certain is that one-size-doesn’t-fit-all...)
  5. 5. A practical answer: All of them, together (Waterfall, Agile and Mixed) by using an architecture-pattern called backbone and edge...
  6. 6. CC-BY GardenOfEaden …agility needs a backbone!
  7. 7. Practice-stuff Practice-questions look like this slide • work in pairs, if possible • work fast – max. 1minute per question • record as you go, with notes or sketches Get pen-and-paper or tablet ready now… (There are ~12 practical questions in this session)
  8. 8. Design and governance #1
  9. 9. Assertion: Everything in the enterprise is connected with everything else. (If so, we can start anywhere.)
  10. 10. Practice-question What’s your problem? Start anywhere: Pick a practical challenge from your current context to work with here.
  11. 11. Trade-offs and uncertainties #2
  12. 12. Too many trade-offs? stability adaptability continuity (exploitation) change (innovation) sameness (economy-of-scale) uniqueness (market-of-one) ‘control’ ‘anarchy’? Waterfall Agile versus versus versus versus versus
  13. 13. Practice-question What trade-offs do you face? Summarise some examples for your current context.
  14. 14. Design for uncertainty CC-BY Todd Hudson via Flickr …requisite-variety
  15. 15. Design for uncertainty © AviationExplorer …requisite-inefficiency
  16. 16. Design for uncertainty …requisite-fuzziness
  17. 17. Practice-questions What are the uncertainties? How do you work with this? Summarise the requisite-variety, variety- weather, requisite-inefficiency, requisite- fuzziness and suchlike in the context.
  18. 18. Everything-as-a-service #3
  19. 19. Assertion: Everything in the enterprise is or represents a service. (If so, we can describe everything in the same consistent way.)
  20. 20. 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
  21. 21. A service represents a means toward an end – ultimately, the desired-ends of the enterprise-vision. The nature of service
  22. 22. Product CC-BY Kiran Kodoru via Flickr Product is static… …a kind of ‘proto-service’
  23. 23. Service CC-BY Igor Schwarzmann via Flickr Service implies action… …action implies service
  24. 24. Services exchange value with each other, to help each service reach toward their respective vision and outcome. Relations between services
  25. 25. Each service sits at an intersection of values (vertical) and exchanges of value (horizontal) Values and value
  26. 26. Services serve. (That’s why they’re called ‘services’…) What they serve is a shared vision, via exchange of value. (And if we get that right, they can sometimes make money, too.)
  27. 27. CC-BY AllBrazilian via Wikimedia It’s also always about people… …‘service’ means that someone’s needs are served
  28. 28. Practice-questions What is this service? Whom does it serve, and why? Summarise the context as a service – its inputs, actions and outputs, actors and stakeholders, values and value-exchanges, and its overarching ‘why’.
  29. 29. 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
  30. 30. Services link together in chains or webs, as structured and/or unstructured processes, to deliver more complex and versatile composite-services. Supply-chain or value-web
  31. 31. Practice-questions What are the interfaces between services? What is exchanged between each pairing of services, or along chains of services? What Exchanges take place before, during and after each main-transaction?
  32. 32. Backbone and edge #4
  33. 33. “Let’s do a quick SCAN of this…” Making sense for design
  34. 34. “Insanity is doing the same thing and expecting different results” (Albert Einstein) ORDER (rules do work here) Take control! Impose order!
  35. 35. “Insanity is doing the same thing and expecting different results” (Albert Einstein) “Insanity is doing the same thing and expecting the same results” (not Albert Einstein) ORDER (rules do work here) UNORDER (rules don’t work here) Order and unorder
  36. 36. A quest for certainty: analysis, algorithms, identicality, efficiency, business-rule engines, executable models, Six Sigma... SAMENESS (IT-systems do work well here) UNIQUENESS (IT-systems don’t work well here) Same and different An acceptance of uncertainty: experiment, patterns, probabilities, ‘design-thinking’, unstructured process...
  37. 37. THEORY What we plan to do, in the expected conditions What we actually do, in the actual conditions PRACTICE Theory and practice
  38. 38. algorithm guideline rule principle Sensemaking creates clarity for action Making sense with SCAN
  39. 39. Practice-questions What do you need to be certain about? What is always going to be uncertain or unique? (‘Messy’ – politics, management, wicked- problems, ‘should’ vs ‘is’, etc.) What will always be ‘messy’?
  40. 40. ORDER (a sense of ‘the known’) UNORDER (a sense of ‘the unknown’) We need governance that can adapt to work with the full spectrum. A spectrum of uncertainty
  41. 41. One of the hardest parts of working with uncertainty is to build the right balance between known and unknown - between backbone and edge.
  42. 42. Backbone and edge order (rules do work here) unorder (rules don’t work here) fail-safe (high-dependency) safe-fail (low-dependency) analysis (knowable result) experiment (unknowable result) BACKBONE EDGE Waterfall (‘controlled’ change) Agile (iterative change)
  43. 43. Backbone, domain and edge order unorder fail-safe (high-dependency) BACKBONE safe-fail (low-dependency) EDGE plan actual Waterfall (‘controlled’ change) Agile (iterative change) Mixed (guided change) analysis (knowable result) DOMAIN experiment (unknowable result)
  44. 44. A spectrum of services
  45. 45. Choices: everything we place in the backbone is a constraint on agility; anything we omit from the backbone may not be dependable. It’s not an easy trade-off…
  46. 46. Vision and values are always part of the backbone: values as ‘shared-services’.
  47. 47. A spectrum of services also implies a spectrum of governance: governance of governance itself.
  48. 48. Practice-questions Which services fit more in backbone, domain or edge? What governance to apply to each: Waterfall, Agile, Mixed? If Mixed, how would the appropriate mix be identified and governed?
  49. 49. Viable services #5
  50. 50. Use the Viable Services 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
  51. 51. These flows (of which only some types are monetary) are separate and distinct from the main value-flows. Investor and beneficiary
  52. 52. Practice-questions What are the interdependencies for this service? What is needed from other services for this to be viable? Identify what is needed from value-web, direction and investor/beneficiaries.
  53. 53. More on the big-picture #6
  54. 54. “We create an architecture for an organisation, but about an enterprise.” “We create an architecture for an organisation, but about an enterprise.” Tom Graves, Mapping the Enterprise, Tetradian, 2010 Whose architecture? Organisation aligns with structure, enterprise with story. We need a balance of both for the architecture to work.
  55. 55. “An organisation is bounded by rules, roles and responsibilities; an enterprise is bounded by vision, values and commitments.” “An organisation is bounded by rules, roles and responsibilities; an enterprise is bounded by vision, values and commitments.” Tom Graves, Mapping the Enterprise, Tetradian, 2010 What architecture? Organisation aligns with structure, enterprise with story. We need a balance of both for the architecture to work.
  56. 56. If the organisation says it ‘is’ the enterprise, there’s no shared-story - and often, no story at all. Whose story?
  57. 57. The minimum real enterprise is the supply-chain - a story of shared transactions. Whose story?
  58. 58. The organisation and enterprise of the supply-chain take place within a broader organisation of the market. Whose story?
  59. 59. The market itself exists within a context of ‘intangible’ interactions with the broader shared-enterprise story. Whose story?
  60. 60. “Customers do not appear in our processes… …we appear in their experiences.” “Customers do not appear in our processes… …we appear in their experiences.” A question of perspective We must create the architecture around the shared-story - not solely around our organisation’s structures. Chris Potts, recrEAtion, Technics, 2010
  61. 61. Every service has its own myriad of stakeholders. Whose story?
  62. 62. value-flow (‘how’, ‘with-what’) value-flow (‘how’, ‘with-what’) These are distinct flows – don’t mix them up! values (‘why’) values (‘why’) moneymoney Values, value-flow, money
  63. 63. Always start from values, not money.
  64. 64. 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.)
  65. 65. Practice-questions Who are the stakeholders for this service? What are their respective needs, priorities, drivers? Identify what is needed to balance the relations and priorities of all stakeholders.
  66. 66. In sourcing via supply-chain, services are ‘outside’, and boundary-of-identity and boundary-of-control are same. Sourcing: supply-chain
  67. 67. In insourcing, services are ‘inside’, and the boundary- of-identity and boundary-of-control are the same. Sourcing: insourcing
  68. 68. In outsourcing, services are ‘inside’ boundary-of-identity but ‘outside’ boundary-of-control. Sourcing: outsourcing
  69. 69. Practice-questions Who ‘owns’ each service? What is each respective boundary-of identity and boundary-of-control? If a service is outside the boundary-of- control, how is it managed and ‘controlled’?
  70. 70. Architecting for change #7
  71. 71. Everything changes…
  72. 72. Practice-questions How does each service change over time, and why? How do you manage migration into and out of the backbone? Identify governance needed to manage this, and governance of governance itself.
  73. 73. Structure and story Afterword
  74. 74. Nice view of structure, but…
  75. 75. …where are the people?
  76. 76. Start with structure, or process...
  77. 77. …but include the people-story!
  78. 78. What did you discover in doing this? What will you do different on Monday morning? Questions and insights • Governance (Waterfall,Agile and Mixed) • Perspective (Inside-out and outside-in) • Design for uncertainty (Same and different) • Design for change (Backbone and edge)
  79. 79. Thank you!
  80. 80. Contact: Tom Graves Company: Tetradian Consulting Email: tom@tetradian.com 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: • The enterprise as story: the role of narrative in enterprise- architecture (2012) • Mapping the enterprise: modelling the enterprise as services with the Enterprise Canvas (2010) • Everyday enterprise-architecture: sensemaking, strategy, structures and solutions (2010) • Doing enterprise-architecture: process and practice in the real enterprise (2009) Further information:

×