Tom Graves

I’ve just uploaded to the Tetradian Books website the ZIP archive of the Visio stencil and template for the function-model process described in the Service Oriented Enterprise book I published a few days ago. The archive includes:

• Visio 2003 stencil for function-models: shapes for Function/Activity, Business System and Dependency
• Visio 2003 template for the stencil, creating a default base-document
• Word 2003 instructions-document (an edited extract from the Services book)

More detail at http://tetradianbooks.com/2009/01/services-model/ , if you need it.

Share and enjoy?

Diana Stobart Wild’s other question on the LinkedIn business architecture forum was about frameworks:

What is Business Architecture? What does a Business Architecture Framework look like?

I think of Business Architecture as a subset of Enterprise Architecture that describes the business from the Strategy down to the enterprise business models (process, data, business rules, etc.). Business parts of the Zachman Framework? Thoughts? Comments?

My response was as follows:

I’d agree that Business Architecture is a subset of Enterprise Architecture, as long as you don’t fall for the TOGAF-style trap of thinking that enterprise-architecture is only about IT!

Business-architecture proper is the strategy layer (Zachman row-2 and upward, also bridging down into row-3).

The jumbled mess of what’s otherwise called ‘business architecture’ only exists because TOGAF and the other IT-centric ‘EA’ frameworks essentially used the term as a generic dumping-ground for ‘everything not-IT’. Instead, think of the remainder of what TOGAF calls ‘business architecture’ as two distinct layers: the logical or integration layer – the equivalent of TOGAF’s ‘Information Systems Architecture’, Zachman row-3 to row-4 – and the physical or implementation layer – the equivalent of TOGAF’s Technology / Infrastructure Architecture, Zachman row-4 to row-5.

Zachman’s structure of layers still works fairly well for this – the only essential change is an extra ‘row-zero’ for compatibility with the Vision layer of ISO-9000:2000. But it does need some serious rework on the columns: for a start, there’s an entire dimension missing, to handle distinctions between physical assets (things), virtual assets (data etc), relational (what your CRM is all about!), aspirational assets (morale and the like), and abstract (such as the financials that your business people do want in their models!); the same for locations (physical, virtual, relational etc) and so on. Still a month or a so away from finishing my book on this, “Bridging the Silos”, but see the ‘Framework’ chapters in the current draft at http://tetradianbooks.com/2008/04/silos/ .

One point that Zachman did get right, but most of the EA-toolset vendors seem to have forgotten, is the key distinction between primitives and composites. As Zachman says, architecture is about primitives (TOGAF’s ‘Architecture Building Blocks’, or ‘ABBs’), whilst solutions come from composites or patterns (TOGAF’s ‘Solution Building Blocks’, or ‘SBBs’). The Zachman Framework is a taxonomy of primitives – root-level entities, some of them fairly abstract; composites are structured collections of primitives that straddle the columns, making up patterns for re-use.

Composites are usable to the extent that they’re architecturally ‘complete’ – i.e. straddle all of the columns – but are re-usable to the extent that they’re incomplete: for example, a BPMN process-model says nothing about ‘Where’ or ‘Why’, so can be re-used in different locations and (in principle) for different purposes. At the mid-layer of the framework, you need to be able to describe a process in abstract terms, to identify KPIs and CSFs and so on; you’d define different SLAs as you go down towards different implementations – manual, machine, IT, etc, but they should all use the same KPIs etc. This is important because if you’re not able to anchor the detail-layer composites into their component sub-composites, all the way down to their root-primitives, you won’t be able to see options for redesign, such as for disaster-recovery or process-reengineering. Think of the classic IT-centric blunder of assuming that every problem must always have an IT-based solution… your only way to avoid that trap is to use a non-IT-centric framework that covers the true whole-of-enterprise space.

