Unpacking TOGAF's 'Phase B': Business Transformation, Business Architecture and Business Buy-In
•Als PPT, PDF herunterladen•
39 gefällt mir•13,935 views
The Open Group Architecture Framework (TOGAF) is a structured method for developing enterprise architectures. As standard, its 'Phase B', 'Business Architecture', is an IT-centric way of viewing the business: we need to 'unpack' it to move to a more holistic view of the enterprise in which IT takes a more realistic role. [Presentation at TOGAF Conference, Paris, April 2007. Describes TOGAF 8.1, but most details apply as much to TOGAF 9. Copyright (c) Tetradian Consulting 2007]
![[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Unpacking ‘Phase B’](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Unpacking TOGAF's 'Phase B': Business Transformation, Business Architecture and Business Buy-In
Ähnlich wie Unpacking TOGAF's 'Phase B': Business Transformation, Business Architecture and Business Buy-In (20)
Mehr von Tetradian Consulting
Mehr von Tetradian Consulting (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Unpacking TOGAF's 'Phase B': Business Transformation, Business Architecture and Business Buy-In
- 1. Unpacking TOGAF’s ‘Phase B’ Business Transformation, Business Architecture and Business Buy-In Tom Graves : Tetradian Consulting Europe: Colchester, England / Australia: Castlemaine, Victoria http://www.tetradian.com TOGAF Paris, April 2007 © 2007 Tetradian Consulting
- 3. The objective gaining business buy-in with TOGAF
- 6. The problem TOGAF feels too IT-focussed for most business-folk
- 8. ...TOGAF ADM in practice? ...and we get so tech-heavy that business don’t love us no more... If we aren’t careful, Ol’ Papa TOGAF gets us back into bad IT habits - like coffee, soda, nachos and pizzas...
- 14. Finding what works Extend the Architecture Design Method (creating a broader view of business-architecture)
- 16. Finding what works A focus on function (Functional Business Model and the like)
- 19. Functional Business Model Shows level-1 ‘Function’, level-2 ‘Process’, level-3 ‘Activity’ (level-4 ‘Tasks’ listed in text form only)
- 22. Business Systems Model Same colour-coding is used in detail-models, Information Systems Model Layout and content is identical to Functional Business Model Colour-codes for business-system ‘clusters’
- 23. Business System detail Icons indicate process-types: Manual processes Machine processes IT-based processes Mixed processes
- 25. Information Systems Model Similar overall layout to Functional Business Model Same colour-coding as Business Systems Model (unrepresented Business Systems assumed to need no Information System support)
- 26. Finding what works Purpose-driven architecture (vision, role, mission, goal, and an emphasis on effectiveness)
- 32. Finding what works Making architecture tangible (four dimensions and a tetradian)
- 34. Map dimensions in tetrahedral form With a simple cardboard ‘tetradian’, the dimensions are tangible ... … rotating between different views… … for a fifth dimension, a sense of the whole… ...IT Architecture and Business Architecture, together, and more... … the architecture seen and felt from every direction. More information: http://tetradian.com/name
- 36. Extending the architecture Extending the ADM concept beyond IT
Hinweis der Redaktion
- Tetradian Consulting The Coach House Balkerne Close Colchester CO1 1NZ England [+44] (0) 781 560 6624 [email_address] www.tetradian.com
- A quick overview of what I’ll be covering here. For most of us, getting business buy-in is one of the hardest parts of enterprise-architecture. And the main reason, I’d suggest, is that TOGAF is too IT-focussed for most business types. If we’re going to engage their interest, and their active involvement, we need to do something different. Especially around the ADM’s ‘Phase B’ – business-architecture.
- So our objective is to gain business buy-in to support enterprise-architecture, especially in those large business-transformation projects. No buy-in, no project, and often no enterprise-architecture: it’s as simple as that.
- Let’s look at the business drivers here. As Dana Bredemeyer explained in his influential article, enterprise-architecture – and TOGAF – grew out of a business need to manage the growing cost and complexity of IT systems. As EA maturity developed, it gave new insights on re-purpose and re-use, and in how to link systems together in new ways – for example, real-time stock levels on an e-commerce system. In the past few years the scope has widened again, aiming to link IT developments more strongly to business strategy and needs. Hence TOGAF 8, the ‘TOGAF Enterprise Edition’.
- The challenge now is to extend this to every aspect of the business – even across complex multi-partner enterprises. If we get it right, the pay-offs are huge. The trick, of course, is getting it right. But this is where TOGAF, in fact all the existing EA frameworks, start to show the strains from their IT heritage.
- The problem is that TOGAF feels too IT-focussed to make sense to most business-folk – especially at the business-transformation level. And if they don’t understand it, they’ll decide they don’t like what they see. We need a framework and methodology that will engage the business in architecture – but that tech heritage gets in the way. So let’s look first at how and why that tech heritage is such a problem.
- Here’s what’s supposed to happen. We download TOGAF from the Open Group website. It’s clear, it’s well-presented and, unlike Zachman, for example, there’s an open, comprehensive methodology. Four explicit architectural layers; migration-planning, governance and change-management; and a solid approach to requirements-management and so on. All looks good. “A well-balanced diet”, you might say.
- If we only want to sort out a tangle of legacy technology – Bredemeyer’s first two maturity-levels – then everything’s still fine. And we do need to do that before we can go further – no doubt about that. But if we try to tackle anything much more than technology, we’ll find that TOGAF’s ‘diet’ is not as healthy as we’d hope. The problem is that the ADM has a huge bulge around technology. That’s where things can go pear-shaped... literally...
- All of the current architecture frameworks, languages and toolsets promote this kind of ‘flatland’, centred on the low-level IT. Technology is like 9 th Avenue, New York – the centre of the world, for the New Yorker . Application architecture is just one street over, on 10 th Avenue. But data architecture is stuck out on the other side of the Hudson River. And business architecture? Way out west, lost in the Pacific Ocean. No wonder there’s a disconnect with business... To resolve that disconnect, we need to put some effort into unpacking the grab-bag that is the ADM’s Phase B – the ‘business architecture’ phase.
- So take a look at the Federal Enterprise Architecture Framework’s ‘Performance Reference Model’. At first, it’s much the same as TOGAF, with ‘Technology’ – information-technology, including Data and Applications – linked to the business-architecture layers. But notice those two greyed-out boxes either side of Information-Technology, labelled ‘Human Capital’ and ‘Other Fixed Assets’. They’re placeholders for future work to link these other domains into a true whole-of-enterprise framework. And that’s what they are: distinct domains, separate from the business-architecture proper. They’re not part of FEAF yet – but they will be. Eventually.
- At least FEAF does acknowledge that they need to exist. At present, TOGAF doesn’t even get that far. Okay, I’m being a little unfair here – especially at a TOGAF conference! But anyone who’s tried to apply the ADM at a business level will know exactly what I mean. Yes, in principle it’s all sort-of there in the ADM, because everything non-IT is lumped together under that heading of ‘business architecture’. But there’s no recognition that there are several distinct dimensions beyond IT, all blurred together into one unmanageable mess. Oops.
- This gives us some idea of the size of that tech-heavy bulge in the ADM. The relatively small area of low-level IT gets more than six times as much attention as the rest of business put together. That’s a huge imbalance. But it isn’t just TOGAF, of course. All the current frameworks are too IT-centric. Even process-aware frameworks like ARIS are poor at understanding people as people, or at modelling flows of physical ‘things’. And none of them seem to have any awareness of non-IT-based narrative knowledge – the main source of business meaning .
- Beyond IT-architecture, what business needs is a much more rounded view. Seeing the world from every direction, every dimension. Not a flatland, a single city, but the globe of an entire business ‘world’. That’s the scope that our architecture frameworks need to support. The ADM isn’t wrong: I need to emphasise that. It does work well – very well – for the earlier tech-oriented maturity-levels. That’s what it was designed for. But it still needs some work to make it better at the next levels – the more business -oriented levels – of enterprise-architecture. So what we need is a way to expand TOGAF’s methodology to manage this wider view.
- To reach those levels, we need to adopt a few ideas from elsewhere, and weave them into the same general structure as the existing ADM. So let’s see some ideas and tools that can be used to fill some of those gaps in the framework.
- These are some examples I’ve come across or invented for use in my own practice, to complement the better-known aspects of business-architecture. A map of business functions is a key first stage in a broader approach to service oriented-architecture, and provides a business anchor for technical architectures. Mapping motivation provides a key understanding not just of the business drivers, but of what drives the business. Increased efficiency is a common business driver for architecture, but what we’re really after is increased overall effectiveness. And pulling architecture out of the abstract and into something that business can touch and feel is one of the best ways to engage them in architecture development.
- Let’s look first at a set of reference-models developed by the Transformation team at one of my Australian clients. The starting-point is a focus on business-function.
- There is a passing reference to function modelling in the ADM, at B.3.ii.c, but no explanation of what it is or how to use it. So here’s one way to do it. My clients started by mapping the business functions in terms of services, in an abstract way, and separate from any fixed notions about organisational structure. From there, they identified a set of ‘business systems’ – clusters of activities in different functional areas that did similar things and shared similar information. And derived from that a set of abstract ‘information systems’ to support the required functionality. Only then did they do their IT Reference Models. In their case they used FEAF, but TOGAF’s much the same for this. The point was that they anchored those models in something that made solid sense to the business.
- The Functional Business Model is a straight functional-breakdown hierarchy in four levels: nothing complicated about it. For simplicity, their model diagram showed only the first three levels. But you need to go to at least that level of detail to make the model usable. Part of my own work there was to map projects and applications onto the Model. That gave the business an immediate visual image of overlaps and gaps in the systems’ coverage of business functions. (Just think for a moment what that knowledge is worth to your own organisation...) The gaps also highlighted potential for new projects. One that I dealt with there was new support for corrective-action – a perennial problem that management had never really recognised till they saw it on that map.
- Here’s the model diagram. (I’ve changed the labels, of course, but the layout and the overall principles are the same.) It’s backed by a text document with a description for each box, and for the next level down, the Task layer. The business-people loved it. We saw a copy pinned on the wall in most managers’ offices, often annotated with little Post-It notes and markers about their own work-area. A really successful way to engage business in architecture – because it had direct meaning to their own world and work.
- The Cost Model is another overlay, mapping the respective operational costs for each Function, Process and Activity. A lot of work, but really worthwhile, because it gave the business a direct, visual map of where their money went. We then mapped each project and application, and their respective costs, onto the same overlay. This showed us our system budget and spend, and how good our targeting was – or wasn’t, rather. Some nasty surprises, the first time we did this... But it also showed exactly what to fix, and how and where and why. This was architecture that got immediate attention from the business – because they could see exactly what it meant to their world.
- The Business Systems Model was another re-use of the same structure and content. Mapping related functionality gave us another way to identify gaps and overlaps – again with big pay-offs in system design and targeting. Two parts to this model: a colour-coded version of the Function Model as an overview; and detail-views for each of the ‘business-systems’.
- Here’s the overview version. (Again, I’ve changed the labels, for commercial confidentiality, but it’s still the same overall structure.)
- And the detail-view for one of the business-systems (again with edited labels). The colour-coded rectangles are links to other business-systems; the round-cornered rectangles are the respective Activities. Two additional points. One is that – unlike any IT-oriented framework – this model does capture flows of physical ‘things’. And see those icons indicating the type of process – manual, machine-based, IT-based, and their combinations. These help to separate the abstract service from any implementation of that service – a distinction that becomes important in a broader, non-IT-centric, view of service-oriented architecture.
- This mapping leads to another ‘clustering’, identifying abstract ‘information-systems’. To protect ‘single source of truth’, we should have one Information System for each Business System, and a single repository for each Information System...
- ...though in this early cut of the Model it work out that way in practice. But it’s a good principle – and again one that makes good business sense. With this groundwork established, it was then safe to go down to IT-centric models – because we could anchor it to something that made sense to the business.
- The next set of ideas, around business-purpose, come from tactics I’ve developed over the past few years for a variety of Australian clients. It’s important because purpose is what anchors the business-architecture.
- Most EA frameworks do call for some kind of linkage to business drivers and goals: for example, it’s tucked away at the top right of Zachman. But there’s not much practical help: a few suggestions in the ADM, but that’s it. One problem is confusion around ‘vision’. It’s not a marketing exercise – we’ll look at this in more detail in a moment. From my own architecture experience, a systematic ‘motivation audit-trail’ of vision / role / mission / goal seems to provide the best approach. And although the vision must be stable, business-purpose overall needs to be dynamic, tracking the strategic ‘weak signals’ of future change in the business environment.
- Let’s look at that audit-trail of vision, role, mission, goal in a little more detail. Mission and Goal are straightforward enough: they’re described well in the Object Management Group’s ‘Business Motivation Model’, for example. But the BMM’s handling of Vision is an almost perfect example of what not to do. We need a Vision that is larger than the organisation – because that’s how our partners and other stakeholders connect with us. The Role describes what we choose to do or not-do in the Vision-world – which defines the space and context in which we connect with those partners. It all makes perfect business sense – if we do it that way. One great example is that all of New South Wales’ government departments have a ‘results logic diagram’ in this form, linking their service-delivery frameworks to concrete results for the community. It motivates people, it provides an explicit anchor for everything the department does. It works . And to assess this kind of audit-trail, we’d use a strategy checklist like SWOT – though these days I’d recommend my own homebrew variant, SCORE.
- Everyone knows SWOT: Strengths, Weaknesses, Opportunities, Threats. Nice, simple methodology: check the boxes, and you’re done. But it’s a bit too simple for today’s more complex world. Hence SCORE. It tackles the same issues, with a SWOT-like checklist, but with a bit more subtlety: Our Strengths are what we already have. Our Challenges are what we know we need, or need to address. Our Options and opportunities come from looking inward, and at the outside world. We watch for probable Responses of the outside world to the chosen strategy. And we explore probable impacts of the strategy on overall Effectiveness. (More on that in a moment.)
- Like the ADM, the SCORE methodology is cyclical, iterative, re-entrant, recursive. We select an issue to assess, then start anywhere, and work our way through all the SCORE dimensions, using each viewpoint as a perspective on the other dimensions. For everything that we identify, we always look at its impact on overall effectiveness, using the effectiveness-checklist: efficient, reliable, elegant, appropriate, integrated. We also watch for anything to measure, whether numeric or qualitative – for example, a new capability that didn’t exist at the previous SCORE. The reason is simple: if we can measure it, we can manage it.
- Managers often obsess about efficiency; but what we really need is effectiveness . There’s no point in making something more ‘efficient’ if it isn’t reliable. If it isn’t elegant – in both the scientific and human sense – it can’t work well. There’s no point in doing something unless we know it’s ‘on purpose’. And we need to make sure these all work together, and tie in well with everything else. These may seem obvious: but they can be easy to miss unless we test for them, systematically, all the time, in every part of our enterprise-architecture.
- Before we look at methodology, let’s explore one more idea to make the architecture more engaging to the business. And this one works by being literally tangible.
- As we’ve seen, existing frameworks bundle everything not-IT into a grab-bag called ‘business architecture’. We need to tease those threads apart into something more usable at an enterprise-wide scope. It’s useful to describe the overall enterprise via four distinct dimensions, the four corners of the business globe: direction or purpose, people, knowledge and physical ‘things’. (IT is one subset of the ‘knowledge’ dimension.) Services, processes and so on sit in the interactions between these dimensions. This interaction is dynamic , not static. What makes it work is a kind of hidden ‘fifth dimension’, linking these four dimensions into a coherent whole. So far, so abstract. But describe that lot, in words alone, to a business-type. See how far you get. (I did, for way too many years. It doesn’t work. At all...)
- What does work is making this tangible – literally. Mapped onto a simple tetrahedron, these ‘four corners of the business globe’ become something that business-folk can relate to, in a direct, tangible way. They can hold it, rotate it in their hands, see the different views. By rotating attention between these views, we gain a sense of the whole, to keep it working as a whole – which is what enterprise-architecture really needs to create for the business. (Another example of ‘making architecture tangible’, from another client. The architects made a little wooden model of the layers of technology, network, applications and so on, with projects as wooden blocks fitted together like a jigsaw. Clever, simple, and very effective: many of the executives said it was the first time they’d understood how their systems worked.)
- Even with something as simple as this, we can see many of the perennial problems of every organisation. Each business area has different emphases on these dimensions – and also dimensions they tend to ignore. Operations, for example, don’t have time to think much about business-purpose; IT are notorious for forgetting about people, whilst HR perhaps think of little else. Yet we can’t expect business-folks to keep each dimension in mind, under the day-to-day pressures of “Do it now !”. It’s too much to ask. So it’s our responsibility, as architects, to keep that balance for the enterprise as a whole – maintaining all four dimensions in our models, always. Try this in your own environment. Find something – anything – that will make the architecture tangible. It’s a simple trick – but it really works.
- Finally, let’s look at a way of using all of this to extend the ADM itself, to flesh out the hollow spaces in Phase B.
- A simple suggestion: take the four dimensions of the tetradian, with that rotation for integration, and lay them out flat in a five-part sequence. You might recognise this as the old Group Dynamics project-lifecycle: Forming, Storming, Norming, Performing, Adjourning. For amusement, the classic Chinese ‘five elements’ also match exactly: Wood, Fire, Earth, Metal, Water. That works well in organisations, too – though that’s another story for another time.
- So take that sequence, and place requirements at the centre, as with the ADM. Add some example artefacts from enterprise-architecture – again much like the ADM – to apply this framework to architecture itself. Then use those five effectiveness-perspectives we saw earlier as views into each dimension. They’re actually variants of the same set of dimensions – so the framework becomes recursive. This may sound a little abstract at first, but you’d be surprised at how much it opens up the understanding of complex systems...
- ...because when we go into it more deeply – which I don’t have time to do here! – that framework gives us a complete and consistent method which we can use in conjunction with the ADM, to unpack that problematic Phase B. It includes everything we’ve seen so here far, and a whole lot more. And it’s all documented in book-form, in a structured way that’s easy to apply in practice. So yup, here’s the sales-pitch. (Except it’s not about money: in electronic form the book’ll cost you nothing.) Take it; use it; share it; add your own ideas to the framework, and share those too. But let’s work together to patch those gaping holes in Phase B, and help build TOGAF and the ADM into something we can use for every aspect of a real enterprise -level architecture.
- So let’s summarise what we’ve seen in this brief excursion. Current frameworks and tools like TOGAF work well for IT-centric architecture; but they don’t work well for anything else. Dumping everything that’s not-IT into a blurry, indistinct grab-bag called ‘business-architecture’ can’t be acceptable any more. What we need to do now is expand that grab-bag into its proper dimensions, and be clear about their characteristics and the interactions between them, linked with the dynamics of business requirements and business integration. The ‘four dimensions’ model – the tetradian – gives us the simplest possible framework for a high-level model of this business ‘globe’; and the 5Ps methodology gives us a way to apply it in everyday business practice. [ends]