Wednesday, June 18, 2008

The Business-IT-Gap has a face

With all the current hypes, just think about the Architecture, SOA and SaaS hype, you might think that agility, stability and interoperability are goals in itself. That they are specific magical ingredients recently discovered about to solve all IT related problems. This would not be an unlogical conclusion. After all, that's what is being promised you will need and get an agile business because that is what everybody needs.

Is it not? No, not at all!

In fact you just met the "Business-IT-Gap" in person. It might be the manager asking a developer for an application that should (obviously) be flexible and stable. Or it might be a sales person or consultant explaining a client that they really need to go for a SOA-solution for agility reasons. Either way you are actually physically facing a (e.g.: talking/listening to) person embodying the Business-IT-Gap.

Really? Explain!

The whole reason why the Business-IT-Gap exists is because managers have lacked to provide enough guidance about what kind of flexibility and interopability and the dagree of stability is that was needed (a responsibility now being hijacked by people calling themselves Architects).

Lacking this guidance resulted in systems lacking flexibility or the wrong kind of flexibility (thus maintainability) and interoperability. Moreover, because every developer has its own personal view on the type of flexibility needed, changes are that what is flexible in one application is fixed in another. Thus in fact lacking this guidance cannibalized the overall investments in flexibility. Believe me this is not theoretically speaking, this is what I see day in and out! I can't believe nobody else notices this...

So what should I do?

Of course, it's not only you. It's the whole branch! Developers should demand more guidance. Sales people and consultants should not propagate agility, interoperability and stability etc. "pur sang". They should explain that it is about Just Enough and about Just Right and that divers from situation to situation and company to company. You just can't and don't want to be totally agile either given a solution or given an total enterprise. It's about finding the right balance between what can be fixed and what should be flexible. Because flexibility comes with a big cost that can only be returned (roi) if it will be used sooner or later. Just think about architecting a house. Realizing all your dreams and whishes (read: requirements) in a totally agile structure would have you end up with something crazy like a hyper expensive stretchable balloon!

But now that you know, you can and should close the gap by asking the right questions and demanding a reasonable answer!

Happy closing the gap!

1 comment:

Theo said...

Hi Marcel,

The question that I have after reading your post is; What do you mean with "totally agile" if you contrast if with "just enough"? Can I actually build something that is totally agile?

In your other post about SOA you link to "SOA in the Real World", there is the statement: With SOA, integration becomes forethought rather than afterthought.

I believe that is all there is.
It provides the flexibility that everyone needs, at no extra cost.

Unfortunately, marketeers and sales people are inflating these basics to the "hyper agility" message.

I think it is a big mistake to (based on that inflation) turn around and say: Just tell me what to integrate with, and I will design "just enough" integration for those integrations. That kills flexibility right from the start.

So lets just continue do what SOA is supposed to do: Design the application to be integratable, to support process changes and integrations not anticipated initially.