Tom Graves / Tetradian

One of the most essential tasks in enterprise-architecture is that of enabling conversations on architectural issues, with any groups of stakeholders, anywhere across the enterprise.

Our toolsets play an important role in those conversations. The right tool used in the right way can really help the conversation, help create new shared understandings across the silos and the specifics of each distinct discipline.

But the wrong tool – or even the right tool used in the wrong way – may instead act as a real barrier against awareness and understanding. Getting the balance right is critical to creating the clarity we need – yet the requirements, and the balance, are different for every type of architecture-conversation.

We’ve long had a good range of frameworks and toolsets for IT-oriented architectures. Some were aimed more at systems-development; others more at taxonomy and ontology and metamodel-development; others again at modelling dependencies across IT systems and ‘business/IT-alignment’; and yet others at requirements-traceability, governance and project-management. Yet they all had one thing in common: their whole focus was about precision, about certainty – because that’s what system design and development really needs.

But as enterprise-architecture at last begins to break out of the IT-centric box that it’s been trapped in for the past couple of decades, we start to hit up against some real limitations of those toolsets:

• most of the underlying metamodels and model-types are still very IT-centric
• user-interfaces are usually complicated, abstract, often intolerant of error, and in some cases even downright ‘user-hostile’
• most of the tools – especially at the high-end – are too expensive for general use
• diagramming is usually abstract (‘boxes and lines’) rather than ‘real-world’ (trucks, people, machines, servers, cables etc)
• support for versioning and for tentative ‘what-if’ experiments ranges from poor to non-existent
• none of the user-interfaces are well-suited for use in real-time exploratory conversations

There’s also still no common exchange-language to transfer architecture-information between the tools that we already have – and even when we get one, we’ll need it to go wider than that, anyway. A lot wider.

When we look at how we actually work with executives or process-designers or security-architects or the like, the tools we most often use at present are a whiteboard or a sketchbook – nothing else has the flexibility that we need. None of the existing tools allow us to play ‘what-if?’ as well as we can on a whiteboard; and the precise formal rigour of model-validation is far more of a hindrance than a help in this kind of work, where half the time we don’t even know what kinds of architectural-entities are involved – the whole point is that that’s what we’re aiming to find out!

But we still need some kind of toolset-help here: images on whiteboards and sketchbooks aren’t easy to share – I’ve often seen people simply photograph the results and pass the image-files around as ‘the model’ – whilst office tools such as Visio and Powerpoint give a spurious illusion that the results have been captured with enough rigour to be re-usable (which they’re not), and are usually too slow and cumbersome for an across-the-table discussion anyway.

So here’s our challenge: develop a toolset for the ‘conversations’ end of the enterprise-architecture spectrum – one that will work on laptops and netbooks, on the new tablet and touchpad systems, and preferably right down to smartphones as well.

It needs to be able to cover any aspect of enterprise-architecture – from business-models to skills to security to process to disaster-recovery to operations to knowledge-management to applications to service-management to IT-infrastructure to building-infrastructure and anything in between.

It needs to be able to adapt itself to the needs and worldviews and language of each of those groups of stakeholders – and provide some means of translation between each group, too.

It needs to be fast, easy to use, engaging, enjoyable, preferably tactile too – yet have a fully-structured methodology and metamodel behind it.

It needs to allow freeform development of models and diagrams – yet still be capable of linking to the formal rigour of the ‘top end’ systems.

Coming the other way, it needs to help us explain the structures and reference-models that we already have in our ‘top-end’ systems – and explain the reasoning behind those models, too – whilst still keeping people actively engaged in the conversation.

And more and more, architects are beginning to recognise that spurious certainty is a real risk for the enterprise – so this also toolset needs to help our stakeholders become more comfortable with uncertainty and change.

Working with a loose consortium of colleagues – including Adrian Campbell, Kevin Smith, Milan Guenther, Nigel Green and others – we’ve done a fair bit of work on this already:

