Doing enterprise architecture - Leanpubsamples.leanpub.com/tb-doingea-sample.pdf · 2014. 2. 8. · England h p:// FirstpublishedApril2009 ISBN978-1-906681-18-0(paperba ) ... plant

Doing enterprisearchitecture

Process and practice in the realenterprise

©2012 Tom Graves

Last published on 2012-03-15

is is a Leanpub book, for sale at:

http://leanpub.com/tb-doingea

Leanpub helps authors to self-publish in-progress ebooks.We call this idea Lean Publishing. To learn more aboutLean Publishing, go to: http://leanpub.com/manifesto

To learn more about Leanpub, go to: http://leanpub.com

http://leanpub.com/tb-doingea

http://leanpub.com/manifesto

http://leanpub.com

Contents

Book contents 1

Introduction 3

Doing enterprise aritecture . . . . . . . . . . 3

Who should read this book? . . . . . . . . . . . 4

What’s in this book? . . . . . . . . . . . . . . . 5

Preparing for aritecture 9

Purpose – strategy . . . . . . . . . . . . . . . . 14

People – governance . . . . . . . . . . . . . . . 18

Planning – frameworks . . . . . . . . . . . . . 24

Practice – methods . . . . . . . . . . . . . . . . 37

Performance – metrics . . . . . . . . . . . . . . 47

A matter of maturity 56

Step 1: Know your business 59

Vision, values, principles and purpose . . . . . . 64

e enterprise context . . . . . . . . . . . . . . 78

Functions and services . . . . . . . . . . . . . . 92

Aritecture governance . . . . . . . . . . . . . 108

i

CONTENTS ii

Appendix: Glossary 126

CONTENTS i

Doing enterprise aritectureProcess and practice in the real enterprise

Tom GravesTetradian Consulting

Published by

Tetradian BooksUnit 215, Communications House9 St Johns Street, Colester, Essex CO2 7NNEngland

hp://www.tetradianbooks.com

First published April 2009

ISBN 978-1-906681-18-0 (paperba) ISBN 978-1-906681-19-7 (e-book)

© Tom Graves 2009

e right of Tom Graves to be identified as author of thiswork has been asserted in accordance with the CopyrightDesigns and Patents Act 1988.

Anowledgements

Amongst others, the following people kindly providedcomments and feedba on the early dras of this book:Miael Ater (CH), Daljit Banger (GB), Stuart Curley (GB),Charles Edwards (GB), Geoff Ellio (GB), Nigel Green

CONTENTS ii

(GB), Bas van Gils (NL), Ziggy Jaworowski (AU), Alexan-der Lorke (GB), Graham McLeod (ZA), Bob MacDonald(AU), Helen Mills (AU), Jos van Oosten (NL), Kim Parker(AU), Liz Poraj-Wilczynska (GB), Erik Proper (NL), Marliesvan Steenbergen (NL), Kevin Smith (GB), Peter Tseglakof(AU), Jaco Vermeulen (GB).

Please note that, to preserve commercial and personalconfidentiality, the stories and examples in this book havebeen adapted, combined and in part fictionalised fromexperiences in a variety of contexts, and do not and arenot intended to represent any specific individual or organ-isation.

Trademarks or registered trademarks su as Zaman,TOGAF, FEAF, ITIL, DyA etc are anowledged as theintellectual property of the respective owners.

Book contentse complete contents of the book are as follows - aptersincluded in this sample are shown in italics:

• Introduction

• Preparing for aritecture

• Purpose – strategy

• People – governance

• Planning – frameworks

• Practice – methods

• Performance – metrics

• A maer of maturity

• Step 1: Know your business

• Vision, values, principles and purpose

• e enterprise context

• Functions and services

• Aritecture governance

• Step 2: Clean up the mess

• Business-systems and information-systems

1

Book contents 2

• What do we have?

• Guiding the process of ange

• Step 3: Strategy and stuff

• Expand outward from IT

• is goes with that

• Abstract-services

• Compliance and quality

• Step 4: Work with the real world

• Designing for service flexibility

• From qualities to values

• Step 5: Powering on

• e service-oriented enterprise

• Dealing with ‘wied problems’

• Enhancing enterprise effectiveness

• What next?

• Hands-off aritecture

• Aritecture as relevance

• Glossary

Introduction

Doing enterprise architecture

Enterprise aritecture is a relatively new discipline, thoughone that is rapidly becoming more important in business,especially in large multi-partner enterprises. But whatdo enterprise aritects actually do? And what kind ofbusiness value can be assigned to the results of that work?To put it in the baldest business terms, what’s the return oninvestment?

Enterprise aritects manage a body of knowledge aboutenterprise structure and purpose. ere are a fair few booksavailable now about the principles and even some of theoverall practices. (You’ll find a selection of books and otherkey references on this listed in the Resources section at theend of this apter.) But in most cases, that’s about as faras they go. What this book does instead is focus on what isdone in practice, in what order, andwhy it is done – the realbusiness concerns that need to be addressed at ea level ofaritecture maturity.

At present, enterprise aritecture is oen described solelyas an aspect of IT, responsible for improving ‘business/ITalignment’. But in practice, it can, and should, cover amu broader scope than just IT. Although it will oenstart out from there, it should eventually encompass thearitecture of the entire enterprise. So the examplesshown here are drawn not only from the usual information-

3

Introduction 4

centric industries su as finance, banking, insurance andthe like, but also other industries in whi IT is merelyone of many different ‘enablers’ – su as in telecoms,logistics, utilities, manufacturing, government and muelse besides.

Enterprise-aritecture is a strategic skill that can be of realvalue to every enterprise, regardless of its size, its type, itsindustry or context. e same principles apply as mu toa theatre, an engineering works, a retail floor, a emicalplant or a bank: it really doesn’t maer. And in someaspects of enterprise aritecture there may be no IT at all:as one commentator put it, an enterprise has an aritectureeven if it doesn’t have electricity.

Whatever your enterprise, this book will show you what todo, when and how and why, to make it all work in practice.

Who should read this book?

is book is intended for enterprise aritects, strategistsand any others tasked with understanding the enterpriseas a whole; and for programme and portfolio managers andothers who guide theanges to business practice that arisefrom that work.

Enterprise-aritecture provides a ‘big-picture’ overviewthat outlines the business context for other aritecturedisciplines: so this book would also be useful for businessaritects, process aritects, security aritects, solutionaritects, soware aritects and the like.

Introduction 5

And executives, service-managers, process-managers andmany others may find this book valuable as a guide to whatenterprise aritects do, and why they do what they do, insupport of the overall enterprise.

What’s in this book?

ere are three main parts to this book. e first deals withwhat’s involved in seing up the aritecture capability,and geing down to work – see apter Preparing foraritecture. Next, we explore the typical kinds of work,and the business concerns they ea address, at ea stageof enterprise-aritecture maturity – see apter A maerof maturity. Finally, we’ll explore what you’d do to keepon enhancing the depth and riness and value of thearitecture capability and its artefacts – see apterWhatnext?.

Ea section includes lists of questions to guide the work.ese lists are fairly comprehensive, but obviously cannotcover everything – given the vast range of possible circum-stances in whi they may be used – and in some casesthe questions themselves must necessarily be somewhatgeneric. So whilst you should find all the essentials here, doexpect to do some translation and adaptation to suit yourown specific context.

What’s not in this book? In essence, anything that iscontext-specific, or is easily available elsewhere. For ex-ample, you’ll need a suitable aritecture-development

Introduction 6

method: for that, you might turn to the current de factostandard, TOGAFâ�˘ Version 9 – all 780 pages of it, forwhi obviously there’s no point in repeating here.

Since TOGAF is designed only for enterpriseIT-aritecture, you may want to supplementit with Bridging the Silos: enterprise ari-tecture for IT-aritects, another book in thisseries, whi shows how to adapt TOGAF tothe real whole-of-enterprise scope.

You’ll need a suitable reference-framework, or set of frame-works – though these should be osen from examples tai-lored to your specific industry, su as eTOM for telecoms,SCOR for logistics or FEAF PRM for government. Andyou’ll need some kind of formal governance-framework, toguide aritecture development and its relationship withange-management: but again, this is described in partin the TOGAF specification, and will need to be linked towhatever teniques you already use to govern enterpriseange. e same applies to metrics, to detailed definitionsof skillsets, and so on: the extra information you’ll needthere will depend on your context, but you should be ableto find that easily enough from your industry’s existingsources.

is book deals with the one specific practical concern:what do you do when doing enterprise aritecture? Ouraim has been to keep this book to a practical size that youcan keep beside you as you work. So to that end, there are

Introduction 7

plenty of cross-references in the Resources sections at theend of ea apter: use them to fill in any gaps and keepyou on tra for your own business context.

Resources

The Tetradian Enterprise ArchitectureSeries

• Tom Graves, Real Enterprise Aritecture: beyond ITto the whole enterprise (Tetradian, 2008) – describesa high-level framework and method for whole-of-enterprise aritecture

• Tom Graves, Bridging the Silos: enterprise aritec-ture for IT-aritects (Tetradian, 2008) – describeshow to adapt and extend IT-aritecture de factostandards su as Zaman, TOGAF, FEAF, ITIL andPRINCE2 for use at a whole-of-enterprise scope

• Tom Graves, SEMPER and SCORE: enhancing en-terprise effectiveness (Tetradian, 2008) – describesa suite of tools and teniques to enhance enter-prise effectiveness, su as the SCORE extension toSWOT strategy-assessment, and the SEMPER diag-nostic and metric for enterprise effectiveness

• TomGraves, Power and Response-ability: the humanside of systems (Tetradian, 2008) – describes thebusiness implications of the diotomy that whilstthe physics definition of power is ‘the ability to do

Introduction 8

work’, most social definitions are closer to the abilityto avoid it

• Tom Graves, e Service Oriented Enterprise: en-terprise aritecture and viable systems (Tetradian,2009) – describes how to extend the principle ofservice-oriented aritecture to the design and struc-ture of the entire enterprise

Other resources

• e Open Group, TOGAFâ�˘ Version 9 (Van Haren,2009)

• Online version of TOGAF 9: seewww.opengroup.org/aritecture/togaf9-doc/ar/¹

• FEAF (US Federal Enterprise Aritecture Frame-work): see www.gao.gov/special.pubs/eaguide.pdf²[PDF]

• Zaman framework: see www.zifa.com³

• ITIL (Information Tenology Infrastructure Library):see www.itil.org.uk⁴ and www.itil-officialsite.com ⁵

¹http://www.opengroup.org/architecture/togaf9-doc/arch/²http://www.gao.gov/special.pubs/eaguide.pdf³http://www.zifa.com⁴http://www.itil.org.uk⁵http://www.itil-officialsite.com

http://www.opengroup.org/architecture/togaf9-doc/arch/


http://www.gao.gov/special.pubs/eaguide.pdf

http://www.zifa.com

http://www.itil.org.uk

http://www.itil-officialsite.com



http://www.zifa.com

http://www.itil.org.uk


Preparing forarchitectureWhat is ‘enterprise aritecture’? It seems traditional tostart off a book of this kind with a set of definitions, buthere we’d perhaps be beer served by a more discursiveexploration, because it’s surprisingly hard to find anythingthat’s definite and definitive about any aspect of this disci-pline…

First, perhaps, the ‘aritecture’ part. Definitions fromthe soware industry, from the 1960s onward, tend toemphasise the need for structure, a consistent descriptionand consistent set of relationships. Elsewhere, especiallyfrom business-aritecture, there’s more of an emphasison business purpose, on devolving outward from strategy.Somewhere between the two, these need to meld into amutual balance, about where structure meets with purpose,and purpose is expressed in structure. Hence that earlierdescription:

• Enterprise aritects manage a body of knowl-edge about enterprise structure and purpose

‘Enterprise’ is perhaps harder to describe. e usual defi-nition is that it’s some kind of group who “coordinate theirfunctions and share information in support of a commonmission or set of related missions”. e cat is that ‘en-terprise’ is not the same as ‘organisation’ – or rather, that

9


a formal organisation su as a company or governmentdepartment is just one special case of an enterprise.

Hence perhaps the key distinction betweenbusiness aritecture and enterprise aritec-ture: the former would formulate their strate-gies and sulike from the organisation’s pointof view, whilst the laer must also look at leastone step above and pay detailed aention tothe common enterprise that is shared by allstakeholders.

So unlike business-aritects, who maintain focus on thestrategic concerns of the company, enterprise aritectsmust be able to work at any level, at any scope. Typically,they will deal more with overview than with detail, thoughearly-maturity enterprise-aritecture will oen hold afirm emphasis on the finer details of IT-system design.

In essence, though, it’s not just about improvements inIT-systems, or in the infamous and oen troublesome‘business/IT alignment’, but about creating a beer under-standing of how everything in the enterprise works witheverything else – IT, people, maines, strategies, tactics,processes, products, services, everything. And it’s not justabout improved efficiency, but improved effectiveness –‘efficient on purpose’.

So where does this all fit, in organisational terms? eshort answer is “it all depends”, because it’ll ange withthe nature of the enterprise, and usually with the level


of aritecture maturity. In the early stages it’ll oenbe included within a project, or be a project in its ownright; but as maturity develops, it’ll need to be set up asa continuing capability, oen acting as a bridge betweenstrategy on one side and ange-management on the other:

• strategy specifies requirements for ange;

• enterprise-aritecture identifies capabilities forange;

• ange-management guides ange in the enter-prise.

e common view of enterprise aritecture, as espousedin the major standards su as FEAF and TOGAF, is thatits role is to define the ‘future state’ of the structure ofthe organisation’s IT. Amazingly, that assertion managesto be misleading in almost every possible way: it’s not justabout the organisation, it’s not just about the IT, there isno ‘the’ – there’s always ‘an aritecture’, but never ‘thearitecture’ – and there is no su thing as a ‘future state’,because everything is anging dynamically, all the time.

• e world is not static: there is no state.

ose standard models then manage to compound theproblems by insisting on a ‘big-bang’ approa to ari-tecture development: we supposedly define ‘the futurearitecture for everything’ in one big project, and then


it’s finished forever. Whi simply does not work for a realenterprise aritecture: it’ll be hopelessly out of date beforewe’re even halfway through the process. It might sort-ofwork for a small subset of a tenology aritecture that’llbeanged anyway as soon as the nextmajor project comesalong, but there’s no way to make it work at the scale of awhole enterprise. We must think in terms of Agile, of aniterative approa to aritecture development, right fromthe start.

To be fair, TOGAF’s designers do insist thatits ADM (Aritecture Development Method)could and should be used in an iterative style.Unfortunately, as anyone who’s used it inpractice will soon discover, TOGAF’s prede-fined scope and structure will fight againstthis, every in of the way. In effect it’s aclassic Waterfall approa with various bits ofAgile vaguely graed on, but without strictAgile-style governance, and in a way whisomehow manages to combine the disadvan-tages of both without the advantages of either.And in my experience, the aempts to patthe problems in the recent TOGAF 9 upgradehave managed only to make it worse. Oh well.

ere are a few enterprise contexts for whia Waterfall approa to aritecture would berequired: it’s all but mandatory in a military


environment, for example. But for anythingelse, the sheer scale of the problems usuallymeans that we must use an Agile approa tomake it work: and we need to do that Agileproperly, too.

But there’s a cat here. Without aritecture, a frameworkof context in whi to place ea iteration, Agile is lilemore than an undisciplined messing-about: so it seemswe’d need an aritecture already in place before we cando Agile aritecture…

e way out of this dilemma is to eat: we invent anaritecture – almost anything that seems appropriate,really – to an act as an initial framework. (More on thatwhen we look at planning and frameworks) below.) Wethen refine that framework with ea subsequent iteration,steadily filling in more and more detail as we go.

