Archive

Posts Tagged ‘Enterprise architecture’

Once more, from the top…?

March 26th, 2012 No comments

Still going round my all-too-usual loop: what the heck am I doing here?

(In a business sense, of course… :-) )

This is a follow-on to my previous post ‘Don’t start with How‘ – about how I’ve been needing an urgent rethink of all my websites and other stuff, and how I ended up going round and round in circles in that rethink by starting from the How. What I need to do instead is follow Simon Sinek’s advice – and my own advice too – and start with Why.

So okay, let’s start this dance again. From the top, please, folks?

So what is that ‘Why’? What the heck am I on about? Nearest I can find is a summary I’ve used often for enterprise-architecture, and which fits well with everything else too: that things work better when they work together, efficiently, reliably, with elegance, on purpose.

That tag-line is actually about the four-and-a-bit dimensions of effectiveness, hence I could rework it into something quite a bit shorter, and closer to a proper enterprise-vision:

  • making things more effective, for everyone

Okay, so I don’t make many things as such – more I mostly think things… (Well, someone has to do that, I guess?) And phrasing needs to be much better, tighter, too. But it’s adequate as a start for now.

So how well does that tie in with my existing business-tag-line, “the futures of business“? The short-answer is ‘sort-of’ (if only somewhat ‘sort-of’…). For example, it gets to be a problem if I have to explain what ‘futures’ is, before I can even start…

(But it’s not as hard as the endless struggle with trying to explain what ‘enterprise-architecture’ is and does… :-( )

The business-focus of what I do is business-transformation.

(Which is about futures, and change – yet also conveniently avoids the no-no word ‘change’ itself… :-) )

This focus on transformation can go all the way from very-big-picture to fine-detail.

(Hence tools such as Enterprise Canvas and the ‘This’-game.)

…and all the processes of doing / thinking / relations / purpose that guide that business-transformation.

(Hence context-space mapping, the tetradian, SCAN, SCORE, the ‘This’-game and so on.)

…to bridge between strategy and execution.

(Including the big-picture scope that comes ‘above’ or before strategy, and the unchangeable-past that comes after execution.)

…it’s about how it works as a whole, for everyone.

(Which, again, is about the really-big-picture, and concerns such as whole-enterprise scope, ‘anti-clients’ and the human aspects of enterprise.)

 …a focus on responsibility and ‘response-ability’.

(Hence the SEMPER diagnostic, and tools such as RACI-maps – and also, at the really-big-picture level, ideas around responsibility-based economics.)

…and, in parallel with that, an emphasis on the human side of systems.

(Hence the book and ‘manifesto‘ on the human side of business-architectures.)

…which links to the role of story in business-transformation and the various architectures of the enterprise.

(Hence a whole swathe of posts and other explorations here, various presentations and the like, and, of course, another book.)

… there’s the notion of service, and the architecture of the ‘service-oriented enterprise’.

(Hence that book too, and all of the work around Enterprise Canvas and the like.)

…about different players’ roles within the enterprise, and responsibilities to the enterprise that go with that role

(Hence the work on the complex tradeoffs between control and agility, and on the respective responsibilities of backbone versus edge.)

…about what’s needed to keep on-track to purpose.

(Hence frameworks such as ‘Vision, role, mission, goal‘, and themes such as governance and service-viability.)

…the need for tools, toolsets and methods that can support the whole of this scope.

(Hence revised-ADM, extended-Zachman, extended-VSM, Enterprise Canvas and yet more books, and many posts on tools and toolsets, methodsmetamodels and the like.)

…and a focus on value and values as core to the whole enterprise.

(Hence many posts on values and related topics, and on kurtosis-risk (‘long-tail’ risk) and the like.)

All of which is, yes, a lot. Yet all of it does come back to effectiveness – and effectiveness for everyone, rather than solely for a self-chosen few.

So that’s it: start from the top, working downward each step of the way towards something practical, something we can use.

And that’s me, I guess; that’s ‘my’ enterprise, the enterprise to which I seem to belong. The enterprise I need to express in everything that I do.

Comments, anyone? Anything that I’ve missed?

Over to you, anyway.

(And thanks also for being here with me on this often-strange journey of mine… :-) )

Don’t start with How

March 24th, 2012 1 comment

Don’t start with How.

Or What, for that matter.

It’s been kinda quiet on this blog the past few weeks, but I’ve been horrendously busy behind the scenes. Some of the ‘busy’ you’ve sort-of seen here, in previous posts about writing and publishing. Other bits you won’t have seen yet, such as the preso for the Africa4IT conference that, in the end, I couldn’t go to – I’ll post the preso on Slideshare soon anyway. A whole load more going on, too.

But most, far worse, I’ve fallen into a classic project-development trap: I started from How.

Fact is that my websites are a mess. My marketing is a mess. Even my email-management is a mess at the moment. And I need to do a heck of a lot to make my material more accessible, rather than buried deep in various blogs and books. So it’s been kinda obvious that I need to get myself together on some kind of web-strategy – or, more correctly, information-relationship strategy. And implement it properly, and urgently.

But what did I do? I started from How.

I’ve spent days – weeks – poring over app-frameworks and web-frameworks and old wiki-code and the Webpress codex, trying to work out the best way to do what I sort-of think I want to do. I’ve reinstalled my old development apps, and some new ones too; I’ve pulled up all manner of development-language reference-guides; I’ve set up  a web-server on each of my test-machines; all the usual stuff. I’ve spent hour after hour agonising over whether I should hold onto my old wiki-formatting, try to go the HTML-sort-of-WYSIWYG route (which I loathe), or go entirely over to Markdown which fits well with my publishing-workflow but still feels way too limited in its formatting. I planned out SQL-schemas that would allow me to reuse the same text on multiple views – mobile and desktop, and on to publishing-flow. I tested out options to go direct to apps-delivery. More and more and more detail.

And in the desperate rush to have something to show as soon as possible, the end-result, so far, is still nothing at all.

Oops…

What I need to do instead is take my own advice:

  • slow down from the rush of doing
  • stop for a moment
  • refocus – where would all of this fit in the big-picture?
  • where’s the story that would hold it all together?
  • then start again from that Why.

