Tom Graves

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.

Over on the Enterprise Architecture list on LinkedIn, Bala Somasundaram asked about the concept of value-trees as a means of tracking compliance to enterprise values, and thence as a means for validating the value of enterprise architecture.

Value-trees are a key theme in the model I’ve used for describing the service-oriented enterprise. More specifically, they are the trails of ‘pervasive services’ that ensure compliance to enterprise values. In effect, they are the vertical, management-oriented analogue of the horizontal value-chains of the enterprise. But whilst the value-chains traverse through a single layer of the enterprise - the operations or service-delivery layer - the value-trees, must, by definition, pervade every part of the enterprise, from top to bottom, from abstract strategy to each individual process-step, each line of code. To give one example, we know from painful experience that quality-based themes such privacy or security or business-continuity cannot be patched on as afterthought once the design is complete: to make it work, we must include them right from the start. A key aspect of the value-tree is the trail of relationships and requirements that devolves downward from the enterprise values, and upward as confirmation that the value-requirements have been met.

In short, value-trees are the means by which the so-called ‘non-functional’ requirements are made functional in a business sense.

For the most simplistic example, assume that the only value in the enterprise is profit. (I did say it was a simplistic example. ) A suite of principles devolve from this value: for example, that the outcomes of value-chain processes shall be measured in monetary terms; that costs of all activities shall likewise be measured in monetary terms (hence Activity Based Costing, for example); and that verifiable mechanisms shall be used to contrast these two sets of measurements, to derive a measurement of the value in its specified terms - i.e. profit, in this example. To do this, we’ll need to aggregate (’roll up’) all the outcomes and costs; and for management purposes, we’ll probably need to be able to disaggregate (’drill down’) through the business-units and groups and clusters, all the way back down to individual activities. The connections and transforms for aggregation and disaggregation are the branches for the value-tree.

A classic PDCA (plan, do, check, act) approach to quality-management - i.e. management of the value-tree - means that the tree itself needs to be supported by four distinct types of activities:

• develop awareness of the value itself, and of the need to monitor the value
• develop capability to enhance monitoring of and improvement against the value
• measure compliance of activities against the value
• verify and audit to monitor and enhance compliance and continual improvement

(Note that some of these may be required to be kept separate, by law or other regulation - for example, financial reporting versus financial audit.)

Next, extend the example to a slightly more realistic set of values. This leads us to something like Balanced Scorecard, which defines enterprise value in terms of four distinct themes: together with the existing financial measures as above, we add perspectives for Customer, Internal Business Processes, and Learning and Growth. Each of these themes has its own value-tree. (One reason why Balanced Scorecard implementations sometimes fail to give the desired results is that the value-trees don’t reach down far enough into the enterprise: if we take a service-oriented view of the enterprise, every activity has a ‘customer’, has its own ‘internal business processes’, and its own capability and need for ‘learning and growth’.)

To extend this further, each of the ‘-ilities’ trails of ‘non-functional’ requirements implies a root-value - for example:

• quality (in terms of the delivered business services or products)
• security (in all its multitudinous variations)
• privacy
• trust and reputation
• health and safety
• environment and waste-management
• transparency and ethics
• efficiency and effectiveness

As described well in TOGAF, each of those themes devolves outward via a set of principles, which ultimately need to link to everything. But on its own, a principle does nothing: it must be applied in practice (hence the importance of governance), and needs to be testable - and that testability must likewise ultimately link down to everything. (Testability isn’t described as such in TOGAF’s definition for the structure of principles, but is described well in Volere, the requirements-modelling process recommended in TOGAF.) The requirement-trees are the means by which the ‘develop awareness’ of the value-trees devolves downward; the tests in those requirements form part of how ‘monitor compliance’ of the value-trees rolls upward.

So a value-tree consists of the following:

• explicit value or ‘theme’, as topmost anchor for the respective tree
• principles that express and describe the value in practical terms (upper branches of the requirements-tree)
• requirements and tests, all the way down to the finest-granularities (both goal-oriented [end-point] and mission-oriented [continual / continuing])
• measurements, with tree of transforms and identifiers for roll-up and drill-down
• support-processes (’pervasive-services’) for ‘develop awareness’, ‘develop capability’, ‘monitor compliance’ and ‘verify’

