The final note in that last post was about EA toolsets, and the need for appropriate support for the output of the game – and perhaps even the game itself – within the toolset. And that point actually brings together a whole stream of different threads that I’ve been tracking for some years here: enterprise as story, toolsets and their user-interfaces, metamodels and architecture-repositories, whole-enterprise scope, notation-agnostic modelling and a whole lot more.

There are (at least) two fundamentally-different viewpoints on enterprise-architecture: as structure, and as narrative. Most current EA toolsets focus only on the ‘structure’ side, and do so variously well; but there’s almost nothing to help us tackle the narrative side of the story, and even less to help us bring those two sides together. Which, in practice, is a serious problem, because story is actually what engages people in the architecture…

In short, we need our EA toolsets to help us bring a better balance between structure and story in the architecture.

To put into context, consider a few scenarios:

Scenario 1: The team reckon they’ve done well with their work on the new business-model, all laid out on the wall on a Business Model Canvas. But how are they going to implement it? Will it actually work in real-world practice? What are the pitfalls and hidden ‘gotchas’ that could cripple the new model’s viability?

To address these concerns, they set up for a game of ‘This’. One of the architecture-team leads, Maria, takes on the role of modeller, using an application on her iPad, the screen hooked up to a data-projector on the wall, but also coupled to the other team-members’ tablets and laptops. (The screen will also show the current manually-selected or randomly-selected ‘This’ question-card.) She also sets up a conference-microphone to capture an audio-channel.

Maria uses the camera on her iPad to take a snapshot of the current model on Business Model Canvas, and pulls the photo into the application. There, she marks up the graphic with zones and links, each of which – behind the scenes – is also noted as a Service or flow-relation in the underlying Enterprise Canvas.

The team choose an arbitrary starting-point, and build outward from there, as per the guidelines for the game. Instead of using the rather sparse Enterprise Canvas notation, Maria pulls up more-descriptive icons and images from a palette – trucks, parcels, people, machines, money, whatever – and places them on the screen as the current ‘This’; behind the scenes, though, the application stores the information in Enterprise Canvas notation. The audio-channel is attached both to the overall model, and to the entity for the current ‘This’; later, the audio-track can be played back, highlighting in matching sequence each of the items described in the model.

During the game, the discussion indicates that some changes will need to be made to the initial business-model. Maria uses the underlying Enterprise Canvas to recreate a new version of that model, in Business Model Canvas layout.

Scenario 2: Two days after the business-model meeting, Maria re-checks some of the people-connections captured in the Enterprise Canvas model during the ‘This’-session, for the purpose of building a list of stakeholders for one of the side-projects arising from the new business-model. She notices that she didn’t capture one person’s name, the process-owner for a related business-process – she remembers that his first-name was Steve, but not the surname. She clicks on the respective icon, and plays back the audio-channel that was captured at the time: Steve’s surname – Cartwright – is now clear, and she types the full name into the model. As she does so, a link to the company’s HRM-system brings up further contact-details for Steve, including several photographs. She selects one photograph, and sets it as the surface-view for that icon in Enterprise Canvas.

Later that day, Arjun reviews the business-model, using the zooming model-display. In the drill-down into the ‘Key Activities’ section of the Business Model Canvas, Steve’s photograph now appears in place of the previous abstract ‘person’-icon. Clicking on the photograph, Arjun sees all of the information on Steve’s role in the proposed business-model, and can also play back the captured audio both from that meeting, and another discussion that took place earlier in the day.