What this is really about is a subtle shi in perspective. eclassic Waterfall approa is like a photograph: we don’tget the full picture – or, in this context, mu if any businessvalue – unless we can see the whole thing in one go. Ifwe cut up a photograph, ea small piece contains the fulldetail of that one area, but gives us no indication of how itfits in with anything else. So until the whole thing – thewhole aritecture – is in place, we’re stu.

By contrast, working with Agile is more like a holograph:we’re always dealing with the whole picture, right fromthe start. Everything, however small, is always connected


to everything else; and if we cut up a holograph, easmall piece always contains a sense of the whole as awhole – the detail will be less, but not the scope. So whenwe do this right, every project not only delivers its ownbusiness value, but also contributes to the business value ofeverything else – if we use the framework holographically.

And we do that by treating every iteration, whatever itsscope, in exactly the same way. Nothing can be considered‘special and different’: so for an Agile aritecture, theclassic IT-centric style of so-called ‘enterprise aritecture’,with its crass definition of ‘business aritecture’ as “ev-erything not-IT that might impact on IT”, would be aguaranteed recipe for failure. To make it work, we haveto dump the idea that IT is a special case that somehowmust be the centre of every enterprise aritecture. Instead,we need to view it as just one example amongst all of thebusiness’ enablers – a service to the business, not the otherway round! Whi might be a bit uncomfortable for someIT-aritects to accept, perhaps: but that’s just too bad,bluntly. e business always comes first.

Purpose – strategy

All activities in enterprise aritecture should begin andend with an explicit business purpose. From the businessperspective, aritecture is a strategic tool, to guide the im-plementation of business strategy: so strategy and purposemust always be at its core.


We need to remember, though, that strat-egy must always be driven by business need– not by IT hype! e fabled ‘IT/businessalignment’ – or, more oen, the la of it –is liered with countless examples of disas-trous aempts by consultants, vendors andeven IT staff to foist overblown ‘solutions’onto a justifiably unwilling business. BusinessProcess Re-engineering (BPR) is perhaps thebest known of these, but right now cloud-computing is shaping up nicely as the probablenext candidate for the ‘Expensive Failure Ofe Year Award’…

ere’s nothing wrong with BPR or cloud-computing as su: they can be very goodsolutions indeed, in the right contexts. Whereit all goes wrong is when the ‘solution’ comesbefore the strategy, or when it’s sold for thewrong reasons – su as the classic IT obses-sions with cost-cuing or ‘efficiency’ for itsown sake, without awareness of the broaderimplications or broader environment. A properly-thought-out, properly-explored strategy mustalways come before any suggestion of ‘solu-tions’: the business and its business-strategyalways come first.

e real driver for any strategy is enhanced effectiveness inthe context of continual ange. And efficiency is only one


of several interweaving strands of effectiveness:

• efficient – makes the best use of available resources

• reliable – can be relied upon to deliver the requiredresults

• elegant – supports the human factors in the context;also ‘elegant’ in the scientific sense, in that clarityand the like will support structural simplicity and re-use

• appropriate – supports and sustains the overall pur-pose of the enterprise

• integrated – everything is linked to and supports theintegration of the whole as whole

Strategically speaking, it’s essential to keep all these strandsin balance with ea other. If we pay too mu aentionto any one strand su as efficiency – especially if it’s atthe expense of the others – we end up with a structure andstrategy that might seem to perform well for a while, butis doomed for disaster further down the tra. And again,we’ll see all too many examples of this in the business pressor elsewhere. Whether the strategy is in response to a newopportunity, a ange in regulation, a new tenology or anew market, the same always applies: we’ll need to assessthe issue’s impact on thewhole of the enterprise, not just onsome selected subsection su as IT. Overall effectivenessmaers.


ere’s more on those effectiveness-themes intwo other books in this series, Real EnterpriseAritecture: beyond IT to the whole enterpriseand SEMPER & SCORE: enhancing enterpriseeffectiveness – more details on those in theResources section at the end of the apter.

e effective purpose of what we do in enterprise ar-itecture will necessarily ange at different levels ofaritecture maturity. For example, there’s lile point ineven trying to use aritecture to assist in strategy until wehave some idea of what business we’re in – seeapter Step1: Know your business) – or made a solid start on cleaningup the aos that will have arisen naturally from too manymergers and acquisitions, or from too many years withoutsome kind of framework to guide consistency in businesssystems – see apter Step 2: Clean up the mess).

More accurately, we don’t so mu ange what we doin aritecture as extend it. Ea maturity-level builds onthose before, but we don’t stop doing the work from thoseprevious levels: whatever maturity-level we’ve reaed at,we’ll always need to keep tra of what business we’rein! e same goes for all the subsequent work on systemconsistency and the like: if we don’t stay aware of all theinfrastructure anges – new systems coming on-line, oldsystems reaing their sunset and being retired – we’ll riskfalling ba into the same mess as before.

Strategy on its own is not enough: we also need some con-sistent means to make it happen, and keep on happening,


in the real world of everyday business practice. So foraritecture, we need clear metrics, to keep tra of what’shappening; we need consistent methods, so that we’re clearabout what needs to happen next; we need a consistent setof frameworks, so we can make sense of what we have andwhat we’re planning to do. But perhaps most all, we needthe right skills and structure to make it happen: the rightpeople, and the right kind of governance. Hence it’s thoseissues that we need to turn to next.

People – governance

Strategy describes the ‘why’ of the business; methodsdescribe the ‘how’ of what needs to happen; frameworksdescribe the ‘what’; and governance brings us ba to ‘why’again, by anoring it in people – theiroices, their actionsand responsibilities.

It’s always about people. No maer how tenical a prob-lem may seem, ultimately it’s always a ‘people-problem’ –more accurately, it’s the skills and commitment and driveof individual people that provide us with themeans to solveany given problem.

Where governance comes in is that it’s the way by whiwe manage the people-side of effectiveness – making surethat things happen ‘on purpose’, in the right order, forthe right reasons, and so forth. Formal structures su asITIL and COBIT and PRINCE2 do this for the IT contextin general, for concerns su as service-management and


project-management: we now need to do the same forenterprise aritecture. Perhaps the key complication isthat some of the governance will ange quite radically aswe move up the maturity scale, but we could summarisethe core themes as follows:

• it’s not a project – it’s a continuing process

• you’ll need different skillsets at different maturities

• you’ll need senior support – eventually, from theexecutive and above

• you’ll need to identify and engage with a wide rangeof stakeholders

• it’s really about creating an ongoing dialogue aboutaritecture

We’ll expand on ea of these themes as we explore thedifferent maturity-levels later; for now, though, these aresome of the points we’ll need to understand before we start.

It’s not a project: Enterprise-aritecture oen starts as aproject, or in a project, and ultimately needs to be appliedto every project, but it isn’t a project in itself. It’s acapability whose task is to manage a body of knowledgeabout structure and purpose – hence, unlike a project, it’snot something that we do once and then quietly forgetabout when it’s done. To retain its business value, we needto keep it going, keep it growing, keep puing it to practicaluse. It’s not a project.


You’ll need a range of skillsets: At present, enterprisearitecture is oen described solely as if it’s some aspectof IT, and that IT tenical skills are the only ones reallyrequired. Even if this were true, we would still needto cover the whole scope of ‘IT’: not just the obviousskills su as data aritecture, applications aritecture,security aritecture, infrastructure aritecture, networkaritecture, service aritecture and the like, but buildinglayout, cooling systems, power infrastructures and a wholelot more.

Once we start to move beyond IT to include the rest ofthe enterprise – especially in industries whi are notinformation-centric, whi is true for most – then therequired skillsets could be anything. At the very least, bythe time we rea the second or third maturity-level, we’regoing to need mu more awareness of the business asbusiness – whi means skillsets in business aritecture,organisational aritecture, process aritecture and so on.So we’ll need to plan for that from the start – includingall the people-issues of how to cope with those shis inskillsets, and in the make-up of the enterprise-aritectureteam.

You’ll need senior support: Because enterprise aritec-ture isn’t a project, it’ll need funding and other resourcesto keep it going, as a kind of conceptual infrastructure forthe enterprise. at can be a whole lot harder than fundinga once-off project – but you won’t get any real value fromenterprise aritecture unless you do this.


And as the maturity expands, so does the scope that you’llneed to cover. You may well start out as a small ‘skunk-works’ project tued away in IT, but by the time you reallyget going you’ll need the authority to tou anywhere inthe enterprise, bridge between any of the organisational si-los, and ask oen awkward questions of just about anyone.To work at that level, you’ll need the full weight of theentire executive behind you.

True, you may not need all of that right from the start –though nice to have, of course! – but you’d beer plan forit right from the start. Whi means you’ll need to be ableto prove your business value right from the start, too.

You’ll need to engage with stakeholders: As the scopeof the aritecture extends, so too does the range of stake-holders with whom you’ll need to engage. Every object,every data-entity, business-rule, business-process and ev-erything else will have a nominal owner – the ‘responsibleperson’ – and others who will have a business stake in theuse and maintenance of whatever-it-is. And every one ofthem will want a say in what happens, or at least be keptinformed on any possible anges. at’s a lot of people– and a lot of resistance to ange if you don’t engagethem in the aritecture. ere’s a key point that’s worthemphasising here:

• People don’t resistange: they resist beinganged.

ey’ll resist ange if they don’t see the point in it – inother words, if they suspect it’s ‘ange for ange’s sake’


– and they’ll certainly resist it if they think it’s solely forsomeone else’s benefit at their own expense. So you needto engage them in the aritecture – engage them in co-creating enterprise ange. If you don’t, what you’ll get isresistance – lots of it. Your oice…

Hence the importance of what TOGAF 9 callsa Communication Plan. But even that is noth-ing like enough: it’s not a one-way messageto be broadcast aer the event. It needs to bea full two-way communication with everyone– a dialogue of equals – that starts from DayOne.

It’s really about dialogue: Aritecture isn’t somethingwe can control. It’s all too big for that – especially at thescale of an entire enterprise. e only way we’ll get it towork is if we share out the load, and preferably amongsteveryone in the entire enterprise.

In essence, aritecture is just an idea: the belief andexperience that things work beer when they’re linkedtogether into a unified whole. ings work beer foreveryone when that happens. But trying to do that byimposing a fixed system of order will only work when theworld is static – whi the real world isn’t. And everysmall ange everywhere impacts on the whole – so wedo need to get those anges to work with all other partsof the whole. e way we do that is through aritecture:more specifically, a continual dialogue about aritecture.


It doesn’t take a large number of people toguide this dialogue, though. At one of ourclients, a nationwide logistics organisationwithsome 35000 employees, the core enterprisearitecture team consists of just five people– and even they also have other duties outsideof aritecture itself.

It’s mu the samewith other ‘pervasive’ themessu as knowledge-management, quality, se-curity, privacy, health and safety: the workis distributed throughout the enterprise, butthe core team that ‘hold the faith’, so to speak,need only be a small handful of specialists.

Or generalists, more accurately – people wholink things together across many different do-mains. In aritecture, the specialist domain-aritects – data, security, applications, pro-cess, service, strategy, infrastructure and soon – are more likely to be aaed to project-teams, guiding the detail-concerns of individ-ualange-projects. It’s the generalists ba atthe core who keep the dialogue going, to helphold everything together. And we don’t needmany people for that: just a core frameworkin whi people can come and go as needed.

Aritecture is also a story, about possibility, and aboutproblems overcome. If we try to force-fit others into


someone else’s story, it’s unlikely they’ll be interested insu a predefined part; but if we engage them in co-creatingthe story, they’re mu more likely to be willing to play.In that sense, engagementmaers; the story needs to makesense, in a dynamic, personal, visceral way.

Another key complication is that people know more thanthey can say, and can say more than they can write down.Oen the story develops through action and emotion asmuas it does through ideas and plans. So the aritecturestory needs to encompass all those dimensions too – andlikewise the framework on whi we build and describeand make sense of that story.

Planning – frameworks

In principle, we could describe relationships between ev-erything in the enterprise in terms of a single sentence-structure:

• “with «asset» do «function» at «location» using«capability» on «event» because «reason»”

is comes from a revision of the well-known Zamanframework. It cleans up the taxonomy, and extends theoriginal with an extra row at the top for enterprise core-constants or ‘universals’, and an extra dimension to clarifyscope and implementations:


Framework rows, columns and segments

is is described in more detail in the ‘Frame-work’ apters in another book in this series,Bridging the Silos: enterprise aritecture forIT-aritects – see the Resources section be-low.

See also tetradianbooks.com/ebook/silos_real-ea-frame-ref.pdf⁶ [PDF] for a two-page sum-mary of the framework and its core principles.

For the vertical dimension of the framework, we partitionscope in terms of timescale – a set of seven distinct layersor perspectives, from unanging constants, to items whiange moment by moment. Ea row adds anotherconcern or aribute:

⁶http://tetradianbooks.com/ebook/silos_real-ea-frame-ref.pdf

http://tetradianbooks.com/ebook/silos_real-ea-frame-ref.pdf




• Row 0: ‘Universals’ – in principle, should neverange: core constants to whi everything shouldalign – identifies the overall region of interest andthe key points of connection shared with enterprisepartners and other stakeholders; added for compati-bility with ISO-9000 etc

• Row 1: ‘Scope’ (Zaman: ‘Planner’) – adds possi-bility of ange: core entities in ea category, inlist form, without relationships - the key ‘items ofinterest’ for the enterprise

• Row 2: ‘Business’ (Zaman: ‘Owner’) – adds re-lationships and dependencies between entities: coreentities described in summary-form for business-metrics, including relationships between entities bothof the same type (‘primitives’) and of different types(‘composites’)

• Row 3: ‘System’ (Zaman: ‘Designer’) – addsaributes to abstract ‘logical’ entities: entities ex-panded out into implementation-independent de-signs - includes descriptive aributes

• Row 4: ‘Develop’ (Zaman: ‘Builder’) – adds de-tails for real-world ‘physical’ design: entities and at-tributes expanded out into implementation-dependentdesigns, including additional paerns su as cross-reference tables for ‘many-to-many’ data-relationships

• Row 5: ‘Deploy’ (Zaman: ‘Sub-contractor’ or ‘Outof Scope’) – adds details of intended future deploy-


ment: implementation of designs into actual so-ware, actual business-processes, work-instructions,hardware, networks etc

• Row 6: ‘Operations’ (Zaman: implied but notdescribed) – adds details of actual usage: specificinstances of entities, processes etc, as created, modi-fied, and acted on in real-time operations

e rows also represent different categories of responsibil-ities or stakeholders, su as senior management respon-sible for row-0 universals, or strategists at row-1 and -2,aritects and solution-designers at row-3 and -4, and linemanagers and front-line staff at row-5 and -6. In effect,this is the same layering that we see in the management-hierary, and in the nesting of abstract services.

Strictly speaking, the row-0 ‘Universals’ aremore like another dimension or baplane,because everything in the enterprise needs tolink ba to them. Since we already havethree dimensions – rows, columns and seg-ments – it’s simpler to show it as an extrarow at the top, and it’s easier for metamodelrepositories to implement it that way, too. Butit’s important to remember, though, that it isin effect another framework-dimension in itsown right.

Below the core ‘Universals’, the framework splits hori-zontally into columns for six distinct categories of primi-


tives, approximating to Zaman’s what, how, where, who,when and why:

• What : assets of any kind – physical objects, data,links to people, morale, finances, etc

• How: functions – activities or services to createange, described independently from the agent (ma-ine, soware, person etc) that carries out thatactivity

• Where: locations – in physical space (geographyetc), virtual space (IP nodes, hp addresses etc), rela-tional space (social networks etc), time and sulike

• Who: capabilities clustered as roles or ‘agents’ –may be human, maine, soware application, etc,and individual or collective

• When: events and relationships between those events–may be in time, or physical, virtual, human, business-rule trigger or other event

