TOGAF BEYOND IT
•Descargar como PPT, PDF•
12 recomendaciones•3,192 vistas
The document discusses extending the use of TOGAF (The Open Group Architecture Framework) beyond IT architecture to encompass enterprise architecture for the entire organization. It proposes two approaches: 1) Expanding the scope of TOGAF phases to focus on business, common, and detailed levels of the enterprise. 2) Extending TOGAF's capabilities by adapting phases for iterative assessment at any scope or complexity using time horizons, expanded Zachman framework, and agile principles. This allows TOGAF to address architecture for any part of the enterprise.
![The TOGAF ADM: an old friend... ,[object Object],[object Object],22 Oct 2009 (c) Tom Graves / Tetradian 2009 ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (17)
Similar a TOGAF BEYOND IT
Similar a TOGAF BEYOND IT (20)
Más de Tetradian Consulting
Más de Tetradian Consulting (20)
Último
Último (20)
TOGAF BEYOND IT
- 1. Using TOGAF beyond IT Tom Graves , Tetradian Consulting in association with White Knight Management TOGAF Hong Kong, October 2009 info@tetradian.com / www.tetradian.com 22 Oct 2009 (c) Tom Graves / Tetradian 2009
- 7. Part 1: Expand the scope 22 Oct 2009 (c) Tom Graves / Tetradian 2009
- 12. A richer architectural ‘stack’ 22 Oct 2009 (c) Tom Graves / Tetradian 2009 Adapted from S-EA-T (www.s-ea-t.com) free enterprise-architecture toolset Use extended scope to develop a more business-oriented view of the usual IT ‘stack’ of architectures Identify features common to all implementations – IT-based, manual, machine-based etc
- 13. Example: Business Operating Model 22 Oct 2009 (c) Tom Graves / Tetradian 2009 Screenshot from free S-EA-T toolset (www.s-ea-t.com)
- 15. Part 2: Extend the capability 22 Oct 2009 (c) Tom Graves / Tetradian 2009
- 17. Use the TOGAF maturity-model 22 Oct 2009 (c) Tom Graves / Tetradian 2009
- 18. TOGAF scope in maturity-model 22 Oct 2009 (c) Tom Graves / Tetradian 2009 Main emphasis of TOGAF, for IT-architecture only
- 23. Adapt Zachman to describe scope 22 Oct 2009 (c) Tom Graves / Tetradian 2009 Zachman rows work well enough as-is Zachman columns need significant rethink to break free of IT-centrism
- 25. Base-framework segments 22 Oct 2009 (c) Tom Graves / Tetradian 2009 Needs dimension of ‘segments’ within columns
- 26. Methods – governance for Agile EA 22 Oct 2009 (c) Tom Graves / Tetradian 2009 Statement of Architecture Work (for iteration) Stakeholder review for primary architecture Stakeholder review for comparison architecture 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
Notas del editor
- Tetradian Consulting Unit 215, Communications House, 9 St Johns Street, Colchester, Essex CO2 7NN, England www.tetradian.com / info@tetradian.com / Twitter: @tetradian White Knight Management PO Box 521, Isleworth, London, TW7 4YY, England www.greenhornconsulting.com / i nfo@greenhornconsulting.com © Tom Graves / Tetradian 2009
- We all know TOGAF and its Architecture Development Method (ADM). It’s long-proven for use in IT-architecture and business / IT alignment. But the enterprise is much more than its IT, and as the Open Group’s Len Fehskens put it, “An increasing number of enterprise architects believe that the rest of the enterprise, often generically referred to as ‘the business’, should be architected as well.” But TOGAF was and still is mostly designed for IT-architecture. How do we re-use it beyond IT?
- The current design of TOGAF is a natural fit for those enterprises that revolve around information and standardised, automatable business-transactions. Hence banking, for example; insurance; finance; some aspects of government. But other industries may have a different focus. In telecoms or manufacturing, ‘technology’ has a much broader meaning than just IT. Other industries or enterprises focus more on people, or physical ‘things’. In those cases, IT is just one amongst many other ‘enablers’ in the background – important, but no more important than anything else. On average, across all industries, IT represents about 2-4% of revenue. In most cases, it is not, and should not be, the sole centre of business attention. So if we are the ‘architect’ the enterprise, we need to be thinking a lot wider than just IT.
- The simplest way to describe the role of EA is that it’s a body of knowledge about enterprise structure and purpose - in the broadest sense of those terms. It’s about decision-support for others, particularly strategy and the PMO. The aim is to enhance the overall effectiveness of the enterprise. Since this architecture needs to be about the whole of the enterprise, we need a framework and method that we can use in a consistent way for any architecture need in the enterprise.
- As we’ll see in a moment, the current version of the ADM won’t cover the whole enterprise. To make it work, something will have to change. The simpler option is to tweak the roles and coverage Phases B, C and D – Business Architecture, Information-Systems Architecture and Technology-Infrastructure Architecture. The catch is that whilst this does expand the scope, it doesn’t overcome some of the other limitations of the current ADM, about the kinds of architectural issues we can address. To resolve those limitations, we’ll need a more serious re-think about what the ADM does, how it works, and how we use it in practice. One of the most important concerns, for example, is that we need a method that’s consistent for every use and purpose, regardless of scope or scale.
- But the key point here is that everything that we need for these expansions already exists in the TOGAF 9 specification . We may need to tweak some of it a bit – in particular, we’ll need always to remember to think outside of the IT-only box. But we don’t need to invent a whole new framework and method: everything we need is already there.
- So let’s look at the easier version first. The main point here is to lift up our sights a bit, and remember that there’s a whole world out there beyond IT.
- 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.
- The simplest way to extend TOGAF is to change the labels and focus of Phases B, C and D: - We use Phase A to identify the scope for the architectural issue, using an expanded version of Zachman – more about that later. - ‘Business architecture’ is ‘the business of the business’: strategy, direction, vision, mission, the big-picture overview. So use Phase B to explore the big-picture impact of the architectural issue in scope. - TOGAF’s ‘Information-system architecture’ is about how everything links together – particularly at the ‘logical’ level. So use Phase C to explore what’s common to all implementations here, and the connections – service-interfaces, for example – that would apply across the scope and for all implementations in that scope. TOGAF’s ‘Information-infrastructure architecture’ is a detailed plan for how one specific type of ‘enabler’ is implemented. So use Phase D to describe detail-level concerns for the issue in scope. Viewed this way, it’s clear that TOGAF’s emphasis on IT is just one possible use of this general-purpose pattern.
- This is one ‘stack’ we’ve found useful for an intermediate view: still mostly about IT, but much more strongly anchored in business needs. Each of these layers actually has its own big-picture, common and detail-level components. We might well do a sequence of architecture iterations, working our way down (or up) the layers, with a distinct Big-picture, Common and Detail assessment for each, and linking each to the next via Phase H and the subsequent Phase A.
- The business operating model describes how the enterprise delivers value (in any sense of ‘value’). Resources, assets and information may all be in any form – physical, virtual or relational. These are ‘pulled’ into enterprise processes that will either add value, consume them in adding value, mould them to create value for the enterprise itself, or use them to maintain quality and overall ‘hygiene’. The results are then ‘pushed’ out to clients in the outer world, either ‘public’ (such as B2C) or ‘private’ (B2C). The architecture needs to describe all of this in a consistent way – not solely the parts where IT-based information is used. This simple amendment to TOGAF’s Phases B to D allows us to do this.
- So, a quick summary of what expanding TOGAF’s scope requires, and allows us to do.
- But if we really want to make TOGAF usable at the whole-of-enterprise scope, we need to do a few more changes. Some of these are quite radical, but they are still ‘legal’ within terms of the TOGAF 9 specification.
- There’ve been various attempts to create a more versatile architecture-method than the ADM. This one’s from Oracle, released just a few days ago. In practice, though, they rarely offer much that’s new, and most – as in this case – remain too IT-centric for whole-of-enterprise use. We would probably be better off if we re-use what we already have in TOGAF.
- 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.
- Governance in the current ADM is also extremely messy – and made messier still by TOGAF 9’s approach to architecture iterations. The problem is that we have four fundamentally different scopes for architecture assessment, all with different stakeholders and standards. And we’re then supposed to do current-state, future-state and gap-analysis for each, in that order – which forces us into a top-down sequence. We then follow that with a single change-programme in Phases E-G, which is supposed to cover absolutely everything, all in one go. It’s no wonder that it all takes so long, and so fraught with difficulty.
- Yet we can simplify this right down if we go back to a structure closer to TOGAF 7, and do just one scope at a time, with one set of stakeholders and standards. We define the scope in Phase A, which automatically also identifies the stakeholders, standards and so on. We then assess the architecture of that scope for chosen time-horizon – usually ‘to-be’, sometimes ‘as-is’. Then, if necessary, we do it again for one or more other time-horizons – the ‘as-is’ or ‘to-be’, or any intermediates. And we then do the gap-analysis and requirements-elicitation and the like, for this one scope. If there are any change-requirements, this leads to an optional change-programme, in Phases E-G, and the mandatory review in Phase H. This keeps everything simple – and fast.
- The implementation phases remain much the same as in the existing TOGAF 9 – though again, they’re often much simpler, and much quicker. The only significant change is that Phase H includes extra activities that align it more strongly with other continuous-improvement methods such as Agile, TQM and Six Sigma: for example, we include specific sections on lessons-learned and benefits-realisation, to feed into the next cycle.
- A key point is that all of this is fast : we’ve done proper architecture-iterations with this in as little as a couple of hours. We can of course use nesting of architecture iterations to do a classic TOGAF-style ‘big architecture’, but the point is that the governance remains consistent throughout. This then works for any architecture, of any scope, at any scale. The key to this is that the respective scope is now defined in Phase A – and it always arises from a defined business-question. This ensures that architecture is always driven by real business needs – and not by whatever hyped-up product the vendors currently want to sell!
- We define the scope in terms of an adapted and extended version of another old friend – the Zachman framework. This kind of framework is the architecture equivalent of chemistry’s Periodic Table of Elements – the foundation for the core metamodel that underlies the entire enterprise architecture. Zachman’s rows or layers mostly work well enough as-is, not least because they describe different groups of stakeholders with different responsibilities in the enterprise. However, the columns do need a significant re-think, not least because there’s an entire dimension missing from the model.
- 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 that cover the full enterprise scope. Unfortunately, Zachman’s original What, How, Where, Who, When and Why don’t actually work well in practice, especially outside of IT. The emphases for each column need to change somewhat, for integrity and consistency in modelling and metamodelling, and also 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 can label as ‘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 ‘segment’ distinctions often aren’t critical in the upper layers, but they do matter as we move down towards the real world. This provides the base-skeleton for a ‘holograph’ of the enterprise. We add more detail and depth with each architecture iteration. We identify architectural scope in terms of this framework in the Phase A of each iteration.
- This combined restructure also sorts out another governance-problem in TOGAF 9: its 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. As mentioned before, this cycle can be used at any timescale: the classic TOGAF cycle takes a couple of years, but some of our clients’ architecture cycles might be no more than a couple of hours. The structure is also recursive, such that cycles can be nested within cycles within cycles, and so on – still with the same consistent governance. 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 TOGAF 9 cycle is held together by a shared repository labelled ‘Requirements Management’. But there’s a lot more that needs to be held in that central repository: it should also include all the architecture models, standards, blueprints, project-plans, governance records, risks, opportunities and other issues, the common glossary and thesaurus, and anything else that needs to be shared across the enterprise to support its overall architecture. Governance of this is not going to be simple; likewise security-management and so on. But the more of it that can be shared across the enterprise, the better the results will be – especially in the longer term.
- So, finally, a quick summary of what extending TOGAF’s capability requires, and allows us to do.
- And, to recap, we’ve used a two-step expansion of TOGAF to extend its capabilities beyond IT. The first step allows us to extend the scope that still retains the familiar B-C-D structure, but is still somewhat limited by the legacy of TOGAF’s IT-centric assumptions. The second step is more radical, asking us to restructure Phases A-D, but breaks us free of those limitations. 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. This re-use of TOGAF and its 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.