Tom Graves / Tetradian

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?

I hadn’t intended to go to TOGAF Munich this week, but a chance email from Jos van Oosten (the lead for the SqEME process framework, over in the Netherlands) got me glancing at the conference agenda – and what I saw there sent me scurrying to search the web for suitable flights. It was previously advertised as being solely about system security – which isn’t my bag at all – but the Tuesday sessions suggest that they’re at last breaking out of the IT-centric rut and getting to grips with whole-of-enterprise architecture – which would be very good news if so… So yup, I’s headin’ there kinda quick to find out, and see which way that wind is blowing.

One side-effect is that I’ve rather hurriedly ‘staked my claim’ to the rework I’ve done on adapting the TOGAF Architectural Design Method (ADM) for use at the whole-of-enterprise scope, with a two-page / single-sheet reference-sheet now posted up on the Tetradian Books website. (Doing this before their conference presentations should verify that I did indeed get there first. ) More on that in the next post. Some time in the near future I’ll also post an equivalent ‘cheat-sheet’ for the revised Zachman framework for whole-of-enterprise architecture.

And although I’m still some weeks away from completing Bridging the Silos, I’ll also post an updated draft on the publishing website, to include the material I’ve slowly been adding over the past few months. Apologies that it’s taken so long, but I’s been kinda distracted…