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?

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…

Still in post-conference catch-up mode. In the meantime, here’s the slidedeck for “Using TOGAF beyond IT”, my presentation to the Open Group conference in Hong Kong. Download the file and view in Powerpoint’s ‘Notes View’ to see the full script.

Note that it explores just one question: what do we need to change in the TOGAF ADM to make it usable for any architecture purpose and any scope in whole-of-enterprise architecture. See my other presentations on Slideshare for other aspects of whole-of-enterprise architecture practice.

Thought it might be useful to various folks (including me!) to post the Twitter-stream from the TOGAF conference (Open Group Enterprise Architecture Practitioners’ Conference, Hong Kong) earlier this week.

For readability I’ve reversed the order so that the tweets are listed earliest-first, and I’ve edited the content slightly to remove RT ‘retweet’ duplications and general ‘personal-stuff’, so as to concentrate on what was said or commented-on during the actual presentations. But otherwise it’s the same as you’ll find on Twitter with the search-hashtag #oghk. Quite long, of course, so you’ll find the rest of this post after the ‘More…’ link.

Read more…

Just back from the TOGAF conference in Hong Kong, hence going through the usual joys of jet-lag and dealing-with-the-backlog.

Quick summary: seems to have been very worthwhile. More evidence of the shift towards the realisation that enterprise-architecture is about more than just IT: in fact that’s now being explicitly stated just about everywhere at the conference, though ‘the usual suspects’ are still doing not-very-much to move out of the comfort-zone of detail-level IT.

Probably the most interesting area was the formal presentation of the ‘Chinese Management Model’, apparently a government-sponsored (or at least government-promoted) model which combines some Western thinking with more traditional Chinese philosophy, drawn from Confucianism, Taoism, Buddhism and more recent Chinese views (Eight Glory and Eight Disgrace). Much of this – particularly Taoism and Buddhism – aligns well with the systems-theory frameworks that we need in order to model organisational complexity, so there’s a strong synergy there. Other local presenters, such as Professor Yao Le of Beijing University, emphasised the importance of balance across multiple dimensions and domains, using the classic yin/yang metaphor, contrasted to linear Taylorist ’scientific management’. Definitely a case of ‘Watch This Space’, it seems.

Another item of wry amusement was the difference between Western and Chinese concepts of timescale and scope. Here in the West – especially in the US/Anglo context – we struggle to get business-folks to think any further than the next financial-quarter – or at very best perhaps a five- to ten-year future – and to think of any scope wider than their immediate context. By contrast, the first slide shown by the first plenary speaker, Robert Xu of software-house Kingdee International, started by showing the Chinese view of recent economic history, summarising the whole globe, starting in 1750 – in other words a quarter-millennium, not the usual Western quarter-year! A very different sense of realism, and very refreshing.

Back to catch-up: a fair bit to post to this weblog, of which the first will be a dump of the Twitter-stream from the conference. More later, then.

This one starts with a blog-post by John Polgreen, of training-group Architecting the Enterprise, called “TOGAF for Feds – Isn’t TOGAF too IT-centric for Fed EA?”. The key issue that of scope:

TOGAF is often associated with IT architecture, as opposed to the business-driven, holistic enterprise architecture espoused by the US Federal government.

John argues that whilst there’s still room for improvement, TOGAF 9 is much more business-focussed than the previous versions:

The present TOGAF definition of enterprise architecture – although holistic – doesn’t seem very business-driven: “…the description of an enterprise as a system in terms of its components, their inter-relationships, and the principles and guidelines governing the design and its evolution.” Contrast this to a definition suggested by Paul van der Merwe to be included in the next release of TOGAF: “The continuous practice of describing the essential elements of a sociotechnical organization, their relationships to each other and to the environment, in order to understand complexity and manage change.”

He then points to the TOGAF ADM (Architecture Development Method) as the solution. But to me the current structure of the ADM is a key part of the problem, not the solution. Since John asked “What are your thoughts? Is TOGAF too IT-centric for your agency? I’d very much like to hear your opinion”, I appended the following comments to his post:

