Search

Stepping-stones of enterprise-architecture: Process and practice in the real enterprise

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    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.

    2 Favorites

    Stepping-stones of enterprise-architecture: Process and practice in the real enterprise - Presentation Transcript

    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
    2. Doing enterprise-architecture
      • What do we do
      • when we’re doing enterprise architecture?
      • Enterprise architecture isn’t a project
        • it’s more like a way of life!
      • Creating an architecture is a long-term process
        • conventional: 1-2 years to start to see business-value
      • BUT in these times no-one will wait for value
        • so we need to do it differently from ‘the book’
      • How do we get results fast? Where do we start?
    3. Use the TOGAF maturity-model
    4. Stepping-stones of architecture
      • TOGAF’s model has 5 levels, hence 7 ‘stones’
      • Each stepping-stone builds on those before:
      • Prepare (and maintain) the foundations
      • Step 1: Build an overview of the business
      • Step 2: Clean up the mess (and keep it clean)
      • Step 3: Guide and manage strategic change
      • Step 4: Ensure robust resilience, continuity
      • Step 5: Service the business’ deeper needs
      • Maintain as an enterprise-wide shared capability
    5. Prepare architecture foundations
      • Emphasis: support for whole-enterprise scope
      • Examples : business, IT-, manual- and machine-based processes, capabilities, customer, partner, supply-chain, shared enterprise
      Purpose – strategy People – governance Planning – frameworks Practice – methods Performance – metrics
    6. Purpose – strategy
      • Enterprise architecture acts as custodian for a body of knowledge on structure and purpose :
        • “ what structure changes do we need for this strategy?”
        • “ what strategy can we support with this structure?”
        • “ what risks, opportunities does this strategy create?”
      • Provides bridge between strategy and PMO etc
      • -- BUT NOTE --
      • IT is only one small part of the enterprise
        • “ typically 2% to 3% of business cost” (Paul Coby, CIO of BA)
      • A real EA must have whole-of-enterprise scope
        • it’s essential in long-term – so best to start there!
    7. Whole-of-enterprise architecture
      • Each EA generation has had to extend the scope:
      • ‘ Classic’ EA starts with IT infrastructure
      • IT tech-architecture depends on applications
      • Applications-architecture depends on data
      • Data-architecture depends on business-info need
      • Information-architecture depends on business
      • Business-architecture depends on enterprise
      • Enterprise-architecture defines the context
      • An enterprise-architecture must have whole-of-enterprise scope – it’s not just detail-level IT!
    8. TOGAF and architecture scope
      • Classic scope of IT-based ‘enterprise architecture’
      IT (3% of enterprise) Everything not-IT ? (97% of enterprise)
    9. Scope of IT in enterprise context
      • Whole-of-enterprise scope
      IT is only a small subset (not even all of Information)
        • three layers: Business, Integration (Common), Detail
        • three columns: People, Information, Physical Assets
    10. People – governance
      • Governance is well-described in TOGAF 9 spec
        • Architecture Charter, Architecture Governance etc
        • but EA-governance is not a subset of IT-governance!
          • organisationally, EA should be outside IT, not subordinate to it
      • Skillsets well-described in Capability Framework
        • but will also need broad range of skills from beyond IT, to cover needs of much broader architecture scope
      • Process-governance as per Agile, not Waterfall
        • multiple, simultaneous, recursive architecture-cycles
      • Will need executive-level support from the start
        • will need that support to bridge across all silos etc
    11. Planning - frameworks
      • Frameworks define structure and meaning
      • TOGAF provides ‘Enterprise Continuum’
        • ‘ Architecture Continuum’ and ‘Solutions Continuum’
        • four layers: Foundation, Common-systems, Industry and Organisation-specific
      • Reference-frameworks define ‘bindedness’
        • mandatory, recommended, suggested etc
      • All items ultimately anchor to base-framework
        • layers of ‘composites’ resolve to explicit ‘primitives’
      • Zachman as an archetypal base-framework
    12. Base-framework columns
      • Columns need restructure to support whole-EA
      At Operations level, we should be able to describe every service as: -- this is an ‘architecturally complete’ pattern or composite
    13. Base-framework segments Needs dimension of ‘segments’ within columns
    14. Practice – methods
      • TOGAF ADM as the obvious choice for method
        • long-proven in IT-architecture
        • ADM is designed for adaptation and extension
      • Must use ADM in Agile style for rapid ROI
        • business will not wait 2+ years before any returns!
      • TOGAF 9 has better support for iterations
        • but may not be usable out-of-the-box for Agile
      • Amend fixed IT-centric scope of TOGAF 9
        • ADM for whole-enterprise: Phase A=iteration scope, Phase B=‘as-is’, Phase C=‘to-be’, Phase D=gap-analysis
    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
    16. Performance – metrics and products
      • Need processes to measure benefits-realisation
        • need to prove the value of enterprise architecture
        • link every iteration to explicit business value
      • Artefacts from architecture work include:
      • Models, metamodels and reference-models
      • Change-roadmaps and portfolio ‘blueprints’
      • Requirements-repository
      • Risks, opportunities and issues registers
      • Architecture-dispensations register
      • Glossary and thesaurus
    17. Step 1: Know your business
      • Emphasis: ‘big-picture’
      • Examples : whole-of-enterprise overview, end-to-end and top-to-bottom integration
      1A: Vision, values, principles and purpose 1B: The enterprise context 1C: Functions and services 1D: Architecture governance
    18. Step 1: Know your business
      • 1A: Vision, values, principles
        • Vision, role, mission, goal
        • Values, principles, business purpose
      • 1B: The enterprise context
        • Compliance, constraints, standards, expectations
        • Assets, locations, events
      • 1C: Functions and services
        • Services; functions; capabilities; the Function Model
      • 1D: Architecture governance
        • Creating architecture capability; creating engagement
    19. Function-model: tier-1 example
    20. Function-model: tier-2 example
    21. Function-model: tier-3 example
    22. Step 2: Clean up the mess
      • Emphasis: ‘ horizontal’
      • Examples : optimise systems, reduce redundancy
      2A: Business-systems and information-systems 2B: What do we have? 2C: Guiding the process of change
    23. Step 2: Clean up the mess
      • 2A: Business / information-systems
        • Business systems; identifying business-systems; modelling individual business-systems
        • Information systems and ‘single source of truth’; identifying single-source-of-truth
      • 2B: What do we have?
        • Assessment for rationalisation: iteration-scope; as-is; to-be; gap-analysis for requirements
        • Implementation for rationalisation: solutions; projects; development and deployment; lessons-learned
      • 2C: Guide the process of change
        • Guiding compliance to architecture roadmap
    24. 2B: What do we have? [1]
      • Assessment phases (under architecture governance):
      • Phase A: define scope for rationalisation
        • typically defined by boundaries of Business System etc
      • Phase B: inventory the existing items in scope
        • develop an ‘as-is’ inventory of the respective items
      • Phase C: identify the required rationalisation
        • develop a ‘to-be’ inventory of the respective items
      • Phase D: establish gaps, change-requirements
        • identify requirements, risks and responsibilities
      • Note difference to TOGAF here – not centred on IT
    25. 2B: What do we have? [2]
      • Implementation phases (under programme governance):
      • Phase E: outline required rationalisation action
        • guide handover of requirements to solution-architects
      • Phase F: assist detailed rationalisation-design
        • provide architectural guidance during detailed-design
      • Phase G: assist rationalisation implementation
        • provide architectural guidance during gateway review
      • Phase H: do rationalisation ‘lessons-learned’
        • benefits-realisation and lessons-learned
      • These phases remain similar to those in TOGAF 9
    26. 2C: Guide the process of change
      • Guiding compliance to architecture roadmap :
      • Assist in defining requirements for change
        • (equivalent to Phases A-D)
      • Assist in solution-architecture
        • (equivalent to Phase E)
      • Assist in detailed project-design
        • (equivalent to Phase F)
      • Review and advise in project implementation
        • (equivalent to Phase G)
      • Review ‘lessons-learned’ from project
        • (equivalent to Phase H)
    27. Step 3: Strategy and stuff
      • Emphasis: top-down
      • Examples : impact of strategy, change of regulation, service-design
      3A: Expand out from IT 3B: This goes with that 3C: Abstract-services 3D: Compliance and quality
    28. Step 3: Strategy and stuff
      • 3A: Expand outward from IT
        • The enterprise as whole - extending scope-awareness; including people and ‘things’ in the architecture
      • 3B: This goes with that
        • Strategy drives change; innovation invokes strategy
      • 3C: Abstract-services
        • Technologies and trade-offs; services in abstract; services for real
      • 3D: Compliance and quality
        • From value to quality; pervasive-services; develop awareness; develop capability; verify and audit
    29. Step 4: Work with the real world
      • Emphasis: bottom-up
      • Examples : disaster-recovery, risk-assessment, run-time load-balancing
      4A: Design for service flexibility 4B: Plan for business-continuity 4C: From qualities to values
    30. Step 4: Work with the real world
      • 4A: Design for service flexibility
        • Design for escalation; the service of escalation
        • Design for resilience; the services balancing-act
      • 4B: Plan for business-continuity
        • The impact of disaster; impact from the bottom up; the impact dashboard
        • Fail-safe and safe-fail; design for failure
      • 4C: From qualities to values
        • Quality in practice; connecting to quality
    31. Step 5: Pull it all together
      • Emphasis: ‘spiral-out’
      • Examples : data-quality, service-management planning, business ‘pain-points’
      5A: The service-oriented enterprise 5B: Dealing with ‘wicked problems’ 5C: Enhancing enterprise effectiveness
    32. Step 5: Pull it all together
      • 5A: Service-oriented enterprise
        • Everything is a service; interdependencies of service
        • Being of service; responsibility, capability as services
      • 5B: Deal with ‘wicked problems’
        • Tame-problems and wicked-problems
          • technical complexity interacts with social complexity
        • Identifying ‘wickedness’; resolving wicked-problems
      • 5C: Enhance effectiveness
        • Enhancing effectiveness
          • keywords : efficient, reliable, elegant, appropriate, integrated
        • Reviewing effectiveness, enhancing agility
    33. Beyond level 5: What next?
      • Emphasis: integration
      • Examples : architecture as an enterprise-wide responsibility
      XA: Hands-off architecture XB: Architecture as relevance
    34. Beyond level 5: What next?
      • XA: Hands-off architecture
        • Preparation for hands-off architecture
        • Project-gateway notification and response
        • Project-completion review
      • XB: Architecture as relevance
        • Conferences
        • Communities of practice
        • Communication
    35. Summary: Doing whole-enterprise EA
      • Adapted TOGAF-ADM for whole-enterprise EA
        • restructure of Phases A-D to resolve IT-centrism
      • Extended-Zachman as base-framework for EA
        • complete coverage of full whole-of-enterprise scope
      • Agile-style model permits rapid return-on-effort
        • consistent for all architecture-iteration timescales
      • TOGAF maturity-model as ‘stepping-stones’
        • gives graded plan for whole-enterprise architecture
      • Proven in real-world practice in and beyond IT
        • logistics, utilities, government, telco etc
    36. Stepping-stones of enterprise architecture
      • Any questions?
      • (or answers, perhaps?)
      • Thank you!
    37. Resources: “ Tetradian Enterprise Architecture” series
      • Books on enterprise-architecture by Tom Graves:
      • Real Enterprise Architecture : beyond IT to the whole enterprise
      • Bridging the Silos : enterprise architecture for IT-architects
      • SEMPER and SCORE : enhancing enterprise effectiveness
      • Power and Response-ability : the human side of systems
      • The Service Oriented Enterprise : enterprise architecture and viable systems
      • Doing Enterprise Architecture : process and practice in the real enterprise
      • See tetradianbooks.com for more details.

    + Tetradian ConsultingTetradian Consulting, 5 months ago

    custom

    846 views, 2 favs, 2 embeds more stats

    What do we do when we’re doing enterprise archite more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 846
      • 835 on SlideShare
      • 11 from embeds
    • Comments 0
    • Favorites 2
    • Downloads 124
    Most viewed embeds
    • 7 views on http://www.pljansen.info
    • 4 views on http://weblog.tomgraves.org

    more

    All embeds
    • 7 views on http://www.pljansen.info
    • 4 views on http://weblog.tomgraves.org

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    more
    -->
    Search
    RSS Feed
    What's new?

    © 2009 SlideShare Inc. All Rights Reserved