Enterprise-architecture on purpose
•Télécharger en tant que PPT, PDF•
13 j'aime•3,142 vues
Using enterprise-architecture to resolve executive-level business-problems [presentation at TOGAF conference, Rome, 26 April 2010]
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Enterprise-architecture on purpose
Similaire à Enterprise-architecture on purpose (20)
Plus de Tetradian Consulting
Plus de Tetradian Consulting (20)
Dernier
Dernier (20)
Enterprise-architecture on purpose
- 1. Enterprise-architecture on purpose Tom Graves , Tetradian Consulting TOGAF Rome, April 2010 info@tetradian.com / www.tetradian.com
- 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. What keeps architects awake at night? 28 Apr 2010 (c) Tom Graves / Tetradian 2010 What keeps IT-architects awake at night?
- 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. 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. 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. 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. 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. Answer: architecture of the enterprise 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Answer: Extend enterprise-architecture to the whole enterprise
- 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. Current ‘enterprise’-architecture 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Current ‘enterprise’-architecture?
- 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. 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. 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. 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. The organisation and the business 28 Apr 2010 (c) Tom Graves / Tetradian 2010 The organisation and the business
- 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. 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. 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. So how does this help our executives? 28 Apr 2010 (c) Tom Graves / Tetradian 2010 So how does this help our executives?
- 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. 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. 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. What actually happened? 28 Apr 2010 (c) Tom Graves / Tetradian 2010 What actually happened? Incident-status (resolved/not-resolved) is attached to reports
- 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. 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. 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. 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. Executive #2: Trust-disasters 28 Apr 2010 (c) Tom Graves / Tetradian 2010 Executive #2: Reclaim trust (for a bank)
- 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. 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. The TOGAF maturity-model 28 Apr 2010 (c) Tom Graves / Tetradian 2010 28 Apr 2010
- 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. 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. 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. 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. 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. 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. 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. Functional business model (tier-1) 28 Apr 2010 (c) Tom Graves / Tetradian 2010 28 Apr 2010 Gets everyone on the same page
- 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. 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. 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. The bank and its extended-enterprise Structure of the bank’s enterprise 28 Apr 2010 (c) Tom Graves / Tetradian 2009
- 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. 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
Notes de l'éditeur
- 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.