• preliminary metamodels and file-structures
• probable user-interface workflows on tablet (mouse/stylus) and touchpad (finger) interfaces
• probable user-experience interactions in multi-stakeholder conversations
• some suggested methodologies
• some key features, such as AudioNote-style synchronised voice-recording and Prezi-style zooming ‘infinite’ workspace
• support for a broad user-extensible range of model-types – potentially-unlimited, including user-defined types
• support for indefinite nesting/layering of models and model-types
• support for freeform-drawing, notes, embedding of user-selected icons and images
• support for reports that enable us to describe some or all of the enterprise as a story

There’s a lot more to do to get this even to an alpha-release state in any format or platform; and whilst all of us, in the group so far, have ‘done our time’ in software-development and the like, none of us is sufficiently available (or, in my case at least, really up to the speed or quality needed) for professional-level app-development on current systems. So we’re going to need help to make this happen.

I for one would prefer to see this as an Open Source or at least freeware/shareware type of development, so as to get this out into as general a usage as possible. (As I see it, this kind of toolset should have many other applications outside of enterprise-architecture, such as in strategy-development, tactical planning etc.) But if some commercial developer wants to take it on, that would be fine too, as long as we can keep the final end-user cost down to app-levels (perhaps $10-30 at most) rather than the three-, four-, five- or even six-digit sums we sometimes see for other toolsets.

So: over to you. Any offers of help or advice? Any other comments or suggestions?

A couple of weeks back, Gabriel Morgan of Microsoft’s internal Enterprise Strategic Planning unit posted an article on what he described as a ‘breakthrough’ in enterprise-architecture, “A Breakthrough: Maturing EA to be a Catalyst to Transform the Company“:

It’s time to rethink enterprise architecture people. Well, at least here in Microsoft IT’s Enterprise Architecture Team it is.

… For the past year or so, I’ve led a crack team of experts focused on aligning IT and the Business, and from this journey I wanted to share with you my current thinking. My team is called Enterprise Strategic Planning and it is a service team dedicated to enterprise-wide strategy and planning. Our initial goal is to become critical to the planning process with the intention of providing data to qualify an optimal set of IT Programs to invest in. … In this article I wanted to share with you something that has occurred to us during our journey and describe some changes we are making that I think is ground-breaking in the Enterprise Architecture domain.

Assuming a primary goal of EA is to align IT to the Business, the problem is that most, if not all, EA Frameworks are not equipped to actually deliver on this goal. They are limited to drawing associations from IT things … to Business things … . Some of the more mature EA teams have partnered with their finance department to apply financial modeling … to these associations to help describe business value in monetary terms and possibly start a chargeback model. These are all great accomplishments but at best they only capture how IT ‘relates’ to the Business. That is, these EA Frameworks and methods are more about IT transparency, not alignment.

I would have to admit that my first response to this would best be described as ‘unprintable’…  (The polite version of ‘unprintable’ would look at certain key phrases in the above, such as “It’s time to rethink enterprise architecture, people”, “a crack team of experts” and “Assuming a primary goal of EA is to align IT to the Business”, and thence to make extremely disparaging remarks about Microsoft, about apparent arrogance, about a supposedly innovative company being literally years behind the leading edge of enterprise-architecture, about breakthroughs that aren’t, and about the vapidity and shallowness of IT-centric assumptions… Oh well…)

My second response, after I’d had a chance to calm down a bit, was perhaps a bit more charitable, if still more than a little sarcastic: something more along the lines of “Welcome to the club, glad to see you’ve woken up at last, any chance we can actually talk about enterprise architecture?” – because to most of us who have been working at that leading edge of EA-development, this supposed ‘breakthrough’ is very old news indeed. It’s actually the understanding that existed decades ago, before IT-architects came in and hijacked the entire industry; several of my IT-oriented clients had each reached that same point independently half a decade or more ago; and even the Open Group, after we’d nagged and bullied and cajoled them for so long, finally ‘got it’ late last year, with “evolving EA from IT to business” now becoming an explicit key theme of current Open Group (TOGAF) conferences. So in terms of the overall EA industry, there’s not a single thing that’s actually new in that Microsoft ‘breakthrough’: and hearing someone call it a ‘breakthrough’ is frustrating in the extreme.

But that second response still misses the point: this actually is a breakthrough – for Microsoft. Which, because of who Microsoft are, means that it’s also a real breakthrough in another sense as well.

