• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Using TOGAF beyond IT
 

Using TOGAF beyond IT

on

  • 7,027 views

Describes amendments to the TOGAF Architecture Development Method (ADM) to extend its scope and capability from its usual IT-architecture to a true whole-of-enterprise architecture. (Download and ...

Describes amendments to the TOGAF Architecture Development Method (ADM) to extend its scope and capability from its usual IT-architecture to a true whole-of-enterprise architecture. (Download and display in 'Notes' view to see the full script.)
Presented at Open Group Enterprise Architecture Practitioners Conference, Hong Kong, October 2009; (c) 2009 Tetradian Consulting 2009.

Statistics

Views

Total Views
7,027
Views on SlideShare
6,891
Embed Views
136

Actions

Likes
7
Downloads
686
Comments
3

9 Embeds 136

http://weblog.tetradian.com 52
http://weblog.tomgraves.org 39
http://www.slideshare.net 33
http://weblog.tomgraves.eu 5
http://confluence.ekor.no 3
http://www.health.medicbd.com 1
http://www.mefeedia.com 1
http://www.linkedin.com 1
https://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

13 of 3 previous next Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Thanks Tom -- good food for the thoughts.

    Thanks,
    AS
    Are you sure you want to
    Your message goes here
    Processing…
  • My apologies, there’s only so much that I can fit into a single 30-slide presentation! This purpose here was to focus solely on amendments to the ADM to make it more usable at the whole-of-enterprise scope, but there wasn’t room to go into your important question in more depth. There’s somewhat more detail in the script (download and show in Powerpoint’s ’Notes’ view), but probably not enough for your need above.

    For a quick summary of the more detailed answer:

    - each of the row/column/segment cells represent primitives

    - almost all real-world entities are composites (i.e. straddling cell/segment borders) within a single row

    - in some (many?) cases, some types of composites may be treated as somewhat like primitives at ’higher’ levels of abstraction (e.g. composites of services and/or processes may be viewed as ’business functions’)

    - as a primitive, a ’function’ is a place where something where something may be changed, with inputs, outputs and controls (e.g. ’function’ in the mathematical sense)

    - to be actioned, a function must be combined as a composite with a capability to form a service

    - a capability is typically either embedded in an asset (e.g. physical machine, virtual software) and/or enacted via an asset (e.g. relational link to real person - people as such are *not* assets, but the relational links with those people are valid assets)

    - a service exposes its interfaces to the ’outside world’

    - a process is a choreographed sequence of transactions/interactions with services

    More detail at http://tetradianbooks.com/2008/12/silos-frame-ref/ ; see also http://tetradianbooks.com/2008/10/silos-method-ref/ for more detail on the suggested amendments to the ADM.

    Many thanks, and hope this helps.
    - tom g.
    Are you sure you want to
    Your message goes here
    Processing…
  • Should you say more (or more explicit) about processes on the slide 24 as you want to go enterprise-wide? Is your 'composite' == 'process' (an explicit way to provide relationships between different primitives)?

    Thanks,
    AS
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Tetradian Consulting Unit 215, Communications House, 9 St Johns Street, Colchester, Essex CO2 7NN, England www.tetradian.com / info@tetradian.com / Twitter: @tetradian White Knight Management PO Box 521, Isleworth, London, TW7 4YY, England www.greenhornconsulting.com / i nfo@greenhornconsulting.com © Tom Graves / Tetradian 2009
  • We all know TOGAF and its Architecture Development Method (ADM). It’s long-proven for use in IT-architecture and business / IT alignment. But the enterprise is much more than its IT, and as the Open Group’s Len Fehskens put it, “An increasing number of enterprise architects believe that the rest of the enterprise, often generically referred to as ‘the business’, should be architected as well.” But TOGAF was and still is mostly designed for IT-architecture. How do we re-use it beyond IT?
  • The current design of TOGAF is a natural fit for those enterprises that revolve around information and standardised, automatable business-transactions. Hence banking, for example; insurance; finance; some aspects of government. But other industries may have a different focus. In telecoms or manufacturing, ‘technology’ has a much broader meaning than just IT. Other industries or enterprises focus more on people, or physical ‘things’. In those cases, IT is just one amongst many other ‘enablers’ in the background – important, but no more important than anything else. On average, across all industries, IT represents about 2-4% of revenue. In most cases, it is not, and should not be, the sole centre of business attention. So if we are the ‘architect’ the enterprise, we need to be thinking a lot wider than just IT.
  • The simplest way to describe the role of EA is that it’s a body of knowledge about enterprise structure and purpose - in the broadest sense of those terms. It’s about decision-support for others, particularly strategy and the PMO. The aim is to enhance the overall effectiveness of the enterprise. Since this architecture needs to be about the whole of the enterprise, we need a framework and method that we can use in a consistent way for any architecture need in the enterprise.
  • As we’ll see in a moment, the current version of the ADM won’t cover the whole enterprise. To make it work, something will have to change. The simpler option is to tweak the roles and coverage Phases B, C and D – Business Architecture, Information-Systems Architecture and Technology-Infrastructure Architecture. The catch is that whilst this does expand the scope, it doesn’t overcome some of the other limitations of the current ADM, about the kinds of architectural issues we can address. To resolve those limitations, we’ll need a more serious re-think about what the ADM does, how it works, and how we use it in practice. One of the most important concerns, for example, is that we need a method that’s consistent for every use and purpose, regardless of scope or scale.
  • But the key point here is that everything that we need for these expansions already exists in the TOGAF 9 specification . We may need to tweak some of it a bit – in particular, we’ll need always to remember to think outside of the IT-only box. But we don’t need to invent a whole new framework and method: everything we need is already there.
  • So let’s look at the easier version first. The main point here is to lift up our sights a bit, and remember that there’s a whole world out there beyond IT.
  • TOGAF 9 tells us that there are four ‘architectures’: business architecture, data architecture, applications architecture and technology architecture. To be blunt, TOGAF’s ‘Business Architecture’ is not a proper business-architecture at all. In essence it’s a random grab-bag for ‘everything not-IT that might impact on IT’, which means that one Phase has to cover perhaps 97% of the enterprise, with high-level strategy all jumbled up with low-level process and everything in between. No wonder that IT’s relations with the rest of the business tend to be so fraught. Before we can use TOGAF for real enterprise architecture, we’ll need to tease out that tangle into a proper order.
  • This image gives us a better idea of the real scope we need in enterprise architecture. It also shows us why IT-centric architecture can be such a problem: it only covers a small part of what’s really needed, but pretends that it’s everything. IT doesn’t even cover the whole of information, because there’s also all the people-based ‘tacit’ information, for example, which is central to knowledge-management. So we need the architecture to be able to cover the whole enterprise – not just the IT.
  • This gives us a Zachman-like grid: a big-picture view which is mostly about business-purpose; and below it, a more explicit focus on people, information and/or physical ‘things’. These we need to split between a ‘logical’ view, which deals with common themes across all implementations; and a ‘physical’ view, which deals with the specific needs of each implementation. So to do a cross-enterprise optimisation of architecture, or to tackle the architectural issues of top-down strategy, we’ll need three distinct architectural assessments: big-picture, the common connections, and the design detail. This also aligns well with service-oriented architecture, especially if we extend the concept of ‘services’ across the whole enterprise.
  • The simplest way to extend TOGAF is to change the labels and focus of Phases B, C and D: - We use Phase A to identify the scope for the architectural issue, using an expanded version of Zachman – more about that later. - ‘Business architecture’ is ‘the business of the business’: strategy, direction, vision, mission, the big-picture overview. So use Phase B to explore the big-picture impact of the architectural issue in scope. - TOGAF’s ‘Information-system architecture’ is about how everything links together – particularly at the ‘logical’ level. So use Phase C to explore what’s common to all implementations here, and the connections – service-interfaces, for example – that would apply across the scope and for all implementations in that scope. TOGAF’s ‘Information-infrastructure architecture’ is a detailed plan for how one specific type of ‘enabler’ is implemented. So use Phase D to describe detail-level concerns for the issue in scope. Viewed this way, it’s clear that TOGAF’s emphasis on IT is just one possible use of this general-purpose pattern.
  • This is one ‘stack’ we’ve found useful for an intermediate view: still mostly about IT, but much more strongly anchored in business needs. Each of these layers actually has its own big-picture, common and detail-level components. We might well do a sequence of architecture iterations, working our way down (or up) the layers, with a distinct Big-picture, Common and Detail assessment for each, and linking each to the next via Phase H and the subsequent Phase A.
  • The business operating model describes how the enterprise delivers value (in any sense of ‘value’). Resources, assets and information may all be in any form – physical, virtual or relational. These are ‘pulled’ into enterprise processes that will either add value, consume them in adding value, mould them to create value for the enterprise itself, or use them to maintain quality and overall ‘hygiene’. The results are then ‘pushed’ out to clients in the outer world, either ‘public’ (such as B2C) or ‘private’ (B2C). The architecture needs to describe all of this in a consistent way – not solely the parts where IT-based information is used. This simple amendment to TOGAF’s Phases B to D allows us to do this.
  • So, a quick summary of what expanding TOGAF’s scope requires, and allows us to do.
  • But if we really want to make TOGAF usable at the whole-of-enterprise scope, we need to do a few more changes. Some of these are quite radical, but they are still ‘legal’ within terms of the TOGAF 9 specification.
  • There’ve been various attempts to create a more versatile architecture-method than the ADM. This one’s from Oracle, released just a few days ago. In practice, though, they rarely offer much that’s new, and most – as in this case – remain too IT-centric for whole-of-enterprise use. We would probably be better off if we re-use what we already have in TOGAF.
  • One key here is the TOGAF Maturity Model, tucked away in Chapter 51 of the specification. It tells us what our architecture should look like at each of its five maturity-levels. But in practice we need to know what to do between those levels. These ‘stepping-stones’ tell us what we can and should do at each stage, to extend the maturity and capability of the architecture. They also build up a palette of capabilities, to tackle an increasing range of architectural concerns: overview first, then ‘horizontal’ clean-up, ‘top-down’ strategy, ‘bottom-up’ real-world impact and innovation, and finally able to use all of these in combination to ‘spiral-out’ from a chosen starting-point. This creates the ability to tackle the real business need: resolve the ‘pain-points’ and ‘wicked-problems’ embedded deep in the enterprise. That’s where we prove the real value of enterprise architecture.
  • But look at where the ADM actually sits, in terms of TOGAF’s own maturity-model. According to the spec, the main focus of a first ADM iteration is to clean up the IT space, defining a set of reference-models and the changes needed to get there. Subsequent ADM iterations provide blueprints for top-down strategic change. As can be seen, this is Step 2 and Step 3 – and again, for IT only. It doesn’t really tackle Step 1: that’s sort-of addressed in the Preliminary Phase, Phase A and Phase B, but not enough to satisfy most business-folks – hence endless problems about business-IT alignment. And it doesn’t deal with much if any of the Step 4 bottom-up issues. Which means we never get to Step 5 – which is where business will have always wanted us to be, right from the start.
  • Governance in the current ADM is also extremely messy – and made messier still by TOGAF 9’s approach to architecture iterations. The problem is that we have four fundamentally different scopes for architecture assessment, all with different stakeholders and standards. And we’re then supposed to do current-state, future-state and gap-analysis for each, in that order – which forces us into a top-down sequence. We then follow that with a single change-programme in Phases E-G, which is supposed to cover absolutely everything, all in one go. It’s no wonder that it all takes so long, and so fraught with difficulty.
  • Yet we can simplify this right down if we go back to a structure closer to TOGAF 7, and do just one scope at a time, with one set of stakeholders and standards. We define the scope in Phase A, which automatically also identifies the stakeholders, standards and so on. We then assess the architecture of that scope for chosen time-horizon – usually ‘to-be’, sometimes ‘as-is’. Then, if necessary, we do it again for one or more other time-horizons – the ‘as-is’ or ‘to-be’, or any intermediates. And we then do the gap-analysis and requirements-elicitation and the like, for this one scope. If there are any change-requirements, this leads to an optional change-programme, in Phases E-G, and the mandatory review in Phase H. This keeps everything simple – and fast.
  • The implementation phases remain much the same as in the existing TOGAF 9 – though again, they’re often much simpler, and much quicker. The only significant change is that Phase H includes extra activities that align it more strongly with other continuous-improvement methods such as Agile, TQM and Six Sigma: for example, we include specific sections on lessons-learned and benefits-realisation, to feed into the next cycle.
  • A key point is that all of this is fast : we’ve done proper architecture-iterations with this in as little as a couple of hours. We can of course use nesting of architecture iterations to do a classic TOGAF-style ‘big architecture’, but the point is that the governance remains consistent throughout. This then works for any architecture, of any scope, at any scale. The key to this is that the respective scope is now defined in Phase A – and it always arises from a defined business-question. This ensures that architecture is always driven by real business needs – and not by whatever hyped-up product the vendors currently want to sell!
  • We define the scope in terms of an adapted and extended version of another old friend – the Zachman framework. This kind of framework is the architecture equivalent of chemistry’s Periodic Table of Elements – the foundation for the core metamodel that underlies the entire enterprise architecture. Zachman’s rows or layers mostly work well enough as-is, not least because they describe different groups of stakeholders with different responsibilities in the enterprise. However, the columns do need a significant re-think, not least because there’s an entire dimension missing from the model.
  • Zachman’s point is that the elements or ‘primitives’ exist within a cell, composites straddle across cells: “Primitives guide architecture; composites guide solutions”. We need primitives that cover the full enterprise scope. Unfortunately, Zachman’s original What, How, Where, Who, When and Why don’t actually work well in practice, especially outside of IT. The emphases for each column need to change somewhat, for integrity and consistency in modelling and metamodelling, and also to align better with BPMN and other cross-enterprise needs. Composites are also patterns . A ‘complete’ composite crosses all columns, and must be complete at the ‘Operations’ layer (row-6). A useful cue is that a composite is usable to the extent that it is complete; but it’s re-usable, as a pattern, to the extent that it is not complete.
  • More important is that Zachman is missing an entire dimension, which we can label as ‘segments’: physical ‘things’ such as servers, physical locations, events virtual data, virtual locations, signals and message-events relational links to people, social-network locations, sales-lifecycle events aspirational keys such as brand, morale, reputation and the enterprise itself and abstracts such as time and money These ‘segment’ distinctions often aren’t critical in the upper layers, but they do matter as we move down towards the real world. This provides the base-skeleton for a ‘holograph’ of the enterprise. We add more detail and depth with each architecture iteration. We identify architectural scope in terms of this framework in the Phase A of each iteration.
  • This combined restructure also sorts out another governance-problem in TOGAF 9: its architecture cycle demands a near-infinity of stakeholder-reviews. In this split, the reviews occur only at phase-boundaries – in fact they are the phase-boundaries. As mentioned before, this cycle can be used at any timescale: the classic TOGAF cycle takes a couple of years, but some of our clients’ architecture cycles might be no more than a couple of hours. The structure is also recursive, such that cycles can be nested within cycles within cycles, and so on – still with the same consistent governance. It’s simpler than the existing ADM; it fits well with an iterative approach; and also fits well with ‘product’-based governance such as in ITIL and PRINCE2.
  • The TOGAF 9 cycle is held together by a shared repository labelled ‘Requirements Management’. But there’s a lot more that needs to be held in that central repository: it should also include all the architecture models, standards, blueprints, project-plans, governance records, risks, opportunities and other issues, the common glossary and thesaurus, and anything else that needs to be shared across the enterprise to support its overall architecture. Governance of this is not going to be simple; likewise security-management and so on. But the more of it that can be shared across the enterprise, the better the results will be – especially in the longer term.
  • So, finally, a quick summary of what extending TOGAF’s capability requires, and allows us to do.
  • And, to recap, we’ve used a two-step expansion of TOGAF to extend its capabilities beyond IT. The first step allows us to extend the scope that still retains the familiar B-C-D structure, but is still somewhat limited by the legacy of TOGAF’s IT-centric assumptions. The second step is more radical, asking us to restructure Phases A-D, but breaks us free of those limitations. The sheer scale of the enterprise-as-a-whole means that we must use an iterative, Agile approach – and this brings faster return-on-effort, too. This re-use of TOGAF and its maturity-model provides a structured ‘stepping-stones’ approach – overview and focus, horizontal, top-down, bottom-up, spiral-out - to develop architectures for any domain, any scope, at any scale, and in any type of industry.

Using TOGAF beyond IT Using TOGAF beyond IT Presentation Transcript

  • Using TOGAF beyond IT Tom Graves , Tetradian Consulting in association with White Knight Management TOGAF Hong Kong, October 2009 info@tetradian.com / www.tetradian.com 22 Oct 2009 (c) Tom Graves / Tetradian 2009
  • The TOGAF ADM: an old friend...
    • Designed for IT-architecture
    • Focus is business/IT alignment
    22 Oct 2009 (c) Tom Graves / Tetradian 2009
    • BUT...
    • Increasing consensus that EA is more than IT
    • EA as ‘the architecture of the enterprise’
    • SO...
    • How do we use TOGAF beyond IT?
  • Enterprise-architecture beyond IT
    • Some examples where EA must extend beyond IT:
    • Telecoms
      • emphasis on market; technology is more than IT
    • Logistics
      • emphasis on ‘things’; manual/machine-based processes
    • Engineering research
      • emphasis on interpretation; long info lifecycles (20yrs+)
    • Government social-services
      • emphasis on people (IT as background-support only); very long info lifecycles; narrative knowledge
    • Ultimately, every enterprise extends beyond IT
    22 Oct 2009 (c) Tom Graves / Tetradian 2009
  • The purpose, and the aim...
    • -- THE BUSINESS ROLE OF ENTERPRISE ARCHITECTURE --
    • 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
    • -- A PRACTICAL AIM --
    • Make TOGAF and ADM usable for architecture at any scope, any complexity, any duration, in any and every part of the enterprise
    22 Oct 2009 (c) Tom Graves / Tetradian 2009
  • Two levels of extension...
    • Part 1: Expand the scope
    • requires only minor refocus of Phases B, C, D
    • no structural change to ADM
      • limitation : like TOGAF 9, can only handle a subset of architecture needs
    • Part 2: Extend the capability
    • includes iterations and their governance
    • consistent at every scope and level
    • does require restructure of ADM Phases A-D
    22 Oct 2009 (c) Tom Graves / Tetradian 2009
  • All needed is already in TOGAF 9...
    • Required TOGAF sections include:
    • Architecture Development Method (Chs 6-17)
    • Adapting the ADM (Ch 5.3)
    • Applying the ADM at different enterprise levels (Ch 20)
    • Capability-based planning (Ch 32)
    • Architecture maturity models (Ch 51)
    • Applying iteration to the ADM (Ch 19)
    • Architecture governance (Ch 50)
    • ...though we may need to use some in new ways
    22 Oct 2009 (c) Tom Graves / Tetradian 2009
  • Part 1: Expand the scope 22 Oct 2009 (c) Tom Graves / Tetradian 2009
  • An unfortunate kludge...
    • Classic scope of IT-based ‘enterprise architecture’
    22 Oct 2009 (c) Tom Graves / Tetradian 2009 IT (3% of enterprise) Everything not-IT ? (97% of enterprise)
  • Scope of IT in enterprise context
    • Whole-of-enterprise scope
    22 Oct 2009 (c) Tom Graves / Tetradian 2009 IT is only a small subset (not even all of Information)
      • three layers: Business, Integration (Common), Detail
      • three columns: People, Information, physical ‘Things’
  • Scope of enterprise architecture
    • Big-picture: vision, strategy, overview, ‘business of business’
    • Common: interfaces etc common to all implementations
    • Detail: implementation-specific, context-specific
    • Aligns well with service-oriented architecture for the whole enterprise
    22 Oct 2009 (c) Tom Graves / Tetradian 2009 B ig-picture / Business Zachman rows 0-2 C ommon / Connection Zachman rows 2-3 D esign / Detail Zachman rows 4-6 [People] [Things] [Information]
  • A simple extension of scope...
    • Change the labels / focus for Phases B, C, D
    22 Oct 2009 (c) Tom Graves / Tetradian 2009 Phase B B ig-picture / Business Phase C C ommon / Connection Phase D D esign / Detail
  • A richer architectural ‘stack’ 22 Oct 2009 (c) Tom Graves / Tetradian 2009 Adapted from S-EA-T (www.s-ea-t.com) free enterprise-architecture toolset Use extended scope to develop a more business-oriented view of the usual IT ‘stack’ of architectures Identify features common to all implementations – IT-based, manual, machine-based etc
  • Example: Business Operating Model 22 Oct 2009 (c) Tom Graves / Tetradian 2009 Screenshot from free S-EA-T toolset (www.s-ea-t.com)
  • Expand the scope - summary
    • Problem:
    • TOGAF Phases B-D too IT-centric for whole-EA
    • Solution :
    • refocus Phase B as ‘Big-picture’ (Zachman 0-2)
    • refocus Phase C as ‘Common’ (Zachman 2-4)
    • refocus Phase D as ‘Detail’ (Zachman 4-6)
    • shift to stronger business-orientation
    • may assess information, people, ‘things’ etc
    • requires no structural change to ADM
    22 Oct 2009 (c) Tom Graves / Tetradian 2009
  • Part 2: Extend the capability 22 Oct 2009 (c) Tom Graves / Tetradian 2009
  • Need for a more generic process
    • Various attempts made to create a more generic framework
      • most are still IT-centric
      • example here is from Oracle Enterprise Architecture Framework
    • Would be better to re-use what we already have in TOGAF 9
    22 Oct 2009 (c) Tom Graves / Tetradian 2009 (http://www.oracle.com/technology/architect/entarch/pdf/oadp_whitepaper.pdf)
  • Use the TOGAF maturity-model 22 Oct 2009 (c) Tom Graves / Tetradian 2009
  • TOGAF scope in maturity-model 22 Oct 2009 (c) Tom Graves / Tetradian 2009 Main emphasis of TOGAF, for IT-architecture only
  • TOGAF assumes top-down sequence 22 Oct 2009 (c) Tom Graves / Tetradian 2009 ...this can easily become a governance nightmare...
    • Phases B-D each include:
      • predefined scope(s)
      • ‘ as-is’architecture
      • ‘ to-be’ architecture
      • gap-analysis
    Preliminary Phase is a special type of cycle, with its own specific governance etc
  • Adapt to support any scope 22 Oct 2009 (c) Tom Graves / Tetradian 2008 A: Define scope for iteration
    • B: Assess for key time-horizon
      • usually ‘to-be’
    • D: Conduct gap-analysis
      • derive change-requirements
    • C: Assess for comparison time
      • usually ‘as-is’ or transition
    Preliminary Phase becomes just another scope, another iteration of the same overall cycle
  • Implementation largely unchanged 22 Oct 2009 (c) Tom Graves / Tetradian 2008
    • Phases E-G much as per standard
      • may not always be required
        • (i.e. optional for assessment-only)
      • different stakeholders each phase
        • E: solution-architects
        • F: planners / designers
        • G: implementers / program mgrs
      • may act on any domain(s)
        • not just for IT-based projects!
    • Phase H expands its role
      • includes lessons-learned, benefits-realisation etc for continuous-improvement
  • Process and governance
    • Use ADM in iterative Agile style for rapid ROI
      • business will not wait 2+ years before any returns!
    • Every iteration begins from a business-question
      • all EA anchored to business drivers, business needs
    • Duration / budget implied by business-question
      • also indicates likely scale of change for Phases E-G
    • Scope is identified / defined in Phase A
      • indicates stakeholders / governance for the iteration
      • indicates models etc needed in Phases B-D
      • indicates success-criteria to be used in Phase H review
    22 Oct 2009 (c) Tom Graves / Tetradian 2009
  • Adapt Zachman to describe scope 22 Oct 2009 (c) Tom Graves / Tetradian 2009 Zachman rows work well enough as-is Zachman columns need significant rethink to break free of IT-centrism
  • Base-framework columns
    • Columns need restructure to support whole-EA
    22 Oct 2009 (c) Tom Graves / Tetradian 2009 At Operations level, we should be able to describe every service as: -- this is an ‘architecturally complete’ pattern or composite
  • Base-framework segments 22 Oct 2009 (c) Tom Graves / Tetradian 2009 Needs dimension of ‘segments’ within columns
  • Methods – governance for Agile EA 22 Oct 2009 (c) Tom Graves / Tetradian 2009 Statement of Architecture Work (for iteration) Stakeholder review for primary architecture Stakeholder review for comparison architecture Gap-analysis / requirements review Solution design review Project plan review Project architecture compliance review Benefits realisation (‘lessons learned’ etc) Architecture Charter Governance-artefacts define methodology’s phase-boundaries
  • That bit in the middle...
    • All Phases / tasks share common set of repositories
      • contain shared ‘products’ of architecture work
      • enables PRINCE2-style governance by ‘products’
    • ‘ Products’ 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
    22 Oct 2009 (c) Tom Graves / Tetradian 2009
  • Extending the capability - summary
    • Problem:
    • TOGAF imposes limits on assessment-capability
    • TOGAF governance too inconsistent for Agile
    • Solution :
    • use time-horizons etc as focus for Phases B-D
    • use expanded Zachman as frame for scope etc
    • define scope for iteration in Phase A
    • allow iterations to nest as required
    • address any architecture, any scope, any scale
    22 Oct 2009 (c) Tom Graves / Tetradian 2009
  • Using TOGAF for 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
    22 Oct 2009 (c) Tom Graves / Tetradian 2009
  • Some suggested resources
    • Books by Tom Graves ( www.tetradianbooks.com ) :
    • Real Enterprise Architecture : beyond IT to the whole enterprise
    • Bridging the Silos : enterprise architecture for IT-architects
    • The Service Oriented Enterprise : enterprise architecture and viable systems
    • Doing Enterprise Architecture : process and practice in the real enterprise
    • SEMPER and SCORE : enhancing enterprise effectiveness
    • Power and Response-ability : the human side of systems
    • Books by other authors:
    • Lost in Translation (Nigel Green et al) ( www.LIThandbook.com )
      • introduces ‘VPEC-T’ – a path to improved communication between business and IT
    • Enterprise Architecture as Strategy (Ross, Weill et al)
      • describes business-oriented role for enterprise architecture
    • Business Model Generation (Osterwalder et al) ( www.businessmodelgeneration.com )
      • describes systematic TOGAF-compatible process to model business drivers etc
    • Simple Enterprise Architecture Toolset ( www.s-ea-t.com )
      • free entry-level toolset for business-oriented enterprise architecture [coming soon]
    22 Oct 2009 (c) Tom Graves / Tetradian 2009