• Why: decisions, reasons, constraints and other testswhi trigger or validate the condition for the ‘rea-son’ and the like, as in strategy, policy, business-requirements, business-rules, regulations etc.

In the lower layers of abstraction - closer to the real-world– we also need to split the columns themselves by contextinto distinct segments or sub-categories. Whilst these couldbe cut multiple ways, a typical set of segments would be:


• physical: tangible objects (‘asset’), meanical pro-cesses and functions, physical or temporal locations,physical events; also align to rule-based skills (‘ca-pability’) and decisions

• virtual: intangible objects su as data (‘asset’),soware processes and functions, logical locations,data-driven events; also align to analytic skills (‘ca-pability’) and decisions

• relational: links to people (as indirect ‘asset’), man-ual processes and functions, social/relational loca-tions, human events; also align to heuristic skills(‘capability’) and decisions

• aspirational: principles and values, brands and be-longing, morale and self-belief (‘asset’), value-websand dependencies (‘location’), business-rules (‘event’);also align with principle-based skills (‘capability’)and decisions

• abstract: additional uncategorised segments su asfinancial (‘asset’, ‘function’), energy (‘asset’), time(as ‘event’-trigger) etc

ese segments are fundamentally different in scope andfunction:

• Physical assets are ‘alienable’ – if I give it to you, Ino longer have it.


• Virtual assets are ‘non-alienable’ – if I give it to you,I also still have it.

• Relational assets exist between two entities (usuallybut not necessarily real people); ea is one hundredpercent the responsibility of both parties – if eitherparty drops it, the relationship ceases to exist – andis actually harder to transfer to someone else than itis to create from scrat.

• Aspirational assets have some similarities with re-lational ones, except that the relationship is more aone-sided ‘to’ rather than a balanced ‘between’.

e enterprise will need to be especially careful how ithandles aspirational assets, for example, because they’reclosely linked to the sense of identity and self, and the pas-sions embedded within them can be extremely destructiveif not treated with respect.

Hence woe betide any company that trashesa mu-loved brand, for example, because theintensity of that aspirational commitment canunleash a wave of anger and retribution thatresembles the inconsolable rage of grief… It’snot ‘rational’ in any normal sense of the word,but it’s definitely real, and does need to betreated as su.

Closer to the opposite extreme, the loss ofmorale and drive that accompanies ‘ange-


fatigue’ has its roots in damage to aspirationalassets: specifically, the loss of that sense ofbelonging, of being part of a known enterprise– an included member of a group who “coor-dinate their functions and share informationin support of a common mission” and so on.

is is crucially important in the aritectureof the enterprise, because it’s the key sourceof personal drive and commitment to the en-terprise. If it’s lost, the most we’ll get frompeople is ‘presenteeism’ – their bodies maybe present, but probably not mu else. Sowhilst these can oen seem subtle or strange,aspirational assets maer.

‘Composites’ of related entities and entity-types may existwithin the same segment in a column, or in differentsegments of the same column. We can then link these com-posites across other columns to create other ‘incomplete’design-paerns – the kind of structures we usually see inaritecture models – or complete the composite across allof the columns for final implementation.

Understanding these asset-categories and the compositescreated from them helps to describe concerns su asstorage and security. For example, a paper form is botha physical asset and a virtual asset: we need to manage itas a physical object, with all of the resultant issues aroundprocurement, inventory, pre-use warehousing, modifica-tion and use, storage and disposal; yet we also need to


manage it as a virtual asset, with all those concerns aboutdata-quality, information-quality and so on. And we candescribe some of the security-concerns by asset-category asfollows:

• physical security: protect alienable asset againstphysical loss

• virtual security: protect non-alienable asset againstloss via physical means (e.g. the of laptop, dam-age to data-server), against inadvertent virtual loss(e.g. deletion, overwrite, out-of-date file-format) andagainst inadvertent or unauthorised replication

• relational security: protect relational asset (e.g. mu-tual trust) against damage or loss from either end ofthe relationship

• aspirational security: protect aspirational asset againstloss at ‘near-end’ (e.g. arbitrary alteration of brand)and at ‘far-end’ (e.g. damage to reputation of thebrand)

Security for abstract assets su as finance is usually acomplex-composite derived from variations of the above.

e various ‘pervasives’ su as privacy, quality, ethicsand the like typically emphasise protection of differentcombinations of asset-categories, for example:

• security: protects physical/virtual assets, also somerelational/aspirational assets su as trust


• privacy: protects virtual/relational assets

• health and safety: protects physical/relational assets

• ethics and corporate social-responsibility: protectsaspirational/relational assets

• environment : protects physical/aspirational assets

• quality: generic – protects the asset-categories thatapply in the respective business context

All of these may intersect in a sometimes bewildering va-riety of ways – for example, safety-critical IT-systems mayinterweave concerns about security, safety, environmentand other themes all within a single aritectural paage.

e balance between incompletion and completion of com-posites also enables aritectural redesign, by anoringtrails of relationship between items or layers, to resolveconcerns su as strategic analysis, failure-impact analysisand complex ‘pain-points’:

• composites are usable when aritecturally ‘com-plete’;

• they are re-usable when aritecturally ‘_in_-complete’.

e notion of ‘bindedness’ – the extent to whi a specificcomposite or primitive should or must be included within a


solution – can be used to convert a model into a reference-framework. e obvious example of bindedness is legalcompliance, because if we don’t comply, we’re breaking thelaw. But it also applies to use of standards of any kind, andmany other practical concerns su as whether a particularoperating-system or soware version or type of milling-maine or whatever should be used in whi contexts andfor what purposes; and what types of skills and experiencewould be needed so as to deliver a particular service ordecision. Levels of bindedness for any item in a reference-model would typically include:

• mandatory: item must be used wherever applicable

• recommended: item should be used unless a pre-ferred solution mandates an alternative

• desirable: use of the item would aid in consistency

• suggested: experience indicates the item may pro-vide a beer or more consistent solution than similaralternatives

Note that these might vary not only accordingto context, but in many cases will also angeover time. Once again, very few items are evertruly static in an enterprise aritecture.

Given all this wide variety of information that constitutesthe overall framework, you’re going to need somewhere to


put it, and some systematic means to keep tra of it all. Atthe least, you’re going to need:

• aritecture repository, including models and meta-models, core references, governance documents andother artefacts

• requirements repository, documenting requirements,tests for confirmation of those requirements, andrelationships between them

• risk and opportunity registers, detailing any risksand opportunities identified in aritecture, and ac-tions to be taken to address them

• glossary and thesaurus, providing standard defini-tions and cross-references between synonyms, homonyms,heteronyms and the like

• dispensations register, recording implementationsthat have been allowed to not comply with the ar-itecture, the reasons for allowing non-compliance,and how to resolve it in future

Whi leads us to another key point, about aritecturetoolsets. Most people start their aritecture with what-ever tools come to hand, whi typically means standardoffice applications su as Excel, Visio and PowerPoint.ese do work well enough for first experiments, butthey don’t scale, they don’t handle versioning, and theycan’t manage themyriad of essential cross-connections and


cross-references that start to emerge as soon as you beginany serious aritecture analysis. So at some stage, andprobably sooner rather than later, you’ll have to face thefacts: you’re going to need a proper enterprise-aritecturetoolset.

And yes, this may hurt, because all of themare expensive, and all of them have significantor even serious limitations: some of them haveuser-interfaces that are best described as ‘user-hostile’, and as yet none of them get close todelivering all of the functionality we need forwhole-of-enterprise aritecture. But there’sno way round it: some kind of purpose-builttoolset is essential for this type of work.

ere’s a wide variety of tools out there: someemphasise visual modelling, others more theunderlying structures and metamodels. Asa consultant and adviser working in manydifferent industries, I prefer the laer, butthat’s what mates my own needs, whereasyour needs may well be different. So I’ll avoidmaking any recommendations here, becausethe ‘right’ toolset is the one that works bestfor you in your own context.

e TOGAF specification provides some use-ful suggestions – see Chapter 42, ‘Tools for


Aritecture Development’, in the TOGAF 9book or website – and there’s an excellentsummary of selection-criteria on the Insti-tute for Enterprise Aritecture Developmentswebsite at www.enterprise-aritecture.info/EA_-Tools.htm⁷ - these should help to ease the painof piing the right toolset for your needs.

In effect, the framework defines meaning within the en-terprise and its aritecture: and we do need at least someof it in place before we start work. But on its own, theframework does nothing: so the next item we need is amethodology for aritecture development.

Practice – methods

Although there are a fair number of formal definitionsaround for enterprise-aritecture, there are surprisinglyfew that describemethodology –what to do in aritecture,how to do it, in what sequence, and so on. For most practi-tioners these days, it almost comes down to a single oice:the Aritecture Development method (ADM) that’s partof TOGAF, the Open Group’s aritecture framework.

Whi is unfortunate, because whilst it’s a good oice forthe early stages of enterprise aritecture – especially ininformation-based industries su as insurance and finance– it’s essentially focused only on IT, and hence is not good

⁷http://www.enterprise-architecture.info/EA_Tools.htm

http://www.enterprise-architecture.info/EA_Tools.htm




for later-maturity aritecture, whi does need to coverthewhole of the enterprise, beyond just its IT. Sowe need todo some amendments here to make it usable in practice forthe whole scope of enterprise aritecture, in any industryand at every level of maturity.

Sadly, this is still true of the latest version,TOGAF 9, whi was released only a fewweeks ago as I write this. Version 9 is mubeer-structured than the previous version,‘8.1 Enterprise’, but it still has the same fixedIT-centric scope, and most of the ancillaryinformation assumes an IT-centred world. It’sstill useful, though, to read the TOGAF 9specification, either in the published book orin the online version: see the Resources sectionbelow for the publication details.

It doesn’t maer mu to us, anyway: theamendments described here will resolve allthose constraints, and will work equally wellwith either version of TOGAF.

TOGAF’s ADM consists of a cycle of eight phases – labelledA to H, and oen referred to as ‘crop circles’. eseare organised in a circle around a central repository forrequirements. e first four phases focus on aritectureassessment: Aritecture Vision for the overall cycle (PhaseA); Business Aritecture (Phase B) Information Systems


Aritecture (Phase C), usually split into sub-phases fordata- and applications-aritecture; and Tenology Ari-tecture for IT-infrastructure (Phase D). Phases B to D eahave explicit subsidiary steps for ‘as-is’, ‘to-be’ and gap-analysis. e second set of four phases deals with defining(Phase E), planning (Phase F) and implementing (Phase G)a ‘roadmap’ for ange, and following through with a final‘lessons-learned’ activity (Phase H).

ese are all preceded by a ‘Preliminary Phase’, in whiwe would set up the aritecture capability itself, its gover-nance, and various core documents su as the AritectureCharter and Aritecture Principles.

To amend it to work beer beyond its inherent over-emphasis on low-level IT, the main anges we need are:

• stronger support for Agile-style development

• allow any scope – not just IT-aritecture

• stronger and more explicit integration with gover-nance

• stronger integration with information-repositories

So first, we clear the des a bit in Phase A. In the originalversion 8.1, a typical complete aritecture cycle wouldtake many months at least. TOGAF 9 allows for more ex-plicit subsidiary iterations within the cycle, but the overallcycle itself still takes as mu as a couple of years. What weneed instead is something that can still deliver real business


value in as lile as a couple of hours. To do this, we movemu of the content of the existing Phase A ba up intothe Preliminary Phase, leaving Phase A free to concentrateon the specific details for the current iteration alone.

Next we need to ange TOGAF’s fixed scope. We can dothat very simply, by seing the scope in our amended PhaseA, and defined in terms of the respective layers, columnsand segments in the framework. We then ange the focusof Phase B to D: instead of the previous fixed scope forea phase, with separate ‘as-is’, ‘to-be’ and gap-analysisin ea, we swap these round su that Phase B covers the‘as-is’ for the selected scope, Phase C does the ‘to-be’, andPhase D the gap-analysis.

When that’s done, we could summarise our revised versionof the ADM as follows:

• Phase A: Define business-scope, business-purposeand future time-horizon(s) for the iteration; scopealso identifies respective stakeholders and applicablegovernance for assessment and any probable imple-mentation phases

• Phase B: Identify the baseline (what is already knownin the aritecture-repositories about the scope), thenassess in more depth the ‘as-is’ context (adding con-tent to the repositories as we do so)

• Phase C: Repeat Phase B for the one or more ‘to-be’time-horizons specified in Phase A


• Phase D: Do a gap-analysis for ea ‘as-is’ and ‘to-be’ pair (from Phase B andC respectively), to identifyrequirements, constraints, risks, opportunities andsulike for future ange.

• Phase E: Review the results of Phase D to allocatepriorities to requirements and identify appropriatemeans to implement the requisite anges (‘solu-tions’, in classic IT-speak); the applicable governance-rules shi from those of aritecture to those ofange-management during this phase

• Phase F: Establish a detailed plan for project-, programme-or portfolio-management to handle theanges ‘fromhere to there’ – in particular, dealing with the ‘peo-ple’ and ‘preparation’ aspects of ange

• PhaseG: Aritecture assistsange-governancewithcompliance, consistency and inter-project synergiesduring implementation of the planned businessange

• Phase H: Return to aritecture-governance to do a‘lessons-learned’ review in relation to the respectivebusiness context, and identify any needs for furtherrelated aritecture work.

As with the Zaman-like framework that un-derpins it, this restructure of the TOGAFADMis described in more detail in Bridging theSilos, in the ‘Methodology’ apters. ere’s


also a two-page summary of the methodol-ogy at tetradianbooks.com/ebook/silos_real-ea-adm-ref.pdf⁸ [PDF].

From this, every aritecture iteration has the same overallstructure. All that really anges is the scope, and thepurpose for the iteration: once that’s set up in Phase A,the rest of the activities follow on naturally from that.e ‘Preliminary Phase’ is actually an aritecture iterationin whi the scope is the aritecture-capability itself.And tenically speaking, Phase H is also an aritectureiteration in its own right, where the scope is the currentcontext of the aritecture: but it’s simplest to leave itwhere it is, if only to remind us to review the aritectureitself on a regular basis.

⁸http://tetradianbooks.com/ebook/silos_real-ea-adm-ref.pdf

http://tetradianbooks.com/ebook/silos_real-ea-adm-ref.pdf




Governance-artefacts define aritecture-cycle’s phase-boundaries

Crucially, anything that looks like content oractivities for a later phase is deliberately heldba until that phase. For example, we don’ttry to do implementation during aritecture-assessment, because the applicable governance-rules are usually different in the respectivephases. If we did try to do implementation tooearly, we’d be likely to do it wrong, or at theleast annoy some important stakeholder whoshould have been involved!

is especially applies to any pre-paaged‘solutions’: anything that looks like a ‘solu-tion’ is explicitly shelved until Phase E at theearliest, so that we fully understand the real


requirements in the context before we lookat any purported ‘solutions’ to those require-ments. e aim here is to reduce the incidenceof deus ex maina delusions – su as theclassic cart-before-the-horse mistake of ‘IT-solution looking for business-problem’ – thatso oen cause so mu bier contention withthe wider business community.

e other advantage of this redesign is that it simplifies thelink to governance. Ea phase now ends with an explicitstakeholder-review: in effect, the reviews define the phase-boundaries. And the review itself provides a PRINCE2-style ‘go/no-go’ gateway at the end of ea phase: sowe don’t assume – as classic TOGAF does – that everyenterprise-aritecture assessmentmust automatically leadto a major ‘roadmap’ for all-out ange of the IT-systems.Oen there’s real business-value to be gained just from theassessment itself.

is is especially true once we anowledgeSnowden’s dictum that ‘every intervention isa diagnostic, and every diagnostic is an in-tervention’: the process of aritecture itself– above all, the engagement in dialogue – isoen the only direct ‘intervention’ we need.