Yes, it’s frustrating to note that, from what appears in the article, Morgan and his group seem not to know that much about any ‘prior art’ – not even from other Microsoft EAs such as Nick Malik, who writes a very good ‘Inside Architecture‘ column at the same MSDN weblog-host, and is even listed in the links on Morgan’s weblog. Yet there is real change here: important change. Take a look, for example, at the business-architecture references that Morgan lists later in the article:

• Porter Five Forces
• Balanced Scorecard
• Business Model Canvas
• Geoffrey Moore ‘Core vs Context’

There’s no IT directly involved in any of those models (unlike, say, Ross, Weill & Robertson’s much-lauded ‘Enterprise Architecture as Strategy‘, which still takes a strongly IT-centric view of business-strategy). For someone like Microsoft, whose whole business-focus is and revolves around IT, that absence of IT-centrism is huge… definitely a real breakthrough.

I also need to remember that my own role in enterprise-architecture is very different from theirs. Morgan and his team are practitioners, dealing with the day-to-day realities of real-world architecture in a very large organisation. I’m a practitioner, too, yes, but my own work these days is mostly about setting-up architecture practices, troubleshooting, and doing practice-refresh for existing architecture groups – it’s consultancy, not mainstream production-level architecture. So although I’m a practitioner, my practice is mostly about theory, futures, creating new tools and techniques: which means that if my work isn’t well ahead of the mainstream, I wouldn’t be doing my job properly. Yet that view gives me a rather jaundiced perspective of the industry: too easy to forget that it does take years – several years at least – for the ideas and themes and concepts that we’re working on now to filter down into everyday EA practice. In short, too easy for me to become arrogant about what I see as other people’s ‘arrogance’… Oops…

Coincidentally, Gartner published their current ‘EA Hype Cycle’ this week, described in a press-release and a one-page graphic. They state that there are now two distinct generations of EA: the ‘traditional’ IT-centric one, which has now reached what Gartner term ‘the Plateau of Productivity’; and an upcoming “more business-focused” version that will help to prevent EA from falling permanently into ‘the Trough of Disillusionment’.

To me, though, these two ‘generations’ respectively represent maturity-levels 2 (“clean up the mess”) and 3 (“top-down strategy”), out of five distinct maturity-levels, as described in my book ‘Doing Enterprise Architecture‘. There are at least two more ‘generations’ to go before we reach a fully usable architecture for the enterprise; and, worryingly, far too few architecture-teams seem to have properly implemented maturity-level 1 – “what business are we in?” – which in the longer term places the entire architecture at risk. (It’s not adequately addressed in either TOGAF or FEAF: TOGAF 9 does sort-of include part of it in a kind of half-baked form in the muddled mess that it describes as ‘Business Architecture’, but that’s about it. To me, the only major framework that does cover it properly is Kevin Smith’s Pragmatic EA, which is still not as well-known as it deserves to be.) So there’s a long way still to go – and a lot of repair-and-refresh to do, too, to clean up the problems caused by the IT-centrism of the existing ‘enterprise’-architecture frameworks.

But I’m wondering just how much this article of Morgan’s should change the view that Gartner shows us. Gartner shows ‘Business-Driven Architecture’ as having only just reached ‘the Peak of Inflated Expectations’: yet the TOGAF conferences, and now Morgan’s article, seem to show it much further on, more like the start of ‘the Slope of Enlightenment’. Fact is that Microsoft is just about as mainstream as they get: so if Microsoft’s EA has now turned beyond IT-centrism to a more explicit whole-of-business focus, what it really tells us is that business-driven architecture has just gone mainstream.

It’s still not a ‘real’ enterprise-architecture as I would understand the term: but it’s a heck of a lot better than than the old IT-centrism. That is a real breakthrough – and very good news indeed.

Watch This Space, at last?

(Another example of How To Lose Friends And Infuriate People, no doubt, but this does have to be said.)

[Update: this post was a reaction to a tweet I received yesterday, but Mike T. (@miket0181) tells me that the IBM CBM described here isn't new, in fact is apparently some years old, so my complaints on that regard are unfair. (Doesn't help that IBM don't put up any dates on their website-posts.) On that part, yes, I ought to apologise, and do - see 'How to screw up in one easy lesson...'. Yet the core critique still stands: it's not a complete model, and potentially is dangerously misleading if used as the basis for a business-architecture. That's my view for now an' I'm stickin' to it, anyways. ]