Start again. Not with the What. Or the How. Always start from the Why.

Sigh.

Watch This Space, folks?

Publishing Tetradian e-books via Leanpub

March 12th, 2012 1 comment

I have at last found a viable workflow to produce e-books of my various books and blogposts, via Leanpub.

There’s one significant constraint in this form of publishing: Leanpub uses Markdown text-files for input, which is a fair bit more limited in its formatting than my books normally use. But that constraint fits well with the very tight limitations of .MOBI (Kindle) files – the cause of so many of my conversion-nightmares prior to finding Leanpub – and it also works well with automated import and conversion of blog-posts, which is something I’ve needed for a very long time.

Leanpub also presents e-books as a ‘package deal’, with EPUB, MOBI (aka AZW, for Kindle) and portrait-formatted PDF formats all included in the one price. They also support an automated means to sell via Apple iBooks (for iPad etc) and Amazon (for Kindle), but doing that costs a fair bit and it’s a much lower royalty, so I’ll only be able to do that for books for which there’s a sizeable demand. For everything else, Leanpub is simple enough and cheap enough to make it worthwhile to publish a lot more of my material that way.

A key theme at Leanpub is publish early, publish often. If you buy a book, you not only get all three file-formats, but you also maintain access to all future updates – Leanpub send you an email to let you know whenever a new update is available.

See my home-page at leanpub.com/u/tetradian for the current status of each item – published or in-development – and, if published, the current content.

—-

I’ll be doing three types of e-book publications: books, practice-notes, and anthologies of posts from the weblogs.

Books (Tetradian Enterprise Architecture series)

These are straightforward e-book versions of my existing books, though in some cases with additional content from the blogs. The aim is that these should also move out to Amazon (for Kindle) and probably Apple (for iBooks). Once published, the content should not change – in other words, the same as for a conventional printed book.

Pricing will be a lot less than for the respective printed book.

Already published on Leanpub:

Conversion from Word is not all that simple: each book takes a few days to get ready for publication, so it’ll be a few weeks before all of the existing books are up there. My current priority-order for conversion of the other published Tetradian EA books is:

  • The service-oriented enterprise - with some additional notes linking it to Enterprise Canvas
  • Doing enterprise-architecture
  • Bridging the silos - with some additional notes on working with TOGAF 9.1 and Archimate 2.0
  • Real enterprise-architecture
  • Power and response-ability
  • SEMPER & SCORE

Please let me know if you need my to change that sequence.

(I’ll probably also do all of the books in the other series at some stage, but it’s not so much of a priority.)

Practice-notes (Tetradian EA Practice series)

These will be ‘mini-books’ – typically about half the length of my usual books – that cover a specific topic focused on some practical theme. The content will be based on existing weblog-posts, but will usually be edited quite a bit to make a more consistent structure and story, and there’ll also be a new introduction-chapter to set the context in each case.

These will be updated occasionally, to keep in line with developments in practice, but also to keep the number of updates sent to Apple or Amazon down to a practicable level.

Pricing should be around half that of the full-length e-books.

Titles already in plan include:

  • Using SCAN for sensemaking – about sensemaking and decision-making for enterprise-architecture with my SCAN framework
  • Modelling with Enterprise Canvas – the simplified notation for Enterprise Canvas, plus model-development methods such as the ‘This’ game
  • Backbone and edge - about the architecture trade-offs between slow-changing core and fast-changing edge, waterfall versus agile, and governance to match
  • From business-model to real-world practice - conversion from Business Model Canvas to Enterprise Canvas, customer-journey mapping and implementation-layer models such as UML and BPMN
  • Modelling service-content - how to use the expanded Zachman-type taxonomy from Enterprise Canvas for whole-of-enterprise modelling
  • Whole-of-enterprise architecture - how and why to extend enterprise-architecture beyond its conventional focus on IT

Again, let me know if you want me to add other themes or to change that priority-order – and keep an eye out on my Leanpub page as to when new Practice Notes e-books will be coming out.

Weblog-anthologies (Tetradian EA Topics series)

These will be straightforward anthologies from the Tetradian and Sidewise blogs – the kind of publishing for which Leanpub was initially designed. There’ll be a very simple introduction-chapter, and some minimal clean-up editing, but otherwise each chapter will essentially be the same as on the weblog.

(Note that, for obvious reasons of cross-reference and cross-linking and the like, some blog-posts will appear in more than one anthology.)

The main purpose here is to sort the many posts on enterprise-architecture and related themes (more than 500 posts so far…) into a more usable form, and in a format that’s convenient for offline reading on Kindle and the like.

These will be updated quite often, whenever a suitable set of blog-posts come along – and because of the frequent updates, will probably not go to Amazon’s Kindle-store or Apple’s iBookstore. (You would do a simple file-import to your reader-device instead.) Perhaps the key point is that once you’ve bought the anthology-book, you’ll continue to get all of those updates for free.

Pricing will be minimal – it’s mainly to cover my time for conversion and clean-up. But the price for each book will rise slowly as the amount of content increases – so the earlier you buy the book, the better the deal you’ll get. :-)

Some key topics already identified include:

  • Tools and toolsets – including all the discussion around metamodels and the like
  • ‘Really Big Picture’ enterprise-architecture – applying EA principles to themes such as economics, sustainability and society as a whole
  • The architecture of management – rethinking management and the like from an EA systems-thinking lens
  • Story and narrative in enterprise-architecture – the underlying themes behind The enterprise as story

Again let me know if there’s any specific theme upon which you’d like me to develop an anthology.

Comments, anyone?

New book ‘The enterprise as story’ is published

March 11th, 2012 No comments

Also launched at the Integrated EA 2012 conference was my new book ‘The enterprise as story‘:

Full title: The Enterprise As Story: the role of narrative in enterprise-architecture

ISBN: 978-1-906681-34-0

Description:

Most current approaches to enterprise-architecture describe everything in terms of structure. Yet people work better with story than with structure – and people are the enterprise. As we expand the architecture towards a true whole-of-enterprise scope, we need to describe the enterprise as story. Story is everywhere in the architecture – even the enterprise itself is a story.

