Tom Graves

Just come off the phone from an excellent conversation with Sigurd Rinde, developer of Thingamy - brilliantly summarised by Hugh ‘gapingvoid’ MacLeod on 30megs.com (”Here’s 30 megs. Now go run Germany.”)

Key point is that it connects exactly with whole-of-enterprise architecture: the architecture analysis phase - the ‘enterprise ontology’ - leads directly to enterprise software for information/process flow. So it’s not just ‘actionable enterprise architecture’ - to use a current popular buzz-term - but executable enterprise architecture. A few of the existing enterprise architecture toolsets are starting to get somewhere close to this - EVA NetModeler from Promis being perhaps the best example - but this comes at it from another direction entirely, and a more immediately usable direction at that.

That’s just the start. The key aim of Thingamy is to tackle the complex, near-chaotic, barely-repeatable process-flows that businesses really use in most of their work, and which to date have barely been addressed by existing enterprise software, precisely because they don’t fit the usual clunky true/false logic. The real-world processes that people use, in fact. Sigurd suggests that something like two-thirds of all business processes fit into this ‘barely repeatable’ category, yet almost all ‘enterprise software’ efforts to date have focussed on the ‘easily repeatable’ end of the scale, precisely because it is ‘easier’ (easier to sell to those who cling onto wistful dreams of ‘control’, too… :wrygrin: ). As with the comparison of analogue and digital - analogue can replicate digital, but digital can never do more than provide a abstraction of analogue - so too are the ‘easily repeatable’ processes merely a limited subset of the real ‘barely repeatable’ ones. So something that’s designed to tackle the ‘barely repeatable’ processes can also do all the ‘easily repeatable’ ones - yet much, much more. Definitely interesting…

To an enterprise architect, one obvious example of a ‘barely repeatable process’ is enterprise architecture itself. With many thanks to Sigurd, I’ve downloaded a copy of Thingamy, and over the next few weeks - time and sanity permitting - will have a go at implementing an executable version of my amended-TOGAF ADM, as one directly useful place to start. Watch this space?

[Many thanks to Sally Bean for her initial pointer to the 30megs site, by the way.]

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.

Many thanks to Tom Cagley of Software Process & Measurement, who interviewed me a few weeks ago for a podcast on enterprise architecture for his SPaMcast.net audience. (Likewise many thanks to Pat Ferdinandi for linking me up with Tom in the first place.) He published the podcast yesterday, so it’s now available for downloading or for listening online. (The interview itself starts about ten minutes into the 50-minute podcast.)

Although I perhaps rambled sideways a bit too often, we covered a broad range of themes around the nominal topic of extending enterprise architecture beyond IT, but in a way that still makes sense to IT-audiences. As Tom suggested, I ended with a plea for IT-folks to get more real about business - with enterprise architecture as the architecture of the whole enterprise, not just its IT - and also to get real about the role of people in process - rather than assuming that IT can do everything, which it can’t and won’t.

A lot of fun for me, and I’m glad to say raised a fair few laughs from Tom as well (and in the right places, too! ). Felt good - would like to do it again somewhen soon.

And though I says it meself I’d say it’s “Recommended listening for anyone interested in enterprise architecture” - so again, many thanks to Tom Cagley for this.

One more from the archives - or rather, a rework into another format of the ‘manifesto’ from the intro to my book Power and response-ability: the human side of systems. The basic version is part of the book, and also available as a standalone reference-sheet, but I thought some people might prefer it in PowerPoint form, with one concept per page. Note, though, that it’s quite a bit over a hundred slides - 95 ‘theses’ plus the section headings - so it does take a while to skim through.

I’ve now published the annotated version of my film-script ‘Wombat & Cockie‘ in book-form - see the Tetradian Books website here for the book-info, and here for the free-download PDF e-book.

Set in the drug-gangs culture of present-day Melbourne, it’s an odd mixture of a cops-and-criminals black-comedy, merged with a Dreamtime motif in which all of the players enact the characteristics and character of the respective bird or animal Dreaming.

Of all my scripts, this is the one most likely to reach production: a colleague spent some time a couple of years ago developing it further, but I haven’t heard from her since. Not that it matters: it’s just a bit of fun, really, though there are some serious themes behind it, using fiction to explore the complexities of interlinked transactions of violence and abuse at a societal level.