A couple of weeks back, as part of the ‘Patterns‘ section in the Enterprise Canvas series, I put up a an example of a variant of the Canvas which I said was definitely dysfunctional, all but guaranteed to be ineffective, and definitely not recommended – a kind of Taylorist-style model of the organisation and its (non-)relationship with its business-ecosystem:

I said explicitly that it was a stereotype, almost a parody – a guide as to how not to view an organisation, with quality-management and coordination subsumed into ‘management’, and rigid separation between the organisation and its broader shared-enterprise.

I was quite certain that no-one would be daft enough to try to model any real organisation in that way.

I was wrong.

Welcome to IBM’s new Component Business Model, where the organisation’s business-world is partitioned into just three layers: Direct, Control, Execute:

I’m going to have to be rude here, and describe this as a kind of ‘bastard child’ of Taylorism and TOGAF, combining many of the worst features of both and not many of their best. The one good item, and a definite improvement on TOGAF, is that the model does explicitly include People as well as Process and Technology:

Using the Component Business Model methodology, our consultants identify the basic building blocks of your business. Each building block includes the people, processes and technology needed by this component to act as a standalone entity and deliver value to your organisation.

But beyond that? – well, let’s compare it to Stafford Beer’s Viable System Model, which I regard as the minimum requirement for whole-of-business modelling:

• system-5, ‘policy / purpose‘ – uh… might be tucked away somewhere in IBM’s ‘Direct’?
• system-4, ‘outside / future‘ – sort-of in IBM’s ‘Direct’, but no reference to ‘outside’?
• system-3, ‘inside / now‘ – yup, right there in IBM’s ‘Control’ – lots of it
• system-3*, ‘monitor / audit‘ (including overall quality-management) – nope, not a sign of it – presumably squeezed into IBM’s ‘Control’?
• system-2, ‘coordination‘ – nope – no sign of it anywhere
• system-1, ‘operations‘ – yup, that’s IBM’s ‘Execute’ – probably…

In terms of the Enterprise Canvas model above, all it has is Staff-Management (what should be the guidance-services, but all scrunched up together in a nearly-unusable way), Line-Management (the Value-Management cell, blown up out of all proportion to its actual relevance) and, uh, Everything-Else…

In other words, there’s probably less than half of what’s needed to make sense of the organisation – but presented as if it’s the whole of it, much like TOGAF’s hopelessly-IT-centric model purports to be ‘enterprise’-architecture.

The four other worked examples are slightly better, but still dangerously incomplete: a Taylorist manager’s-eye view of the business-world, without any clue as to any of the glue-functions that hold it all together. You’ll also note that each one of those examples has a very different structure in its ‘horizontal’ axis – but no indication at all as to how it’s derived. Presumably only IBM’s own consultants could be considered competent to understand the ‘magic sauce’ needed to do this, and the rest of us mere mortals may do nothing else but bow down in awe?

What’s also irksome is that IBM have the temerity to present this as something ‘new’:

IBM’s Component Business Model is a new way of looking at your business. It represents the entire business in a simple framework that fits on a single page. It is an evolution of traditional views of a business, such as business unit, function, geographic or process.

Fact is that this is nothing ‘new’ at all: okay, it might seem new to IBM, but not to just about anyone else in ‘the trade’. We were doing it more than half a decade ago in Australia Post – certainly 2004, and probably earlier. It was only a Visio hack, but in business terms it proved straight away to be one of the most valuable artifacts from our Business Transformation team: just about every single manager in the whole organisation grabbed hold of their own copy and placed it, much annotated, above their desk. Since then I’ve done one or more of these models for just about every one of my enterprise-architecture clients: you’ll find a couple of (de-identified) examples in that VSM slidedeck referenced above, and in probably half of my other TOGAF-conference presentations over the past few years. I even published the instructions on how to build an ‘organisation-on-a-page’ map, complete with Visio templates, on my Tetradian Books website some two or three years ago. Aleks Buterman and his colleagues have had their own generic version – which they call an Enterprise Architecture Capability Map – up on their website for almost a year now. And it’s even built into some of the EA toolsets, such as Troux Metis, and, I believe, IBM’s own System Architect, and again has been so for years. So what’s ‘new’ about it? Nothing, frankly – other than the fact that IBM have finally cottoned-on to what the rest of us already knew anyway.