This ground-breaking book places story at centre-stage for the architecture, itself using a narrative structure to explore the role of narrative in enterprise-architecture. Via business story-structures such as the Market-Cycle, and genres such as We Sell Certainty, it shows how stories underpin every aspect of the enterprise – and how we can use story within the architecture to enhance overall enterprise effectiveness.

Topics covered include:

  • how to use story and narrative to assist in sensemaking for architecture
  • how to create engagement in the architecture through story
  • how to balance structure and story for better business results
  • how to identify and use business-story genres to guide overall architecture
  • how to change the organisation’s relationships with its ‘anti-clients’ from business-risk to business-opportunity
  • how to use story-patterns to identify and resolve strategic business-issues
  • how to leverage your own experience to create stronger architecture stories

If you want to create real engagement in the architecture and the enterprise, this is one book you’ll definitely need.

You can already order the printed book from Amazon.co.uk or Amazon.com, and presumably most other book-retailers as well.

(Ignore the comment on Amazon about ‘Temporarily out of stock’: Amazon say that for any print-on-demand book that they themselves don’t produce… It’s at most a couple extra days’ delivery-time, that’s all.)

I’ll also be adding it to the book-set deals on Kevin Smith’s Pragmatic EA bookshop: should be set up within the next few days, anyway.

And new - you can now buy the e-book from Leanpub, as a complete set of PDF (portrait-format), EPUB (for iPad, Sony-Reader etc) and MOBI (for Kindle).

I’ll be doing a lot more publishing via Leanpub from now on: not just e-books of the existing books, but also smaller more focussed e-books on topics such as SCAN sensemaking and modelling with Enterprise Canvas. More details on that in an upcoming post, anyway.

Presentation ‘The enterprise is the story’ now online

March 11th, 2012 No comments

The enterprise is the story‘ – my presentation from the recent Integrated-EA enterprise-architecture conference in London – is now online on Slideshare:

The slidedeck is just under 80 slides, split into five sequences:

  • “What’s the story?” – introducing the idea of story as a way of working within enterprise-architectures, using the example of Carnaval, in Rio de Janeiro
  • “A cast of thousands!” - describing the ‘sharedness’ of enterprises and the enterprise-story, again using Carnaval as its example
  • “The plot thickens…” - linking story to process and the practical details of the enterprise
  • “To be continued…” - exploring the structure of story, and strategic-structures that cause failure of the organisation’s story
  • “Every picture tells a story” - a plea for stronger support of story in our enterprise-architecture toolsets

For once, I did a slidedeck that’s more about visuals than words – and it certainly seemed to go down well with the audience, which is always good fun. :-)

The conference is, for me, one of the highlights of the year, because they cover architectures with such an enormously varied scope: most of the attendees are from defence / security contexts or high-reliability areas such as rail-transport or air-traffic control. I put in a a few sort-of visual jokes that I put in specifically for them – which seemed to go down well, too.

I also did a audio-recording, but it’s a bit crackly. I’ll try to clean it up and, if so, attach it to the slidedeck to make a bit more of a standalone presentation.

Share and enjoy, anyway?

On Archimate 2.0

February 29th, 2012 4 comments

Archimate 2.0 is now available – its formal release was at the end of January 2012, during the Open Group conference in San Francisco. I’ve been a bit busy in the meantime, so this is the first chance I’ve had to do a proper review.

Why Archimate?

Archimate aims to be the standard notation for all enterprise-architecture work, bridging an important gap between free-form whiteboard-style sketches and detail-layer executable models.

The catch is that it all depends on what’s meant by the term ‘enterprise-architecture’… which is not a trivial point, as Len Fehskens explained on the Open Group blog early last year, in his seminal post ‘Enterprise Architecture’s Quest for its Identity‘.

The short answer is that version 1.0 of Archimate was a very good fit for what Fehskens describes as ‘EITA’ – enterprise IT-architecture. It was not a good fit for whole-enterprise architecture – a literal ‘architecture of the enterprise’ – because in essence everything in Archimate 1.0 centred around IT, and it had no real means to describe anything that did not in some way directly impact upon IT.

