benefit from all our premium research
related research from the MWD library
most recent posts
- Why isn’t HR more involved in social collaboration initiatives?
- Teradata acquires more Big Data tech, but what will it do with what it already has?
- Zimbra adds to its to-do list with Mezeo acquisition
- Overwhelmed by the volume of Big Data information out there? Step this way…
- Microstrategy World 2014: new product packaging, courting LOB users and raising its profile
Tuesday, May 15, 2007 by admin
In my previous post I explained how in order to get real value out of Enterprise Architecture (EA) work, it’s critical to focus not only on the outputs of EA work, but also on the process/practice of EA – and moreover that the process/practice has to focus on *conversations*.
What does this mean for tools, technologies and methodologies which purport to aid architecture work of different flavours? To get to the bottom of this, it’s important to add another thought into the mix, which concerns the nature of IT work in large organisations.
What we found in our research for our book is that in large organisations (which are of course the organisations most likely to be pursuing EA activities) IT work is only very rarely truly centralised. Even where there is “officially” one central IT department, the reality is most often that there are other pockets of IT activity that happen elsewhere – perhaps in subsidiaries, remote offices, or within particular business departments. What we also found is that it’s pointless trying to centralise IT work and force all IT activity to happen in one place. A top-down, centrally enforced IT mode of production might work for a short while, but soon enough entropy will work its slippery spell and projects will start springing up elsewhere (this is just one reason why the book is called the Technology Garden).
In reality, then, there’s little point in planning and executing high-level architecture work in a highly centralised fashion, when IT work is actually federated. At least part of successful and value-adding architecture practice is going to be conducted on corporate road trips, not in bunkers or ivory towers.
So I’m starting to realise that a lot of architecture theory and method is not always very helpful.
At best the focus of the theory and method work can only be one part of a much wider picture, and it needs to be hidden from that main piece of the action – the business-IT conversations. We need new techniques, technologies and new skills to drive the conversations. We need tools and approaches that promote lightweight, collaborative and iterative work – tools and approaches which we can use to share ideas and edge towards agreements as we make those road trips.
There are lots of tools and approaches on the market that help people “do things right” in bunkers or ivory towers. But let’s not forget that there’s something that’s at least as important as “doing things right”, and that’s “doing the right thing”. Figuring out *that* part of the equation is where road trips come in. Where are the tools?
I really hesitate to use the terms “Web 2.0″ or “Enterprise 2.0″, but what’s needed is an approach which builds off the kinds of capabilities you’ll be familiar with if you’re a student of those two-dot-oh-isms. Hosted platforms with universal remote access; and collaborative editing and sharing of information.
Embarcadero is planning on supporting this kind of scenario in future releases of its EA/Studio modelling tools, and Lombardi is already testing the market, from a process architecture perspective, with Blueprint.