And I hate to think how much they charge for this ‘new’ approach… a lot, no doubt…

Sorry, folks, but I’d have to say I’m underwhelmed at all of this. Seriously underwhelmed. Oh well.

Bah.

This is a fairly full collection of tweets over the past few days from the Open Group enterprise-architecture conference over the past few days – more detail on the conference-programme here. It lists most items posted under the #ogrome hashtag: I’ve left out a few RTs (re-tweets) and administrative items, but otherwise it’s pretty much all there.

There’s also a lot of it – at least a couple of hundred tweets – so it’s best to put in a ‘Read more…’ link at this point:

Read more…

Running a bit late this time due to self-imposed pressure to get a book complete. But it’s the same old miscellany of a week’s-worth of Tweets and links, sorted into the same old categories, preceded by the same old ‘Read more…’ link.

Read more…

Reading James Taylor’s recent piece “Business rules are king“, pretty much every one of my enterprise-architecture alarm-bells went off.

Yes, it’s a good article – recommended reading. And I would strongly agree with its implication that there’s a real and urgent need for discipline around business-rules. But the reason for the alarm-bells is that it’s promoting business-rules as ‘the answer’ – and for the most part IT-based ‘business-rules engines’ at that.

Which us places straight back in Taylorist territory, along with all those other classic IT-driven business failures such business-process re-engineering. Not a good idea…

The reasons why it’s not a good idea are three-fold:

• placing all the business-rules into an automated system will lead to a ‘fit and forget’ attitude unless there is a very strong emphasis on rule-maintenance – one of many ‘human factors’ that were forgotten about in BPR’s rush to ‘IT-ise’ all business processes
• identification and codification of business-rules assumes that the rules that can be derived from the people who run the existing processes are sufficient, invariant, accurate and complete – which, as early-generation knowledge-management also discovered, they rarely are…
• the viability of using automation for decision-making is dependent on the context – a fact of which frighteningly few IT-system designers seem to be aware

There seems to be a view that everything can and must be reduced to simple rules, following a cart-before-horse thinking that everything should be done by IT, and simple rules are what IT handles best. In other words, dangerously back-to-front. It’s bad enough trying to get anything useful out of IT for decision-support; but using IT for all decision-making – which is the ‘nirvana’ that the article would evidently prefer – is likely to be lethal. And I don’t quite know what we as enterprise-architects can do to prevent this headlong rush into repeating the exact same mistakes as in BPR and the rest – all that’s different this time is that it’s more explicitly coming from the ‘rules’ part of the process, rather than process-implementation overall.

This is clear if we look at it from the perspective of context-space mapping:

The point is that there’s a spectrum of abstraction of rules: principles sit at the low-abstraction end of this spectrum, rules sit at the high-abstraction end – in fact a conventional ‘rule’ is actually an extreme abstraction of a principle that applies to a specific context. If we try to use the wrong level of abstraction, especially in the wrong context or wrong type of context, we are all but guaranteed to hit serious trouble. And I see little to no awareness of that fact in most of the current literature on business-rules: instead, there seems to be an assumption that just about everything can be reduced to simple binary rules that can be implemented by simple IT, because that’s what we want to happen. In other words, the entire approach seems driven by little more than wishful thinking – which again is not a good idea…

IT-systems and simple business-rules work well together: both operate on a binary true/false logic, and both will enable high-speed binary-logic decision-trees – in other words, over on the lower right-hand side of the usual Cynefin-derived context-space base-map.

Most IT-based analytics – over on the upper-right of the base-map – work on the same binary logic as the simple systems, but introduce the ability to handle more and more layers of complication. The catch is that each layer of analysis takes a finite amount of time – which takes it further away from the ‘Now!‘ demanded by real-time decision-making. And the only real result of increased computing-power has been to increase the levels of complication in the analytics, sometimes beyond anyone’s ability to understand it – as was the case with the software systems used in many of the risk-calculation models that drove the current financial crash.