For a logistics context, for example, we could model how information about a package would move through the system, but not the physical package itself: so there was no real way describe any of the scenarios by which the parcel and the record of that parcel might become misaligned – or, perhaps more importantly, become realigned. (In the real world, that kind of misalignment still happens way too often for anyone to be comfortable or complacent about it – as can be seen in so many Twitter-complaints with the ‘#fail’ hashtag. It’s a very real business-problem – and usually a problem that is rooted somewhere deep within the architecture of the enterprise. Which is why it is our problem.)

There were also several key items that were missing from the Archimate metamodel that were going to be needed by anyone aiming to bridge the infamous business/IT-divide – particularly about motivation. (There’d been some coverage of that in the earlier versions of Archimate, but were dropped in the 1.0 release, perhaps to improve its alignment with the TOGAF 9 metamodel.)

The underlying anatomy of Archimate is also somewhat problematic. As I explained somewhen mid last year in a long post, ‘Unravelling the anatomy of Archimate‘, to me there are what seem to be several fundamental flaws in the structure of its metametamodel that actively constrain its use to an IT-oriented view of enterprise-architecture. And there seems to be no easy way to resolve those flaws without going a long way down into the internals and starting again. The surface-layer can look much the same – and certainly remain backwards-compatible – but the internals would need to be very different to make Archimate usable for the kind of business-oriented enterprise-architecture that so many more EAs are moving towards now.

So when I first found out about the revision for this new version, my attitude was ‘high hopes but not high expectations’. And that’s pretty much what’s happened – except that there’ve been some been very useful additions, some of them in places that I didn’t expect.

So for those of us working in whole-enterprise architectures, there’s good-news, and there’s bad-news. And there’s quite a lot of good-news, and nothing in the bad-news that we wouldn’t have expected, so let’s get the latter out of the way first.

Bad-news: there’s no fundamental move away from IT-centrism

The bad-news it that we’re still stuck with the same inane IT-centrism as before – right from the very first sentence of the specification:

An architecture is typically developed because key people have concerns that need to be addressed by the business and IT systems within the organization. … Architecture descriptions are formal descriptions of an information system, organized in a way that supports reasoning about the structural and behavioral properties of the system and its evolution.

There’s a lot more to any enterprise than just its IT-based information-systems, but in essence that’s all that this new version of Archimate would allow us to handle. And that annoyingly-arbitrary constraint is carried through into the same old pseudo-layering of Business, Application and [IT] Technology, in which ‘Business Layer’ is a similarly arbitrary and annoyingly-incomplete placeholder for ‘anything not-IT that might affect IT’. Not only absurd, but now seriously out-of-date for current EA practice – as even Open Group would freely admit, given the nominal focus of many of the presentations at the San Francisco conference and elsewhere

Sigh.

And they’ve used the same ‘plug-in’ concept for all the new add-ons as in the TOGAF 9 metamodel – which is a nice idea, but there’s nothing to support it in the existing Archimate metametamodel. So the result is that the underlying architecture has become yet more fragmented – which is going to make it even harder to do the fundamental rework of the architecture that must be done it’s to be usable forward into the future.

Oh well.

But that’s about the sum-total of the bad-news, and none of it was unexpected, so let’s move on to what is good in the new release.

Good-news: the Motivation extension

This wasn’t unexpected, but it’s still very good news: we can now link any architectural-entity explicitly to the reasons why it exists, and in a manner that allows for formal rigour between all of those interrelationships, roughly in line with the Business Motivation Model (BMM). The new entities are a subset of the BMM, but still eminently usable:

  • Stakeholder
  • Driver
  • Assessment
  • Goal
  • Requirement
  • Constraint
  • Principle

In the Business layer we can link these to the existing entities for Value and Meaning, to create a (mostly)-complete trail of derivation for business-purpose. No equivalents in the other two layers, but it probably doesn’t matter as long as entities there are linked up into the Business layer, either direct or via the new Motivation entities.

The only thing that’s bizarre about this is the whole idea of treating motivation as an ‘extension’, rather than core. To use Simon Sinek’s term, surely we should always ’start with why‘?

Good-news: the Implementation & Migration extension

This one’s likewise very good news, and I wasn’t expecting it at all. This gives us a means to model the dynamics of an architecture – the way in which the architecture itself undergoes change. Again the new entities here are only a subset of what we really need for this, but they’re certainly enough with which to get started:

  • Work-Package
  • Deliverable
  • Plateau (for example, an ‘intermediate state’ at some predefined time-horizon)
  • Gap

It does make sense to describe this as an ‘extension’, because we don’t need it to describe a particular configuration or ‘state’ of an architecture – though we do need it whenever the architecture is to change.

The really good-news about this is that it provides a nice graphic workaround for the fact that almost none of the existing toolsets handle architecture-dynamics in any useful way. And if the toolset-vendor implements the appropriate ‘hooks’, this would also provide a solid anchor-point for cross-links into project-management tools and the like. Nice.

Good-news: the Location entity, and other minor amendments

A Location entity had been included in the earliest iterations of Archimate, but for some unfathomable reason it was dropped long before the Version 1.0 release; it now makes a very welcome and very necessary return.

A glance at Zachman should give the reason why it’s so important: without it, we have no means to describe the ‘where‘ of the architecture, whether in virtual, physical or any other form.

The Location entity is arbitrarily placed in the Business layer – which makes no sense, of course, because location should apply to everything, but it’s probably the only way that it can be handled within that absurd IT-oriented ‘layering’. Despite that placement, it is allowed to connect with every other entity, mostly via ‘assignment’ or ‘association’ relationships.

The other oddity is that there’s no explicit distinctions between types of location – particularly virtual versus physical, which is extremely important even in IT-architecture. No doubt this can be handled within toolsets via attributes, but it is a distinction that needs to be addressed.

There are a few other clean-ups down in the Technology layer, mostly new types of IT-specific relationships for newer technologies. To me the most significant item is Infrastructure Function – significant mainly because its stated purpose is to reinstate some much-needed structural symmetry in the underlying metametamodel for Archimate.

What next?

The specification ends with a ‘Future Directions’ chapter, which summarises some ideas about what could be added in future. Which is all fine: except they still don’t include anything that would make it more usable for the non-IT aspects of enterprise-architecture.

At the very least, if Archimate is to be usable for what it purports to do, we need it to be able to cover the symmetric equivalents of Application and Technology in the non-IT space – and not try to dump it all into ‘Business’, where most of it does not belong. The core partitionings that we need in an architecture are:

  • role-type – passive-structure, behaviour and active-structure
  • asset-type – physical-object, virtual-information, human-relation
  • agent-type – physical-machine, IT-system and/or human-process

Role-type is the nominal core of current Archimate. But asset-types are in effect conflated into and scrambled within Technology, Application and Business layers respectively; and the only agent-type fully acknowledged is IT-system, with the others either ignored (physical-machine) and/or arbitrarily shunted into the Business ‘layer’ (human-process). This makes it all but impossible, for example, to use Archimate to describe business-process redesign or process-fallback where the existing or alternate implementation-methods would use machines or manual-processes; it makes it impossible to describe a business-continuity plan for a context where the IT is out of action; it still leaves it impossible to describe that logistics paralleling-problem between physical parcel versus information about the parcel. This are real needs in any viable enterprise-architecture, and we need a notation that can cover them. Hence, if Archimate is to be the notation of choice for EA, it needs to address these concerns: there is simply no other option.

From assorted snippets of conversation with various colleagues I know that such concerns are being explored in the discussions for the next version of TOGAF, currently code-named ‘TOGAF Next’. So if Archimate is to keep aligned with TOGAF, any putative ‘Archimate Next’ would have to follow suit. So I do still have high hopes for something useful and usable happening there; is it too unreasonable this time to have high expectations as well?

Data-architecture 101 and the naming-problem

February 4th, 2012 No comments

The echoes of the ‘naming-problem‘ around business-architecture and the like continue to rumble on, this time via another happy Twitter-exchange with Ron Tolido:

  • rtolido: @tetradian just show me the non-IT people that invented #entarch and / or #bizarch :)
  • tetradian: @rtolido we’re in a circular-definition here: what you call #entarch or #bizarch is whatever was ‘invented’ by IT-people… //  crucial problem is that IT-people labelled as ‘enterprise architecture’ to something that wasn’t ‘architecture of the enterprise’ // likewise with IT version of ‘business-architecture’, which _isn’t_ ‘architecture of the business’ // once we sort out that mess, it becomes obvious IT-people did not invent it – but until then, we have those circular-definitions… // non-IT-people: Deming, Boyd, Beer, Alexander, even Taylor, for heavens’ sake…
  • rtolido: @tetradian All true! Just pointing to the actual roots of both #entarch and #bizarch . Not saying it’s a good thing per se.
  • tetradian: what you’re doing at present is propping up _fundamental_ mistake: mislabelling of ‘IT-view of business’ as ‘business-architecture’ // ‘Open Group Cert in IT-view of Business’ is fine – just don’t call it ‘business-architecture’, because it isn’t! :-) // Data Architecture 101: don’t assign names to things that don’t mean the same as what those things actually are! :-)

And that last point is actually a good idea: apply a bit of bog-standard data-architecture practice to this problem. Let’s look at this whole mess from the perspective of Data Architecture 101:

Step 1: A core principle: all entities shall be assigned meaningful names or terms – i.e. that the assigned name shall correspond to the ‘natural meaning’ of the entity.

Step 2a: If a term that is currently assigned to an entity does not match the ‘natural meaning’ of the entity but is not in common use, the updated name for the term shall be promulgated, and action taken to dissuade use of the former misleading-term.

Step 2b: If a term in common use is currently assigned to an entity but does not match the ‘natural meaning’ of that entity, an architectural ‘waiver‘ or ‘dispensation‘ shall be issued, acknowledging the current usage of that term.

Step 3: If a waiver is issued, the waiver does not mean that the misleading usage is acceptable, but rather that although the fait-accompli is accepted in the present, all efforts must be made to prevent the misleading-term from becoming further entrenched, and every opportunity taken to promulgate a replacement ‘natural-meaning’ term.

This is basic stuff, the kind of routine data-architecture work I was doing twenty years ago and more. Software-coders do it every day; web-designers do it; database-administrators do it. But not, apparently, the people who purport to maintain the formal standards for this kind of work. To use a certain famous phrase, “this does not compute…” :-|

Let’s look at this in a bit more detail.

First, that principle from Step 1, the notion of a ‘natural meaning’. A term or entity can of course be assigned any name at all: sometimes projects and the like are intentionally assigned misleading names, for security purposes or because they’re being used only as ‘working title’ or suchlike. Sometimes such names do stick, misleading or not: ‘tank’ is a classic example. But in general – especially in a data-architecture or in any part of an enterprise-architecture – an entity should be assigned a name that aligns with its use and function: for architectural purposes it doesn’t help anyone if we decide to use the label ‘Glue Pot’ for a delivery-truck, for example, or ‘Salmonella Breeding Station’ as the label for the cafeteria business-unit. In general, it’s a lot more helpful if we call a spade a spade, and so on.

[We can take this a bit further, perhaps - hence the old adage that "An Englishman calls a spade a spade, but an Australian calls it a bl**dy shovel"... :-) ]