The short answer to “Is TOGAF 9 too IT-centric for your agency?” depends on two factors:

• whether you think enterprise architecture is primarily about the relationship between business and IT, versus whether it’s about the enterprise as a whole, of which IT is only one small part;
• whether the work of the agency is centred around information (eg. IRS), versus some other domain(s) (eg. Parks & Environment)

If your concern is more with the first side of both of those two spectra – the business/IT relationship, in an information-oriented agency – then TOGAF 9 will be a very good fit, with TOGAF 9 a valued improvement over the previous version. For those contexts, the short answer would be ‘No’: TOGAF is not too IT-centric for the agency.

But the fit becomes progressively worse as you move to the other side of either of those spectra. Unlike FEAF, TOGAF has almost no concept of people (FEAF’s ‘Human Capital’), or of physical things other than IT-infrastructure (FEAF’s ‘Other Fixed Assets’). If your need is to build a whole-of-enterprise view for an agency that deals primarily with people or with physical things, TOGAF 9 provides little real gain over TOGAF 8. It’s true there are a few real improvements – such as the section on Capability-Based Planning – but in some ways it anchors the architecture even more rigidly into the IT domain. For those contexts, the short answer would be ‘Yes’: as it stands, TOGAF would definitely be too IT-centric – and in some cases even dangerously so.

The key problem-area is one of scope. The TOGAF 9 ADM retains from the previous version exactly the same fixed IT-centric scope, with a linear progression from ‘Business Architecture’ – in essence, “everything not-IT” – through ‘Information Systems’ to ‘Technology Infrastructure’. The end-point is always to clarify the design and structure of the IT-systems: everything else is peripheral to that purpose. If the architecture has any other purpose – as it will do in most agencies, especially as architecture maturity develops – the current design of the TOGAF ADM may become an active hindrance almost every step of the way.

(In principle the new section on Iterations should relieve this to some extent, but the iterations concept is not well-enough described to be useful in practice: in essence the ‘new’ ADM is still a Waterfall model with a few half-hearted attempts at Agile vaguely tacked on, with a governance model that fits neither approach well enough to be reliable – especially at an enterprise-wide scale.)

The ADM principle is sound, and provides a much-needed methodology that FEAF lacks. But for anything other than IT-oriented ‘enterprise’-architecture in information-centred agencies, TOGAF 9 is usable only if we can break free from the existing ADM’s fixed IT-centric scope. To do this, we need to rethink the detailed structure and sequence of the ADM, whilst retaining the overall principles of the methodology.

Key requirements for such a revision include:

• stronger support and governance for Agile-style iterations
• support for consistent management of iterations of any duration and any level of nesting
• support for any architecture scope, dependent on the needs of each iteration
• explicit removal of any assumptions about the centrality of IT

The latter requirement also supports architectural assessment of contexts where IT may not be involved or even available, such as in process-design and planning for some disaster-recovery/business-continuity scenarios.

For one example of one such modified version of the TOGAF ADM, see http://tetradianbooks.com/2008/10/silos-method-ref/. A matching framework to identify scope for architecture iterations is at http://tetradianbooks.com/2008/12/silos-frame-ref/.

Realised that the free-download reference-sheets from the Tetradian Enterprise Architecture books would be useful to have up on Slideshare as well, so have uploaded them there for more general accessibility than solely from the Tetradian Books website.

• “A framework for whole-of-enterprise architecture” – the amended-Zachman reference-sheet from Bridging the Silos: enterprise architecture for IT-architects
  
• “A revised TOGAF ADM for whole-of-enterprise architecture development” – the amended-ADM reference-sheet from Bridging the Silos: enterprise architecture for IT-architects
• “Power and Response-ability – a workplace ‘Manifesto’” – the PDF version of the ‘manifesto’ from the Introduction to Power and Response-ability: the human side of systems
  • (note: a Powerpoint version of the ‘manifesto’ is also available on Slideshare)

A minor glitch in that they ended up as ‘Presentations’ rather than ‘Documents’: anyone know how to fix this? There doesn’t seem to be anything about it in the rather limited online help on Slideshare itself: odd…

Hope it helps, anyways.

