It was set up as a dinner-event. I’d been asked by Florian Kreuger and the others of the Alfabet crew to act as the pre-dinner ‘controversial conversation-starter’ (that’s how I interpreted it, anyway ) to get the ideas flowing during the dinner itself, and Craig Martin from the Australian-based international recruitment/consultancy group Enterprise Architects provided a more conventional follow-up discussion after the dinner itself, talking about trends in focus and recruitment for the worldwide EA discipline.

Okay, so the dinner itself was good, yet what I found most refreshing was that just about everyone understood that enterprise-architecture needs to be broken out of the IT-centric stranglehold. (That’s very different from the TOGAF conferences, where, despite various claims and espoused-aims to the contrary, IT-centrism still clearly holds sway.) Perhaps what helped most was that these were all senior-level practitioners of EA: no consultants, no academics, just people putting ideas into practice every day at a very high level within their organisations. And although most were still linked to IT in some way, these weren’t solely the usual information-centric industries – banks, insurance, finance, tax – that typify the usual ‘EA’ discussions: instead, we also had retail, manufacturing, mining, pharma, telecoms and a whole slew of others, which created a much richer awareness of what ‘the architecture of the enterprise’ really needs to cover.

Some comments here also in praise of Simon Allen and the Alfabet crew, because a key part of what made the event so successful was in what they deliberately did not do. There was no sales-pitch, no dominating Powerpoints, no “we are the best blah-di-blah-di-blah”, in fact not even a brochure in sight. What they did do instead was provide an excellent space and context for the gathering, explain the background to the meeting, their opinion that an interest-group would be a good idea for the EA profession as a whole – and then carefully got out of the way. Very unusual behaviour for a vendor – and absolutely brilliant, because it was exactly what was needed to make this work.

(A follow-up email from Simon indicated that some of the EAs from Bank of America and Citibank will be carrying the interest-group forward, so it looks like it’ll continue on as an entity beyond this one event – which is also very good news.)

The same attitude seems to be carried through into the Alfabet toolset itself, I notice. It does just one task – IT planning, from overview all the way down to fine-detail – and does it very well indeed. It then provides hooks to link that task into a whole range of other EA themes – business-relationships, the IT side of EA management, IT finance, IT risk-management and so on – but it doesn’t claim to do ‘all of enterprise-architecture’, and (perhaps more to the point) it doesn’t claim that its own specific subset of the EA space ‘is’ the whole of EA. Compared with most of the ‘big-name’ toolset vendors, that is unusual… Most of my own EA work barely touches detail-level IT, but for those who do, the Alfabet toolset certainly seems worth a good look – if only because of the realism and conceptual honesty in its approach.

One last point: Florian Kreuger and some other colleagues from other organisations have started a new blog called Beyond EA, which is not so much ‘beyond EA’ as about moving beyond IT-centric EA. Some good posts there, though right now it’s temporarily down for site-maintenance: when it comes back up again, it’ll be well worth keeping an eye on what happens there, because they do seem to have some refreshing new ideas about ways forward for EA.

Good signs of movement in the EA space, anyway.

• 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?

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 ).

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.

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.

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.