Hence the notion of ‘natural meaning’, that in order to minimise the potential for confusion, things should be named according to what they are or what they do.

And a simple test for ‘natural meaning’ is inversion of the term: if the inversion gives the same meaning as the assigned term, it’s more probable that, overall, the term won’t cause confusion. (There’s a proper grammatical-term for this inversion, but I’ve forgotten it: someone remind me, perhaps?) Take ‘data architecture’, for example: the inversion is ‘the architecture of data’, which in both cases is what actually happens in the practice of data-architecture – so we can be reasonably comfortable that we have something close to ‘natural-meaning’ there. In practice, ‘data-architecture’ is a term we can trust to make sense.

Likewise ‘security-architecture’, as the architecture of security; or ‘brand-architecture’, as the architecture of the relationships and the like between business brands;  or ‘IT-infrastructure architecture’, as the architecture of the infrastructures of IT-systems. These all make clear sense, whichever way round we put it; and keep the same meaning, whichever round we put it.

But when we try this inversion with the supposedly-’official’ usages of ‘enterprise-architecture’ or ‘business-architecture’, it just doesn’t work:

enterprise-architecture:

  • natural-meaning (from inversion): the architecture of the enterprise (i.e. organisation as a whole, plus extensions into the value-network and overall ecosystem within which it operates)
  • common-usage in TOGAF, FEAF etc: the architecture of the IT-systems in use within the organisation, with some reference to the usage of those systems within the organisation’s business

business-architecture:

  • natural-meaning (from inversion): the architecture of the business (or, more specifically, ‘the business of the business’)
  • common-usage in TOGAF, FEAF etc: anything not-IT that might impact upon IT, organised and described solely in terms of its actual or potential impact on IT

In both cases the IT-oriented common-usage is a very long way from the natural-meaning of the term – which guarantees confusion as soon as we move outside of the narrow confines of an IT-oriented view. And in both cases that common-usage meaning describes only a very small subset of the scope of the natural-meaning – in other words, wherever the IT-oriented common-usage is dominant, it represents a serious term-hijack that blocks visibility of the remainder of the natural-meaning scope.

Which, in any competent data-architecture, would clearly indicate that have a couple of seriously-invalid term-usages here. Which means we need to do something about it. Which brings us to Step 2.

It’s clear that Step 2a can’t apply here, because both of these invalid terms are very much ‘out there’.

Which means that we move to Step 2b: we issue a waiver.

But we do not forget what a waiver actually means here, and what responsibilities it places on all of us, collectively, in terms of action we must take in future to correct the architectural risk. In particular, it does not mean that we simply throw up our hands in the air and say “oh well, it doesn’t matter” – because clearly it does matter, because equally-clearly that usage of the term will not make sense to anyone outside of the ‘in-group’ cabal. Instead, the waiver says that we must take action to correct the fault – exactly as with any other type of architectural fault.

Which brings us to Step 3. What we actually need in this case is the metaphoric equivalent of a full ‘Cease & Desist’ order, to demand that people not only stop all use of this misleading usage of the terms, but take action to correct all materials in which either of those two misleading usages occur. For example, TOGAF would need to be rewritten from scratch: given the natural-meaning, it wouldn’t be allowed to use the term ‘enterprise-architecture’ just about anywhere in the whole document, and ‘Phase B: Business Architecture’ would either cease to exist, or be reconstructed as a proper multi-domain structure, within which ‘the architecture of the business of the business’ is merely one amongst many other domains that can impact upon IT.