Scenario 3: Juan has been tasked with developing the IT-architecture for the e-commerce component of the new business-model. His business-unit has standardised on Archimate notation for all IT-architecture models. He opens the Enterprise Canvas model, and, using it as an active backplane, identifies Canvas entities that would map directly to Archimate equivalents: Canvas ‘Service’ to Archimate ‘Business Service’, ‘Application Service’ or ‘Infrastructure Service’, Canvas ‘Exchange’ to Archimate ‘Business Interface’, ‘Business Object’ and so on. He explores the additional detail recorded in the ‘This’ session to identify Archimate ‘Business Function’, ‘Business Event’, ‘Business Actor’ and the like. As he adds these entities to the Archimate model, they’re also attached to the Enterprise Canvas model in the backplane via composition-relation links into the respective Canvas ‘Service’, ‘Exchange’ entities and flow-relations.

Scenario 4: The following morning, one of the business-model team, Vasily, remembers that more detail was needed about warehouse configuration, for potential locations – both physical and logical – for new sensors that will be needed for logistics-tracking in the new business-model. He goes down to the warehouse, takes his smartphone out of his pocket, calls up the Enterprise Canvas model, selects the ‘New Sensors’ entity, and starts a new game of ‘This’ with that entity as its starting-point. He manually selects the question ‘What are the locations of This?’, and attaches to that card the photos that he takes, direct from the phone’s camera application.

In the Enterprise Canvas, Juan has already been identified as one of the people responsible for the ‘New Sensors’ component of the business-model. He receives a notification that new items have been added to the Enterprise Canvas; he opens that part of the model, reviews it, and adds new entities to his Archimate model, which are automatically linked back to the Enterprise Canvas.

So there we are.

Plenty of other scenarios we could add, too: about a meetup in a cafe, about people exchanging ideas in the elevator, about how this information might be used by a project-manager and her team, by a process-designer to gather feedback from the factory floor, by managers using a dashboard in high-level resource-planning, and so on. But that’s detail enough for now: four interlinked scenarios, all working on the same models in different ways, with different software-applications, on different hardware-platforms, for different purposes, all supporting each other.

So is that what actually happens in practice at present? Is that how we do our everyday architecture work?

Uh, no…

In which case, why not? Seriously: why not?

On the surface, it’s all straightforward enough: the work itself is essentially what architects and others do already. The only trouble is that it’s well-nigh impossible to do most of this in any existing EA toolset: most tools now should be able to cope with the Archimate-specific part of the modelling, but that’s about it – and they probably wouldn’t be able to link any of that model to anything else. As for the rest? – well, forget it, guys, you’re outta luck…

Ouch…

It should all be seamless, pretty much exactly as described in those scenarios above. In practice, it isn’t. In fact, the way we have to do it at present is a frustration-filled, kludge-ridden, error-prone mess of manual translations, bits of paper, scribbled notes, anguished phone-calls and worse. Hence no surprise that it often doesn’t work very well – if at all.

Yet there really is no need for it be that way, and no reason for it to be that way either.

To which the only remaining question is: Why? Why is it this way?

To me at least, it seems that the only real reason is that the current EA-toolset market is crippled by its own lack of imagination – and that’s all that’s holding us back.

Okay, yes, sure, there’s a sizeable amount of development-work required. But seriously, none of it would be hard to an experienced developer, someone who’s familiar with the current generation of development tools. Everything I’ve described above is already available in various apps and elsewhere – there’s nothing new as such in any of it. The only reason I haven’t done it myself is that I’m way out of date on that whole area, and it would take me months or years to do what a current developer would know how to do in days.

Have a wander around this blog: I’ve already done most of the conceptual work that’s needed for this, on toolset-ecosystem, overall requirements, metamodels, user-interface, underlying notation-agnostic structures and so on. For example, take a look at these posts:

• The toolset-ecosystem
• More on that enterprise-architecture ‘help-needed’
• EA metamodel: two questions
• EA metamodel – the big picture (and the small picture too)
• Simplifying the Enterprise Canvas
• Using Enterprise Canvas as a service-viability checklist

So I’m serious about this: it’s all there – a huge market, just waiting for the first person with the nous to pick this up and run with it.

Is anyone up to this challenge? And if not, what do we enterprise-architects do about it?

Comments/suggestions, anyone?

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?

