The no-plan Plan: architecture-dynamics

And the next part of that expansion on my ‘no-plan Plan‘ (or ‘manifesto for whole-enterprise architecture’, or whatever it is): this time on the dynamics of architecture. In other words, it’s a focus on how we handle changes to the architecture itself, rather than mainly about changes that that architecture needs to address.

Most of this will be painfully familiar to every experienced enterprise-architect – whatever type of enterprise-architecture we do. It’ll be especially painfully-familiar to those who’ve had to struggle with the current crop of EA toolsets, which – to be blunt – seem to range between mostly-useless and worse-than-useless for almost anything to do with architecture-dynamics. Oh well.

So, first: what do I mean by ‘architecture-dynamics’?

In essence, it’s about how we keep track of change within the architecture itself – in particular, versioning, transitioning, lifecycles and dependency-dynamics. Let’s look briefly at each in turn.

Versioning

In principle, this should be simple: keep track of edit-changes to anything. In practice, it’s a bloomin’ nightmare: doing it properly requires some seriously clever thinking in the design of the architecture-repository, and some equally clever tricks in user-interface design so that we can actually retrieve the older versions in any comprehensible way. (For example, take a look at Apple’s Time Machine for some good ideas on version-access, though in a context that’s actually a lot simpler than what’s needed for an EA-repository.)

How do existing EA toolsets do this? In way too many cases, they ‘solve’ the problem by doing nothing about it: there’s no version-management at all. Instead, it’s just been tossed into the ‘too-hard basket’, and then rather carefully forgotten in the forlorn hope that somehow we won’t notice it’s missing. (We do.) Sure, there are various kludges and workarounds: for example, one vendor’s recommended ‘method’ for versioning is to clone the entire repository and save it as a named backup somewhere. Okay, a few vendors do do a reasonable job of it – Troux comes to mind here – but even that is mostly done by a clone-and-relabel at an instance-level, which still seems pretty clunky in practice, and definitely error-prone if we were ever to risk letting inexperienced users loose on the system.

What’s absurd is that it shouldn’t be all that hard to do. As I remember, versioning-support is defined right down at the root MOF metametamodel level for the OMG notations such as UML and BPMN, so for that at least there ought to be a swathe of different implementations, surely? For my own work I haven’t gone down into implementation fine-detail as yet, but the ‘mote’ metamodel structure that I described in a series of posts a couple months back had all of that built in as well. The design-concept was based on a really simple yet fully-versioned wiki-engine that’s been around for over a decade: and if I can describe it, surely someone more competent at system-design than I am – which is just about anyone in ‘the trade’, I would have thought – should be able to do it a lot better than that?

Overall, though, versioning is still a ridiculous mess in most (all?) EA toolsets, and we need to be a lot more vocal about saying so, and demanding a better deal on this.

Transitioning

This is about keeping track of the process of change: from what to what, how, when, who, why, and so on. Again, should be straightforward. And usually isn’t. Sigh…

One of the things that really confuses everything here is the myth of ‘architecture state’. We all know how it’s supposed to work: there’s the current-state (the ‘as-is’), the future-state (the ‘to-be’), and, perhaps, various intermediate-states. Everything nice, neat, tidy, well-defined and all. There’s only catch: there is no ‘state’.

‘State’ is a myth, made up by project-managers – and, hence, toolset-vendors – to make their life seem simpler and prop up the happy delusion that they’re ‘in control’ of something that, by definition, cannot be controlled as such. The idea is that, once we reach that perfectly-planned end-point of the project, we’ll have ‘got there’ – all finished, all done, all over bar the congratulations at a job well done. But by the time we ‘get there’, the ‘future-state’ that we’d predicted in the plan isn’t ‘there’ any more: to quote Gertrude Stein, “there is no there there”. The same is true even for ‘current-state’: in any dynamic environment, change happens all the time, so even ‘now’ isn’t ‘now’ any more, either. There is no state.

Except, of course, all those EA toolsets assume that there is. Well, for those that can actually conceive of the idea of change, that is: for several toolsets that I’ve seen, their ‘method’ for describing difference is, again, to clone a copy of the repository and save it somewhere with a label of ‘current-state’ or ‘future-state’. (Except, again of course, there’s no way to create links between those two different repositories, so we have no way to describe, within a single repository-based report, what will change between those two ‘states’, and what won’t. Real helpful. Oh well.)

Much like versioning, we need to be able to define arbitrary labels for planned time-points and such-like, and attach them to any entities as we choose within the repository. And create cross-reference links between ‘as-is’ and ‘to-be’, to mark a state that isn’t a state because nothing is static anyway. And describe all the other aspects of transitioning – responsibilities, temporary bypasses, timings, dependencies and all the other transitory mechanics of the tasks – in any way that even the most pernickety of project-managers might need. All within the same EA toolset. Please?

Again, what we have on offer at present is mostly just another ridiculous mess, and again we need to be a lot more vocal about saying so, too.

Lifecycles

Everything has its own lifecycle: things change within the architecture, whether we plan to change them or not. Call it self-versioning, if you like: except that some of it may happen behind our back, whilst we’re not looking, and it still affects the viability of architecture, whether we know about it or not. T-r-i-c-k-y…

Some of our toolsets – particularly those that have developed out of a CMDB background or equivalent – do seem to have a fairly good handle on this point; most others, uh, don’t. At all. Or worse.

That’s about all that needs to be said about that, really. Except that, again, it’s something we probably need to make some noise about to the vendors. Or perhaps make that a lot of noise? Again? Loudly? Sigh…

Dependency-dynamics

Okay, this one is a serious challenge, though the toolset-vendors really ought to be up for it if they want to keep our business.

In principle, it’s a straightforward follow-on from all of the above: if something changes, other things that depend on it may be affected too. But that means that each of those items may also need new versions, new transitions, and new changes to their lifecycles. Which then affects anything else that may be dependent on that, which then affects anything dependent on that, and so on, and so on, sometimes with odd, unexpected, untraced, looped, delay-ridden, reciprocal-and-everything-else complexities. This can get to be real tangled, real quickly… Oh joys…

Again in principle, this is little different from the usual ripple-effects in a plain old bog-standard spreadsheet. Except that most spreadsheets don’t deal with versions, transition and lifecycles along with all those supposed-to-be-relatively-straightforward ripple-effects. And a repository is not the same as a spreadsheet anyway (unless you happen to build it that way). Which means that this is a lot trickier than it looks at first glance. Which is why most toolset-vendors seem to take the easy way out, and don’t bother to do anything about it at all.

Which would be fine if we didn’t need it. Which unfortunately we do. And will need a lot more once people start to realise just how powerful a well-populated holographic whole-enterprise architecture can be. Oops…

So yes, something else about which we again need to be vocal. Lots.

(And lots more that could be said about all that, no doubt, but again best leave it at that for now?)