Each tree is fairly straightforward in itself: the complications arise from the fact that many of them will present conflicting requirements (e.g. security versus trust, safety versus efficiency). Because of this, there needs to be a tree of relative priorities, some of which may be imposed from ‘outside’ (e.g. legal requirement for priority of health and safety before profit). Ideally, there needs to be one single ‘master-value’ which acts as the ultimate arbiter for priorities - hence the importance of an unchanging enterprise vision.

Better stop there for now: but as usual, comments/suggestions would be most welcome!

Another item from the LinkedIn conversations.

We’d been having a detailed discussion on the internal structure of TOGAF 9, when the following comment came from one of the other participants:

“I see TOGAF 9 as an SDLC method with a bit of knowledge management. Am I missing something?”

It was clearly meant as a snarky putdown, but it’s worthwhile answering at face value.

TOGAF is a method, a framework and various other components that, together, form a quality-system.

As a metaphor, or a very approximate analogy, every quality-system is “an SDLC method with a bit of knowledge management”. COBIT is. So is ITIL, Deming’s PDCA, ISO-900x, Six Sigma, the US Army’s ‘After Action Review’, and many many other examples.

Beyond the metaphor, TOGAF is a (much larger) superset of “an SDLC method with a bit of knowledge management”. In some cases software may be involved in the end-result, but it’s not about development of software as such - it’s about development of the enterprise as whole (hence ‘enterprise architecture’, not ’software architecture’). There is quite a bit of knowledge involved, but also a strong emphasis on business purpose (i.e. emotional/relational/aspirational, not virtual), and also on dialogue, emergence and ecosystems - i.e. proactive rather than solely reactive.

When assessing the quality concerns within a quality-system itself, the devil is in the detail. Hence there’d been a lot of reference to detail in that LinkedIn thread [and hence the putdown - he couldn’t be bothered to read the detail, so he decided to heckle instead]. Once we’ve identified and cleaned up the flaws and inconsistencies in the detail, we can simplify, clarify: simplicity is a desirable characteristic for an SDLC-like quality-system.

At the end, we’re after simplicity without being simplistic. Describing TOGAF as “an SDLC method with a bit of knowledge management” is a usefully simple analogy; but unless there is awareness of the detail behind that simplicity, it risks being dangerously simplistic.

By analogy, trying to build a house with virtual bricks and imaginary girders is not a good idea: looks good on paper, perhaps, but doesn’t work in practice. Likewise, trying to develop an enterprise with a software-development method is not a good idea. That’s the real distinction here.

Okay, back ‘home’ in England after the TOGAF conference in San Diego. Time to reflect a bit.

First: a real sense that I’m not as on my own in my approach to enterprise-architecture as I thought and felt I’d been: there are a lot more folks out there now who recognise the inadequacies of standard IT-centric TOGAF, it’s just that in many cases it was still at the level of a feeling of discomfort rather than explicit articulation.

(In that, I owe an apology to Len Fehskens and Walter Stahlecker, who did indeed articulate that discomfort at the TOGAF Munich conference last October. After I first saw their presentations at Munich on ‘the future of EA’, it did feel that a fair bit of had been all but lifted from the conversations I’d had with them at previous conferences; but I now acknowledge I’d done an Isaac Newton, claiming exclusive ‘possession’ of ideas that were more out there in the general aether. The simple fact is that they’d arrived at much the same conclusions as I’d done, but each from an entirely different direction: I should have celebrated that fact rather than being annoyed about it! :wrygrin: )

Anyway, for me, a lot of very good conversations: the mood seemed far more receptive than before to ideas about the need to get out of the IT-centric rut and move to a more explicit whole-of-enterprise perspective. Having the books definitely helped in that: in street-value terms, I must have given away something like $3,000-worth of books, plus probably much the same in e-books, but it meant that I had something concrete and (literally) tangible to back up my thesis about the need for a broader EA scope, and it certainly helped in terms of establishing credibility. It was really noticeable, though, that the people who picked up on the ideas quickest were almost all outside of ‘mainstream’ EA - either in non-information-centric industries and contexts (such as one of the US federal government departments, or again a large logistics operation), or from countries outside of the US/British ‘axis of IT-centrism’ (such as Norway, Malaysia, Japan, China, Switzerland, and, of course, the Netherlands).