Yet in practice – and certainly as the scope widens – more and more of our actual day-to-day work consists of creating and enabling new conversations: architectural conversations between business and IT and anyone and everyone else in the overall enterprise. The ‘one idea’ of all architecture is that things work better when they work together, with efficiency, with clarity, on purpose: and to make that happen, we need to get people to talk with each other. Simple as that, really.

One practical problem we face is that the architecture tools that we have available to us at present are not that well-suited to that purpose. For some conversations, yes – but those tend to be the most technical of the conversations. For the ordinary-yet-important conversations with everyday stakeholders, we’re not well-served at all. And as we move more and more out of the purely technical domains and towards a true ‘architecture of the enterprise’, the more that gap is going to get in our way.

One tool to rule them all?

What we really need is something that’s probably impossible in practice: a single tool that will cover the whole spectrum from the loose, freehand sketching and storyboarding of architectural issues and requirements, all the way through to the tight rigour and discipline that we need in specifications for real-world design and implementation.

We also need that imaginary ‘one tool’ to cover another whole spectrum of usages, from centralised repositories and very large ‘scorecard/analysis’ displays through to multi-screen desktops to single-screen laptops to tablets and touchpads right down to handhelds and smartphones.

The big, expensive enterprise-architecture toolsets such as System Architect or ARIS or Troux Metis tend to sit over in one corner of the matrix between those two spectra: they embody the formal rigour of software-, system- or process-design and simulation, and they need big repositories, big servers and big displays to deliver their best performance. These are also definitely not tools that should (or even can) be used by general users – a fact I know from painful first-hand experience of the months we had to spend tidying up the mess that our business-managers made of our repository after we’d foolishly allowed them to play with it for a single week…

Then there’s the mid-range: toolsets such as Avolution or BizzDesign Architect or Sparx Enterprise Architect, or Alfabet or Essential. All of these are well suited to laptops and other larger single-screen systems, and each tend to emphasise particular themes: metamodelling with Avolution or Essential, for example, or Archimate business/IT-alignment with BizzDesign or Sparx, or IT-infrastucture configuration with Alfabet. They all have some kind of internal repository, which in turn supports some kind of diagramming; but it’s not always easy to share – especially across a whole multi-organisation enterprise. And these are still tools for specialists – not something that we can use with everyday business-folk, as I discovered the hard way when I presented a set of BPMN diagrams at an executive-meeting…

Down in the far corner, though, there’s almost nothing: no usable toolsets for idea-thrashing with ops-staff, developers, executives and all the other myriad non-specialists. Office tools such as Powerpoint and Visio are just-about-okay for documentation after the event – though they provide little to no support for architecture-rigour at all – but they’re far too slow and cumbersome for real-time discussion. So it’s no surprise that for most architects I know, their most important tools are a whiteboard and a sketchpad – and not only do those provide no linkage to formal architecture-rigour, but it’s usual not even possible to record and share the results. Which means that we have almost nothing with which we can engage people in the architecture itself – in the discipline of the architecture.

But what would such a toolset look like? What aspects of architecture-discussions could it cover?

Enabling interactive conversations on architectures

One project that I’ve been involved in (as a member of its alpha-test team) is Alex Osterwalder’s iPad app for his Business Model Canvas framework – perhaps take a look at the videos on Alex’s post. That’s also a key reason why I developed the Enterprise Canvas concept, to extend the same basic idea to the whole-of-enterprise scope. And there’s also a swathe of iPad or smartphone apps that cover themes such as sketching or mindmapping or outlining or project-management, that do at least enable us to record in a form which can be stored and re-used later.

The real aim, though, is to get to some kind of toolset that is freeform enough to be used in live discussions, yet beneath the surface embeds at least some of the rigour needed for architecture-development. There are some great hints towards this in an article in HBR by Michael Schrage, ‘How Your Smartphone Will Transform Your Elevator Pitch‘, which are worth noting in some detail here:

… His [business-idea] was undeniably clever, but aspects of his business model weren’t clear to me. He had his elevator pitch answers down pat, but I wanted to learn more. Unprompted by me, Osman whipped out his smartphone and handed it over. I was watching a decent video clip illustrating his product’s features and functionality. I could tap to hear testimonials. I could tap to play with a simulation of the software. In a matter of moments, the device had transformed Osman from an entrepreneur I was having a conversation with to a guide and narrator of an interactive experience. My focus and attention alternated between what he said and what appeared onscreen. Sometimes he’d take, touch, and hand back the device; other times, I’d point to something onscreen and ask another question.

The object — and our interaction with it — became an intimate part of our conversation. We couldn’t have discussed either [his product] or his answers to my questions the same way without it. An idle part of me wondered how cool it would be if our conversation (and my questions) could be recorded and time-stamped along with what was appearing onscreen. Osman refused to allow his smartphone to decay into a sales tool or product pitch — although those elements were baked into the material — and instead used the device as a medium to both reinforce his conversation points and invite new questions and comments from me.

I can say without hesitation that this felt technically and interpersonally different from “laptop-on-the-table” presentations I’d experienced 1,000 times. We were standing up, drinking coffee, chatting, and taking turns holding, viewing, and manipulating this device. The kinesthetics, eye contact, questions, and interruptions revolved as much around the device as us. We would have been worse off without it.

And, further on in the article:

Elevator pitches are important. The ability to boil down the essence of your innovation into a tasty forty-second sound-bite remains essential. Only now, the pervasiveness, ubiquity, and visuality of mobile devices quantitatively and qualitatively changes the ecology of interpersonal interaction. It’s no longer about what you say and how you say it; it’s increasingly about what you hand over.

What do you hand over that transforms the conversation? What do you hand over that visually and interactively adds value to your spoken words? What do you hand over that complements and supplements your pitch? What do you hand over that invites and inspires the curiosity you want? What do you hand over that makes you more persuasive?

… “Hand-it-over” innovation pitches can be seamlessly slipped wherever your prospects desire. Indeed, an excellent measure of “hand-it-over” effectiveness is whether the person who you “hand-it-over” to actually asks you to send what they’ve been seeing and interacting with.

So let’s summarise some of the key themes there:

• it’s not a presentation, it’s an interaction – a two-way or multiway conversation
• the interaction is kinesthetic – it involves touch (ie. handling and interacting with the device) as well as listening and seeing
• if practicable, the interaction itself should be recorded, as an annotation on the original presentation
• if practicable, it should be possible that the whole interaction can be shared

Beyond the whiteboard

That’s what we need for that part of our enterprise-architecture work – a toolset that enables us to engage directly with our stakeholders. And it needs to go both ways, too: to take a model or diagram from the formal ‘big-system’ part of the toolset-spectrum and share it and discuss it; and also enable and capture discussions about requirements, about trade-offs, about different understandings and paradigms and worldviews and expectations and assumptions across all the myriad of different perspectives in the enterprise. Both ways. About anything – about any aspect of the architecture.

Which also means that we must have some kind of language to enable us to move information up and down through that spectrum, across different devices, different systems, different toolsets. (It seems very unlikely that one vendor will ever cover the whole range that we need – but the information itself must be able to move around in any form that we need, yet always anchored back to the formal rigour required by each architecture-domain.) So that’s another hurdle to cross, because no such language exists at present.

So, given all of this, how could we improve on the venerable whiteboard and sketchpad? How could or would we record that kind of interaction? And how can we support a form of diagramming that is as interactive and illustrative as a whiteboard-session, yet still enables the underlying rigour? The specialist EA toolsets may be too cumbersome for this kind of interactive use, but surely we can create something with more rigour than Powerpoint or Visio?

That’s our challenge here. Comments/suggestions, anyone?

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.