If you really want to cut costs, improve ef-ficiency, enhance overall effectiveness, oen


the best way to do this is to get people to re-think their own way of working – not imposea ‘new way of working’ on them from out-side. Enhanced awareness of the way in whieverything links with everything else leads tosmall anges in action that can snowball bythemselves into natural larger-scale ange:and if we do it right, it hardly costs anythingat all.

Another source of business-value is that, once we link thearitecture information-repositories more strongly intothe assessment methodology, even the smallest iterationwill add a lile more into the ‘holograph’, that body ofknowledge about enterprise structure and purpose. isnot only includes models and other aritecture informa-tion, but requirements in general, updates to the sharedenterprise glossary and thesaurus, and notes on new andrevised risks and opportunities.

at perhaps doesn’t sound mu, but evensmall updates to the thesaurus, for example,can help a lot, if sometimes in unexpectedways. Misunderstandings and miscommuni-cations can cost a great deal, and not justin direct monetary terms: that thesaurus willmaer.

And opportunities can arise in some very un-expected places. e most intensive users of


early mobile phones were not in the uppereelons of big-business – as the telcos hadexpected – but jobbing builders and small-traders, for whom communications on-site andon the move had a very high value indeed.And in those same early days, engineerswouldoen exange test-messages with ea othervia the tenology’s parallel control-annel,whi usually worked even when there wasn’tenough signal for the normal voice-annel tooperate. e tenique seemed useful, so, as asmall experiment, one telco made the annelvisible on their subscribers’ handsets – andwas taken completely by surprise whenwhat’snow known as ‘texting’ took off like wild-fire. at’s why text-messages are restrictedto 160 aracters: the control-annel wasn’tdesigned for texting at all. But it’s a clever re-use of existing tenology – leading to a veryvaluable business opportunity.

e other point here is that by linking review of therepositories into the aritecture cycle, they should nevergo out of date – because they’re re-assessed and updatedevery time we do any work in the respective space.

Historically, enterprise aritecture frameworks have beengreat on the theory, but oen not so great on the prac-tice. So there’s also a lot about methodology that wecan learn from other disciplines, above all on the links


between knowledge, governance and action. Two valuablesources in this are ITIL – especially Version 3, whi is farless IT-specific than the previous version – and PMBOK,the ‘Project Management Body of Knowledge’. Anotherwell-known example is Christopher Alexander’s work onpaerns in building-aritecture, whi has been adaptedto many other aritectural domains. But there are plentyof other sources for good ideas: all we need do is keep oureyes open, and remember always to think wider than justthe usual constraints of the IT-centric world.

Performance – metrics

What’s the value of your aritecture? And value towhom? ese aren’t trivial questions: if you can’t answerthem, and if you can’t prove the value, it’ll likely be yourjob that’s on the line…

ere are actually four different yet interdependent themeshere:

• identifying what ‘value’ means within in the enter-prise – in other words, not just money, but all theother ‘pervasives’ too;

• identifying the metrics and transforms needed tomeasure andmonitor business-activity and business-performance in terms of ea of those values;


• identifying andmeasuring the impact that the enterprise-aritecture has on those measured values – whigives us the business-value of the aritecture;

• monitoring and measuring the performance of thearitecture practice – just like any other businesscapability.

None of these are as simple as they might at first seem –though measuring the business-value of the aritectureis probably the hardest allenge, because some impactsare identifiable only in terms of what didn’t happen, whatdidn’t gowrong, and oen the real returns can bemeasuredonly in the performance of the enterprise as a whole.

Oddly enough, metrics and business-value arehardly addressed at all in the TOGAF specifi-cation. You’ll find more detail, though, in the‘Completion’ apters in Bridging the Silos,whilst the role of the ‘pervasives’ is exploredin depth in another companion book,e Ser-vice Oriented Enterprise – see the Resourcessection for more information on those.

One of the hardest parts – whi is why we need to addressit right from the start – will be weaning people away froman over-dependence on measuring performance only inmonetary terms. Whether we think of it in the positive, asprofit – in a commercial enterprise – or negative, as cost-cuing – su as in a government-department – money is,


obviously, an interesting and important metric. But oddly,it’s oen not mu use as a metric, because very few thingsare directly controlled by money. Tenically speaking, it’smore usually a complex derivative, an outcome of otherfactors rather than a driver in its own right: and what wemost need to measure are the things we can control.

A perhaps useful piece of historical trivia here:the word ‘economy’ literally translates as ‘themanagement of the household’, in fact upuntil the middle of the nineteenth century theword ‘economist’ was essentially synonymouswith ‘housewife’. en a few folks came upwith the metaphor of an enterprise or a wholenation as a ‘household’ on a larger scale – andhence ‘the economy’ as the management ofthat shared ‘household’. Hence, in turn, all thepresent-day notions of ‘economics’.

But in doing so, they made a fundamentalmistake: they measured that economy onlyin monetary terms, and ignored everythingelse. If you do that, the ‘economy’ metaphorno longer works: managing the householdfinances is rarely easy, but in many ways it’sthe easy part of managing a household, andit’s certainly not the only one!

Balanced Scorecard is a good start, to get people thinkingwider than money: but even that still places financial


return as one of its four dimensions, placing it on an equalfooting with ‘Customer’, ‘Internal Business Processes’ and‘Innovation and Learning’. is is misleading because,unlike the others, financial return is not a lead-indicatorbut a lag-indicator – it tells us where we’ve been, but notwhere we’re going. To manage an enterprise – or for thatmaer the aritecture of that enterprise – what we needare those lead-indicators.

Whi is where the values of the enterprise – its ‘perva-sives’ – come into the picture, because by definition they’rethe themes that are of value to the enterprise, and hence thethings we most need to measure. Whi is why we needto identify them as early as possible within our enterprise-aritecture work – see section ‘Vision, values, principlesand purpose’ in apter Step 1: Know your business. Asa very minimum, we need to measure against those fivestrands of effectiveness:

• Is it efficient? – does it make the best use of theavailable resources?

• Is it reliable? – can it be relied on the deliver therequired results?

• Is it elegant? – does it support the human factors inthe context?

• Is it appropriate? – does it align with the businessvalues and purpose?


• Is it integrated? – does it help to link everythingtogether?

Once we have those, and a real ‘balanced scorecard’ that’stailored to the true values of the enterprise, we have ameans to measure the value of the aritecture.

We also need to monitor our own performance in doingenterprise aritecture. Again, a focus on those five strandsof effectiveness will be helpful here, but probably the bestapproa will be to use one of the ‘capability maturitymodels’ that are becoming more generally available forenterprise aritecture.

Two maturity-metrics that I’ve found usefulare Marlies van Steenbergen’s ‘DyA Aritec-ture Maturity Matrix’, from her book Buildingan Enterprise Aritecture Practice, and theMeta Group’s ‘Aritecture Maturity Audit’.Even though they’re aimed primarily at IT-aritecture, they’re sufficiently detailed andfine-grained enough to give valuable point-ers for any type of enterprise aritecture –though in my experience the Meta Group’sversion is the more useful of the two for as-sessing the early stages of aritecture matu-rity.

To keep things simple, though, we’ll sti withthe minimalist maturity model from the TO-GAF specification for the rest of this book,


as its basic five-step frame fits beer withour more generic needs here. It doesn’t mea-sure performance as su, but it does provideclear guidance as to what to do next at eastep – whi is, aer all, the real purpose ofperformance-metrics.

e other key aspect of performance is about lessons learnedfrom the previous ‘perform_ing_’ of the work. Enterprisearitecturemanages a body of knowledge about enterprisestructure and purpose: what have we added to that bodyof knowledge during this cycle of work? To quote the USArmy’s ‘Aer Action Review’ process:

• What was supposed to happen?

• What actually happened?

• What was the source of ea difference?

• What can we learn from this, to do differently nexttime?

Keeping tra of ‘the numbers’ will help – no doubt aboutthat. But it’s questions like those above, extending thenarrative and dialogue of the aritecture, that will reallyhelp most to embed the aritecture into the enterprise, andto demonstrate in direct, everyday practice the real valueof our work.


Resources

• FEAF (Federal Enterprise Aritecture Framework):see www.gao.gov/special.pubs/eaguide.pdf⁹ [PDF]

• Preparation for enterprise IT-aritecture: see Chap-ter 6 ‘Preliminary Phase’ and Chapter 7 ‘Phase A: Ar-itecture Vision’ in Open Group, TOGAFTM Version9 (Van Haren, 2009)

• Aritecture Development Method (ADM): see PartsII and III in online TOGAF 9 atwww.opengroup.org/aritecture/togaf9-doc/ar/¹⁰

• DyA (DynamicAritecture): see eng.dya.info/Home/¹¹

• Effectiveness inwhole-of-enterprise aritecture: seeTom Graves, Real Enterprise Aritecture: beyond ITto the whole enterprise (Tetradian, 2008)

• ITIL (IT Infrastructure Library): seewww.itil-officialsite.com¹²

• COBIT (Control Objectives in Information and re-lated Tenology): see www.isaca.org/cobit¹³