Let’s not beat about the bush here: that is what needs to happen. Anything less represents not only only an architectural risk on a major scale, but an ongoing risk whose impacts increase exponentially with every passing day.

Sadly, Reality Department indicates we’re very unlikely to get this – not least because it would require Open Group, CapGemini, Federal Enterprise Architecture, Gartner, Zachman and all the rest to recall every scrap of their past publications on ‘enterprise’-architecture, and rewrite the whole darn lot. But we need to say, and continue to insist, that this is what needs to happen in future. We do not simply allow them to continue promulgating these (and many other) fundamentally-wrong term-usages in the enterprise-architecture space.

That’s Data Architecture 101, as applied in a perfectly straightforward way to current ‘enterprise’-architecture – what the Americans call ‘eating our own dogfood’.

And if we aren’t willing to do it to our own work, why on earth should anyone else trust us to do it to theirs?

Pretty simple, really.

So, whatcha gonna do about it, folks?

One separate but related and very important addendum: I am not knocking TOGAF in itself here, nor anything or anyone else in the IT-architecture space. IT-architecture is extremely important, and Open Group and others have been doing sterling work in that space for many years. To my mind, no-one should doubt this, and I’m very happy to sing their praises on that part of the work, and invite and encourage others to do likewise.

All that I’m saying is that what TOGAF etc call ‘enterprise-architecture’ should not be called ‘enterprise-architecture’, for the simple reason that it is not ‘the architecture of the enterprise’.

Likewise the somewhat jumbled collection of bits-and-pieces that TOGAF and its ilk call ‘business-architecture’ should not be called ‘business-architecture’, for the simple reason that it is not ‘the architecture of the business’.

