Enterprise-architecture on purpose

4,811 views

Published on

Using enterprise-architecture to resolve executive-level business-problems [presentation at TOGAF conference, Rome, 26 April 2010]

Published in: Business
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,811
On SlideShare
0
From Embeds
0
Number of Embeds
165
Actions
Shares
0
Downloads
458
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide
  • Tetradian Consulting Unit 215, Communications House, 9 St Johns Street, Colchester, Essex CO2 7NN, England www.tetradian.com / info@tetradian.com / Twitter: @tetradian © Tom Graves / Tetradian 2010
  • TOGAF 9 tells us that there are four ‘architectures’: business architecture, data architecture, applications architecture and technology architecture. To be blunt, TOGAF’s ‘Business Architecture’ is not a proper business-architecture at all. In essence it’s a random grab-bag for ‘everything not-IT that might impact on IT’, which means that one Phase has to cover perhaps 97% of the enterprise, with high-level strategy all jumbled up with low-level process and everything in between. No wonder that IT’s relations with the rest of the business tend to be so fraught. Before we can use TOGAF for real enterprise architecture, we’ll need to tease out that tangle into a proper order.
  • This image gives us a better idea of the real scope we need in enterprise architecture. It also shows us why IT-centric architecture can be such a problem: it only covers a small part of what’s really needed, but pretends that it’s everything. IT doesn’t even cover the whole of information, because there’s also all the people-based ‘tacit’ information, for example, which is central to knowledge-management. So we need the architecture to be able to cover the whole enterprise – not just the IT.
  • This gives us a Zachman-like grid: a big-picture view which is mostly about business-purpose; and below it, a more explicit focus on people, information and/or physical ‘things’. These we need to split between a ‘logical’ view, which deals with common themes across all implementations; and a ‘physical’ view, which deals with the specific needs of each implementation. So to do a cross-enterprise optimisation of architecture, or to tackle the architectural issues of top-down strategy, we’ll need three distinct architectural assessments: big-picture, the common connections, and the design detail. This also aligns well with service-oriented architecture, especially if we extend the concept of ‘services’ across the whole enterprise.
  • One key here is the TOGAF Maturity Model, tucked away in Chapter 51 of the specification. It tells us what our architecture should look like at each of its five maturity-levels. But in practice we need to know what to do between those levels. These ‘stepping-stones’ tell us what we can and should do at each stage, to extend the maturity and capability of the architecture. They also build up a palette of capabilities, to tackle an increasing range of architectural concerns: overview first, then ‘horizontal’ clean-up, ‘top-down’ strategy, ‘bottom-up’ real-world impact and innovation, and finally able to use all of these in combination to ‘spiral-out’ from a chosen starting-point. This creates the ability to tackle the real business need: resolve the ‘pain-points’ and ‘wicked-problems’ embedded deep in the enterprise. That’s where we prove the real value of enterprise architecture.
  • But look at where the ADM actually sits, in terms of TOGAF’s own maturity-model. According to the spec, the main focus of a first ADM iteration is to clean up the IT space, defining a set of reference-models and the changes needed to get there. Subsequent ADM iterations provide blueprints for top-down strategic change. As can be seen, this is Step 2 and Step 3 – and again, for IT only. It doesn’t really tackle Step 1: that’s sort-of addressed in the Preliminary Phase, Phase A and Phase B, but not enough to satisfy most business-folks – hence endless problems about business-IT alignment. And it doesn’t deal with much if any of the Step 4 bottom-up issues. Which means we never get to Step 5 – which is where business will have always wanted us to be, right from the start.
  • But look at where the ADM actually sits, in terms of TOGAF’s own maturity-model. According to the spec, the main focus of a first ADM iteration is to clean up the IT space, defining a set of reference-models and the changes needed to get there. Subsequent ADM iterations provide blueprints for top-down strategic change. As can be seen, this is Step 2 and Step 3 – and again, for IT only. It doesn’t really tackle Step 1: that’s sort-of addressed in the Preliminary Phase, Phase A and Phase B, but not enough to satisfy most business-folks – hence endless problems about business-IT alignment. And it doesn’t deal with much if any of the Step 4 bottom-up issues. Which means we never get to Step 5 – which is where business will have always wanted us to be, right from the start.
  • But look at where the ADM actually sits, in terms of TOGAF’s own maturity-model. According to the spec, the main focus of a first ADM iteration is to clean up the IT space, defining a set of reference-models and the changes needed to get there. Subsequent ADM iterations provide blueprints for top-down strategic change. As can be seen, this is Step 2 and Step 3 – and again, for IT only. It doesn’t really tackle Step 1: that’s sort-of addressed in the Preliminary Phase, Phase A and Phase B, but not enough to satisfy most business-folks – hence endless problems about business-IT alignment. And it doesn’t deal with much if any of the Step 4 bottom-up issues. Which means we never get to Step 5 – which is where business will have always wanted us to be, right from the start.
  • But look at where the ADM actually sits, in terms of TOGAF’s own maturity-model. According to the spec, the main focus of a first ADM iteration is to clean up the IT space, defining a set of reference-models and the changes needed to get there. Subsequent ADM iterations provide blueprints for top-down strategic change. As can be seen, this is Step 2 and Step 3 – and again, for IT only. It doesn’t really tackle Step 1: that’s sort-of addressed in the Preliminary Phase, Phase A and Phase B, but not enough to satisfy most business-folks – hence endless problems about business-IT alignment. And it doesn’t deal with much if any of the Step 4 bottom-up issues. Which means we never get to Step 5 – which is where business will have always wanted us to be, right from the start.
  • But look at where the ADM actually sits, in terms of TOGAF’s own maturity-model. According to the spec, the main focus of a first ADM iteration is to clean up the IT space, defining a set of reference-models and the changes needed to get there. Subsequent ADM iterations provide blueprints for top-down strategic change. As can be seen, this is Step 2 and Step 3 – and again, for IT only. It doesn’t really tackle Step 1: that’s sort-of addressed in the Preliminary Phase, Phase A and Phase B, but not enough to satisfy most business-folks – hence endless problems about business-IT alignment. And it doesn’t deal with much if any of the Step 4 bottom-up issues. Which means we never get to Step 5 – which is where business will have always wanted us to be, right from the start.
  • Enterprise-architecture on purpose

    1. 1. Enterprise-architecture on purpose Tom Graves , Tetradian Consulting TOGAF Rome, April 2010 info@tetradian.com / www.tetradian.com
    2. 2. Architecture’s ‘one idea’ 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Architecture’s ‘one idea’: Things work better when they work together with clarity with elegance on purpose
    3. 3. What keeps architects awake at night? 28 Apr 2010 (c) Tom Graves / Tetradian 2010 What keeps IT-architects awake at night?
    4. 4. Enterprise architecture can help 28 Apr 2010 (c) Tom Graves / Tetradian 2010 bandwidth security cloud business-IT alignment single point of truth enterprise 2.0 disaster-recover planning system optimisation server failover applications integration Enterprise architecture can help with all of these concerns
    5. 5. What keeps executives awake at night? 28 Apr 2010 (c) Tom Graves / Tetradian 2010 But what about beyond IT? What keeps executives awake at night?
    6. 6. Executive #1: PR disasters 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Executive #1: “ Will we be hit with another PR disaster tomorrow morning?”
    7. 7. Executive #2: loss of market respect 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Executive #2: “ We’ve become the least-respected firm in our industry - what can we do about it?” - how do we get our market back?”
    8. 8. Enterprise architecture can help here too 28 Apr 2010 (c) Tom Graves / Tetradian 2010 How do we use enterprise architecture to help with those urgent business concerns?
    9. 9. Answer: architecture of the enterprise 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Answer: Extend enterprise-architecture to the whole enterprise
    10. 10. Whole-of-enterprise architecture 28 Apr 2010 (c) Tom Graves / Tetradian 2010 <ul><li>Each EA generation has had to extend the scope: </li></ul><ul><li>‘ Classic’ EA starts with IT infrastructure </li></ul><ul><li>IT tech-architecture depends on applications </li></ul><ul><li>Applications-architecture depends on data </li></ul><ul><li>Data-architecture depends on business-info need </li></ul><ul><li>Information-architecture depends on business </li></ul><ul><li>Business-architecture depends on enterprise </li></ul><ul><li>Enterprise-architecture defines the context </li></ul><ul><li>Enterprise-architecture needs whole-of-enterprise scope </li></ul>
    11. 11. Define ‘enterprise’ 28 Apr 2010 (c) Tom Graves / Tetradian 2010 [An enterprise is] an organisation or cross-functional entity supporting a defined business scope and mission. An enterprise includes interdependent resources – people, organisations and technology – who must coordinate their functions and share information in support of a common mission or set of related missions. FEAF definition
    12. 12. Current ‘enterprise’-architecture 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Current ‘enterprise’-architecture?
    13. 13. An unfortunate kludge... <ul><li>Classic scope of IT-based ‘enterprise architecture’ </li></ul>28 Apr 2010 (c) Tom Graves / Tetradian 2010 28 Apr 2010 IT (~3% of enterprise) Everything not-IT ? (~97% of enterprise)
    14. 14. Scope of IT in enterprise context <ul><li>Whole-of-enterprise scope </li></ul>28 Apr 2010 (c) Tom Graves / Tetradian 2010 28 Apr 2010 IT is only a small subset (not even all of Information) <ul><ul><li>three layers: Business, Integration (Common), Detail </li></ul></ul><ul><ul><li>three columns: People, Information, physical ‘Things’ </li></ul></ul>
    15. 15. Scope of enterprise architecture <ul><li>Big-picture: vision, strategy, overview, ‘business of business’ </li></ul><ul><li>Common: interfaces etc common to all implementations </li></ul><ul><li>Detail: implementation-specific, context-specific </li></ul><ul><li>Aligns well with service-oriented architecture for the whole enterprise </li></ul>28 Apr 2010 (c) Tom Graves / Tetradian 2010 28 Apr 2010 B ig-picture / Business Zachman rows 0-2 C ommon / Connection Zachman rows 2-3 D esign / Detail Zachman rows 4-6 [People] [Things] [Information]
    16. 16. Business architecture vs enterprise architecture [1] 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Business -architecture is the architecture of business Enterprise -architecture is the architecture of the enterprise ( not solely the architecture of the enterprise-IT!)
    17. 17. Business architecture vs enterprise architecture [2] 28 Apr 2010 (c) Tom Graves / Tetradian 2010 We define an enterprise-architecture for an organisation about an enterprise
    18. 18. Business architecture vs enterprise architecture [3] 28 Apr 2010 (c) Tom Graves / Tetradian 2010 An organisation is bounded by rules and responsibilities An enterprise is bounded by values and commitments
    19. 19. Business architecture (Business Model Canvas) 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Business architecture example Business Model Canvas ( http://businessmodelgeneration.com ) Customer Relationships Key Partners Key Activities Value Proposition Customer Segments Key Resources Channels Revenue Streams Cost Structure
    20. 20. The organisation and the business 28 Apr 2010 (c) Tom Graves / Tetradian 2010 The organisation and the business
    21. 21. Value-proposition is the centre 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Value-proposition is the centre We need value-propositions for every stakeholder-group
    22. 22. Who is the architecture for? 28 Apr 2010 (c) Tom Graves / Tetradian 2010 We define an enterprise-architecture for an organisation about an enterprise
    23. 23. People – the nature of enterprise Structure of the enterprise 28 Apr 2010 (c) Tom Graves / Tetradian 2009 Stakeholders in the broader ecosystem (includes non-clients, anti-clients, government, general community) (enterprise is bounded by shared commitment to the vision ) Prospects Clients Organization (bounded by rules) (boundaries may be partly porous) Partners ( must share same vision) may also be clients or prospects Service Providers (must acknowledge and align to vision) may also be clients or prospects
    24. 24. So how does this help our executives? 28 Apr 2010 (c) Tom Graves / Tetradian 2010 So how does this help our executives?
    25. 25. Executive #1: PR disasters 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Executive #1: Real (if unofficial) business metric: Number of days between bad headlines in the newspaper
    26. 26. Executive #1: PR disasters 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Real newspaper headline: Agency fails again! Ten Category-1 * incidents in just one suburb still not resolved in two months! *Category-1: threat to life: must be resolved within 24 hours
    27. 27. Executive #1: PR disasters 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Result of (very urgent!) review: Agency had resolved incident, in less than one hour but Records could not show this, because of weak application/data architecture
    28. 28. What actually happened? 28 Apr 2010 (c) Tom Graves / Tetradian 2010 What actually happened? Incident-status (resolved/not-resolved) is attached to reports
    29. 29. What actually happened? 28 Apr 2010 (c) Tom Graves / Tetradian 2010 What actually happened? Reports can only be cleared when attached to incident-record
    30. 30. What actually happened? 28 Apr 2010 (c) Tom Graves / Tetradian 2010 What actually happened? Incident was threat to a pregnant woman and unborn child Child not yet born = no date-of-birth
    31. 31. What actually happened? 28 Apr 2010 (c) Tom Graves / Tetradian 2010 What actually happened? No date-of-birth = can’t auto-create record No manual override = can’t clear reports until child is born
    32. 32. Executive #1: PR disasters 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Architecture moral of this story: Every automated system needs an option for manual override
    33. 33. Executive #2: Trust-disasters 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Executive #2: Reclaim trust (for a bank)
    34. 34. Executive #2: Trust-disasters 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Executive #2: Direct source of lost trust “ The only metric that matters is shareholder-value” (an ‘undiscussable’ policy-directive)
    35. 35. Executive #2: Trust-disasters 28 Apr 2010 (c) Tom Graves / Tetradian 2010 (to tackle this one, we’ll need to look at the structure of enterprise-architecture itself)
    36. 36. The TOGAF maturity-model 28 Apr 2010 (c) Tom Graves / Tetradian 2010 28 Apr 2010
    37. 37. Executives and enterprise architecture 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Executives want to know about “ What business are we in?” (EA stage #1) and Resolving ‘pain-points’ (EA stage #5) (everything else is just detail...)
    38. 38. The structure of enterprise-architecture 28 Apr 2010 (c) Tom Graves / Tetradian 2010 but current ‘enterprise-architecture’ doesn’t serve either of those needs well
    39. 39. TOGAF scope in maturity-model 28 Apr 2010 (c) Tom Graves / Tetradian 2010 28 Apr 2010 TOGAF 8 (IT-architecture only) TOGAF 9 (mostly IT-architecture) TOGAF calls this ‘business-architecture’ (but doesn’t explain how to do it...)
    40. 40. The structure of enterprise-architecture 28 Apr 2010 (c) Tom Graves / Tetradian 2010 For this executive’s trust-problem we need to work on EA step #1: “ Know your business”
    41. 41. Business architecture vs enterprise architecture [2] 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Quick reprise on organisation versus enterprise: We define an enterprise-architecture for an organisation about an enterprise An organisation is bounded by rules and responsibilities An enterprise is bounded by values and commitments
    42. 42. EA step #1: ‘Know your business’ 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Two key themes for ‘Know your business’: ‘ Get everyone on the same page’ (functional business model) and Relationships between organisation and enterprise (vision, role, mission, goal)
    43. 43. Functional business model 28 Apr 2010 (c) Tom Graves / Tetradian 2010 A Functional Business Model helps to bring everyone ‘ on the same page’ to increase trust, respect and communication within the organisation in this case, we created a two-tier function-model to enhance communication at executive/senior-management level
    44. 44. Functional business model (tier-1) 28 Apr 2010 (c) Tom Graves / Tetradian 2010 28 Apr 2010 Gets everyone on the same page
    45. 45. Bank functional model (tier-1) 28 Apr 2010 (c) Tom Graves / Tetradian 2010 28 Apr 2010 Gets everyone on the same page (literally – we put the workshop participants’ photos on it)
    46. 46. Functional model (example tier-2) 28 Apr 2010 (c) Tom Graves / Tetradian 2010 28 Apr 2010 (this is for a different organisation, but it illustrates the same principles of layering)
    47. 47. Enterprise vision 28 Apr 2010 (c) Tom Graves / Tetradian 2010 The vision is a common theme that links everyone in the extended-enterprise to increase trust, respect and communication beyond the organisation in this case, we worked with the team to create a preliminary vision for the bank in relation to its enterprise
    48. 48. The bank and its extended-enterprise Structure of the bank’s enterprise 28 Apr 2010 (c) Tom Graves / Tetradian 2009
    49. 49. Vision as a link to enterprise 28 Apr 2010 (c) Tom Graves / Tetradian 2010 28 Apr 2010 <ul><li>Ends : the results we wish to achieve </li></ul><ul><li>Means : the methods and activities by which we will achieve those Ends </li></ul><ul><li>Vision and Goal are Ends </li></ul><ul><li>Mission and day-to-day activities are Means </li></ul><ul><li>Role is the chosen bridge between Ends and Means </li></ul><ul><li>Organisational roles bridge activity and Goal, or Goal and Mission </li></ul>Means Goal Mission Role Vision activity Ends
    50. 50. Vision: “better financial futures” 28 Apr 2010 (c) Tom Graves / Tetradian 2010 <ul><li>Would make sense to every enterprise stakeholder: </li></ul><ul><li>Credit-clients want better financial futures for self and/or family </li></ul><ul><li>Business-clients want better financial futures for their business </li></ul><ul><li>Government wants better financial futures for all </li></ul><ul><li>Even the anti-clients would agree on this </li></ul><ul><li>and </li></ul><ul><li>The bank wants better financial futures for itself </li></ul><ul><li>The vision defines the enterprise – a stable anchor </li></ul>
    51. 51. Executive #2: resolving the trust-problem 28 Apr 2010 (c) Tom Graves / Tetradian 2010 This vision-phrase “ better financial futures” was used as the key reference-anchor for subsequent work on organizational-development, market-development community-relations and internal architectures
    52. 52. Architecture’s ‘one idea’ 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Architecture’s ‘one idea’: Things work better when they work together with clarity with elegance on purpose
    53. 53. Some suggested resources <ul><li>Books by Tom Graves ( www.tetradianbooks.com ) : </li></ul><ul><li>Real Enterprise Architecture : beyond IT to the whole enterprise </li></ul><ul><li>Bridging the Silos : enterprise architecture for IT-architects </li></ul><ul><li>The Service Oriented Enterprise : enterprise architecture and viable systems </li></ul><ul><li>Doing Enterprise Architecture : process and practice in the real enterprise </li></ul><ul><li>Enterprise Architecture in Real-Time : strategy, sensemaking and solutions </li></ul><ul><li>SEMPER and SCORE : enhancing enterprise effectiveness </li></ul><ul><li>Power and Response-ability : the human side of systems </li></ul><ul><li>Books by other authors: </li></ul><ul><li>Lost in Translation (Nigel Green et al) ( www.LIThandbook.com ) </li></ul><ul><ul><li>introduces ‘VPEC-T’ – a path to improved communication between business and IT </li></ul></ul><ul><li>Enterprise Architecture as Strategy (Ross, Weill et al) </li></ul><ul><ul><li>describes business-oriented role for enterprise architecture </li></ul></ul><ul><li>Business Model Generation (Osterwalder et al) ( www.businessmodelgeneration.com ) </li></ul><ul><ul><li>describes systematic TOGAF-compatible process to model business drivers etc </li></ul></ul>28 Apr 2010 (c) Tom Graves / Tetradian 2010 28 Apr 2010 (c) Tom Graves / Tetradian 2009

    ×