My regular outing to make use of Lightning Source’s annual ‘free setup’ promotion, it’s technically vanity-publishing - but I spent at least six months writing the script, so it seems worthwhile to get something tangible out of all that work! It won’t be available in printed form, other than direct from me, but anyone is welcome to download the e-book for free.

Hope it helps, anyway: “Share and Enjoy”?

And the last in the current series of slide-decks that I’ve placed on Slideshare.

This one’s from early 2007, and describes some of the analysis that I did at that period to find ways to break free from the usual IT-centric constraints of so-called ‘enterprise’ architecture. Full title is Whole-of-enterprise architecture: Extending enterprise architecture beyond IT. Some of the slides have been re-used in other presentations in this series, but the detailed content is specific to this example. Hope you find it useful, anyway.

Another slide-deck from a fair while back (2001, in this case), but still seems relevant today. Many of its quotes reference a section in The Economist edited by Peter Drucker, about ‘the business of the future’.

[It’s in PDF format, as the ‘Notes View’ of the PowerPoint, soslides and script together.]

Another item from my slide-deck collection: this one’s based on some work I did for a client in 2007 on extending Zachman and TOGAF to meet their whole-enterprise architecture needs. It describes TOGAF 8, but much the same applies to TOGAF 9.

Yes, I know, I’m overdoing the posts at the moment… but it does seem to be relevant, though.

This one’s about the following Twitter exchange between myself (’@tetradian’) and TOGAF training-specialist John Polgreen, starting from the Colin Wheeler ‘tweet’ discussed in my previous post:

• colinpwheeler Depends on the true definition of each. One person said to me that there is no business without information, one and same.
• tetradian “business=information” is VERY dangerous! business = transactions + conversations + relations + purpose
• JohnPolgreen the point here is that we’ve put the emphasis on the IT side of EA for too long, now we must see business and IT holistically.
• tetradian yes - IT is only 1 part of 1 dimension of business, but popular b/c it gives desired illusion of control
• JohnPolgreen back to TOGAF - what can we do to shore up Phases A and B to help create a more holistic approach to EA?
• tetradian we don’t ’shore up’ TOGAF Phases A/B, we drop the idea of only 4 architectures - see http://bit.ly/Rl6tm
• JohnPolgreen what about a decision point after Phase A - light IT, your modified ADM; heavy IT, old ADM w shored up B

…at which point it’s clear we need to switch to an explanation that won’t fit in Twitter’s 140-character limit!

There’s a confusion here about the role of the initial stage in an architecture-cycle (TOGAF’s ‘Phase A’), caused by TOGAF’s inherent IT-centrism and its muddled notions about what an iteration is and does - blurring Waterfall and Agile styles in a way that really doesn’t work.

Classic TOGAF (version 8 or 9 - they’re essentially the same here) confuses the structure of the EA cycle - the iteration Phases, which are essentially a pair of interlinked quality-management cycles - with the content of the EA cycle - its scope and business-question. That’s what I aimed to resolve in the cleaned-up ADM.

The architecture method is a means to address any architecture-related business-question. In effect, TOGAF’s existing structure presumes that any business-questions to be addressed will be IT-related - hence John’s ‘heavy IT’. In particular, it presumes one of three possible requirements: clean up the IT-architecture, including IT-applications, IT-maintained information, and IT technology-infrastructure; identify the impact on IT of any change to business-strategy or compliance requirements; and use reviews of the technology / IT landscape to suggest and drive changes to business practice.

But it needs to be understood - hammered home, in fact - that this is only a small subset of enterprise architecture. As it stands, TOGAF may be IT-heavy, but it’s still EA-light. As I’ve described in my books - especially in Doing Enterprise Architecture - the real scope for EA is much broader. Yet once we understand that it is broader, paradoxically, we can also make the cycle structure much simpler. We drop any assumptions about a fixed scope (TOGAF’s Phases B, C1, C2 and D). We drop any assumptions about the scale and duration of the cycle (which shunts much of TOGAF’s Phase A into the special-purpose iteration represented by TOGAF’s Preliminary Phase). We drop any assumptions about the necessary scope and scale of implementations (simplifying TOGAF’s process-heavy Phases E to G). We drop any technology-centric assumptions about the final benefits-realisation / lessons-learned assessment (TOGAF’s Phase H). And we simplify the whole thing by using a classic IT trick: we make it recursive, allowing cycles within cycles within cycles, all under exactly the same governance rules.