[The latter point should be obvious when we consider that TOGAF's 'business-architecture' assumes that the entirety of the non- IT executive - in other words, the CEO, CFO, COO, CMO, CHO and any non-IT CTO, and all of their respective domains - can all meaningfully be lumped together as 'the business', with only IT needing aany differentiation from the rest. Anyone who's had any dealings at executive-level will know that it's, uh, not quite as simple as that? :wry-grin: ]

Best leave it there for now, I guess. Over to you?

Competence, non-competence and incompetence

February 4th, 2012 No comments

One of the key reasons why I’m so vehemently against any-centrism and suchlike revolves around the question of competence – or, more usually, the lack of it.

Competence is where someone knows what they’re doing, and does it. And, oddly, often don’t bother to say that they’re competent – perhaps because they don’t need to say it, their actions say it well enough instead. The outcome of competence is fairly certain, even in contexts of high uncertainty.

Non-competence is where someone doesn’t know what they’re doing, and will either not do it, or will do the best they can, yet with the explicit intent to use it as a learning to improve their competence. Importantly, they will usually say that they don’t know what they’re doing. The outcome of non-competence is uncertain, even in nominally-certain contexts, but at least we are aware of the risks.

Incompetence is where someone doesn’t know what they’re doing- i.e. is non-competent to do the task – but either purports and/or believes themselves to be competent. They will usually say that they are competent, even though demonstrably they are not; they claim to be responsible, yet have limited ‘response-ability’. The outcome of incompetence is fairly certain, and frequently dire, yet lack of awareness of the risks is often rampant, or in some cases the risks actively concealed.

Someone who is non-competent can become competent by learning the respective skills, or be competent by proxy, via finding someone else who is competent at doing the respective type of task. I treasure my non-competence, because it means there’s always more for me to learn. And as an enterprise-architect, I am, almost by definition, non-competent in much if not most of the detail-aspects of areas that I need to cover: hence one of my key competencies is the ability to learn enough of a new area fast enough to be able to guide meaningful exchanges between people who are fully competent in some detail-area but are not competent in others with which they need to connect.

Yet one of the key criteria for non-competence, and to separate it from incompetence, is a willingness to accept that we are non-competent, and say so. If we’re not aware that we’re non-competent, we automatically increase the risk of being incompetent. And if we know that we’re not competent, yet somehow ‘need’ to claim that we are competent, we would, again, automatically be incompetent – with a very high risk of inappropriate or ineffective outcomes of the work.

In part it’s a cultural problem: the risk of incompetence increases wherever a culture exhibits any of these characteristics:

  • prioritises content over context, ‘truth’ over context-dependent usefulness
  • has an insistent ideological base (leading to the same as above)
  • is typified by rampant egotism, self-advertising and self-centrism
  • is frequently swayed by tides of hype and ‘following after the latest fad’
  • displays an almost desperate need to be ‘right’

Unfortunately, all of these attributes are extremely common in business, and in many cases are actively prized… By definition, they’re also more likely to be common in any ‘truth’-oriented domain, one which operates primarily on ‘true/false’ decision-making – hence, in practice, the tendencies towards IT-centrism and finance-oriented business-centrism, both of which rely on simple true/false logic for most of their operational decisions.

In SCAN terms, all of these are where the Simple certainties of Belief – either as ideology and/or as self-belief – are inappropriately applied to the far side of the Inverse-Einstein Test, where the uncertainties of the Ambiguous and the Not-Known cannot be avoided.

This gives us a dysfunctional ‘diagonal’ decision-path, where Assertion is imposed on the Not-known, or Ambiguity ‘solved’ by arbitrary Belief:

Yet the real problem here is somewhat more subtle:

  • someone who is competent will typically not bother to say so, but will just get on with the work instead
  • someone who is non-competent will typically say that are not competent, but will often actually be adequately-competent, or at least willing to learn to become so
  • someone who is incompetent will typically claim that they are competent, and will usually not be willing to learn how to become so, because to do so would betray to themselves and others the fact that they are actually not competent

Which, in practice, leaves us with a huge dilemma:

  • those who do not claim to be competent usually are competent
  • those who do claim to be competent frequently are not competent

Hence, again, the kind of mess that we see so often in enterprise-architectures, wherever IT-centrism, business-centrism and the like predominate… Oh well.

Comments, anyone?

IT-centrism, business-centrism and business-architecture

February 3rd, 2012 2 comments

This one continues the recent theme of IT-centrism and why it’s such a problem for enterprise-architecture, but extends it into a slightly different direction, courtesy of a Tweet yesterday by Ron Tolido:

  • rtolido: interesting stuff coming soon around a global Business Architect certification standard by The Open Group #ogsfo

Important to say here that I have enormous respect for Ron: quite apart from his senior role at CapGemini, he’s also an amazing innovator in IT-architecture and enterprise-architecture, with ideas such as Slow IT, the importance of a demolition strategy, and the SCOOTER metaphor. Yet I must admit I was absolutely horrified at that comment above, and said so:

  • tetradian: @rtolido IT-centrism in TOGAF etc has crippled #entarch for half a decade: please don’t let OG do the same to #bizarch as well…

The point is that, given their track-record so far on business-architecture,  I can hardly think of any organisation that’s less qualified than Open Group to create such a standard. For Pete’s sake, even the Piddletrenthide Parish Parent-Teacher Panel would probably do a better job of it…

And no, I’m not being nasty here – I’m serious about this. The utter shambles that is TOGAF’s ‘Phase B: Business Architecture’ should sound clangorous alarm-bells about any such suggestion: it’s just a random collection of ‘anything not-IT that might affect IT’, with no structure, no symmetry and no sense. If you want to see how so much of so-called ‘enterprise’-architecture actively increases the infamous ‘business/IT-divide’, you need only to take a careful look at the TOGAF specification for its ADM Phase B. And these people seriously consider themselves competent to define a global certification for business-architecture? No way! – please…?

Anyway, my Tweet-response above triggered a reply from Ron:

  • rtolido: @tetradian it’s an IT thing to criticize IT-centrism but after all: #entarch is an IT people invention. Let’s try to do better with #bizarch

To which my first response was ‘What the…?‘, which came out in more polite form on Twitter as this:

  • tetradian: @rtolido “it’s an IT thing… entarch is IT-invention” – disagree on both counts, but yes, please let’s do better with bizarch…

Let’s tackle Ron’s points in reverse order…

At least there’s an acknowledgement that we could do better with business-architecture than has been done with those current attempts at ‘enterprise’-architecture. That’s something. Good.

On “#entarch is an IT-people invention”, it isn’t. That’s a convenient myth that IT-people want to believe – though no doubt a fair few of them will want to throw various historical quotes at me to ‘prove’ their provenance. Sure, the term ‘architecture’ has long since been linked to IT – almost half a century, by now. And somewhen around a couple of decades back, some bright spark extended that idea to distinguish between a context-specific IT-architecture versus an IT-architecture at organisation-wide or enterprise-wide scope, as ‘enterprise-wide IT-architecture’ – at which point some idiot conflated that nominally-valid term to a no-doubt ‘simpler’ shorthand term as ‘enterprise-architecture’, without any awareness of just how misleading that would be, or how much damage that term-hijack would cause. Yet reality is that there are many long-established business disciplines such as systems-thinking and design-thinking as applied to the enterprise that have a much better natural fit with the term ‘enterprise-architecture’; the original meaning of ‘business-analysis’ was also probably very close, too. In short, ‘enterprise IT-architecture’ is arguably “an IT-people invention”; but enterprise-architecture most definitely is not.

On “it’s a IT thing to criticise IT-centrism”, I’m not quite sure what Ron means there – whether only ‘IT-people’ have the right to do so, or else that anyone criticising IT-centrism is inherently self-identifying as an ‘IT-person’. If it’s the former, then the fact that I’ve had perhaps 30 years experience in and around IT might qualify me to criticise? But more to the point, my background is as an explicit cross-discipline generalist – I’m one of the few people formally qualified as such, with an MA in General Studies from London’s Royal College of Art. And it’s in that sense, as a long-experienced practitioner of ‘design-thinking’ within a very wide variety of business contexts, that I see IT-centrism as such a problem. (And, for that matter, business-centrism – which I’ll come back to in a moment.) In terms focus of attention, the single most important fact in enterprise-architecture, or business-architecture, or any other architecture, is this:

Within any architecture, everywhere and nowhere is ‘the centre’, all at the same time.

What happens in any form of ‘-centrism’ is that we keep on being dragged back to some specific area that claims to be ‘The Centre’ of the architecture. Rather than an ‘outside-in’ view – an awareness of the whole – we’re constrained to an ‘inside-out’ view, where everything in the architecture is seen only in relation to and in terms of that single ‘The Centre’. If there is no direct connection to that ‘The Centre’, or no direct impact, whatever-it-is is usually dismissed as ‘out of scope’, and often deemed not even to exist. Hence, in TOGAF’s inherently ‘inside-out’ view – in which IT-infrastructure is its actual ‘The Centre’ – we have no means to describe anything that is not-IT and that does not in some way impact directly on IT.

[To illustrate the point, try using TOGAF or its linked Archimate-notation to describe the physical activity of a production-line, the trucks and conveyor belts and other machines of physical logistics, the human activity of paper-based record-keeping, or the physical infrastructure - cooling, power-supplies and suchlike - of an IT data-centre: if you can do it all, you'll have to use some horrible kludges and fudged reframings of the supposed standards in order to do it... And yet all of these things would be essential in an enterprise-architecture for the respective industry.]

I need to reiterate that it isn’t only IT-centrism that creates this kind of problem: it’s any-centrism. What I’ve also been seeing recently is a lot more ‘business-centrism’ in enterprise-architectures, where ‘the business of the business’ is taken to be ‘The Centre’ of the enterprise-architecture. We see this, for example, in the insistence that financial metrics are the only metrics that count, and that return-on-investment (ROI) and the like can only be measured in financial terms – which might be valid within certain subsets of business-architecture, but are way too constrained to be valid in the far broader scope of enterprise-architecture. In some ways this trend worries me even more than IT-centrism, because by the nature of business it will tend to have even more of the wrong kind of credibility, making that much harder to counterbalance and correct within the architecture.

Anyway, Peter Bakker dropped in a useful comment at this point, pointing to a classic early essay by Christopher Alexander, famed author of A Pattern Language:

And a brief Twitter-exchange with Nigel Green served to enliven the discussion again:
  • taotwit: @tetradian @rtolido erm.. Tom I think you’re mixing up what EA is with what should be! :-)
  • tetradian: @taotwit @rtolido if someone’s defining a new standard, surely it should be about what should be, not about preserving current mistakes? :-)
  • taotwit: @tetradian @rtolido good point – I hope they listen to the likes of Alec Sharp and Patrick Hoverstadt

