Unpacking TOGAF's 'Phase B': Business Transformation, Business Architecture and Business Buy-In


Published on

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]

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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]
  • Unpacking TOGAF's 'Phase B': Business Transformation, Business Architecture and Business Buy-In

    1. 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
    2. 2. <ul><li>The objective </li></ul><ul><ul><li>getting buy-in from the business with TOGAF </li></ul></ul><ul><li>The problem </li></ul><ul><ul><li>TOGAF feels too IT-focussed for most business-folk </li></ul></ul><ul><ul><li>it doesn’t connect enough with their world </li></ul></ul><ul><li>Finding what works </li></ul><ul><ul><li>re-focus on TOGAF’s ‘Phase B’ – ‘B for business’ </li></ul></ul><ul><ul><li>Functional Business Model and other extensions </li></ul></ul><ul><li>Extending the architecture </li></ul><ul><ul><li>reserve TOGAF for IT-centric parts of architecture </li></ul></ul><ul><ul><li>rethink the architecture for whole-of-enterprise </li></ul></ul>Unpacking ‘Phase B’
    3. 3. The objective gaining business buy-in with TOGAF
    4. 4. Bredemeyer on enterprise-architecture <ul><li>“ Increasing the scope of Enterprise Architecture to encompass more disciplines increases the benefits to be gained:”* </li></ul><ul><li>EA = Technical Architecture </li></ul><ul><ul><li>reduce IT complexity and costs [initial TOGAF] </li></ul></ul><ul><li>EA = Enterprise-Wide IT Architecture (EWITA) </li></ul><ul><ul><li>support IT collaboration among different parts of the enterprise [TOGAF Phase C and D] </li></ul></ul><ul><li>EA = EWITA + Business Architecture (BA) </li></ul><ul><ul><li>increase enterprise agility and alignment with business strategy [TOGAF Enterprise] </li></ul></ul>* Bredemeyer et al., “Enterprise Architecture as Business Capabilities Architecture”, http://www.bredemeyer.com, slide 10
    5. 5. Business need for enterprise-architecture <ul><li>Business now needs a new level of architecture maturity for business-transformation: </li></ul><ul><li>EA = integration across entire enterprise </li></ul><ul><ul><li>increase adaptability, resilience, management of opportunity / risk </li></ul></ul><ul><ul><li>increase synergies between processes and partners </li></ul></ul>...but here TOGAF starts to show its limitations – its great strength in IT-architecture can become a hindrance to business integration
    6. 6. The problem TOGAF feels too IT-focussed for most business-folk
    7. 7. TOGAF ADM in theory... <ul><li>Four architectures </li></ul><ul><ul><li>business architecture (Phase B) </li></ul></ul><ul><ul><li>data architecture (Phase C1) </li></ul></ul><ul><ul><li>application architecture (Phase C2) </li></ul></ul><ul><ul><li>technology architecture (Phase D) </li></ul></ul><ul><li>Architecture Design Method </li></ul><ul><ul><li>iterative, recursive </li></ul></ul><ul><ul><li>requirements at the centre </li></ul></ul><ul><ul><li>strategy, governance, migration and change-management </li></ul></ul><ul><li>‘ A well-balanced diet’ </li></ul><ul><ul><li>keeps the business happy </li></ul></ul>
    8. 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...
    9. 9. IT-centric architecture: too parochial? <ul><li>Like the old New Yorker cover, </li></ul>...and everything else of decreasing importance the further away it is from that centre... ...which is not what business wants or needs from us an IT-centric ‘enterprise-architecture’ tends to see its world as flat, with low-level technology at the centre of it all...
    10. 10. FEAF – the hidden dimensions <ul><li>FEAF PRM (Performance Reference Model) </li></ul>“ Technology” (Information Technology only, incorporating data and applications) “ Other Fixed Assets” (machines, machine-processes, vehicles etc) “ Human Capital” (people, manual processes etc) Business-architecture layers
    11. 11. TOGAF and the hidden dimensions <ul><li>TOGAF’s ‘Business Architecture’ barely touches those hidden dimensions </li></ul><ul><ul><li>no acknowledgement of people as people, no recognition of physical ‘things’ </li></ul></ul><ul><ul><li>also no awareness of non-IT-based knowledge </li></ul></ul>
    12. 12. Why we need to unpack Phase B <ul><li>The ADM’s over-emphasis on technology becomes unacceptable at this stage </li></ul><ul><ul><li>almost three times as much emphasis as on applications and data </li></ul></ul><ul><ul><li>more than six times as much as the rest of the business together </li></ul></ul>
    13. 13. Beyond an IT-centric architecture <ul><li>Instead of enterprise- IT - architecture, </li></ul>...and must be willing to explore and map any aspect of the broader enterprise, to create a greater understanding of that whole. an integrated, business-oriented enterprise -architecture needs to see its ‘world’ as a whole, like a globe, with no real centre as such...
    14. 14. Finding what works Extend the Architecture Design Method (creating a broader view of business-architecture)
    15. 15. Extending the business-architecture <ul><li>Some examples of ideas and tools proven to work well </li></ul><ul><li>Mapping business-functions </li></ul><ul><ul><li>adapted from extensions of FEAF </li></ul></ul><ul><ul><li>Functional Business Model, Costs Model, Business Systems Model, Information Model </li></ul></ul><ul><li>Mapping motivation </li></ul><ul><ul><li>adapted from OMG Business Motivation Model </li></ul></ul><ul><ul><li>vision, role, mission, goal – and SCORE </li></ul></ul><ul><li>An emphasis on effectiveness </li></ul><ul><ul><li>efficient, reliable, elegant, appropriate, integrated </li></ul></ul><ul><li>Making architecture tangible </li></ul><ul><ul><li>a ‘home-brew’ tactic to engage business </li></ul></ul>
    16. 16. Finding what works A focus on function (Functional Business Model and the like)
    17. 17. FEAF-style reference models <ul><li>Functional Business Model </li></ul><ul><ul><li>what is done, independent of organisation structure </li></ul></ul><ul><li>Business Systems Model </li></ul><ul><ul><li>‘ clustering’ of activities and information </li></ul></ul><ul><li>Information Systems Model </li></ul><ul><ul><li>‘ chunking’ of applications and repositories </li></ul></ul><ul><li>other technical-layer models </li></ul><ul><ul><li>Information Model, Technical Model, Services Model, etcetera </li></ul></ul>...with an emphasis on business-function
    18. 18. Functional Business Model <ul><li>Model is hierarchy of four levels of business </li></ul><ul><ul><li>Function, Process, Activity, Task </li></ul></ul><ul><ul><li>diagram shows Function, Process, Activity only </li></ul></ul><ul><li>Map each project, application onto Model </li></ul><ul><ul><li>visually highlighted overlaps between projects </li></ul></ul><ul><ul><li>data overlaps indicate possible ‘multiple sources of truth’ and other data-quality issues </li></ul></ul><ul><ul><li>gaps indicate possible gaps in IS support </li></ul></ul><ul><ul><ul><li>also may indicate potential new projects </li></ul></ul></ul><ul><ul><ul><li>example : support for quality-system corrective-action </li></ul></ul></ul>
    19. 19. Functional Business Model Shows level-1 ‘Function’, level-2 ‘Process’, level-3 ‘Activity’ (level-4 ‘Tasks’ listed in text form only)
    20. 20. Functional Cost Model <ul><li>Overlay on Functional Business Model </li></ul><ul><ul><li>full cost-breakdown to level-3 (Activity) </li></ul></ul><ul><ul><li>aggregate costs for each Function, Process </li></ul></ul><ul><li>Map costs to Activity, project, application </li></ul><ul><ul><li>enables ‘what-if?’ analysis </li></ul></ul><ul><ul><ul><li>“ what cost reductions could we achieve if…?” </li></ul></ul></ul><ul><ul><li>enables more precise targeting of projects </li></ul></ul><ul><ul><ul><li>high-cost project targeted on low-value Activity? </li></ul></ul></ul><ul><ul><ul><li>combined high-cost projects overlapping Activity? </li></ul></ul></ul><ul><ul><ul><li>no applications supporting high-value Activity? </li></ul></ul></ul>
    21. 21. Business Systems Model <ul><li>Identifies ‘clusters’ on Functional Business Model </li></ul><ul><ul><li>‘clustered’ activities perform similar functions or share a lot of information </li></ul></ul><ul><ul><li>each ‘cluster’ is called a business system </li></ul></ul><ul><li>Groups together activities that are likely to be supported by the same information systems </li></ul><ul><ul><li>leads to purchase or development of computer systems that do not overlap in functionality </li></ul></ul><ul><li>Overview model: colour-coded Function Model </li></ul><ul><li>Detailed model for each Business System </li></ul><ul><ul><li>model includes text descriptions of business systems </li></ul></ul>
    22. 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. 23. Business System detail Icons indicate process-types: Manual processes Machine processes IT-based processes Mixed processes
    24. 24. Information Systems Model <ul><li>Identifies ‘chunks’ of IT functions required to support each Business System </li></ul><ul><ul><li>each 'chunk' is an information system </li></ul></ul><ul><li>Information systems do not imply what IT application will be used </li></ul><ul><ul><li>describe broadly what we want IT apps to do </li></ul></ul><ul><li>Define information systems for the whole without reference to existing IT applications, to ensure: </li></ul><ul><ul><li>apps perform functions that make sense to do together </li></ul></ul><ul><ul><li>apps do not overlap in functionality </li></ul></ul><ul><ul><li>apps cover all the functionality we require </li></ul></ul>
    25. 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. 26. Finding what works Purpose-driven architecture (vision, role, mission, goal, and an emphasis on effectiveness)
    27. 27. Business-driven architecture <ul><li>The anchor for a business-architecture, and for any quality-system, is business vision and business purpose </li></ul><ul><li>Clarity on business purpose </li></ul><ul><ul><li>importance of an emotive ‘vision’ to support motivation </li></ul></ul><ul><ul><li>provides point of contact with customers, partners, suppliers, other stakeholders </li></ul></ul><ul><li>Need for audit-trail of purpose for all activities </li></ul><ul><ul><li>suggested structure of vision / role / mission / goal </li></ul></ul><ul><li>Purpose is dynamic </li></ul><ul><ul><li>systematic foresight tools to track strategic ‘weak signals’ </li></ul></ul>More information: http://tetradian.com/vrmg
    28. 28. Purpose - vision, role, mission, goal <ul><li>Vision </li></ul><ul><ul><li>never ‘achieved’, always larger than the organisation </li></ul></ul><ul><li>Role </li></ul><ul><ul><li>what the organisation does and does not do towards the Vision </li></ul></ul><ul><li>Mission </li></ul><ul><ul><li>condition or capability to be created and maintained </li></ul></ul><ul><li>Goal </li></ul><ul><ul><li>time-limited, identifiable condition </li></ul></ul>Use SWOT or SCORE checklist to assess and validate strategy
    29. 29. The dimensions of SCORE <ul><li>S trengths / services / support </li></ul><ul><ul><li>existing capabilities and resources, potential for synergies </li></ul></ul><ul><li>C hallenges / capabilities needed </li></ul><ul><ul><li>‘ weaknesses’ indicate needed capabilities and resources </li></ul></ul><ul><li>O ptions / opportunities and risks </li></ul><ul><ul><li>opportunity is also risk, risk is also opportunity </li></ul></ul><ul><li>R esponses / returns / rewards </li></ul><ul><ul><li>probable or emergent consequences of action or inaction </li></ul></ul><ul><li>E ffectiveness </li></ul><ul><ul><li>efficient, reliable, elegant, appropriate, integrated </li></ul></ul><ul><li>all linked together as a unified whole </li></ul>
    30. 30. Methodology - Using SCORE <ul><li>Select an issue </li></ul><ul><li>Identify, record, compare any measurable items </li></ul><ul><ul><li>new capabilities, etc </li></ul></ul><ul><ul><li>compare against previous SCORE assessments </li></ul></ul>More information: http://tetradian.com/score efficient reliable elegant appropriate integrated <ul><li>Assess impact of each item on effectiveness </li></ul>strength challenge option response effectiveness <ul><li>Start checklist anywhere </li></ul><ul><ul><li>often start with Strengths, or Options, but not required </li></ul></ul><ul><li>Work through the list </li></ul><ul><ul><li>repeat/iterate in any order </li></ul></ul>
    31. 31. An emphasis on effectiveness <ul><li>Is it Efficient? </li></ul><ul><ul><li>maximises use of resources, minimises wastage of resources </li></ul></ul><ul><li>Is it Reliable? </li></ul><ul><ul><li>predictable, consistent, self-correcting, supports ‘single source of truth’ </li></ul></ul><ul><li>Is it Elegant? </li></ul><ul><ul><li>clarity, simplicity, consistency, self-adjusting for human factors </li></ul></ul><ul><li>Is it Appropriate? </li></ul><ul><ul><li>supports and maximises support for business purpose </li></ul></ul><ul><li>Is it Integrated? </li></ul><ul><ul><li>creates, supports and maximises synergy across all systems </li></ul></ul><ul><li>Aim is to ensure systems fit in with everything else </li></ul>More information: http://tetradian.com/score
    32. 32. Finding what works Making architecture tangible (four dimensions and a tetradian)
    33. 33. Making architecture tangible <ul><li>Four dimensions to the structure of the enterprise: </li></ul><ul><li>Business-direction dimension (purpose) </li></ul><ul><ul><li>Business drivers/goals, strategy/tactics, performance, etc </li></ul></ul><ul><li>People dimension (relationships) </li></ul><ul><ul><li>skill-sets, teamwork, social networks, rostering, etc </li></ul></ul><ul><li>Knowledge dimension (conversations) </li></ul><ul><ul><li>information-technology, tacit knowledge, business meaning </li></ul></ul><ul><li>Physical dimension (transactions) </li></ul><ul><ul><li>machinery, warehousing/stock, logistics, lead-times, etc </li></ul></ul><ul><li>and the integration of these into a coherent whole </li></ul>
    34. 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
    35. 35. Each view is a subset of the whole <ul><li>Typically, each area sees up to three dimensions at one time: </li></ul><ul><li>an Operations area sees only People, Machines, IT/Knowledge (as on right) </li></ul><ul><li>an IT area sees only IT/Knowledge, Machines and Business </li></ul><ul><li>an HR area sees only People, Business, perhaps IT/Knowledge </li></ul>The business system is comprised of all four dimensions, always; the architecture must model this whole, as a whole.
    36. 36. Extending the architecture Extending the ADM concept beyond IT
    37. 37. ‘ Flatten out’ tetradian format to 5Ps <ul><li>Business dimension </li></ul><ul><ul><li>map as Purpose , D irection </li></ul></ul><ul><li>Relational dimension </li></ul><ul><ul><li>map as P eople </li></ul></ul><ul><li>Knowledge dimension </li></ul><ul><ul><li>map as Preparation , K nowledge </li></ul></ul><ul><li>Physical dimension </li></ul><ul><ul><li>map as Process , T asks </li></ul></ul><ul><li>Integration between dimensions </li></ul><ul><ul><li>map as Performance , M etrics </li></ul></ul>Underscored letter in dimension-name is key-code in SEMPER-5 model – see next slide
    38. 38. Full 5Ps framework (SEMPER-5) <ul><li>Place requirements at the centre </li></ul><ul><ul><li>as per TOGAF ADM </li></ul></ul><ul><li>Identify architecture artefacts </li></ul><ul><ul><li>distinct for each dimension </li></ul></ul><ul><li>View each dimension from effectiveness perspectives </li></ul><ul><ul><li>efficient, reliable, elegant, appropriate, integrated </li></ul></ul>
    39. 39. A documented methodology <ul><li>A complete high-level methodology </li></ul><ul><ul><li>for each dimension... </li></ul></ul><ul><ul><ul><li>purpose, people, preparation, process, performance </li></ul></ul></ul><ul><ul><li>for each view, from each effectiveness-perspective... </li></ul></ul><ul><ul><ul><li>efficient, reliable, elegant, appropriate, integrated </li></ul></ul></ul><ul><ul><li>describe principles, practice and broader applications </li></ul></ul><ul><ul><ul><li>procedure: purpose, people, preparation, process, performance </li></ul></ul></ul><ul><li>Use as an adjunct to ADM’s Phase A and B </li></ul><ul><li>Documented in book form </li></ul><ul><ul><li>“ Real Enterprise-Architecture: beyond IT to the whole enterprise” </li></ul></ul><ul><ul><li>free download from the Tetradian website </li></ul></ul><ul><ul><ul><li>http://tetradian.com/download/real-ea_v1.pdf </li></ul></ul></ul>
    40. 40. Summary <ul><li>Existing frameworks and tools such as TOGAF are excellent for an IT-centric ‘enterprise-architecture’ </li></ul><ul><li>Those frameworks and tools are not well-suited at present for use beyond that scope </li></ul><ul><li>An integrated approach to enterprise-architecture is essential for further synergies across organisations </li></ul><ul><li>The ‘ four dimensions ’ model provides a simple starter-framework for an integrated architecture </li></ul><ul><li>The 5Ps methodology (SEMPER-5) provides detailed ideas on how to apply this in architecture practice </li></ul><ul><li>Many thanks! </li></ul>