Successfully reported this slideshow.
Your SlideShare is downloading. ×

How architectures fail, and what to do about it

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

Check these out next

1 of 76 Ad

How architectures fail, and what to do about it

Download to read offline

Why do enterprise-architecture fail? Three of the most common causes are:
-- Blurring between the distinct roles of architecture and design
-- Starting architecture too late and/or finishing too early in the process for making something real
-- Placing arbitrary constraints on content, scope and/or scale

Each of these errors causes the architecture to fragment and then fail.

In this slidedeck, we explore the causes for each of these errors, why they occur, the effects that the errors have, and what to do to avoid them.

Why do enterprise-architecture fail? Three of the most common causes are:
-- Blurring between the distinct roles of architecture and design
-- Starting architecture too late and/or finishing too early in the process for making something real
-- Placing arbitrary constraints on content, scope and/or scale

Each of these errors causes the architecture to fragment and then fail.

In this slidedeck, we explore the causes for each of these errors, why they occur, the effects that the errors have, and what to do to avoid them.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to How architectures fail, and what to do about it (20)

Advertisement

More from Tetradian Consulting (16)

Recently uploaded (20)

Advertisement

How architectures fail, and what to do about it

  1. 1. How architectures fail, and what to do about it Tom Graves, Tetradian The Bridge, June 2021
  2. 2. Hi. I’m Tom. (yeah, I’ve been around for a while…)
  3. 3. These days I’d describe myself as a travelling salesman for useful ideas... and perhaps also as a maker of tools for change
  4. 4. Three common causes for architecture failure: #1: Blurring between distinct roles of architecture and design #2: Starting architecture too late and/or finishing too early #3: Placing arbitrary constraints on content, scope and/or scale
  5. 5. We’ll use a modified (service- oriented) version of the Zachman frame to illustrate these fails Row-0 ‘Enterprise’ is in ‘unchanging future’, and should not change; Row-6 ‘Action-record’ is in the ‘unchangeable past’, and cannot change (Only the layers / rows are shown here – for this purpose, we’ll only need Zachman-like columns to describe Fail #3)
  6. 6. Each layer downward brings us closer to reality
  7. 7. Fail #1: Blurring between distinct roles of architecture and design
  8. 8. Architecture and design are two distinct types of task within a process of realisation… - a process of change to take an abstract intent and make it real
  9. 9. Each layer downward brings us closer to reality
  10. 10. The change-process is iterative, going up and down the stack… - things are usable to the extent that they’re ‘architecturally-complete’ - things are re-usable to the extent that they’re ‘architecturally-incomplete’
  11. 11. ‘Architecturally-complete’ means that we can give exact real-world answers to each of the Zachman questions: - Who? - What? - When? - Where? - How? - Why?
  12. 12. So what are architecture and design? - what are the differences in their tasks?
  13. 13. Architecture is… “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” (source: IEEE-1471) [...and as a verb, the processes of development for these items]
  14. 14. Architecture is also… “an exercise in narrative... a vehicle for the telling of stories, a canvas for relaying societal myths, a stage for the theatre of everyday life” (source: Matthew Frederick, ‘101 Things I Learned In Architecture School’) [Don’t ignore this - the architecture won’t work without it!]
  15. 15. Architecture connects back ‘upwards’ to the broader-scope constraints, and refines them for the current layer
  16. 16. Design is… “specifications towards implementation, in accordance with defined constraints, and at the requisite level of detail for the current stage of realisation” (source: Tom Graves) [...and as a verb, the processes of development for these items]
  17. 17. Design adds the detail needed for the current layer, reaching ‘downwards’ towards the real
  18. 18. Note: the design at each layer also provides the architecture for the next layer down towards reality
  19. 19. If we consider each layer as a distinct viewpoint, then architecture and design represent distinct views that are available from each and all of those viewpoints
  20. 20. Architecture and design are different tasks… ...don’t mix them up!
  21. 21. Core architecture questions: - What are the underlying vision, values, desires, drivers, stories? - For options, what are the constraints, boundaries, laws, standards?
  22. 22. Architecture is not design... if we only do architecture, we get stuck in analysis-paralysis, never getting any closer to reality
  23. 23. Core design questions: - Given the constraints, what is the most effective option? - Given the constraints, what is the best way to make that option real?
  24. 24. Design is not architecture... if we only do design, we wander out of scope, build on untested assumptions, or get stuck with ‘vendor-driven architecture’
  25. 25. Architecture and design are different tasks… ...don’t mix them up!
  26. 26. How to avoid Fail #1: Blurring between distinct roles of architecture and design
  27. 27. Architects work most on architecture, but also do some design Designers work most on design, but also do some architecture Be clear at all times which type of task you’re doing – they’re not the same!
  28. 28. At all times, remember which layer you’re working on, and the type of content and detail that it requires – the layers are not the same!
  29. 29. At all times, remember which way you face, either ‘upwards’ for architecture, ‘downwards’ for design – their tasks are not the same!
  30. 30. Fail #2: Starting architecture too late and/or finishing too early
  31. 31. Architecture and design will iterate up and down the realisation-stack… - Start too late: ignoring upper layers - Finish too early: no support for final stages of realisation
  32. 32. Enterprise- architecture must address the whole of the realisation- stack – or else the overall architecture will fragment
  33. 33. Classic ‘EA’ only covers part of the realisation- stack - ‘logical’, plus some of ‘physical’ and ‘conceptual’
  34. 34. A question of timescales: - Classic ‘EA’: c.1-5 years - Engineering: c.5-50 years - Human: c.0-100 years - Real EA: microseconds to millennia
  35. 35. If we only have a partial architecture, covering only part of the real timescale, how will the whole realisation-process work, with nothing to hold it together?
  36. 36. Partial architectures are not enough to make this work… If the connections from abstract to real are not complete, across all requisite timescales, the architecture will fail!
  37. 37. To support continual-iteration, architecture and design must support the entire lifecycle… This must include run-time, task- outcomes and decommissioning
  38. 38. We do this bit! (No idea – it’s nothing to do with us…) We tell others how to do this bit Not our problem – let them deal with it Architecture done wrong...
  39. 39. Architecture done right… We do this bit! We are also responsible for this bit We advise others on the architectures for this bit We learn from this bit
  40. 40. A simple guideline: If you can’t decommission it, don’t build it!
  41. 41. If decommission is ignored, the plan/build process becomes a machine for creating technical- debt... - decommissioning must be included in the architecture!
  42. 42. How to avoid Fail #2: Starting architecture too late and/or finishing too early
  43. 43. TOGAF done wrong Time to look at all the shiny new toys! Tedious paperwork that doesn’t matter and no-one reads Where we get to do the fun bit! The final design, which is perfect, of course The boring bit where we have to keep telling people that they’ve got the design wrong
  44. 44. TOGAF done right Benefits-realised, lessons-learned, tasks to reduce technical-debt Essential setup to connect to earlier architecture-work Our part of the architecture responsibility Demonstrator design showing how to align to the architecture Help people ensure that their designs and design-choices do align with architecture constraints and guidelines
  45. 45. If a classic ‘EA’ must run as a separate entity, ensure that it has adequate hooks into architecture and design for all other parts of the realisation- stack, maintained by other business units
  46. 46. Fail #3: Placing arbitrary constraints on content, scope and/or scale
  47. 47. We need to include in the architecture all of the Zachman columns: Who? What? When? Where? How? Why? But we need to do it properly - there’s an entire dimension missing from the Zachman framework...
  48. 48. C a p a b i l i t i e s L o c a t i o n s F u n c t i o n s A s s e t s E v e n t s D e c i s i o n s What How Where Who When Why C a p a b i l i t i e s ( a g e n t / a c t i o n s ) L o c a t i o n s F u n c t i o n s A s s e t s C a p a b i l i t i e s ( s k i l l - l e v e l ) E v e n t s D e c i s i o n s Asset-types: Physical Virtual Relational Aspirational Abstract Decision/skill-types: Rule-based Algorithmic Guidelines Principle-based rows 1-2 rows 2-3 rows 3-6 Vision row 0
  49. 49. That missing dimension in Zachman…
  50. 50. Asset-types apply in What, How, Where, When
  51. 51. Decision/skill-types apply in Who, Why
  52. 52. The realisation process only works properly when all of those dimensions are fully present
  53. 53. Classic IT-centric ‘EA’ only works on a subset…
  54. 54. …if the architecture and design will only address this subset- of-a-subset, how will it connect up with everything else in the overall architecture of the enterprise? ‘whole-enterprise’ EA ‘classic’ EA Enterprise Scope (context) Business- services Service- content Service- design Service- deployment Action- record row-0 row-1 row-2 row-3 row-4 row-5 row-6 FUTURE NOW
  55. 55. On ‘enterprise-architecture’: a subset is not the whole: ‘enterprise-wide IT-architecture’ is only one small subset of ‘the architecture of the enterprise’ - don’t mix them up!
  56. 56. Beware of ‘anything-centrism’! IT-centrism is a serious problem in enterprise-architecture – but so is business-centrism and the like The problem is not in IT itself, but in any over-focus on a single arbitrary domain
  57. 57. Beware of frameworks and methods that cannot link subsets of architecture together! Frameworks that cannot link together will cause the architecture to fragment and fail
  58. 58. Many current architecture- frameworks are ‘something- centric’ - they embed arbitrary hard-wired constraints on content, scope and scale…
  59. 59. …but there is no reason why this has to be so – we can instead restructure the framework to be consistent for any content, scope and scale
  60. 60. Beware of IT-centrism, business- centrism, all forms of ‘-centrism’ - all of them will cause the architecture to fragment and fail
  61. 61. How to avoid Fail #3: Placing arbitrary constraints on content, scope and/or scale
  62. 62. Subsets are part of a larger whole Most times we’ll only be working on a subset, but we need to ensure that it’s always connected to the whole Ensure that the whole is always maintained as the whole
  63. 63. Subsets are part of a larger whole Build and maintain ‘hooks’ that can connect each aspect of change to the broader whole Do this for every stage throughout the realisation-stack
  64. 64. Subsets are part of a larger whole Specialism in frameworks is often useful, but we must ensure that they ‘play nice’ with all other specialisms Take active steps to guard against any and all forms of ‘anything-centrism’
  65. 65. Subsets are part of a larger whole Wherever practicable, use tools and frameworks that are self-adapting to the needs of each context Specialism in our frameworks needs to be optional, not hard-wired!
  66. 66. Wrapping up...
  67. 67. Fail #1: Blurring between distinct roles of architecture and design
  68. 68. How to avoid Fail #1: - Be clear about the differences between architecture and design - Know which to use at each moment - Know which layer you’re working on at each moment
  69. 69. Fail #2: Starting architecture too late and/or finishing too early
  70. 70. How to avoid Fail #2: - Ensure that the whole realisation- stack is fully covered - If your architecture covers only part, establish hooks to connect to the rest - Include run-time and decommission in the overall architecture
  71. 71. Fail #3: Placing arbitrary constraints on content, scope and/or scale
  72. 72. How to avoid Fail #3: - Always start from the needs of the context – not hardwired assumptions! - Always connect across the whole - Always beware of potential risks from any form of ‘anything-centrism’
  73. 73. A final note: Our real aim here is to improve effectiveness across the whole: “Things work better when they work together, on-purpose” http://weblog.tetradian.com/tagline-for-enterprise-effectiveness/
  74. 74. Why do architecture? Because life is better for everyone when things work better, things work together, things work more on-purpose, as a more effective, unified whole.
  75. 75. Thank you! tetradian.com

×