IT-systems are still not good at handling non-binary modal-logics – “the logic of probability, possibility and necessity”, such as expressed in the MoSCoW set of requirements-priorities of must, should, could and can wait. Humans are very good at modal-logic; IT isn’t. James Taylor’s article refers to pattern-based decision-making, which places it somewhat on the upper left of the base-map – but note again that each pattern-match must always take a finite amount of time, and it does not fit well with the underlying binary-logic of current IT-systems. Using IT as decision-support for human decision-making is generally okay, but the more that IT is involved, the higher the risk of what Dave Snowden describes as ‘pattern-entrainment’ – in other words, premature selection of a pattern, trying to force-fit a pattern to the context rather than ‘listening’ to the context itself. Current IT is getting much better at near-real-time pattern-matching, such as face-recognition or smile-recognition on most present-day digital cameras. Yet as anyone who’s used such systems would know, they’re nowhere near accurate enough to decide when a picture is actually any good – and sometimes we don’t want a smile in the picture. Much the same applies in business: using automated pattern-matching is great for decision-support, but extremely dangerous for decision-making.

And no IT-system is likely to be much good at dealing with real-time chaos, ‘the new’, where no possible pattern exists because it is new – but again, real people can handle decision-making in such contexts via skills and principles. In those contexts, there are no rules – and yet business-rule proponents seem to promote the delusion that their ‘business-rule engines’ can handle everything.

So I’m wary: very wary. Before letting any of such systems loose on any real-world context, I would want to make very sure that they’ve done the appropriate context-space mapping, and matched the decision-making methods to the respective contexts. But I don’t see much evidence of that: what I see instead is way too much wishful-thinking, and an almost desperate desire on both the business-side and the IT-side to try to force the world to fit their respective delusory dreams of ‘order’ and ‘control’. Oh well… Guess we have to wait and let them fail yet again, even more expensively, and then set out to tidy up the mess? – though I do worry that we’re getting close to the point where we’re no longer able to afford such expensive mistakes, in any sense of the word…

Another weblog item that’s been triggered by a question on Twitter, though in this case it came via a personal ‘direct message’ from Australian enterprise-architect Mike Aikins (@AussiMike):

Surely there are groups focused on the art and discipline of strategic planning and execution? How can we coalesce #entarch and these groups

Often there will be several “groups focused on the art and discipline of strategic planning and execution” – or there should be, at any rate. It’s true that enterprise architecture – and especially IT-architecture – will often be landed with a strategic role, though I would suggest that that’s more by default than by actual understanding of what EA is or does.

(Once again this has turned out to be a long explanation, so read on after the ‘Read more…’ link.)

Read more…

The current week’s-worth of assorted Tweets and links, in the usual categories, and with the usual ‘Read more…’ link to open ‘em up.

Read more…

Yet another longish one about enterprise-architecture (EA) and related themes – skip over it if that’s of no interest, otherwise click the ‘Read more…’ link to what follows.

Read more…

A few days ago my colleague John Polgreen posted an article of mine Adapting the ADM for Government Architectures on his ‘TOGAF for Feds’ blog on the (US) Government Technology Research Alliance (GTRA.org) website. The main theme was that to make TOGAF work well for non-information-centric government agencies and similar organisations, we need to do some significant changes to TOGAF’s Architecture Development Method cycle (the ADM). I summarised the modified ADM and taxonomy-framework, and illustrated all of this with a fairly lengthy case-study of the use of this modified framework in a government agency in the social-services sector.

The problem is that for many TOGAF practitioners, those changes are often too much of a jump from standard ADM practice. For example, in an unattributed comment on the blog, John’s colleague ‘GB’ complained:

One can transform TOGAF into any process one wants.

Is this really TOGAF for government? Or even for enterprise architecture?

Or is it TOGAF for business consultants dealing with a government department?