Some parts of the conference were excellent - particularly the business architecture sessions led by Bob Weisman - but some were appalling, bluntly. The lead keynote speaker said almost nothing useful beyond sales-pitch, and even somewhat sarcastically that EA was irrelevant to his own work - which was not a good start…  And at least two of the plenary sessions on cloud-computing were blatant sales-hype, with nothing of substance behind them at all: a bit disappointing, to say the least (which to my mind was true of the entire cloud-computing hype, to be honest - I’m seeing all too many memories of the ‘Business Process Re-engineering’ farrago a few years back, such that it’s clear that no lessons have been learned from that debacle at all). But there were some definite highlights, too, such as Bob Weisman’s presentation on “Enterprise architecture: the strategic tool for innovation in tough times”, and Chris Armstrong’s presentation on “Agile enterprise architecture”: in that sense, it was worth going there, regardless of the TOGAF 9 launch.

And TOGAF 9 itself? Well, I’ve had more of a chance to look at it in depth (i.e. something to do in the long long waits at airports, and on the flights themselves…), but I’m still disappointed at the lost opportunity that it represents. To be fair, The Open Group is focussed on “boundaryless information flow”, so the over-emphasis on IT should hardly be a surprise; and the history of TOGAF itself, certainly from version 7 onwards, represents a slow climb up from the IT-centric depths. But although the Open Group may need to emphasise information above everything else, that isn’t true of the enterprise-architecture discipline as a whole: and since TOGAF is the leading framework here, that imposes some really frustrating and unnecessarily arbitrary limitations on where and how we can use it. Hence the disappointment.

There’s no doubt, though, that from an IT-architecture perspective, TOGAF 9 is a huge improvement on the previous version. There’s been a lot of clean-up, it’s far better structured, the Content Framework (adapted from CapGemini’s IAF, apparently) and Capability Framework (from Bob Weisman) look like a good basis for future standards for interoperability and architecture governance. And there’s some explicit guidance on how to link across to SOA and security-architecture - though, like me, some of those practitioners are a bit disappointed that the links don’t go far enough into their respective spaces.

Yet despite all that good effort, it still doesn’t work properly for iterative architecture, or for anything outside of an IT-centric scope. And the reason is exactly the same as before: the absurd assertion that all enterprise architecture can be crammed into a fixed scope of ‘anything not-IT that impacts on IT’ (the proper meaning of what they term ‘business architecture’), ‘information systems architecture’ (IT-only) and ‘technology architecture’ (again, IT-only). It does sort-of work for low- to mid-level EA maturity; but it acts as a rigid block against moving any further in maturity-levels - and that move is what business is demanding now.

The good part, I suppose, is that the critiques and solutions I developed in Bridging the Silos and Service-Oriented Enterprise apply to and work just as well with the new version as they did with the old. I’ve now set myself the target of doing a new ‘TOGAF 9 edition’ of Silos in time for the next Open Group conference in London, in April: on that, Watch This Space, as usual?

In transit to San Diego, for the Open Group conference and the launch of TOGAF 9. Weighed down with what feels like a ton of books (though it’s probably only about 30kg - I’d hate to have to carry a literal ton of books…) to hand out there, as an ideas-and-marketing exercise: if you’re going to be there, give me a yell somewhen.

Otherwise, yes, probably expect even more erratic service than usual for the next few days - especially today and Thursday/Friday, which will be eaten up with travel.

Best wishes to all.

Was intending to miss the next TOGAF conference - it’s in February, in San Diego, which means dealing with all the joys of US ‘Homeland Security’ as well as a seriously expensive travel-bill. But it looks like I’d better go, ‘cos not only is it the formal launch for TOGAF 9 - which I do need to know about - but it seems they’ve finally, finally ‘got it’: the conference agenda specifically includes a stream on “Extending EA to the Enterprise”:

Extending EA to the Enterprise: Re-thinking Architecture, Quest to Apply Architecture Holistically

The subtitle is a direct quote from Len Fehskens’ presentation at TOGAF Munich, so I guess he’ll be presenting there.

I’ve put in a bid to do a presentation there, which should defray the expenses a bit - they offer a lower conference fee for speakers. But if not, well,  I have possible alternatives to cut the cost. And Silos should at last be be in print by then. As usual, Watch This Space?

I’ve now posted on the Tetradian Books website a two-page (single-sheet) reference-sheet on the revised TOGAF ADM that I use for whole-of-enterprise architecture.

The sheet is an extract from the ‘Methodology’ chapters in my still somewhat delayed book Bridging the Silos: enterprise architecture for IT-architects, where each step of the adapted ADM is described in a lot more detail.

Share and Enjoy, as usual?