Once we do this, it becomes clear that TOGAF is a special-case worked-example of the use of an enterprise architecture method, in which there are specific sub-cycles to address the detail of the required business-issues, manual-process issues, application and data concerns, and technology-infrastructure changes needed to address a specific type of business-question. So there’s no need for “a decision point after Phase A - light IT, your modified ADM; heavy IT, old ADM w shored up B” - more to the point, to do so would introduce unnecessary complications, enshrining unnecessary special handling for what is actually not a particularly especial case. Instead, the scope, the stakeholders and the overall assessment approach are all specified within Phase A.

Once you fully grasp that point - that TOGAF’s Phases B, C and D are simply examples of usages of a generic assessment-process which compares required or actual conditions at specified time-horizons, to derive change-requirements - it simplifies the whole procedure right down. There is no ‘light IT’ versus ‘heavy IT’: some architectural concerns may involve no IT, but it’s all the same architecture development process. We start with four straightforward questions:

• what things?
• what information?
• what relations with and between people?
• for what purpose?

…and build the architecture outward from there.

TOGAF complicates things unnecessarily. Keep it generic; keep control of any unwanted, unwarranted special-cases arising from unfounded assumptions such as IT-centrism; keep it simple, keep it simple, keep it simple. That’s why I keep pushing and pushing for a simpler, broader approach to enterprise architecture: because that’s what works.

This one’s a pick-up from a ‘tweet’ by Colin Wheeler, replying to John Polgreen:

Depends on the true definition of each. One person said to me that there is no business without information, one and same.

Red-rag-to-bull time for me: in effect that “one person” is saying that business is only information, which is about as insanely IT-centric as one can get. So yes, I exploded:

“business=information” is VERY dangerous! business = transactions + conversations + relations + purpose

…which in classic Twitter style is probably too compressed and cryptic to make any sense at all… oh well. But worth expanding on here.

The line about “transactions + conversations + relations + purpose” is an expansion on the old Cluetrain tag-line that “markets are conversations”, using a crosslink to the ancient ‘four dimensions’ of physical, virtual, relational and aspirational that I use in most of my work on enterprise architecture (EA):

• physical ‘things’
• virtual information and imagined space
• relations between people
• aspirations for individual and shared purpose

Transactions may be physical, virtual, relational etc; conversations are a composite of virtual information and relations between people; and so on, and so on. The architecture of the enterprise must support every required combination of these themes.

But classic ‘enterprise architecture’ strips all of this down to a tiny subset: the small segment that can be handled exclusively by IT systems. It then turns this round, and says that business is computer-based information - hence the IT-centric delusion that IT is the sole centre of the business world. It’s true that we can just-about get away with this delusion when the business genuinely is information-centric - as in insurance, finance or banking - but even then it’s all too easy to forget about the other dimensions, as the banks did when they set out to dismiss the relational aspects of business by closing all their retail branches, and then wondered why they had no customers left… sure, it produced significant short-term savings but very nearly at a cost of killing the business. Not wise… In any other industry, from aviation to logistics to manufacturing to retail to utilities to pharma to telco to… well, anything, really… that IT-centric delusion means that the resultant EA rapidly becomes worse than useless: its blinkered view actively hinders the development of the business, because it all but ignores anything other than IT-based information. Which, right now, is precisely why so many organisations are challenging the value of their EA. Not wise, on either side…

So there’s a general warning here to every architect. If someone says “no business without information”, they’re right: information is an essential aspect of business - though it may come in many different forms, from conversations to scraps of paper to ideas drifting in from the aether as well as in electronic records sitting in a data-centre or on a screen. But whenever anyone throws in an exclusional rider, such as “no business without information, one and same” - that business is only information - that should set alarm-bells ringing straight away. The business and its architecture always involve all of the dimensions - physical, virtual, relational, aspirational - all of them, interweaving, always. Anyone who says otherwise is deluding themselves, and others, trying to take some over-simplified ‘easy way’ such as IT-centrism that always works out to be harder in the long run. You have been warned!