• PRINCE2 (Projects In Controlled Environments): see[www.ogc.gov.uk/methods_prince2.asp](hp://www.ogc.gov.uk/methods_-prince2.asp)

⁹http://www.gao.gov/special.pubs/eaguide.pdf¹⁰http://www.opengroup.org/architecture/togaf9-doc/arch/¹¹http://eng.dya.info/Home/¹²http://www.itil-officialsite.com¹³http://www.isaca.org/cobit




http://eng.dya.info/Home/


http://www.isaca.org/cobit



http://eng.dya.info/Home/


http://www.isaca.org/cobit


• Zaman Framework: see www.zifa.com¹⁴

• Framework and method for Agile aritecture: seeTom Graves, Bridging the Silos: enterprise aritec-ture for IT-aritects (Tetradian, 2008)

• PMBOK (Project Management Body of Knowledge):see Project Management Institute at www.pmi.org¹⁵andWikipedia summary at en.wikipedia.org/wiki/ProjectManagementBodyofKnowledge¹⁶

• Paerns: see Christopher Alexander, A Paern Lan-guage: towns, buildings, construction (Oxford Uni-versity Press, 1977)

• Balanced Scorecard and its variants: see Wikipediasummary at en.wikipedia.org/wiki/Balanced_score-card¹⁷

• Aritecture maturity model: see Martin van denBerg and Marlies van Steenbergen, Building an En-terprise Aritecture Practice: tools, tips, best prac-tices, ready-to-use insights (Sogeti / Springer Verlag,2006)

• MetaGroupAritectureMaturity Audit: MetaGroupPractice, (2000), Vol 4 No.4 (for Part 1) and No.5 (forPart 2)

¹⁴http://www.zifa.com¹⁵http://www.pmi.org¹⁶http://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge¹⁷http://en.wikipedia.org/wiki/Balanced_scorecard

http://www.zifa.com

http://www.pmi.org

http://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge

http://en.wikipedia.org/wiki/Balanced_scorecard


http://www.zifa.com

http://www.pmi.org

http://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge



• Aer Action Review and other ‘lessons learned’teniques: see Chris Collison and Geoff Parcell,Learning to Fly: practical lessons from one of theworld’s leading knowledge companies (Capstone, 2001)

A matter of maturityWhat we need to do at ea step in enterprise-aritecturedepends to a large extent on the level of maturity that’sbeen aieved to date. e TOGAF specification describesfive distinct levels that it labels ‘ad-hoc’, ‘repeatable’, ‘de-fined’, ‘managed’ and ‘optimised’. ose, though, are thematurity-levels we aieve aer we’ve done the work. etypical steps for the work itself would be more as follows:

1. From nothing, to creating a stable base for ‘ad-hoc’fixes – see apter Step 1: Know your business

2. From ‘ad-hoc’, to structures that are efficient, reliableand repeatable – see apter Step 2: Clean up themess

3. From repeatable, to sufficiently well defined to re-spond to theanging needs of strategy – seeapterStep 3: Strategy and stuff

4. From defined, to managed well enough to respondin real-time to the confusions and crises coming upfrom the real world – see apter Step 4: Work withthe real world

5. From managed, to optimised well enough to talethe organisation’s more intractable ‘pain-points’ and‘wied problems’ – see apter Step 5: Powering on

56

A maer of maturity 57

ese layers build on ea other, but the work of ea layernever actually ends: we need to continue to revisit therespective context and scope for ea, to review and amendas we climb upward.

Continuing updates for ea layer underpin maturity growth

So if and when we get to the ‘Optimised’ maturity-level,there’ll always still be further work to do, in maintainingthe dialogue that underpins the aritecture – see Whatnext?¹⁸ But at least we know we’ll be doing it fromstrong, stable foundations – and contributing in every waytowards real business value.

Resources

• Levels of aritecture maturity in TOGAF: see ap-ter 51, ‘Aritecture Maturity Models’ in e OpenGroup, TOGAFTM Version 9 (Van Haren, 2009)

¹⁸../Text/Whatnext.xhtml#anchor40

../Text/Whatnext.xhtml#anchor40



A maer of maturity 58

• TOGAF (e Open Group Aritecture Framework):seewww.opengroup.org/aritecture/togaf9-doc/ar/¹⁹

¹⁹http://www.opengroup.org/architecture/togaf9-doc/arch/



Step 1: Know yourbusinessWe can only implement a strategy successfully if we havesome initial idea about what business we’re in. IT-oriented‘enterprise aritects’ oen try to skip this step in the rushto get down to ‘the fun stuff’ – the fine detail of computingtenology. But it can be a lethal mistake, because we endup optimising the tenology for a business that we don’teven know – and hence are then all but forced into thetrap of promoting pre-paaged IT-‘solutions’ as strategies,because it’s the only part of the business we do know. So,to put it simply:

• Whatever part of the business we’re in, the busi-ness of the business must always come first.

Whi means that however mu we might want to ‘getdown and get dirty’ with the detail-level IT –whi usuallyis the next stage, by the way – we must do this task first.

Purpose and strategy: e focus here is on the nature ofthe business – its vision, values and business purpose, thebusiness milieu in whi it operates and its role within thatcontext, and its core business functions and processes.

Our aim here is to show why an aritecture capabilitywould be useful for the enterprise – and demonstratethat use by producing, at minimal cost, a simple set of

59


aritectural artefacts that have immediate practical valuefor the business.

From a FEAF perspective, what we’re creatinghere is a first cut at the BRM and PRM – theBusiness Reference Model and PerformanceReference Model.

From a TOGAF perspective, mu of whathappens here would be termed ‘Business Ar-itecture’. But note that we do mu of itbefore we develop the Aritecture Charterand the like: in fact mu of the equivalentof TOGAF’s Preliminary Phase happens nearthe end of this stage, rather than at the start.e reason is simple business-politics: yes, wemust do all the Preliminary Phase work beforewe get down to what TOGAF thinks of as ‘en-terprise aritecture’ – but we won’t even getthat far unless we already have some businesscredibility behind us. Whi means we needto do something that is immediately meaning-ful and valuable to everyone in the business –not just the IT-folks. Hence the slightly ba-to-front way we’ll do things here.

We still do it under solid governance, though– stakeholder reviews and all that. Unless wedo that, it isn’t aritecture.


People and governance: is is only a first-cut ‘proof ofconcept’, so we’ll need to keep things as simple as possible.Oen it’ll be slipped in ‘under the counter’ as a kindof skunk-works project, with costs quietly buried undersomeone’s discretionary budget – though for credibilityreasons it’d be best if that ‘someone’ is fairly senior to startwith. In governance terms, that ‘someone’ would also bewho we would report to during the work, though the end-results – the Function Model, the Aritecture Charter andso on – should be distributed for comment as widely aspossible.

is is one of the few parts of enterprise-aritecture that could be done entirely byexternal consultants or other ‘outsiders’. Infact it’s almost beer to use outsiders here,especially in the early stages, because theywould see the enterprise differently from any‘insider’s assumptions, and would also havemore licence to ask the essential ‘stupid ques-tions’ su as “What is this business, any-way?”.

Planning and frameworks: We have a minor dilemmahere, in that whilst we’re aiming to create the core overviewsof the enterprise, the ‘holograph’ approa means we needone already existing before we can start, so as to de-rive business value. e answer is to use the Zaman-like framework described earlier in section ‘Planning –


frameworks’, in apter Preparing for aritecture, as itprovides a core taxonomy to make sense of where and howeverything fits together. Ultimately, everything we’ll dofrom now on will anor ba into that core framework:so we don’t just end up with an enterprise aritecture, westart with one.

You will also need a fairly complete ari-tecture toolset: aritecture repository andframework, requirements repository, risks andopportunities registers, and preferably the glos-sary and thesaurus as well. (You won’t needthe dispensations register as yet, because wedon’t get that far in this stage.)

But whilst it does have to be fairly complete,it doesn’t need to be that sophisticated as yet.For the first pass through this work, you canget away with using standard office applica-tions su as Excel, PowerPoint and Visio.is would also be good as a test-case for atrial version of a proper purpose-built toolset– but do first make sure that you can exportfrom the toolset, otherwise you risk losing allof this work.

Practice and methods: Ea section of work shouldfollow the standard method and governance as describedearlier in section ‘Practice – methods’, in apter Preparing


for aritecture. e only variation would be that in somesections, su as developing the Function Model – seesection ‘Functions and services’ below – it may be useful todo the ‘to-be’ (Phase C) before the ‘as-is’ (Phase B), to helpstakeholders disengage from assumptions about the imag-ined ‘inevitability’ of current organisational structures andprocesses.

Although it’s unlikely there would be mu – if any –design and implementation for formal ange-projects todo here, it will still be important to engage programme-management and the like in the overall process – if onlyto garner their suggestions and feedba on how the han-dovers of governance-responsibilities will need to workwhen we move later into the more active stages of enter-prise aritecture.

Performance, end-products and metrics: First timethrough, the overall work for this step should require nomore than a few person-weeks of effort – just enoughto establish the intended role and business value of thearitecture capability. You’ll probably need to take moretime when you revisit this work at later stages of maturity,but that above should be sufficient to make a useful starthere. Typical artefacts from this step would include:

• strategic description of the enterprise context – vi-sion, values, purpose, market, legal and regulatorymilieu, etc


• high-level descriptions of the needs within that con-text that are serviced by the organisation

• core content for the aritecture framework – assets,functions, locations, capabilities, events and deci-sions

• core Function Model – ‘the enterprise on a page’– summarising how the organisation serves thoseneeds

• formal documentation of the authorised roles, re-sponsibilities, activities, deliverables, funding andreporting-relationships for the enterprise aritec-ture capability

is step would usually be run as an explicit short-termproject, hence keymetrics would typically include on-time,on-budget, and all required deliverables completed. Alsosome measure of customer-satisfaction would be useful –not only satisfaction of direct customers su as the project-sponsor, but more generally of the likely aritecture stake-holders.

Vision, values, principles andpurpose

At the highest level, ‘the enterprise’ is not the organisation,but the broader context in whi the organisation operates,


and whi it shares with all other stakeholders in thatenterprise. e purpose of this section is to identifyand document the organisation’s relationships with thatbroader enterprise.

You’ll also find this type of assessment use-ful as part of due-diligence for a proposedmerger or acquisition. Assuming you’ve al-ready done this for your own organisation,this exercise will provide you with the essen-tial information for a gap-analysis on cultureand baground – the basis for a crucial go/no-go decision, because the degree of alignmentis a known key criterion for future success orfailure here.

On the people side, the skills you’ll need are those forroutine business-analysis. For a first pass you’ll probablyonly need tomeet upwith a few strategists and other seniorplayers, though for later iterations you’ll need to extendthat scope, eventually to every part and every level of theoverall enterprise.

For planning, you’ll need access to typical business doc-umentation su as the Annual Report and the corporateintranet. e aritecture-entities you identify will usuallybe placed in the topmost rows of the framework.

e practice would be based on teniques su as vision-ing and the Business Motivation Model, with appropriatedocumentation.


As described above, performance would usually be mea-sured in simple project-completion terms: on-time, on-budget and sulike.

Vision, role, mission, goal

Use the ‘vision, role, mission, goal’ structure to summarisethe overall ecosystem in whi the organisation exists, andthe role or roles it ooses to play within that ecosystem.

Note that the terms ‘vision’ and ‘mission’ areused here in a slightly different way thanin common business use – see the Glossaryappendix for definitions. ese usages help usto avoid the temptation to view the organisa-tion as the enterprise – one of the most com-mon yet most dangerous mistakes in business-visioning.

For more detail on the ‘vision, role, mission,goal’ process, see the apter ‘Aritectureon purpose’ in Real Enterprise Aritecture:beyond IT to the whole enterprise, and the‘Practice – Service Purpose’ apter in eService Oriented Enterprise: enterprise ari-tecture and viable services.

e vision is not a ‘future state’ for the organisation itself,but describes the common theme shared by all stakeholders


in the enterprise. e typical phrasing of a vision wouldnot be emotive in itself, but would invite or incite anemotional commitment to the shared ‘cause’: two goodexamples are “a sociable world” (brewers Lion Nathan)and “boundaryless information flow” (standards-body eOpen Group). A mission here is more in the sense ofa trade-mission, not a military-style ‘sending’ – in otherwords, an ongoing capability to serve a role within theenterprise, rather than an activity with a defined point ofcompletion.

• What vision is common to all stakeholders in theenterprise? What single phrase describes the overallenterprise?

• What role or roles does the organisation play withinthe enterprise, to contribute towards the vision?What roles does it not play – hence leaving openfor other stakeholders? Who are these other stake-holders, and what roles do they play within theoverall enterprise? What relationships and transac-tions are implied by these different roles within theenterprise? How would you verify that ea role –especially the organisation’s ownosen role or roles– does support the enterprise vision?

• What mission or missions – ongoing services andcapabilities – would be needed to support ea roleundertaken by the organisation in that enterprise?What metrics would you need to confirm that ea


mission is ‘on purpose’ and effective in supportingthe respective role?

• What short-, medium- and longer-term goals andobjectives underpin ea mission? What are thetimescales and deliverables for ea goal? By whatmeans do you verify that ea goal is aievable, andhas been aieved? How do you verify that ea goaldoes support the respectivemission in an appropriateand effective way?

Once this basic high-level picture has been established,use a tenique su as the Business Motivation Model todevolve the view downward into the detailed operations ofthe organisation.

Beware, though, that the BMM does tend to-wards that dangerous self-referential notion oforganisation as ‘the enterprise’ – particularlyin its handling of higher-level terms su as‘vision’ and ‘mission’. Remember that thereal enterprise here is always larger than theorganisation: the detail-layers of the BMMwork well enough, but take care at the top!

Store the results in the aritecture-repository either inrow-0 (for the vision and role, whi should probablynever ange) or in the upper rows of the ‘reason/decision’column (for missions and goals). Also note any addi-tional information requirements, risks and opportunitiesthat may arise, and save these to the respective repositories.


Values

Next, identify the required, espoused and actual valuesindicated for the organisation’s relationships in the enter-prise:

• What shared values are required from every playerin the overall enterprise, in order for that enterpriseto aieve success within the terms of its vision?

• What individual and collective values – either im-plicit or explicit – are required to support ea of therelationships and transactions in the organisation’sroles within the enterprise?

• What values does the organisation espouse, bothin its relationships with others and its relationshipswithin and to itself?

• What actual values does the organisation expressin its actions and relations with others and withinitself?

• Are there are any misalignments between required,espoused and actual values? If so, what impactsdo these differences have, on the effectiveness ofthe shared enterprise, of the organisation in relationto and with the enterprise, and the organisation’sinternal function and relationships within itself?

Identify required values from an assessment of what ‘effec-tiveness’ would look like in relation to the enterprise and


its vision: for example, fairness and trust will usually berequired in almost any functional enterprise.

Identify espoused values from the organisation’s AnnualReport or other public sources, su as an ‘About Us’ or‘Our Values’ section on a website, or publicity materialprovided to prospective employees.

Identify actual values from the behaviours or phrases ac-tually used within the organisation; note especially howthese may vary at different levels or in different parts ofthe organisation.

e SEMPER diagnostic can be valuable here,because it’s designed to identify the effective‘ability to do work’ from the kind of languageused to describe different aspects of the work-context. If the organisation claims that itvalues transparency, for example, yet peopleare using phrases su as “we’re just mush-rooms, fed sh*t and kept in the dark”, it doeskind of imply there’s a significant mismatbetween espoused and actual values! In someorganisations, the scale of mismat can behuge – with correspondingly huge impacts onthe organisation’s overall effectiveness, too…

A SEMPER analysis can be downright scary attimes, because of the ease with whi it sur-faces problematic issues su as those value-mismates; but it does also describe what to


do to resolve ea of those problems. You’llfind more detail on SEMPER in the book SEM-PER & SCORE, and also on the sempermet-rics.com²⁰ website.

Document the required and espoused values in the upper-most rows of the aritecture framework, and also as corerequirements in the requirements repository. Documentea values-mismat as a priority item in the risks register.

Principles

From values we move to principles, because the organi-sation’s principles describe how its values should be ex-pressed in practice. Values define the ‘pervasives’ forthe enterprise, but in themselves are somewhat abstract;whereas principles are – or should be – concrete, actionableand verifiable.

One key complication is that, by their nature, principleswill oen compete or conflict: transparency versus privacy,for example, or innovation versus the safety of ‘the known’.We need to document su clashes, and, wherever practica-ble, assign priority to one or other principle so as to simplifydecision-making in the field.

One useful principle, perhaps, is an anowl-edgement that although every person in the

²⁰http://sempermetrics.com

http://sempermetrics.com




enterprise is personally responsible for resolv-ing the balance of principles, no-one ever ac-tually aieves it – not in the real world,anyway!

e appropriate test there would not be ademand for an impossible ‘perfection’, butmore that all applicable principles were takeninto account, and that all reasonable effortswere made to resolve any conflicts, under theconstraints of the context.

Principles are not law as su, but in someways are almost above the law – they’re whatlaw is drawn from, in fact. Law describes howthings ought to work in theory; principles pro-vide guidance as to how to make things workin practice. In effect, a law is a pre-paagedinterpretation of principles: so whenever wemeet a circumstance where ‘the law’ – in theenterprise sense, as the organisation’s rule-book or whatever – doesn’t make practicalsense, we need to recognise the primacy of theunderlying principles.

at’s why the first principle in the TOGAFspecification is about the primacy of princi-ples: principles really do come first. But theyin turn express the enterprise values; and the


values themselves express the shared visionthat defines what the enterprise is. at’swhy all this perhaps abstract-seeming stuffmaers: because without it, the organisationhas no practical purpose. Whi is not a goodidea…

Principles form hieraries as they devolve down into thedeeper detail. But ultimately every one of them needs tobe anored ba into one or more values; and in turnevery value needs to be expressed in explicit, measurable,actionable principles:

• What principles apply in the enterprise? In whatways are these principles expressed and documented?

• What value or values does ea principle express?How would you confirm that those values are ex-pressed by the principles?

• Are there any principles – explicit or implicit – thatdo not seem to be anored in any espoused enter-prise value? If so, what values are implied by suprinciples? Do any su ‘shadow’ values conflictwith the espoused values of the organisation? If so,how, and whi values ‘win’?

• What principles express ea value? Is every es-poused value expressed within at least one hieraryof principles whi devolves all the way down to the


operations layer? If not, what principles would berequired to express that value?

• In what ways are ea principle applied, in theory,and in practice? What evidence exists that theyare applied? – or not applied? If not applied inpractice, what needs to be done to ensure that theyare applied? What metrics would be needed tomonitor and confirm this?

• What conflicts exists between principles? Whatguidance is provided to help people resolve suconflicts between principles in their own work?

For a first pass at this in an ‘aritecture demonstrator’project, you would probably only assess this at the mostabstract level; but in later reviews you’ll need to go mudeeper, sometimes right down to the fine detail of systemdesign and everyday operations. It’s only when values areexpressed as principles that they become meaningful asvalues: until then they’re just an abstract ‘nice idea’.

e TOGAF 9 specification includes a veryuseful section –Chapter 23, ‘Aritecture Prin-ciples’ – about principles and how to defineand document them. As usual, we’ll need tocompensate for TOGAF’s obsessive IT-centrism– su as its bizarre assertion that aritec-ture principles are a subset of IT-principles –but otherwise their recommended format fordefining principles works well in any context:


• name: represents the essence of the rulein a form that is easy to remember;

• statement : presents a succinct, unam-biguous summary of the rule;

• rationale: anors the principle ba tothe business reasons and business-benefitsarising from the principle, and ultimatelyto the core value or values that it repre-sents;

• implications: describes how the prin-ciple should be expressed in everydayactions or in influence on practical de-cisions.

“Essentially, principles drive behaviour”, saysthe TOGAF specification. It also adds a e-list of keywords for validating well-describedprinciples: understandable, robust, complete,consistent and stable; to these we should alsoaddmeasurable and verifiable, so that we havesome means to confirm that the principle hasbeen applied n practice.

Recommended, anyway.


Principles represent the core reasons and decisions of theorganisation, pervading the values throughout every layerand function, downward into the fine detail of systemsdesigns and individual actions. Document them in therespective rows of the ‘decisions’ column of the frame-work and in the requirements repository, as linked trailsof decomposition and derivation linked ba to the rootenterprise-value.

Business purpose

Finally, as a crosse, we come ba to purpose. e pre-vious parts of the assessment should have identified whatthe organisation believes its business purpose to be; we nowneed to e that against the reality. e difference cansometimes be painful, but nonetheless important to know…

Our guide for this is a phrase coined by the cyberneticistStafford Beer: “the purpose of a system is what it does”.In systems-theory terms, the organisation is a system inits own right, interacting with the larger ecosystem of theoverall enterprise. e vision, values and principles de-fine what the organisation’s purpose should be, in theory;Beer’s phrase – usually shown as its acronym ‘POSIWID’– indicates its effective purpose in practice, and hence theactual principles, values and, probably, vision.

e organisation states that health and safetyare key values, but the reality is that there


are high rates of accidents, illness and ab-senteeism. From POSIWID, we can be fairlycertain that those themes are not valued inpractice…

e organisation’s websites asserts the pri-macy of quality above everything else in itsproducts. But POSIWID shows us that themanagers believe the only thing that maersis ‘the numbers’ – and their bonuses reflectthat fact, too. Notice what impact this hason product-quality – and on overall effective-ness…

Values maer : yet we need to be clear whivalues actually apply in the enterprise, other-wise we have no means to identify when whatwe do really is ‘on purpose’.

Any values-mismat will lead to ineffectiveness: ea issomething we’ll need to address as an organisation – andhence needs to be documented in the aritecture gap-analysis.

• If “the purpose of the system is what it does”, whatreal principles and values are implied in what hap-pens in the organisation and in its relations with theoverall enterprise?


• Comparing the results with the values and prin-ciples already documented, what conflicts can beidentified? In ea case, do the espoused valueshave priority, or the actual ‘shadow’ values? Whatis the impact of ea values-mismat on overalleffectiveness?

Document ea mismat of values or principles as a high-priority entry in the risks-register.

The enterprise context

e purpose of this section is to establish the contextand expectations of the overall enterprise in whi theorganisation operates. is includes concerns su as legaland regulatory constraints, applicable industry and otherstandards, and the key ‘things’, locations and events thatcomprise the enterprise context.

On the people side, the skills you’ll need, as in the previoussection, are those for routine business-analysis. You’ll alsoneed access to a handful of ‘insiders’ who know the natureof the business fairly well – whi could be you, of course.

For planning, most of the information you’ll need wouldbe provided by those ‘insiders’: you could find it byslogging your way through documents and intranets andindustry reference-material, but asking the right people afew questions will be mu quier! e aim here is to


populate more of the framework’s upper rows, so you’llneed some kind of aritecture repository, as before.

e practicewould be based on standard business-analysisteniques, documented as described below.

As before, performance would be measured in simpleproject-completion terms, reporting ba to the projectsponsor.

Compliance, constraints, standards,expectations

In the previous section we’ll have identified the overallmilieu – the ‘vision’ – and the role that the organisationplays within it, whi identifies the effective requirements.In aligning itself to the vision, the organisation oosesconcomitant constraints implied by its values and prin-ciples. Here we explore the constraints that come in tothe organisation from the milieu, by dint of oosing toenact that role within the enterprise. ese include anylaws and other regulations that would apply; any requiredstandards from the industry, or needed for interaction withcustomers, suppliers, partners and other players in theenterprise; and expectations from the general communityabout corporate social responsibility and the like.

ese constraints will ea have differing degrees of ‘bind-edness’, and may vary in different jurisdictions, geogra-phies, communities and so on:


• What laws and other regulations apply in this busi-ness context? To what extent and in what ways arethey binding on the organisation? In what ways dothese vary in differing jurisdictions and the like?

• What constraints – and opportunities – do theseimply for the organisation and its business in theenterprise? What trade-offs do these imply againstthe business requirements?

• By what means would the business confirm its com-pliance with these constraints? What actions andinformation would be required? How would youmonitor and measure compliance? What wouldbe the consequences of failure to comply? Whatopportunities arise from the required compliancewith these constraints?

Note that these can be a lot more compli-cated than they may at first seem: some reg-ulations are binding across geographies, andsome jurisdictions assert their rea into othercontexts entirely. US regulations on te-nology export or money-laundering, for ex-ample, are deemed to apply throughout theentire supply-ain from source to end-user.And movement of staff may be restricted notonly by local residency-rules, but also somevery nasty booby-traps su as the way somecountries extend their citizen-obligations to


foreign-bornildren of former nationals. edefinition of ‘former national’ can be danger-ously blurry here, as one of our colleagues dis-covered the hard way in Greece aer movingthere on business: although he’d been born inAustralia, and a full Australian citizen, the factthat one of his grandparents had been Greekmeant he was also classed as a Greek citizen– and he was forcibly draed into compulsorytwo-year military-service there. Su realitiesare genuine risks for the globalised enterprise:we need to be aware of them in the aritec-ture.

Sudetails may notmaer toomuon a firstpass assessment, of course, but they certainlydo maer when we explore these concerns inmore depth in subsequent reviews.

Next we need to note the various standards that wouldapply in ea context:

• What standards – quality-standards, tenical stan-dards, interface standards, language standards andsulike – apply in ea area of this business context?To what extent and in what ways are they bindingon the respective areas of the organisation? In whatways do these vary in differing regions and the like?



• By what means would the business confirm its com-pliancewith the constraints of these standards? Whatactions and information would be required? Howwould you monitor and measure compliance? Whatwould be the consequences of failure to comply?What opportunities arise from the required compli-ance with these constraints?

And there are what wemight call ‘good citizen’ constraints,whi may not have the force of law or formal standardsbehind them, but can still impose serious sanctions in termsof reputation or cooperation:

• What social expectations and social standards – ethics,environment, general ‘good neighbourliness’ and soon – apply in ea area of this business context? Towhat extent and in what ways are they binding onthe respective areas of the organisation? In whatways do these vary in differing regions and the like?



• By what means would the business confirm its com-pliance with the constraints of these expectationsand standards? What actions and informationwouldbe required? How would you monitor and measurecompliance? What would be the consequences offailure to comply? What opportunities arise from therequired compliance with these constraints?

e SEMPER diagnostic might also be helpfulhere as an initial metric, identifying effectivesocial reputation via language-cues in descrip-tions of the organisation from the broadercommunity and other ‘external’ stakeholders.

Document the results in the respective parts of the ar-itecture repository: the constraints themselves in the‘decisions’ column of the framework, required metrics inthe ‘virtual asset’ segment, risks and consequences in therisks-register, and so on.

Assets, locations, events

In this part of the work we aim to fill out more of the coreparts of the framework, by identifying the assets, locationsand events that are central to the organisation’s businesswithin the enterprise.

ere are a lot of questions in this part, manyof whi may seem very unfamiliar – even


bizarre, perhaps – if your previous aritec-ture experience has been only in an IT-centriccontext. Don’t worry about it, though: allthese questions and categorisations do maer,as we’ll see later, but we don’t have to do it allin one go! If any part seems too alien to makesense, do the best you can for now, and allowthe questions to make more sense over time asthis mu larger picture of the enterprise startsto coalesce.

Later on we’ll need to go into all of this inmu more depth, of course, but for a first-pass this review would need only to capturethe most essential types of items – enoughto create some kind of top-level anor forsubsequent iterations of the aritecture cycle.

So first, assess the key asset-types:

• What types of physical assets – physical ‘things’ –are important to the organisation’s business? Whatroles do these assets play in the business – for ex-ample, as input supplies, as output products, or usedas consumables in business processes? What valuedoes ea type of ‘thing’ have for the business? Howare these assets obtained, maintained, monitored,managed through their life-cycle, and disposed-of atthe end of it?


• What types of virtual assets – data, information,knowledge – are important to the organisation’sbusiness? What roles do these assets play in thebusiness – for example, as records, as metrics, ascontent for delivered services, as controls in businessprocesses? What value does ea type of virtual-asset have for the business? How are these assetscreated, obtained, maintained, monitored, managedthrough their life-cycle, and disposed-of at the endof it?

• What types of relational assets – relationships withother organisations and actual people – are impor-tant to the organisation’s business? What roles dothese assets play in the business – for example, aslinks with employees, suppliers, customers, share-holders, regulatory bodies, other stakeholders? Howare these links used in business processes – suas through contracts and other agreements? Whatvalue does ea type of relational-asset have for thebusiness? By what means does the organisationidentify when relational-assets need to be created,or have been anged, damaged or deleted, by theentity at the ‘far end’ of the link? How are these as-sets obtained, maintained, monitored and managedthrough their life-cycle?

• What types of aspirational assets – the personalsense of belonging, commitment and shared-purpose– are important to the organisation’s business? Inwhat ways do others connect to the business –


for example, morale and commitment of employ-ees, customers’ sense of ‘belonging’ via a brand, orcommunity perception of reputation? To what doesthe organisation itself belong – for example, to anation, to an industry, or to the shared enterpriseas represented by its vision and role? What impactsdo these assets have in business processes su asin HR, productivity, marketing? What value doesea type of aspirational-asset have for the business?By what means does the organisation identify whenaspirational-assets need to be created, or have beenanged, damaged or deleted, by the entity at the‘far end’ of the link? How are these assets obtained,maintained, monitored and managed through theirlife-cycle?

• What types of other abstract assets – abstract con-ceptual entities su as finance, credit and energy –are important to the organisation’s business? Whatroles do these assets play in the business – for ex-ample, as access to resources for business processes,as measures of success, as relational factors in trans-actions? What value does ea type of abstract-assethave for the business? How are these assets obtained,maintained, monitored and managed through theirlife-cycle?

Document ea type in the upper rows of the respectivesegment of the ‘assets’ column in the framework.


In business we would oen talk about assetsand liabilities as if they’re different things.But in aritectural terms they’re actually thesame: a ‘liability’ is an asset that has been as-signed a negative value, or is a future promiseto deliver that asset. So if you come acrossreferences to liabilities, document them as ifthey’re the respective type of asset, but with arider to indicate the negative valuation.

Finally, some asset-types will only make sense as compos-ites: a paper form, for example, is a combination of physicalasset (paper) and virtual-asset (information-record). Wher-ever practicable, we need to be able to split these into theirbase-categories, to enable down-to-the-roots redesigns inthe more difficult aritecture concerns su as disaster-recovery planning; but in some cases su decompositionsmay not make any sense, and we’ll need to document thatfact:

• What types of composite assets – combinations ofany of the above ‘atomic’ asset-categories – areimportant to the organisation’s business? Whatare their base asset-categories? In what ways is itpossible – or not possible, in practice – to split thecomposite into its base-categories? What are theconsequences of not being able to split the compositeinto its base-categories?


Document ea of these as a composite that bridges therespective segments of the ‘assets’ column.

Next, assess the key types of location and their composites:

• What types of physical locations and their associatedlocation-semas – geographic, building-floor etc –are important to the organisation’s business? Whatroles do these locations play in the business – forexample, as retail contact-points, manufacturing lo-cations, physical storage, resource sites? What valuedoes ea type of location have for the business?How are these locations identified, obtained, main-tained, monitored, and managed through their life-cycle?

• What types of virtual locations and their associ-ated location-semas – networks, naming, web-addresses, contact-numbers etc – are important tothe organisation’s business? What roles do theselocations play in the business – for example, as vir-tual contact-points, as nodes for information routes?What value does ea type of virtual-location havefor the business? How are these locations identified,created, obtained, maintained, monitored, managedthrough their life-cycle, and disposed-of at the endof it?

• What types of relational locations and their associ-ated location-semas – su as market-segments,nodes in reporting-relationship trees and social-networks


– are important to the organisation’s business? Whatroles do these locations play in the business? Howare these locations used in business processes? Whatvalue does ea type of relational-location have forthe business? By what means does the organisa-tion identify when relational-locations need to becreated, or have been damaged or deleted, by theentity at the ‘far end’ of the link? How are theselocations identified, created, maintained, monitoredand managed through their life-cycle?

• What types of aspirational locations and their as-sociated location-semas – in particular, the end-nodes of aspirational-assets – are important to theorganisation’s business? What value does ea typeof aspirational-location have for the business? Howare these locations identified, maintained, monitoredand managed through their life-cycle?

• What types of other abstract locations and theirassociated location-semas – time and time-zones,for example – are important to the organisation’sbusiness? What roles do these locations play in thebusiness – for example, as reference-points for mea-surement of performance? What value does eatype of abstract-location have for the business? Howare these locations identified, maintained, monitoredand – where feasible – managed through their life-cycle?


• What types of composite locations – combinationsof any of the above ‘atomic’ location-categories –are important to the organisation’s business? Whatare their base location-categories? In what ways isit possible – or not possible, in practice – to splitthe composite into its base-categories? What are theconsequences of not being able to split the compositeinto its base-categories?

Document ea type in the upper rows of the respectivesegment of the framework ‘locations’ column, or as a com-posite bridging the respective segments of the ‘locations’column.

And assess the key categories of events and their compos-ites:

• What types of physical events are important to theorganisation’s business? What roles do these eventsplay in the business, as input- or output-triggers forroutine or exceptional business processes? Whatvalue does ea type of physical event have for thebusiness? How are these events identified, moni-tored and managed within an overall life-cycle?

• What types of virtual events – messages, signals,data-values – are important to the organisation’sbusiness? What roles do these events play in thebusiness, as input- or output-triggers for routine orexceptional business processes? What value does


ea type of virtual-event have for the business?How are these events identified, monitored andman-aged within an overall life-cycle?

• What types of relational events – arrivals, depar-tures, contacts, other events in relationships withother organisations and actual people – are impor-tant to the organisation’s business? What rolesdo these events play in the business, as input- oroutput-triggers for routine or exceptional businessprocesses? What value does ea type of relational-event have for the business? How are these eventsidentified, monitored andmanagedwithin an overalllife-cycle?

• What types of aspirational events – suas reputation-or public-relations events, or anges to brand – areimportant to the organisation’s business? What rolesdo these events play in the business, as input- oroutput-triggers for routine or exceptional businessprocesses? What value does ea type of aspirational-event have for the business? How are these eventsidentified, monitored andmanagedwithin an overalllife-cycle?

• What types of other abstract events – su as cy-cles of time – are important to the organisation’sbusiness? What roles do these events play in thebusiness, as input- or output-triggers for routine orexceptional business processes? What value doesea type of abstract-event have for the business?


How are these events identified, monitored andman-aged within an overall life-cycle?

• What types of composite events – combinations ofany of the above ‘atomic’ event-categories – areimportant to the organisation’s business? What aretheir base event-categories? In what ways is itpossible – or not possible, in practice – to split thecomposite into its base-categories? What are theconsequences of not being able to split the compositeinto its base-categories?

Document ea type in the upper rows of the respectivesegment of the framework ‘events’ column, or as a compos-ite bridging the respective segments of the ‘events’ column.

Functions and services

e purpose of this section is to establish what the organ-isation does, and the skills and experience needed to do it.

On the people side, the skills and people-contacts you’llneed will be mu the same as for the previous section,su as those for routine business-analysis.

For planning, most of the information you’ll need wouldagain come from those ‘insiders’; mu of it resides onlyin people’s heads, and oen you’ll find you’re the firstperson to write it all down. e aim here is to define core


content for the upper rows of the remaining two frameworkcolumns, ‘function’ and ‘capability’.

e practicewould be based on standard business-analysis.

And performance would again be measured in project-completion terms, as specified by the project sponsor.

Services

For this section it’s useful to take a ‘service-oriented’ viewof the enterprise, and assert that everything in an enterprisedelivers a service. As the ITIL v3 specification puts it,“Customers do not buy products: they buy the satisfactionof particular needs”. And we satisfy those ‘particularneeds’ through the services we provide. In that sense,products are proto-services that provide the end-customerwith a means to deliver a self-service: for example, avacuum-cleaner provides the service of cleaned floors.

is gives us a means to understand the mutual role ofenterprise functions and capabilities, because a service isa structured combination of function and capability. Oneway to model at a high level this primacy of services isthrough aResults Logic Diagram, whi constructs a trailof derivations from the end-result of the organisation’s ac-tivities – su as in the FEAF specification’s term ‘servicesto citizens’ – ba through the layers of internal servicesand their results, to the core functions of the organisation.

A mild warning: it’s very easy to misuse a


Results Logic Diagram to justify the existingstructure of the organisation – whi may befair enough, but that’s not really the pointhere!

What we want is a gap-analysis from ‘as-is’ to ‘to-be’, to identify potential for usefulange. But if we start the Results Logic fromthe ‘as-is’, by definition there would be nogap, and hence no real point – other than asa public-relations exercise, perhaps. Instead,first do it strictly as a ‘to-be’ analysis: imaginethat, given a perfect world, what business-functions and services would you need, tosupport all of the steps in the ‘results logic’?Once you have that, you can link across to the‘as-is’, to develop that gap-analysis that youneed.

To build the diagram, start from the enterprise vision asidentified earlier:

• Given the overall priority – the vision – for theenterprise, what are the key client-results for theorganisation’s stakeholder-groups – its equivalent of‘services to citizens’?

• For ea client-result, what are your respective enterprise-results – the measures or metrics by whi the


organisation confirms that it has aieved its ownoutcomes and the client outcomes?

• For ea enterprise-result, what is the tree of intermediate-results – the linked outcomes of subsidiaryMissions?

• For ea set of intermediate-results, what is thepremise – the set of core assumptions defining therole of a service-group?

• For ea premise, what is the service-group withinthe organisation that delivers that service or Mis-sion?

Given that hierary of results, we can then start to modelthe mating hierary of services that would deliver thoseresults. From there, we can identify common functions thatunderpin the services, and the differing capabilities thatactually deliver them.

Functions

e terms ‘function’, ‘capability’ and ‘service’ are oenblurred together, but perhaps the best way to understand‘function’ is to think of it in mathematical terms: a functionsu as a=func(x,y) implies that something is returned –oen in anged form – from the activity of the function.So to look for business functions, look for where somethinghappens in the business – in particular, where somethingis anged. Services describe what it is that the businessdelivers; functions describe what it does.


Because of this, a Function Model is one of the mostuseful tools in the entire enterprise-aritecture. We canuse it as a single-page summary of the business as awhole; we can use it as a base-map for all manner of othercross-references, from project-toupoints to costings toinformation-systems and process-flows; we’ve oen seenmanagers use it as a way to show new recruits where theirown work fits in with that of everyone else.

is is the one aritecture artefact that makesimmediate sense to everyone: it maers.

If you’re looking for qui wins and instantcredibility – whi you usually will be, atthis earliest stage of the game – then creatingeven a simple Function Model should be oneof your highest priorities. You’ll need also tohave done at least some of the work above, tohelp you make sense of the information as anaritect, but this is where other people willtend to sit up and start to take aritectureseriously.

For a first-cut you’ll probably only need a two-tier version, with perhaps a few hints towardsthe more detailed third-tier – more on thatin a moment. But you should be able toget together something useful and meaning-ful within even a couple of days’-worth of


trawling: so not only is it a valuable model,it doesn’t cost mu to do, either.

e model is a layered list of business functions, laid outas a visual summary of what the enterprise does. eaim here is to create a model that remains mu the sameas long as the organisation does that kind of work, so itneeds to be independent of any current assumptions aboutbusiness structure. So we start with the ‘to-be’ model, thedescription of the idealised enterprise, and then later workbawards to the ‘as-is’ to give us our gap-analysis.

ere are no set rules about layout: the ‘best’ model iswhatever best describes the business. Whiever way wedo it, though, it’s usually organised as a nested hierary,with three or four tiers of functions:

• Tier 1: major categories of business functions – keyaspects of what the organisation as a whole actuallydoes.

• Tier 2: clusters of related activities – the majorsupport-missions for the tier-1 functions.

• Tier 3: ‘activities’ or clusters of related tasks –typically the emphasis of a team’s or a person’s work.

• Tier 4: the individual tasks within business pro-cesses – the actual delivery-processes.


ere’s rarely enough space on a diagram for the tier-4functions, so they’re usually listed within a supporting textdocument.

Some industries already have their own genericfunction-models, su as eTOM for telcos, andSCOR for supply-ain and logistics. ey’llneed adaptation to the specific context of theenterprise, even within the respective indus-try, but they’re useful as guidelines in anycase.

To identify candidate functions and activities, trawl throughany available sources for information about points wherebusiness processes start and end, or wherever something isanged:

• org-art entries: ea role implies one or morebusiness functions – though they may overlap, or berepeated in multiple locations, or aggregate severaldistinct functions

• the organisation’s Annual Report: almost by defini-tion, this is supposed to list every major category ofbusiness activity

• references to projects: ea is likely to imply a new orupgraded capability, whi again implies a function


• references to phone-lines or other contact-points:these imply business-functions behind the points ofcontact

• business data-models: look for the implied functionsthat would create, read, aggregate, update or deletethe information-items

e other obvious source for information isthrough conversations with appropriate staff –though beware that they’re likely to want youto list every one of their tasks as a top-levelbusiness function!

Every business function does something, so ea function-label on the model should include a verb. For tier-1 andtier-2 functions you can get away with using abstractverbs su as ‘Provide’ or ‘Manage’, but for tier-3 or tier-4especially, you need to use more proper descriptive verbssu as ‘Receive’, ‘Assess’ or ‘Monitor’.

For tier-1 functions, ask:

• What are the major categories of business functions?

• How do these functions relate with ea other, interms of service-categories and service-layering?

Aim to define some six to twelve tier-1 functions. esewill usually be evident in the structure of the enterprise:


for example, every organisation will have a set of contact-points for customers and other stakeholders, a set of corebusiness-processes, a layer for strategy and management,and a set of business-support functions su as HR andfinance.

Functions: tier-1 example

Functions at tier-3 and below are relatively easy to identifyin the trawl through documents and the like. But tier-2functions are oen less obvious at first, and we’ll needto derive them from natural clusterings of tier-3 functions,su as implied by higher-level entries in the org-art,or groups of functions that reappear together in differentlocations. So for ea tier-1 category:

• What are the main clusters of related activities thatoccur within this category?

• How do these functions relate with ea other, interms of service-categories and service-layering?


Functions: tier-2 example

Expect to identify around 40 to 50 of these in total. eycan sometimes be found from job-titles: a tru driver, forexample, or a warehouse manager, who ea do a range ofrelated business activities and tasks. e org-art will alsogive some pointers on this, though again take care not totie the list too tightly to anything that’s likely to ange.

Every business function will use assets; take place in loca-tions; be linked by events; and be impacted by laws, rules,regulations, standards, constraints and other business rea-sons or decisions. So these in turn form a useful set of cross-es for ea function:

• What assets does the function use, create ange,update, delete, destroy? What category of asset,or combination of asset-categories, is involved inea case – physical, virtual, relational, aspirational,abstract? In what way does the function ange therespective asset? In that sense, what category offunction, or combination of function-categories, is


involved in ea case – physical, virtual, relational,aspirational or abstract?

• What locations are related to the function? Whatcategory of location, or combination of location-categories, is involved in ea case – physical, vir-tual, relational, aspirational, abstract?

• What events trigger or are triggered by the function?What category of event, or combination of event-categories, is involved in ea case – physical, vir-tual, relational, aspirational, abstract?

• What reasons or decisions apply to or impact on thefunction? What category of reason, or combinationof reason-categories, is involved in ea case – rule-based, analytic, heuristic guideline, or principle?

ere’s more detail on this, and on how totale the other two tiers, in the ‘Practice –Services and Functions’ apter in the com-panion volume e Service Oriented Enter-prise.

And there’s also a mating Visio stencil andtemplate for building a Function Model attetradianbooks.com/services-model²¹ .

²¹http://tetradianbooks.com/services-model

http://tetradianbooks.com/services-model

http://tetradianbooks.com/services-model


Again, keep it simple – at this stage this is only a firstpass, not a full detailed assessment. Gather whateverlevel of information seems useful, and document it as linksbetween entities in the aritecture repository.

Capabilities

Functions need to be linked to capabilities in order todeliver services. A function describes a required ange,but on its own has no way to enact that ange; and onits own a capability has no function – literally so. Yetwe do need to assess ea separately, because differentcombinations of capability and function deliver differentservices.

e specification for theArimate aritecture-notation standard includes a useful illustrationof this in its insurance-industry example.

• At the higher level, the client sees asingle insurance-claims service, imple-mented in several different ways – dif-ferent detail-combinations of functionand capability, but with the same over-all business-function – su as a web-interface, a call-centre, a retail store-front, a personal visit by a claims-adjuster,and so on.


• At the ba-office, there are two differ-ent serviceswith, again, similar business-functions: one handles claims for below$1000, the other function manages anylarger claim. e capabilities used toimplement ea would be different, be-cause different competencies apply: thelower-value claims can be handled viaa rule-based approa, implemented byIT, or by a trainee, perhaps; the higher-value claims require higher levels of skillsand experience, hence probably a humanprocess perhaps baed up by an IT-based decision-support system.

Same overall function, same overall businessservice, but with different business-rules, dif-ferent asset-types, different events or evendifferent locations, will oen imply a differentcombination of capabilities.

is points to the last of the framework columns, and thelast of the content that we need to populate in this first pass.To do this, we need to note that whilst Zaman describescapability as ‘who’, it’d be more accurate to describe it asthe real ‘how’ – the competencies, rather than the activities– of a business-service.

We’ve le this till last because it’s oen the most difficultof the lot. e reason is that capabilities inherently mergewithin themselves two sets of categories:


• the set used mainly for assets, but also for functions,locations and events: physical, virtual, relational,aspirational, abstract

• the set used mainly for reasons and decisions: rule-based, analytic, heuristic, principle-based

e former set indicate how and to what the capability isapplied; the laer set represent the required skill-levels:

• rule-based: no real skill required, can be imple-mented via training, or built-in within soware ormaine function

• analytic: requires analytic competence and usuallysome practical experience; may be built into so-ware, but at significant cost

• heuristic: requires genuine skill and practical experi-ence for context-specific interpretation; autonomoussoware systems possibly but at high cost and highcomplexity; IT is usuallymore effective in a decision-support rather than decision-making role

• principle-based: requires high degree of skill andability to cope with inherent uncertainty; not yetfeasible to build any IT-based system with this typeof capability

As mentioned earlier, there is some natural alignmentbetween these two sets of categories, but not enough that


they could fully substitute for ea other. So in effect weneed to map capabilities using a matrix between the twosets: a clerk might do only simple rule-based decisionson virtual data, whi could well be handled beer by asoware-driven process, but a maintenance engineer ormainist might require a high degree of skill with physicalobjects, for example, and be very hard to replace by ITalone.

Amoment’s calculationwould show that thereare at least twenty cells in that matrix: toomany to make it worthwhile to list all thepossible assessment-questions here. So forthis column, adapt and combine the previousquestions on assets, locations and events) withan assessment of skill-levels as above, to arriveat appropriate questions for ea cell.

