Stepping-stones of enterprise-architecture: Process and practice in the real enterprise
•Download as PPT, PDF•
38 likes•9,867 views
The document discusses adapting the TOGAF enterprise architecture framework to have whole-enterprise scope rather than just focusing on IT. It proposes a stepped maturity model with 7 "stepping stones" to gradually expand the architecture's coverage. Each step builds on the previous to ultimately integrate all of an organization's business, people, information, and physical assets. The steps are described as preparing foundations, building an enterprise overview, rationalizing existing systems, guiding strategic change, designing for real-world constraints, and pulling everything together into a service-oriented enterprise.
![Doing enterprise-architecture ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (9)
Similar to Stepping-stones of enterprise-architecture: Process and practice in the real enterprise
Similar to Stepping-stones of enterprise-architecture: Process and practice in the real enterprise (20)
More from Tetradian Consulting
More from Tetradian Consulting (20)
Recently uploaded
Recently uploaded (20)
Stepping-stones of enterprise-architecture: Process and practice in the real enterprise
- 1. Stepping-stones of enterprise-architecture Process and practice in the real enterprise Tom Graves , Tetradian Consulting TOGAF London, April 2009 info@tetradian.com / www.tetradian.com
- 3. Use the TOGAF maturity-model
- 13. Base-framework segments Needs dimension of ‘segments’ within columns
- 15. Methods – governance for Agile EA Statement of Architecture Work (for iteration) Stakeholder review for ‘as-is’ Stakeholder review for ‘to-be’ Gap-analysis / requirements review Solution design review Project plan review Project architecture compliance review Benefits realisation (‘lessons learned’ etc) Architecture Charter Governance-artefacts define methodology’s phase-boundaries
Editor's Notes
- Tetradian Consulting Unit 215, Communications House 9 St Johns Street Colchester Essex CO2 7NN England www.tetradian.com [email_address] Twitter: @tetradian © Tom Graves / Tetradian 2009
- A simple question: what do we do when we’re doing enterprise architecture? What issues do we tackle, in what sequence, for what business reasons, for what business value? And how do we get results fast ? Those are real concerns – especially in the present business climate. But whilst the TOGAF ADM tells us what to do within an architecture cycle, it doesn’t tell us where to start. To help with that, we turn to a less-well-known part of TOGAF: the Maturity Model.
- It’s tucked away at the back of the document, in Chapter 51. For each of its five maturity-levels, it tells us what our architecture should look like at that level. But in practice what’s more of interest is the steps between those levels – because they tell us what we can and should do at each stage, to extend the maturity and capability of the architecture. These then are the stepping-stones of architecture .
- There are five levels in the TOGAF model, hence seven ‘stones’ – the foundations below, the five levels, and a plateau of continual improvement above. These seven steps summarise the kinds of work that our architecture-group has done in a variety of organisations and industries in Australia and elsewhere. To be honest, there’s a lot more to enterprise architecture than TOGAF itself can show us. But with a bit of help we can use TOGAF’s general tools and models all the way through.
- First, we build the foundations. In our own work, we categorise these under five distinct headings: - purpose, and overall strategy; - people, and the governance concerns; - planning, and the role and choice of frameworks; - practice, and the methods to use for architecture development - performance-metrics for business-value, and the artefacts we will produce within the work
- Looking at strategy, the main role of enterprise architecture is as a body of knowledge on enterprise structure and purpose - in the broadest sense of those terms. It’s about decision-support for others, particularly strategy and the PMO. It’s not about trying to take control of the business - so the business-folk don’t need to panic! But we must break away from TOGAF on one crucial point. TOGAF’s ‘enterprise architecture’ is essentially about IT, yet IT itself is only one tiny part of the business – barely 2%-3% in British Airways’ case, for example. Right from the start, enterprise architecture has to be about the whole of the enterprise – not just its IT.
- The reason for this is that everything connects with everything else. Look at enterprise-architecture’s own history: we may have started with technology-infrastructure, but the trails of dependencies mean that eventually we must end up connecting across the whole of the enterprise. Enterprise IT-architecture is the architecture of the enterprise IT alone. But enterprise architecture is the architecture of the enterprise – of everything in the enterprise. We don’t have to leap to that level straight away: but we must accept, right from the start, that that’s the full scope we’ll need by the end.
- So where do TOGAF’s classic ‘four architectures’ come into this? Business architecture, data architecture, applications architecture and technology architecture? They do matter, of course, and matter a lot. But complex as it is, IT is only a small part of the enterprise cost-base and complexity. What TOGAF blithely calls ‘business architecture’ may well be thirty times the size of all of the IT put together: so TOGAF’s views on architecture are a bit out of balance, to say the least. To be blunt, TOGAF’s ‘business architecture’ is little more than a random grab-bag for ‘everything not-IT’, with high-level strategy all jumbled up with low-level process and everything in between. If we’re going to use TOGAF for real enterprise architecture, we’ll need to disentangle that mess as we go along here.
- 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 the architecture strategy we’ve used in all our work is that we aim to cover the whole enterprise – not just the IT. More on how to do this in a moment, when we look at frameworks. First we need to deal with some of the ‘people-stuff’.
- Most of the governance issues are well-described in the TOGAF document. We need to do some translation to break out of its IT-centrism, but that’s about all. A key governance point is that ‘the whole enterprise’ is far too large for a classic-TOGAF ‘big cycle’. To make it work, we’ll have to split it into smaller Agile-style iterations. And to bridge across all of the silos, we’ll need high-level support, usually right up to the CEO. We may not need it right from Day One, but we’d better plan for it right from the start.
- In planning, we need some kind of framework to tell us what everything means . Again, TOGAF does help in this, with its ‘Enterprise Continuum’ and the like – though unfortunately the new Architecture Metamodel is all but useless for this kind of work. A reference-architecture is a set of rules and guidelines that specify the ‘bindedness’ of each component in the structure. Behind this, we need some kind of base-ontology to define categories of meaning and function. In our own work we use for this an extended version of Zachman.
- Zachman’s framework is the architecture equivalent of chemistry’s Periodic Table of Elements. Zachman’s point is that the elements or ‘primitives’ exist within a cell, composites straddle across cells: “Primitives guide architecture; composites guide solutions”. We need primitives which cover the full enterprise scope. The original Zachman layers work well enough for this, though we also add one layer above, to align with ISO-9000 and the like. But Zachman’s columns don’t work so well, especially outside of IT. So as you’ll see, we’ve restructured them somewhat, to align better with BPMN and other cross-enterprise needs. Composites are also patterns . A ‘complete’ composite crosses all columns, and must be complete at the ‘Operations’ layer (row-6). A useful cue is that a composite is usable to the extent that it is complete; but it’s re-usable, as a pattern, to the extent that it is not complete.
- More important is that Zachman is missing an entire dimension, which we’ve labelled ‘segments’: physical ‘things’ such as servers, physical locations, events virtual data, virtual locations, signals and message-events relational links to people, social-network locations, sales-lifecycle events aspirational keys such as brand, morale, reputation and the enterprise itself and abstracts such as time and money These distinctions often aren’t critical in the upper framework layers, but they matter more and more as we move down towards the real world. This provides the base-skeleton for a ‘holograph’ of the enterprise, to which we add more detail and depth with each architecture iteration.
- The TOGAF ADM is our obvious choice for an architecture method. One difference is that we’ll need to use it in an iterative Agile style. In theory, TOGAF 9 does now provide better support for iterations, but to be blunt it doesn’t work in practice: we’ll need to amend that. And its fixed IT-centric scope is a serious problem. The current Phases B, C and D are architecture-iterations in their own right, each with their own as-is, to-be and gap-analysis. Instead, we generalise from TOGAF’s ‘four architectures’. We set an appropriate iteration-scope in Phase A, then do the as-is in Phase B, the to-be in Phase C, and the gap-analysis in Phase D. That then works for any architecture, of any scope, at any scale.
- It also sorts out a governance-problem in that TOGAF 9’s architecture cycle demands a near-infinity of stakeholder-reviews. In this split, the reviews occur only at phase-boundaries – in fact they are the phase-boundaries. This cycle is recursive, so it can be used at any timescale. The classic TOGAF cycle takes a couple of years, but at AusPost our some of cycles were no more than a couple of hours. It’s simpler than the existing ADM; it fits well with an iterative approach; and also fits well with ‘product’-based governance such as in ITIL and PRINCE2.
- The other key point is that we link every architecture-cycle to explicit business-value. We don’t start any work until we’ve identified how we’ll measure that. The visible outcomes of the work include all the models and documents. Less visible, but perhaps even more important, is communication with stakeholders. Ultimately, the architecture is the dialogue about the idea of integration across the enterprise. Once we’ve defined all of that, we’ve reached Level Zero : we’re ready to go.
- The very first part of architecture is to establish what business we’re in. This may sound obvious, but it’s rarely done in conventional IT-architecture - and we need it as the anchor for all subsequent architecture-compliance. This is typically done as a short-term project, and often by outside consultants – almost the only time, in fact, when outsiders can define the architecture of the enterprise.
- Identifying and modelling all of this provides the initial content for our ‘holograph’ of the enterprise, using that Zachman-like framework: - the topmost layers of vision, values, principles and core business-drivers - key assets, functions, locations, capabilities, events and decisions – the framework columns; and - the balance between framework segments – for example, how central is information here, compared to things, to people-relationships, to brands and so on? Much of this is what TOGAF would call ‘business architecture’. But note that we only set up the full architecture capability – TOGAF’s Preliminary Phase – at the end of this work, when we’ve established our ‘business-cred’.
- One essential artefact for ‘business-cred’ is the function-model, or business-service model. It’s a way to summarise the whole of the enterprise on a single page. It’s typically created in three or four tiers. The first tier is literally a summary. It’s useful, but it doesn’t tell us much that we don’t already know.
- But when we split each of those ‘business services’ into its next-tier functions, we start to get a better idea of what really goes on in the organisation. It’s also clear that this is about the whole enterprise – not just its IT. That helps to allay a lot of business-folks’ fears about enterprise-architecture.
- And by the time we get to tier-3, we have something that’s of direct, practical use to the business. Almost all of the managers at AusPost printed out their own large-sheet copies of this to pin on the wall, often covered with personal annotations and PostIt tags. (For confidentiality, by the way, I’ve changed the detail here, to look like a plastics factory. The point is that the same principles apply to every enterprise.) This gave us the credibility to get architecture established as an ongoing capability rather than solely as a short-term project. At this point, we’ve have reached Level 1. Ad-hoc projects can now make sense in relation to the architecture.
- Here we step into classic TOGAF territory – ‘horizontal’ optimisation of systems, cleaning up the mess in the IT context, and in end-to-end processes and elsewhere. And it wil l be a mess, too - don’t be under any illusions about that. There’ll be a jumble of undocumented point-solutions, legacy-systems that can’t talk to each other, people running ragged with all the fire-fighting… But you’re not alone in this. Everyone ’s systems are in this kind of mess when they start architecture. That clean-up must be done first, though - otherwise adding anything new will only make the mess worse.
- Again, don’t be under any illusions about timescale. There’s no getting round the reality that, in any reasonable-sized organisation, this is going to take at least a couple of years overall. But the key – as we did at AusPost – is to start off by splitting up the work into distinct ‘Business Systems’, each with their own information-systems and ‘single source of truth’. If you then clean up one Business System at a time, each iteration is much shorter – often a month or two at most. And the return on investment is much quicker too – which again is crucial for maintaining business-credibility.
- And it’s in the clean-up that that amendment to the ADM starts to show its value. In this case, the scope for each iteration is defined by the boundaries of the respective Business System, which we identified and modelled in the previous step. The principles for this assessment-work are well described in the TOGAF 9 document for each of their ‘architectures’. If you generalise from those principles, and apply them to the Business System scope rather than to a predefined IT-specific ‘architecture’, you’ll see that it fits into this sequence here. Note that architecture governance-rules apply most here – as opposed to change -governance rules, which take priority in the following phases.
- The solution-design, project-plan and develop/deploy phases are all much the same as in TOGAF. Which they should be, because most of this is under change-governance, not architecture-governance. Architecture is just the ‘client’ here. ‘ Lessons-learned’ here may differ slightly different from the TOGAF description – because the scope is determined by the Business System, not solely by IT – but otherwise the principles are much the same. Exactly as in TOGAF, the results feed into requirements for new architecture iterations.
- And once we’ve done the rationalisation – or even just its assessment and solution-design phases - we have a complete portion of an architecture ready to use as a reference-model for compliance. Having cleaned-up in that area, we now need to ensure that new projects don’t mess it up all over again. Guiding change was a central part of our earlier work at AusPost. To avoid the dreaded role of ‘architecture police’, the trick was to get in early, at the first idea-stages for each project. Getting architecture included into the regular PMO processes as described here was a major milestone for architecture acceptance. Making architecture repeatable brought us to Level 2 in the Maturity Model.
- One of the key aims of TOGAF 9 is to drive the architecture from strategy – though note that even in TOGAF we don’t get there till the second and subsequent cycles. The difference here is that we can start building that support as soon as we’ve done the first Business System – a matter of months, not years. The key emphasis here is top-down assessment and integration.
- The main focus is ‘this goes with that’ – identifying top-down trails of dependencies and impacts from change and innovation. The TOGAF 9 document mentions two themes that can help here: service-oriented architecture, and security-architecture. But again we need to generalise these somewhat, away from TOGAF’s IT-centric assumptions. Service-orientation at an abstract business level, for example, helps us understand the trade-offs between different technologies, and allows us to identify what’s common between different implementations. That’s important in business-continuity planning, as we’ll see later. And security is only one of many qualitative ‘pervasive services’ for which we need to build support throughout the architecture. When we’ve finished all this, we have an overall architecture defined from top to bottom – in other words, Level 3 .
- In the next step we switch the emphasis the other way round – bottom-up rather than top-down. This allows us to tackle the architecture of key operations-level concerns such as load-balancing and business-continuity planning. It also provides a way to link to operations-level process-management and quality-management. That was a key part of my own work at AusPost.
- Here we’ll model issues such as service-escalation, and switching between service-implementations for disaster-recovery. This builds on the previous step’s work on abstract-services and service trade-offs. For disaster-recovery we need to look closely at ‘safe-fail’ fallback – most of which only makes sense if we can connect the bottom-up view to the previous top-down dependency-trails. The same is true of quality-management: strategy sets the direction, but it does need to connect right down into the real-world practice. This way, the architecture links to other forms of management, and is itself consistently managed – so we’ve reached Level 4 .
- By this stage we can model in any direction: overview and focus, horizontal, top-down, bottom-up. We now link all these approaches together, to architecture the kind of themes that business really wants us to tackle: - the role of service in its broadest sense – and its links to business value - business ‘pain-points’ and other so-called ‘wicked-problems’ - enhancing overall effectiveness across the whole enterprise We’re a long way past TOGAF here, by the way. This is real enterprise architecture – not just IT-architecture.
- The crucial point is that this kind of work will only succeed if we include the human side of systems into the architecture. For example, service-oriented architecture at last makes sense when we extend it across the whole enterprise, and link it to some ‘old-fashioned’ yet essential notions about service and responsibility. Business-problems turn ‘wicked’ when technical complexity meets social complexity. It’s why BPR failed so badly, and why the current hype about cloud-computing will likely fail the same way. The blunt fact is that complex business-problems cannot be solved by IT alone. We’ve come across plenty of examples of that at AusPost and elsewhere. And ultimately it’s all about effectiveness: not just efficient, but ‘efficient on purpose’ and everything else. When we’ve addressed these issues appropriately, our architecture is optimised – and hence at Level 5 in that maturity model.
- But we don’t stop there just because we’ve reached some imaginary milestone. Architecture isn’t a project – it’s an ongoing capability, whose role is to support continual improvement and adaptation of the enterprise. And rather than us keep on changing it from outside, we need to bring the architecture to the point where the enterprise can adapt itself to its changing conditions and needs. To get there, we need to do something that will feel really scary: we must let go of both the command and the control of the architecture.
- The key understanding here is that whilst we’re responsible for the architecture, we don’t possess it. It belongs to the enterprise as a whole, in the same sense that a city-plan belongs to every citizen. One way to help this happen is to relinquish control by shifting to a ‘hands-off’ architecture. This is like the ‘building-regulations’ and ‘planning-permission’ in a city - and for the same reasons it only works when all of those support-structures are already in place. So don’t try this too early – and especially, not just as a cost-cutting exercise! In the same way, the architecture needs to be relevant to people’s business lives. To do that, we let go of command, and shift to dialogue about architecture, through conferences, communities-of-practice and other forms of committed communication. Ultimately, architecture is just an idea , that integration across the enterprise helps everyone. In that sense, the architecture is the dialogue here.
- So, to recap, conventional ‘enterprise architecture’ is mainly for IT-architecture in information-centric industries. To go beyond that, to a true ‘architecture of the enterprise’, TOGAF and the like will still work well if we tweak them a bit to expand their scope and versatility. The sheer scale of the enterprise-as-a-whole means that we must use an iterative, Agile approach – and this brings faster return-on-effort, too. And TOGAF’s maturity-model provides a structured ‘stepping-stones’ approach – overview and focus, horizontal, top-down, bottom-up, spiral-out - to develop architectures for any domain, any scope, at any scale, and in any type of industry.
- There’s more detail on all of this in the book – “Doing Enterprise Architecture” – but that’s all we have time for here. I hope this has helped for your own enterprise architecture, anyway. But in the meantime, any questions? Any answers, perhaps? And thank you.