Bob Lewis
Columnist

How to manage architecture.

analysis
Mar 15, 20053 mins

Dear Bob ... Our technical architecture is in need of serious attention. A group of consultants just walked us through a proposal I found intimidating. It isn't just that it was very time-consuming and expensive, although it was both. What concerns me more is that their methodology - basically, document current state, define future state, analyze gaps and plan migration - just feels wrong. I can't put my finger

Dear Bob …

Our technical architecture is in need of serious attention. A group of consultants just walked us through a proposal I found intimidating. It isn’t just that it was very time-consuming and expensive, although it was both. What concerns me more is that their methodology – basically, document current state, define future state, analyze gaps and plan migration – just feels wrong. I can’t put my finger on what I don’t like about it, though.

So help me understand – is my gut telling me something useful for a change, or should I just have skipped the tiramisou last night?

– Architecturally challenged

Dear Challenged …

I can’t comment on your intestines, nor would I want to. Nor, for that matter, can I tell you whether the proposal you received is a good or bad idea. Fundamentally, there are two ways of going about developing an architecture plan; they showed you one of them.

There’s nothing intrinsically wrong with a present state/future state/gap/migration methodology. It’s a tried and true approach to understanding what needs to get done. (Truth in advertising: I’ve led this kind of thing myself; I have to defend it!)

It’s primary weakness is that it’s a one-time, big-bang kind of thing. Once you’re done you end up with a bunch of projects that chew up all of your resources for the duration of the migration. That’s fine if your current architecture is seriously broken and needs blowing up. It’s less fine if you need to remediate your architecture while continuing to support a business.

The alternative is to take a “portfolio management” approach. Think of each of your three architectural layers – platforms, information, and applications – as an investment portfolio. Analyze the components of each to determine its overall health in terms of fit to function, quality of engineering, market stability, lack of redundancy, and integration with the whole.

For the information layer, include the health of the platform each repository is built on in its health assessment. For the application layer, include that, and the health of its information repositories.

Score everything on a green/yellow/red scale and you get a quick picture of what most needs replacement at any given time. Squint a bit and you can get a picture of what you can solve by replacing point solutions with suites.

This is, of course, just a quick sketch. The biggest disadvantage is that you never get a clean, shiny new architecture. The biggest advantage is that along with the architecture strategy you get a process you can use for ongoing management of the architecture.

– Bob

——–