I’m so late with delivering my paper on Enterprise Architecture. It’s not that I haven’t progressed it since the last draft, it’s just that said progress hasn’t actually involved putting pen to paper. I’ve just been thinking hard.
One of the constraints of “Enterprise Architecture” thinking and writing is that the moment you say “architecture”, everyone thinks you’re about to waffle a load of techie. So I’ve taken to using the words “business blueprint” to try and convey what I’m thinking.
Another word that causes confusion is “interface”. Another techie word that conveys vast meaning to those in the know, but little to those not. My thinking is that, if anything, the enterprise architecture that I’m writing about is less about “in” and more about “out” – i.e. it’s about breaking open the enterprise and making the way that it works clear and accessible to and from the outside. So, less about “interfaces” and more about “outerfaces”. I think that’s a critical point – you need many hundreds of interfaces on the inside of government, but you need only one “outerface” if you are going to make it transparent. Outsiders don’t want to know about insiders; the outside world doesn’t want to learn government vocabulary; outsiders need a front door, a single way in, a single “outerface”. The job then is for the internal workings to take care of everything else.
I’m also trying to get the “unplug and replace” analogy into our vocabulary. I want to be able to fragment the components that go into any system so that we new and better ones emerge over time, I can just rip them out and put the latest/greatest in. I want each module to be walled off from the others so that the touch point is absolutely clear and so that the amount of testing that needs to be done is kept to a minimum. I don’t want 3 weeks of regression for every new module, unless that’s a virtual 3 weeks using a fully automated tool that actually gets the job done in 7 minutes or less, saving me the cost of 3 weeks of resource. If I can “unplug and replace”, then I can progress faster – and, better still, anyone who is developing projects now doesn’t have to stop what they’re doing, they just have to align along the same principles – and then, when a given modules, proves to be the best one, everyone can make use to it and stop having to support their own custom one. This, I think, will give us the chance to make the right things happen without causing planning blight wherever I look.
Next up is the whole “web service” thing. Get any technologist in a room for 3 minutes and say “next steps” and pause. The (one-way) conversation will be about and only about web services, as if they alone are the answer to everything. Three years ago I used to stand on stage and note that “XML” had become the global saviour of IT – it was going to ensure that we could do anything that we want anytime. Now web services have that mantle, although the “service oriented architecture” has probably fought and won the most recent battle – and remains a concept that few can understand or communicate. Whatever it is, we need one. Just like we need grid computing and all that other good stuff – after all, if we don’t, how will we rescue the technology industry from its mire. I do, actually (although it may not be completely clear), see that web services are a vital part of what we need to get things done. But, please, don’t get religious about it.
The final puzzle I’m grappling with, other than the organisation necessary to complete (or maybe even start) the work, is how to fund it without hump costs. The argument about “spend to save” or “economies of scale” long ago became redundant. Technology investment in any public sector economy anywhere in the world has not demonstrated saves, it has merely allowed things to keep pace or appear at least a little less inefficient. There’s some kind of strategy around “save to spend” – i.e. what can you stop, cutback or reduce to create the headroom needed or perhaps which projects can you redirect so that the output is nearer where you want to be than otherwise. But, then we’re back to the game again.