Agreed with Nigel there: a business-architecture certification scheme would need input from people like Alec or Patrick, or likewise from other key figures in business-architecture or business-innovation such as Alex Osterwalder or Steve Blank. But, like me, none of them are members of Open Group – which means that not only do we not have a voice, but what we say will be ignored anyway. In other words, Open Group expressly locks out many of the people who are doing real innovation in business-architecture, and then wonders why there are real doubts about the usefulness or validity of what it then produces as its ‘standard’.

Which brings us to the disaster-area of certification. In principle it’s a good idea, even a very necessary idea: every profession needs some way to identify and validate core knowledge and the like. But when the certification for a discipline is managed by a group that evidently do not understand what that core-knowledge actually needs to be, then we have a problem… and that’s exactly what we have with Open Group and business-architecture.

Open Group are an IT-standards body: and they’re very, very good at what they do in IT. But they’re not a general business-standards body – and that fact is becoming extremely important here. In the days when TOGAF was solely about IT-architecture – as it was up until version 7 – then it made sense for the ‘enterprise IT-architecture’ standard to be maintained by the Open Group. But the problem with any enterprise-scope architecture is that, by definition, you have to take everything in the enterprise into account: hence an expansion out into data- and applications-architectures in TOGAF 8, and then, in TOGAF 8.1 ‘Enterprise Edition’, the addition of a loosely-defined ‘anything not-IT that might affect IT’. Unfortunately they made two fundamental errors at that point: because that random bundle represented IT’s view of what it called ‘the business’, they labelled it ‘Business Architecture’; and they then described the whole IT-specific structure as ‘Enterprise Architecture’ – both of which sort-of made sense from their own inside-out perspective, but made no sense to anyone else, especially when looking outside-in. Oops…

Anyway, back to certification. So first, there is a real value in having a common language for specific types of architecture. In that sense, the TOGAF 9 ‘Foundation’ certification is genuinely useful, because it tests knowledge of that common language.

Likewise the practitioner-certifications such as ITAC, which assess someone’s practical skills and competence. Unfortunately it’s no use to me, though, as it still assumes that the only possible path to enterprise-architecture is via detail-level IT-infrastructure architecture, which I don’t do and never have. (I’ve done a lot of mainstream data-architecture in my time, but that doesn’t towards ITAC certification either.)

But to my mind – and in my experience, too – the mid-level certification, ‘TOGAF Certified’, is actually worse than useless: to be blunt, it’s almost a measure of how much someone is not competent to do enterprise-architecture. Yikes… there are some serious problems there…

That perhaps sounds a bit harsh: it’s not. There are two interlinked reasons why this is so.

The first is that ‘TOGAF Certified’ is a content-based exam. All it tests is how well people know the TOGAF specification – not architecture-practice. And to be blunt, the TOGAF specification is a long way from what’s needed to do enterprise-architecture – especially in any industry other than ‘the usual suspects’ of banking, finance, insurance, tax. (Why those industries? Because their business-models are built almost entirely around large volumes of simple structured information with automatable business-processes – in other words, strongly IT-oriented. Which doesn’t apply to most other industries.) I almost failed my TOGAF 8.1 exam because I answered several questions in terms of what I knew worked in practice, rather than what’s written in the book. And the ‘correct’ answer in the book was just plain wrong: I knew from real-world practice that it was exactly what not to do. Needless to say, I wasn’t impressed when I was penalised in the exam for doing it right…

The second reason is that TOGAF is not a standard. This isn’t some arbitrarily-unkind assertion that I’m making: it’s not only common knowledge, but I’ve even heard several senior Open Group figures say so in public. (Exact quote: “Of course no-one uses TOGAF out of the box! – we always have to customise it one way or another”.) The best way to describe TOGAF is that it’s a somewhat-better-than-random cookbook of ideas and practices vaguely held together by a almost equally-vague structure of the Architecture Development Method [ADM] – and that’s it. There’s not much guidance in TOGAF itself on how to customise TOGAF: you get that from experience, with a bit of help from some of the better training-providers.

So what we have at present in the ‘TOGAF Certified’ exam is a way-too-simplistic multiple-choice test on the supposed content of a ‘standard’ that actually isn’t a standard and often doesn’t match up at all well with real-world practice anyway. So just how much use do you think that’s going to be? To anyone? Honestly? Hmm…

And given that, how much credence would you place on a certification-scheme by the same people on a domain which they demonstrably don’t understand much if at all, judging by the current content of TOGAF’s ‘Phase B: Business Architecture’? Oops…

Hence why I’m extremely wary of letting this current attempt by Open Group go unchallenged: they really are almost the least-appropriate group to do the job.

No question at all that we do need some very good work to happen on business-architecture, and urgently so. But please, not from Open Group? – at the very least, not until they’ve tidied up the utter shambles of ‘Business Architecture’ in the current TOGAF, and can demonstrate that that they can keep their reflex IT-centrism under better control than at present?

Sigh… Oh well… back to the grindstone, I guess…

Over to you for comment or whatever, anyway.

Tweets from Open Group conference, San Francisco (day 3)

February 2nd, 2012 No comments

A set of Tweets from the third and final main day (01 Feb 2012) of the Open Group conference in San Francisco, collated via the#ogSFO hashtag. (Tweets from Day 1 are here; from Day 2 are here.)

Once again, many thanks indeed to all those who Tweeted, to help us all get a better picture of the current Open Group view of enterprise-architectures.

Same minor edits as in the previous posts:, I’ve stripped out most of the ‘#ogSFO’ hashtags in the text, and added occasional comments of my own in italics, but otherwise the following is as Tweeted by the respective participants.

I’ve also added a few wrap-up remarks of my own at the end.

As usual, somewhat less volume again on this day of the conference, but still several pages’-worth, so continue after the break.

Read more…