There are actually two separate points here. One is the implicit assertion that ‘enterprise architecture’ is still solely the architecture of the enterprise-IT; as John also mentioned in a comment, that notion is at last becoming more generally acknowledged as unworkable, and that we must extend the architecture out to the full scope of the enterprise. (Importantly, this extended ‘architecture of the enterprise’ is not the same as business-architecture.) The other is that many TOGAF folks are still uncomfortable with the idea of dumping the existing phases B, C and D – ‘Business Architecture’, ‘Information-Systems Architecture’ and ‘Technology Infrastructure Architecture’ respectively – even though they don’t work in practice for anything other than IT strategy-development and implementation. (In the re-worked version of the ADM they’re replaced entirely by a separate focus on as-is, to-be and gap-analysis for the selected scope – similar to the structure of the ADM in the earlier TOGAF 7.)

The core problems here are that the TOGAF 9 ADM is usable only for top-down strategy development (the sequence of the phases B, C and D), and only for IT-systems and IT-delivery (the current content of B, C and D). The enterprise-architecture method needs to cover a broader range of development types – overview, horizontal optimisation, top-down, bottom-up and spiral-out – and to address any scope in the enterprise. Hence the reason for suggesting some fairly fundamental changes to the ADM structure. But as long as we’re comfortable with sticking solely to top-down development, we can still retain something very close to the existing B, C and D, but capable of covering any enterprise scope. To do this, we rename the Phases as follows:

• Phase B: ‘Business Big-picture’
• Phase C: ‘Communication and Common’
• Phase D: ‘Domain Detail’

Phase B: Business Big-Picture

In this layer we explore the strategic imperatives for the business – what we might call ‘business-architecture proper’ – and the business drivers that impact on strategy. This is all at the big-picture level, and would typically include vision, values, business-role, business-missions and suchlike, and whole-of-organisation reference-models such as the Functional Business Model, and the FEAF Business Reference Model (BRM) and Performance Reference Model. This would be similar to the high-level components in the TOGAF 9 ‘Business Architecture’, though would not necessarily focus solely on strategic themes that would impact on IT.

What it would not contain is any tactical or operational themes: so-called ‘manual’ bsuiness-processes and the like. The tendency of TOGAF practitioners to bundle together everything ‘not-IT’ as ‘business architecture’ is a common cause of friction between IT units and the rest of the business, and also a common cause of architectural design-failures at the implementation stage.

Phase C: Communication and Common

In this layer we explore what needs to be shared with domains other than the primary domain in scope. For IT, applications and data are what are shared with other business domains – hence the two subsidiary components in TOGAF’s ‘Information Systems Architecture’. But here we need to make this more general, because the primary domain in scope may be any part of the business – HR, for example, or security, or manufacturing, or marketing. Typical deliverables here would be the domain equivalents of FEAF’s Service Reference Model (SRM) and Data Reference Model (DRM).

A service-oriented analysis of the enterprise will usually be the most appropriate tactic here: define everything as services, and summarises the structure and content for interfaces, service-contracts and SLAs, qualititative criteria, success-factors (CSFs) and performance-indicators (KPIs). This is also where trade-offs between different implementations should be assessed.

Phase D: Domain Detail

In this layer we explore the fine detail that’s specific to the ‘primary domain in scope’, and which should in general not be of any active concern for other domains (‘black-box encapsulation’, in service-oriented terms). For IT, this is the detail about network infrastructures, configuration-management, life-cycle management and so on – the TOGAF Technology Infrastructure Architecture’. Typical deliverables here would be the domain-equivalent of FEAF’s Technical Reference Model (TRM), and else capability-architecture models that cover IT-based, human-based and machine-based capabilities.

This layer in particular is where the often-idealised top-down strategy needs to connect with the bottom-up constraints of real-world operations. Architecture governance becomes extremely important here, with cross-linkages to ITIL, CoBIT, Six Sigma and other detail-level process-management and quality-management disciplines, as appropriate to the respective domain.

Anyway, try this in your TOGAF practice: see what you think, see how it works in practice. It’s not as versatile as the full amended-ADM, but it’s a useful ‘halfway-house’ that’s easier for existing TOGAF practitioners – and because it is truly generic, rather than IT-centric, and consistent across all domains, it should also help to bridge the chasms of the dreaded ‘IT-business divide’.