e skill-level assessments will also indicatewhi capabilities can be implemented by IT,with relative ease, or more expensively, oronly with inordinate difficulty, or not at all.With lu, this should dissuade all but themost insanely over-enthusiastic IT-advocatesfrom aempting to build ‘solutions’ in con-texts for whi by definition they cannot fea-sibly work – whi should help to defuse someof the anger and angst so oen loed up in thebier relationship between business and IT!


From this, build a capability-map for the enterprise:

• What capabilities are implied as required by theResults Logic Diagram? How would you categoriseea capability, in terms of asset-type acted uponand required skill-level?

• What capabilities are implied as required by theFunction Model? How would you categorise eacapability, in terms of asset-type acted upon andrequired skill-level?

• What capabilities are implied by ea key asset-type, location and event identified in the previousassessments here? What is the required skill-level inea case?

• What capabilities are implied by ea key reason,decision, constraint, standard or sulike identifiedin the previous assessments here? What is therequired skill-level for appropriate decision-makingin ea case? What asset-types would be involved inea case? What events or functions would call forthis capability?

• Does the capability need to vary in different loca-tions? If so, what location-category is implied inea case?

Document the results of these assessments in the upperrows of the ‘capability’ column in the framework, togetherwith any cross-links as required.


is then completes the population of the base ‘holograph’in the framework – the pre-built aritecture that we’llneed in place before we can do any work under properaritecture governance. e final actions for this stepare to define all the governance processes and artefactsthat we’ll need for subsequent aritecture cycles, and themethods, tools and teniques by whi we will share andcommunicate the results of that work.