Over the past few years I’ve done quite a bit of work on a ’service oriented enterprise’ framework, based on the classic Stafford Beer ‘Viable System Model’ – see the Wikipedia summary at http://en.wikipedia.org/wiki/Viable_System_Model . We extended this at Australia Post and elsewhere to include support for quality-systems, security-management and so on. Again, there’s still some way to go, and the book is probably at least six months away, but there’s a summary in my article on the service-oriented enterprise in the current itSMF “IT Service Management Global Best Practices” book (see http://www.vanharen.net ) and in my presentation to the TOGAF Glasgow conference back in April (see PDF at http://www.tetradian.com/download/togaf_ea-soe_apr08_FV.pdf ).

Been following a ‘business architecture’ thread on LinkedIn, and came across a couple of discussion-questions by Diana Stobart Wild, who seems to be an enterprise architect somewhere in the north-east US. Thought it might be useful repeating here what I wrote there, as it’s all fairly generic but does summarise my current approach to business-architecture.

Her first question was on business-architecture tools:

Which tools are in the Business Architect’s toolkit?

to which I replied as follows:

If you come from an IT-centric architecture background, the first need is to realise that the standard EA view of business-architecture is a mess – it’s essentially a random grab-bag of ‘everything not-IT’. So you need first need to sort it into the business equivalents of TOGAF or FEAF’s three layers, such as:

• strategy and policy (real meaning of TOGAF’s ‘Business Architecture’ – Zachman row-3 and above)
• tactics and system design (equivalent of ‘Information-systems Architecture’ – Zachman row-3 to row-4)
• process implementation (equivalent of ‘Technology Architecture’ – Zachman row-4 to row-5 [and, in past tense, row-6])

For the strategy layer, one obvious tool is BRG / OMG’s Business Motivation Model [PDF]. It has some flaws – particularly its dangerous mishandling of ‘Vision’ – but it’s a good starting-point. Several EA toolsets implement the BMM, though sometimes under different names: for example, IBM/Telelogic System Architect calls it the ‘Enterprise Direction’ model.

For the middle systems-layer, to be honest, I don’t know: we’ve been doing a lot towards modelling that space – see my book “Real Enterprise Architecture: beyond IT to the whole enterprise”, at http://tetradianbooks.com/2008/04/real-ea/ and the current draft of “Bridging the Silos: enterprise-architecture for IT-architects”, at http://tetradianbooks.com/2008/04/silos/ – but there’s still a fair way to go yet. Troux’s ‘Metis Enterprise Architecture Framework’ covers [covered? it may not still exist...] a lot of the space, but as usual ends up being too IT-centric for real business-architecture use. Even so, Troux is probably the best bet at present: in my experience, to be blunt, most of the other well-known EA toolsets are so obsessively IT-centric that for business-architecture they often seem more of a hindrance than a help.

At the process level, there are plenty of tools and models available, many of which are not inherently IT-centric, such as all the IDEF and TQM and Six Sigma toolkits. Some IT-centric tools can be re-used in a non-IT-centric way, too: you can use BPMN for implementation-layer business-architecture modelling, for example, once you realise that the Process entity doesn’t care how it’s implemented unless you really need to translate across to BPEL; and the ‘Data Object’ entity doesn’t need to be data, but can actually be any type of asset – physical, virtual, relational or whatever.

Another tool I’ve found invaluable for understanding complexity in business-architecture, and the boundaries between what can and can’t be handled by IT, is Cynefin – see the Wikipedia summary at http://en.wikipedia.org/wiki/Cynefin , also Snowden, D & Boone, M “A Leader’s Framework for Decision Making” Harvard Business Review November 2007.

A theme which came up several times in the Troux Directions conference, and came up in several different ways, was the need for some means to share and exchange enterprise-architecture information between multiple organisations, so as to handle the reality that ‘enterprise’ is now very often broader than a single organisation.

The catch right now, of course, is that every vendor has their own proprietary file-format and metamodel. They’d each no doubt be very happy if their own format became ‘the exchange standard’, because that would de-facto enforce a single-vendor monopoly, in the same manner as Microsoft Word. But the multi-vendor environment is a reality: and that ain’t going to change – especially at the prices that the EA-toolset vendors charge for their products… But what could change the game is an open-source approach to the whole field: firstly for exchange-formats, and possibly for toolsets too. When vendors charge upwards of US$500,000 for a single complete suite of products, there has to be room for an EA equivalent of OpenOffice there somewhere…