Yikes! Talk about misinterpreted in a sound-bite…

(Before I go any further, a note to all in the TOGAF training/education community: from what you’ve read elsewhere, you may at present believe that I’ve been attacking you personally. As you’ll see below, this is not the case – so please accept my apologies for others’ interpretations of what I wrote. Do read on – and thank you.)

There are a few Tweets going round that suggests I’m attacking TOGAF (again), this time by suggesting that TOGAF training is worse than useless:

harsh deduction by @tetradian: TOGAF certification almost an indication that one is NOT capable of doing #EA

“… close to … a TOGAF certification is an indication that someone is not capable of doing enterprise architecture.” http://bit.ly/uZDZd

I’ll admit my original post summarising the London TOGAF conference last month does indeed include that latter quoted text. But it’s quoted way out of context: so please, do read the whole post before you jump to that conclusion! – because it isn’t what I’m saying at all.

First, it’s not my own ‘deduction’: it’s a near-verbatim report from a broader discussion at the TOGAF conference. From the certification perspective, four key themes came up from the conference, all from leading members of the TOGAF community:

• the reference-architectures (Part VI of the TOGAF spec: ‘Technical Reference Model’ and ‘Integrated Information Infrastructure Reference Model’) are way out of date, and at the least need a complete overhaul, if not dumped altogether [that was from the Open Group's lead Allen Brown, in one of the plenary sessions]
• “almost no-one” uses the ADM in the form described in the TOGAF specification [in my last post I said I thought that was one of the guys from Deloitte, but my notes indicate it was Mike Lambert from Architecting the Enterprise, one of the lead TOGAF training groups]
• enterprise architecture is much broader than IT, and must now encompass the whole of the enterprise [that theme came up at least a dozen times, in plenary sessions and elsewhere]
• enterprise architecture needs to be understood as a professional discipline, comparable to other professional disciplines such as medicine and building-architecture [again, many people, but particularly Len Fehskens, Open Group VP on Skills and Capabilities]

These are all points that, yes, I have personally pushed hard over the past few years: but you can see from the above that it’s not just me that’s saying it – it’s being echoed now right from the centre of the TOGAF community itself. (Just this once, I’m not ‘the Outsider’ here! <wrygrin>)

So, to the problem of certification. The key point is that certification alone is not an indication of professional competence. Back in my aero-engineering days, it was common knowledge that newly-graduated engineers were a potentially lethal danger to everyone in the place: they knew just enough to think that they knew what they were doing, with that arrogant certainty of the newly-qualified, but had no idea of how to work with the subtle complexities and constraints of the real world of engineering. For example, they would specify components that couldn’t actually be made, or assemblies that could be made but couldn’t physically be assembled. Even for the best, it usually took a year or two at least “to learn how to make my mathematics sufficiently imprecise to be usable”, as one of them put it. Crucially, there were a few who never learnt that lesson, and instead clung on to their certification as ‘proof’ that they were competent – which in practice more proved that they were not competent to be let loose on a real aircraft. Or, in this context, a real enterprise.

On its own – and again I’ll emphasise, on its own – an enterprise architecture certification does not and cannot indicate competence: it needs to be balanced by real-world practice. For which, again, crucially, this profession at present has no means to monitor or measure.

Next, look at what’s actually covered in the existing TOGAF certification: it’s primarily about the ’standard’ ADM and the reference-models – which are no longer used in that form in practice. And – as also indicated in those themes from the conference – real enterprise architecture is much, much broader than IT: yet everything in the existing certification is centred on IT. So anyone who does slavishly follow the ’standard’ will be almost guaranteed to create an architecture that might at first seem ‘efficient’, but will be so outdated, so IT-centric and so far off the real mark that it will at best be useless, and possibly much worse than that.

What the old TOGAF 8 certification exam did not cover was how to adapt the ADM to the enterprise, or how to create reference models and use them for compliance-monitoring and risk-management – which is what is actually most needed in those stages of architecture that the TOGAF spec aims to cover. And there’s no way that any of that kind of context-dependent knowledge could be assessed in a simplistic multiple-choice exam such as is still used for TOGAF certification. As I mentioned in the previous post, I nearly failed my TOGAF exam because in many parts of the test, none of the options shown on the screen actually matched what I knew from experience works in practice, and the nearest available guess turned out to be ‘wrong’ according to the specification in the book. Conversations at the conference made it clear that I was far from alone in that experience: in effect, anyone who presents a high score in their TOGAF certification may have the book-knowledge but know nothing about the practice, whereas many will score low because they are competent in practice. So as it stands, the TOGAF certification not only tells us nothing about professional competence, but can be actively misleading: a high score may well indicate that someone is not competent to do the work, whereas a low score indicates either high competence or complete failure, with no apparent means to distinguish between those two extremes.

All of which adds up to a serious problem.

It does not, however, mean that TOGAF training is wrong. Quite the opposite: many of the trainers I talked with at the conference made it clear that their training-courses emphasise the importance of adaptation of the ADM, development and use of reference-models, and all the other skills needed to assess and adapt to the enterprise context, and how to extend EA beyond the IT domain itself. To develop those professional skills, we’re likely to need more training, not less; and much of that training needs to be context-specific, too. The catch is that almost none of this material is in the current TOGAF specification, and none at all is assessed in the current TOGAF certification. So yes, whilst to my mind the TOGAF specification is still annoyingly limited and limiting, that’s not the real problem in this case. The point here is that, as it stands, the TOGAF certification is not only meaningless but actively misleading: and right now that is a real, genuine, active, in-your-face, fundamental problem for the profession.

This is a problem that’s being addressed: as I said in the previous post, Len Fehskens is specifically tasked with this on behalf of the Open Group, and others are tackling it in other ways with other groups. But we must first acknowledge that it is a real problem, and one that won’t go away simply by ignoring it, which is all that had been happening to date. So, yes, whilst it’s an uncomfortable fact to face, one of the key signs that the EA profession is maturing as a profession is that it is now willing to face up to such uncomfortable facts.

‘Bad’ news that’s good news all round, in fact.

Delighted to say that Lightning Source have done it again with my new book Doing Enterprise Architecture: a one-week turn-round from sending in the PDF source-files to delivery of the first fifty copies on my doorstep. Very impressive.

And the print-version is now available on both Amazon.com and Amazon.co.uk – those two links point direct to the respective Amazon detail-page. For other online retailers, or your local friendly independent bookstore – like the ever-helpful Red Lion Books in Colchester – use the ISBN book-number: 978-1-906681-18-0

I’ll also have copies to hand out at the TOGAF conference in central London next week – see you there, perhaps?

Please pass the word on for me, if you would? Many thanks!

Just had confirmation from the Open Group that they’ve accepted my proposed presentation for the TOGAF London enterprise architecture conference at the end of April. Working title is Stepping-Stones of Enterprise Architecture, with the following abstract:

TOGAF 9 includes a well-described architecture capability-maturity model. This session, illustrated with practical examples from a wide range of industries, explores how to use the maturity ’stepping stones’ to guide the choice and sequence of architecture activities, in a way that expands outward to engage the whole enterprise.

The ‘takeaways’ would be as follows:

• how to use TOGAF 9 at a whole-of-enterprise scope
• how to use the TOGAF 9 maturity-model as architecture ’stepping-stones’
• how to use enterprise values to bridge across the IT/business divide

In other words, the same overall themes that I’ve been pushing hard for a couple of years now, about how to adapt TOGAF and the like to work with the real enterprise, rather than solely the tiny subset that is its IT.

Variation this time is that I’m using the TOGAF maturity-model (adapted from COBIT or CMMI, I believe?) to show why we need to do things in what is actually a very different order from what TOGAF itself suggests, and why we have to bend the TOGAF-ADM quite radically in order to make it work for the real enterprise.

The detail for all of this will be in my upcoming book Doing Enterprise Architecture: process and practice in the real enterprise – which I now definitely have to finish and get published in time for the conference! (I’m still just about on schedule, but the timing will be tight – wish me luck, perhaps?)

And if you’re going to TOGAF London, I look forward to seeing you there.