Architecture governance

e purpose of this section is to set up the formal gover-nance processes for the enterprise-aritecture capability.

I’ve placed this part at the end of this step,rather than at the beginning, because up tillthis point there won’t have been that muneed for aritecture governance – the workwill have been done under normal projectgovernance instead. But once we’ve proventhe value of the notion of aritecture – whiwe should have done by now, especially withthe Function Model – we’ll have to tale theneed for governance of the aritecture itself,in its own terms.

When you revisit this stage –whiyou shoulddo on a regular basis, probably at least once


or twice a year – you would of course alreadyhave all of the governance documents in place.For a revisit, it’s probably best to review themfirst, before doing any of the other work of thisstage. But for the first pass, we won’t need todo it until here.

Note that, from the business perspective, part of thatgovernance is formed by the processes through whi youengage others in the aritecture ‘conversation’.

On the people side, this is where we move out from desk-based business-analysis and start to engage with people ingeneral. e range of people you’ll need to work with willdepend on the osen scope – a smaller pilot, at the start,but eventually out to the entire enterprise – but people-skills in general will begin to come mu more to the forehere, rather than the analytic skills that have been the mainrequirement so far.

For planning, you’ll need some kind of ‘communicationplan’ as to how you will engage with the various stake-holders, and a formal process or elist for defining therequired governance.

e practice would be based on that communication plan,and the ‘governance for governance’ process.

If you’re familiar with TOGAF, mu of whathappens here is a simplified version of TO-GAF’s Preliminary Phase, combined with the


parts of its Phase A ‘Aritecture Vision’ thatdeal with overall setup for aritecture ratherthan the details for a single iteration.

One important difference is around scope. TO-GAF assumes that enterprise aritecture willalways be a major effort, encompassing theentire enterprise – or all of its IT, anyway. Butthat isn’t what happens in practice: if nothingelse, you won’t get the funding until you’veproven the business value. Instead, pi asmall area of the business as a pilot, and doyour initial governance-planning and the likefor that area alone. Once you’ve proven thevalue of the work, you’ll need to expand thescope – but at the start, keep it simple, andkeep it small.

And whilst performance would again be measured inproject-completion terms, as specified by the project spon-sor, perhaps a more important metric would be the indi-cations of acceptance and take-up of the aritecture bythe broader business community – of whi the FunctionModel would probably be the first example.

Creating engagement

For aritecture to be useful, people have to be willing touse it. And they’ll only be able to use it if they know


it exists – whi is why it’s essential for aritects tocommunicate what they do. Hence the importance of a‘communications plan’ and the like – and from there, oftools su as wikis and intranet websites to put that planinto practice.

Chapter 36 ‘Aritecture Deliverables’ in theTOGAF 9 specification includes an all-too-brief description of the role and content of anaritecture Communications Plan. As thatsummary states, mapping out the stakeholdersand their communication needs is somethingwe must do right at the start, in Phase A of thecycle – but we then need to use that plan, andkeep the dialogue going beyond the nominalscope of any single aritecture cycle.

e plan is only the start-point of engagement– and that engagement maers. Make it hap-pen!

Communication and engagement is the other side of thearitect role. e cat is that it’s mostly about people, notabstract analysis – and that demands a completely differentskillset from that we’ve used so far. For many enterprisearitects, dealing with all of the interpersonal politics andother ‘people-stuff’ is hard – but all of our previous workwill be in vain unless we do tale it. All those analysesand models and the like may be the babone of the work,


but the real aritecture – the place where the aritectureis literally ‘real-ised’ – is always through people. edialogue is the aritecture.

By the way, it’s wise here to expect that peoplewill tell you “you’ve got it all wrong”, orworse, with disparaging comments about yourcompetence – or la of it – thrown in for goodmeasure. Painful though this may be, it’s anatural consequence of the processes bywhipeople learn in a collective space: meaningemerges from a collective conversation aboutthe ‘unknown’, “I don’t know what I want,but I’ll know it when I see it”. Hence weneed something – almost anything, really –to initiate and guide that conversation. Whimeans that at the start of the conversation, theusual response is “I don’t know what I want,but I know that isn’t it” – or, in short, “you’rewrong”.

So don’t worry about it, and above all don’tover-defend your work: the aritecture is thedialogue, not just the end-result. Ask theiradvice, ask what you could do beer. at’show engagement happens: and when oth-ers become passionate about the aritecture,‘owning’ what they’ve co-created with you,you’ll know you’ve succeeded.


Yes, it can be intensely frustrating – insanely, hair-tearingly,mind-bendingly frustrating –when other people ‘just don’tget it’ in relation to the aritecture. But that’s our prob-lem, not theirs: if we want others to ‘get it’, it’s up to usto provide conditions under whi they can ‘get it’, wherethey can see the benefits of working with others in theenterprise in an aritectural way. Some typical reasonswhy they don’t ‘get it’ would include:

• “this aritecture stuff doesn’t make sense” – so weneed to find ways in whi it does make sense forthem

• “it doesn’t apply to our context” – sowe need to showwhere it applies, and why

• “it’s just theory” – so we need to show how it worksin practice

• “no-one bothered to ask us” – so we need to showwhere it does take their experience into account

• “it’s working now, why do have to ange it?” – sowe need to justify, in their terms, the requirementsbehind the ange

• “we don’t have time for this stuff!” – so we need toshow why they don’t have time to not do ‘this stuff’