I’ve summarised what I think are the overall requirements for such a toolset in my book Bridging the Silos: enterprise architecture for IT-architects – see page 14-15 (p.20-21 of the PDF file) in the current draft version on the Tetradian Books website. But to get all of that together will take a fair time, and the most urgent need right now is for some kind of exchange-format. A few places that seem to provide useful pointers:

• IDEAS Group (International Defence Enterprise Architecture Specification) – okay, it’s military, but at least the site makes it clear that it’s not IT-centric
• XPDL eXtensible Process Definition Language (Workflow Management Consortium) – process-specific, but could be extensible for enterprise architecture
• OMG standards around MDA Model-Driven Architecture, such as XMI XML Metadata Exchange – sure, the MDA is still IT-centric at present, but OMG are putting a lot of effort right now into breaking it out of the IT-only box

The key to all of this, though, is going to be defining not just an extensible file-format but an extensible system-architecture that can be flexible enough to handle all of the present and future requirements for enterprise-architecture. Sounds like a big ask, I know, but should be doable as long as we keep the core ideas really simple, and focus on leaving the right hooks for extensibility.

Anyone else interested in this? If so, let’s set up a suitable forum on LinkedIn, perhaps, and continue the conversation there.

Spent Thursday at the Troux Directions conference in London, hosted by Troux, one of the leading vendors of toolsets for for enterprise architecture. A good day in many ways, yet overall I’ll admit I did come away feeling more than a bit disappointed.

Troux seems more advanced in their thinking than some of the other big-name vendors, but still a strong sense of stuck in business-as-usual. Given that EA has been so ‘poisoned’ by the TOGAF types and worse, clinging desperately to their delusions of an IT-centric world, Troux have tried to re-badge their offering as ’strategic IT planning’: but in reality it’s still same-old-same-old. Firstly it’s ‘planning’: yet as they themselves freely admitted, we can’t plan any more – the world we deal with now is too complicated and too dynamic for that. Secondly, it’s still hopelessly IT-centric: ’nuff said, really… And thirdly, they still have not even begun to grasp the bald fact that in the present-day business climate, ‘enterprise’ and ‘organisation’ are no longer the same thing.

I can understand their dilemma: they need to sell to single organisations – because that’s where the budgets come from – but what they’re selling needs to cover any scope, from a small subset of the organisation (as in classic IT-centric ‘EA’) to a wildly dynamic superset of an enterprise that spans partners and suppliers and customers and even competitors across many different industries and across the entire globe. They’re not even starting to tackle those issues, in fact they seem to be running away from them as fast as they can: but that’s where EA practices – and hence EA toolsets – definitely need to be, right now, whether the vendors like it or not.

(To be fair to Troux, their panel of ‘industry experts’ was even less aware of those realities. When I asked about what kind of support they could offer to non-IT-centric enterprises, and/or those to whom financial return was not the sole measure or even the primary measure of success, my question was met with blank stares of incomprehension, and eventually a muttered non-reply from one of the panel members that didn’t even remotely answer the question. Oh well.)

Also disappointing was that their star turn, a lead architect from Merck in the US, perfectly illustrated my point about ’small countries’ versus ‘big countries’. He purported to be showing work which was brand new, world-leading and the rest, and he obviously believed it was (well, after all, it came from the United States, which everyone knows is the world-leader in everything, right?). But in fact his centrepiece ‘capability model’ was, in essence, a pale reflection of the work we did at least four years ago at Australia Post: as far as the ’small countries’ were concerned, it was nothing new at all, in fact just a routine technique that I’ve used in several clients now over the past few years.

Oh well.

But thanks are due to Troux, in any case, for putting on a good show, and a good place to exchange ideas with the handful of practitioners (once again, most of them from the ’small countries’, I note) who were trying to tackle the much broader scope that a true enterprise architecture requires.

More comments in the next post or two, anyway.