• “why should we bother to help anyone else?” – sowe need to show why it’s in their own interest to doso


We can’t make the aritecture happen on our own: anenterprise is about shared goals, shared vision. So weneed to understand that whilst we may have nominalresponsibility for the aritecture, we don’t possess it: itbelongs to everyone in the enterprise. e aritecturewill only happen when people feel that they ‘own’ it too:not imposed on them from above, but something in whithey themselves are co-authors, co-creators. at’s whatengagement is about; that’s what it’s for.

is is one of the reasons why the Function Model isso important: it describes the enterprise in a way thatincludes everyone. Another reason is that it provides abasis for story – a story of the enterprise as a whole, as anecosystem. Ea business-process is the thread of a story;ea use-case and transaction is a story; with the FunctionModel we can show how these stories literally weave theirway across the organisation and the enterprise, touingdifferent business functions and services and capabilities,using the enterprise assets in different ways and in differentlocations, triggering other business events for differentbusiness reasons. e aritecture is a story: so to helpothers make sense of the aritecture, tell it as a story – anarrative whi includes them in the story.

Storytelling is a skill in itself, and one whosebusiness applications and business value areonly now beginning to be beer understood.One resource we’ve found useful for this, andfor practices on ‘narrative knowledge’ in gen-


eral, is the Australian consultancy Anecdote:see their website at www.anecdote.com²² .

Typical teniques for engagement include:

• publishing models and other artefacts – typically viathe aritecture-toolset

• running your own intranet-website, including wikisand other facilities for feedba– again, some aritecture-toolsets will support this requirement ‘out of the box’

• seminars and ‘public’ presentations across the enter-prise

• workshops for engagement with operations staff,particularly those with direct involvement in front-line business processes

• maintaining a ‘wating-brief’ relationship with se-nior staff, strategists, project-managers and othersinvolved in ange-management

• building working-relationships with those respon-sible for other ‘pervasive’ themes su as security,privacy, quality, health and safety, ethics and envi-ronment

It’s unlikely that you would use ea of these approaesin a first pass of the aritecture, but it’s worthwhile

²²http://www.anecdote.com

http://www.anecdote.com



considering all of the options from the start, as you’llcertainly need them later on.

In the ‘Completions – Closing the loop’ ap-ter in the companion volume Bridging theSilos there’s more detail on tactics for linkingwith knowledge-management, ange-management,quality-management, communities of practiceand other probable allies within the enterpriseto help us with these aspects of engagement.

Aritecture is a dialogue, not a monologue: so perhapsmost of all, listening is more important than talking. Peopleare likely to listen to what we have to say only if they feelthey too have been heard.

From this, two-way communication creates engagementwith people; and engagement in turn creates governance.More precisely, it creates the kind of governance in whipeople want to be involved, because the work has meaningto them. And that’s what we’re aiming for here: enterprisearitecture only becomes the aritecture of the enter-prise when the enterprise in general is engaged in everyaspect of its creation and use.

Creating the architecture capability

For the aritecture development so far, we’ve run it as astand-alone project, or embedded as part of another project.


We’ve reaed the first maturity-level, andwe’ve presentedthe results, as a kind of proto-aritecture. Everyone – wehope! – is happy with what we’ve done: we’ve proven thataritecture is indeed of value to the enterprise.

But that’s it: we’re done. We can’t do it this way again: itworks well enough for a first-pass, but it’s not sustainable– especially in terms of its governance. To take it further,we need to set it up as a proper enterprise capability, withproper governance and so on.

What follows will be sufficient to set you upfor the next step in aritecture maturity, butit doesn’t stop there, of course. Ea time youange the formal scope of your aritecture,or get ready to move up to another maturity-level, you’ll need to revisit this work, to reviewand update the aritecture capability and itsgovernance.

Depending on where and at what level you want to moveon to next, there can be quite a bit of work to do at thispoint – almost a mini-project in its own right, in fact. Butwhilst there’s fair bit to do – including a sizeable amount ofpaperwork, no doubt – it’s all straightforward, and for themost part already documented in the TOGAF specificationand other aritecture descriptions: you’ll need to tailor itto your own context, but that’s about all that’s required.We can summarise it as follows:


• you’ll need sufficient funding, equipment, work-space and other resources

• you’ll need the right people

• you’ll need an appropriate toolset and repositoriesand registers in whi to record and maintain that‘body of knowledge about enterprise structure andpurpose’

• you’ll need formal governance, including formal au-thority to engage others in the work

• you’ll need to define governance-artefacts to be cre-ated, updated and used within the aritecture cycleitself

It’s not really feasible here to describe how to obtain theright funding and resources: that’ll depend on the natureof the organisation, its organisational culture and structure,on the scope to be covered by the aritecture capability,and a whole host of other context-specific factors. All wecan say for certain here is that it’ll have to be done, andprobably done first. But having done all the previous workof this step, you should now be able to prove the potentialbusiness-value of aritecture – whi means it should bea lot easier than trying to argue the business-case fromscrat.

Finding the right people and bringing them on board will,again, be somewhat context-dependent. But by now –su as from the comments earlier, in the section ‘People –


governance’ in apter Preparing for aritecture – you’llhave a beer idea of the range of skillsets that’ll be neededfor the next stage: so again this should be easier thanstarting to build the right team from scrat.

Chapter 52 ‘Aritecture Skills Framework’in the TOGAF9 specification summarises theskillsets needed for IT-aritecture. It doesn’textend mu beyond that scope, but it does atleast suggest the probable skills and levels ofexperience needed at ea maturity-level fortrue whole-of-enterprise aritecture. Recom-mended.

e same applies to toolsets and repositories: we exploredthose issues in the section ‘Planning – frameworks’ inapter Preparing for aritecture. You should reviewthose facilities and capabilities there as part of this activity– for example, you’ll soon be needing a purpose-builtaritecture toolset if you’re not already using one, andyou’ll need to include a dispensations-register as part ofthe repositories for all further aritecture work. But it’sall straightforward enough: it just needs to be done – andpaid for, whi may be the hardest part!

e main work here will be around governance – inparticular, developing and documenting all the requisiteprocedures – and governance-artefacts used within thearitecture-cycle.


In the companion volume Bridging the Si-los, the apter ‘Completion – Aritecture-artefacts’ provides summaries of the purposeand content for most of the documents used inthemodifiedAritectureDevelopmentMethoddescribed earlier, in apter Preparing for ar-itecture. In the lists below, documents de-scribed or referenced in Bridging the Silos areshown with a number-sign (#).

ere’s also a whole section in the TOGAF9 specification – the Aritecture CapabilityFramework – that deals with governance andrelated documents, whilst its Chapter 36, ‘Ar-itecture Deliverables’, provides brief sum-maries of the purpose and content of a wholerange of typical aritecture-artefacts. eseare fairly comprehensive, but unfortunatelymany of the descriptions are scrambled byTOGAF’s obsessive IT-centrism – for example,its insistence that aritecture-governance is asubset of IT-governance – so we need to doa certain amount of translation before we canuse them in real whole-of-enterprise aritec-ture. (e specification is further scrambledin that it also includes descriptions of sev-eral documents that relate to implementation-governance rather than aritecture-governance– whi don’t belong there at all.) In the listsbelow, documents described or referenced in


the TOGAF specification are marked with anasterisk (*).

Typical governance-procedures and related documents foroverall aritecture governance include:

• Aritecture Governance # * and Aritecture Board* – defines the governance processes for the aritec-ture itself

• Aritecture Charter # * – identifies and defines theformal authority and responsibilities for aritectureas a business capability or business unit

• Aritecture Principles # * – identifies and describesthe principles used to govern aritectural decisions,with applicable higher-level principles included byreference

• Aritecture Standards # * – identifies and describesthe formal and other standards used to guide ari-tecture decisions and designs, with external stan-dards usually included by reference

Formal governance procedures and work-instructions willalso be needed formanagement of the aritecture-repository,requirements repository, risks and opportunities register,issues register, dispensations register and glossary andthesaurus. Since it’s likely, though, that these will alsobe shared outside of aritecture, their governance will


probably need to be beyond the authority of aritectureitself.

Typical aritecture-cycle governance-artefacts include:

• Request for Aritecture Work # * – describes thebusiness-questions and context to be addressed in anaritecture-cycle

• Statement of Aritecture Work # * – maintains arecord of all aritecture work and decisions in thecurrent aritecture-cycle

• Aritecture Roadmap * – overview of proposedanges arising from a large-scale aritecture-assessmentin ‘classic’ enterprise-aritecture

• Project-plan orMigration-plan # * – overview and/ordetailed description of a proposed project or portfolioof projects

• Aritecture Compliance Statement # * and associ-ated elists * (for IT only) – asserts the extent towhi a proposed implementation complies with thespecified aritecture, and describes reasons for anynon-compliance

• Aritecture Description Statement # – simplifiedAritecture Compliance Statement used in ‘hands-off’ aritecture (see section ‘Hands-off aritecture’in apterWhat’s next?)


• Aritecture Position Statement # – describes ari-tect’s recommended response to non-compliance inan Aritecture Compliance Statement or Aritec-ture Description Statement

• Aritecture Dispensation Statement # – describesaritect’s reasons for permiing a non-compliantimplementation, and recommendations for futurereview and resolution

• Phase__-completion reports # – describes the activ-ities and results of an aritecture-cycle Phase, andincludes stakeholder sign-off for the respective Phase

Governance will also be needed to manage some otherconcerns su as security and visibility of aritecturemodels, descriptions, frameworks, roadmaps definitionsand other products from the aritecture work.

You may need other governance processes and artefacts inyour own specific context, but these at least should serveas a start.

Resources

• TOGAF (e Open Group Aritecture Framework):seewww.opengroup.org/aritecture/togaf9-doc/ar/²³

²³http://www.opengroup.org/architecture/togaf9-doc/arch/




• Adapting TOGAF for whole-of-enterprise scope: seeTom Graves, Bridging the Silos: enterprise aritec-ture for IT-aritects (Tetradian, 2008)

• BusinessMotivationModel: see businessrulesgroup.org/bmm.shtml²⁴

• Vision, role, mission, goal: see Tom Graves, RealEnterprise Aritecture: beyond IT to the whole en-terprise (Tetradian, 2008)

• Visioning and purpose in service-oriented aritec-ture: see Tom Graves, e Service Oriented En-terprise: enterprise aritecture and viable services(Tetradian, 2009)

• SEMPER diagnostic and metric: see Tom Graves,SEMPER and SCORE: enhancing enterprise effective-ness (Tetradian, 2008)

• Online version of SEMPER diagnostic: seewww.sempermetrics.com²⁵

• ITIL (IT Infrastructure Library) and primacy of ser-vices: see www.itil-officialsite.com²⁶

• Arimate specification: see Arimate Practically(Arimate Foundation, 2007) andwww.arimate.org²⁷

²⁴http://businessrulesgroup.org/bmm.shtml²⁵http://www.sempermetrics.com²⁶http://www.itil-officialsite.com²⁷http://www.archimate.org

http://businessrulesgroup.org/bmm.shtml

http://www.sempermetrics.com


http://www.archimate.org

http://businessrulesgroup.org/bmm.shtml

http://www.sempermetrics.com


http://www.archimate.org


• Business storytelling and narrative knowledge: seewww.anecdote.com²⁸

²⁸http://www.anecdote.com



Appendix: Glossaryis summarises some of the terms and acronyms we’vecome across in the book.

ADM: acronym for Aritectural DesignMethod, themethod-ology used in TOGAF to guide development of enterprisearitecture

AriMate: a visual language used to model enterprise ar-itectures, developed by Netherlands consortium Telem-atics

aos domain: in the sensemaking framework, domainof inherent uncertainty and unpredictability; decisions areguided by principles and values; represented in the businesscontext by unique market-of-one customisation and bynon-repeatable maintenance issues; also useful when de-liberately invoked in creativity, in narrative and dialogue,and in foresight_teniques su as _scenario construction

complex domain: in the sensemaking framework, domainof emergent properties and non-linear relationships be-tween factors; decisions are derived from heuristics andguidelines; unlike aos, whi is inherently uncertain,may oen create an illusion of predictability, especiallywhere linear analysis is applied within a short-term, nar-row set of assumptions

complicated domain: in the sensemaking framework,domain of complicated yet identifiable cause-effect rela-tionships; decisions are derived from contextual analysis

126


DyA: acronym for Dynamic Aritecture, an enterprise-aritecture framework developed by Netherlands consul-tancy Sogeti

effective: ‘on purpose’, producing the intended overallresult with an optimised balance over the whole; requiresbroad generalist awareness of the whole, rather than thenarrow focus required to create local efficiency, henceoen contrasted with efficient

efficient: ‘doingmore with less’, creating the maximum re-sult with minimum use or wastage of resources in a specificactivity or context; improved incrementally through activelearning and related teniques for feedba and reflection,although major improvements usually require a ange inparadigm

emergence: context within whi cause-effect paernscan be identified only retrospectively, and in whi ana-lytic teniques are usually unreliable and misleading

enterprise aritecture: a systematic process to modeland guide integration and optimisation of the information-tenology of an enterprise or (at higher maturity-levels)the entire enterprise

FEAF: acronym for Federal Enterprise Aritecture Frame-work, a framework and methodology developed for enter-prise aritecture by the US government

goal: a specific objective to be aieved by a specified pointin time; emphasis on the physical or behavioural dimensionof purpose, contrasted with mission, role and vision


mission: a desired capability or state to be aieved,usually within a specified timeframe, and to be maintainedindefinitely once aieved; emphasis on the relational and,to a lesser extent, the virtual dimensions of purpose, con-trasted with goal, role and vision

narrative: personalised and oen emotive expression orinterpretation of knowledge, as history, anecdote or story

optimisation: process of integration in whi efficiencyin different areas is traded-off and balanced for maximumeffectiveness over the whole, between different layers andsub-contexts su as departments, business processes andbusiness units

principle: a conceptual commitment ormodel, the conceptual-dimension equivalent of value

purpose: an expression of individual and/or collectiveidentity - the aspirational theme of “who we are and whatwe stand for”; incorporates distinct dimensions of vision,role, mission and goal

recursion: paerns of relationship or interaction repeat orare ‘self-similar’ at different scales; permits simplificationof otherwise complex processes

role: a declared focus or strategic position within the‘world’ described by a vision; emphasis on the conceptualand, to a lesser extent, the relational dimensions of purpose,contrasted with goal, mission and vision

scenario: an imagined future context, developed for thepurpose of understanding both the present context and


options for action in the future context

simple domain: in the sensemaking framework, domain ofcertainty and known cause-effect relationships; decisionsare predefined by laws, rules and regulations

strategy: ‘big picture’ view of an action-plan for an or-ganisation to implement a purpose, usually emphasising itsvision, role and mission components; contrasted with thetactics required to execute the plan

tactics: detailed missions, goals and other step-by-stepactivities to execute a strategy, or some segment of anoverall strategy

TOGAF: acronym foreOpenGroupAritecture Frame-work, an IT-oriented framework and methodology forenterprise aritecture developed collectively by membersof the Open Group consortium

value: an emotional commitment – ‘that whi is valued’,either individually or (in an enterprise context) collec-tively)

vision: description of a desired ‘world’, always far greaterthan any individual or organisation; described in the presenttense, yet is never ‘aieved’; emphasis on the aspirationaldimension of purpose, contrasted with goal, mission androle

visioning: generic term for the process of identifying,developing and documenting vision and values, leadingtowards strategy and tactics


Zaman framework: a systematic structure for categori-sation of models within an IT-oriented enterprise aritec-ture, developed by John Zaman

Doing enterprise architecture - Leanpubsamples.leanpub.com/tb-doingea-sample.pdf · 2014. 2. 8. · England h p:// FirstpublishedApril2009 ISBN978-1-906681-18-0(paperba ) ... plant

Documents