Integration architecture can be very frustrating some days. I'm having one of those weeks. Fortunately I'm off on vacation next week so I can clear what's left of the mind.
As most large organizations experience, we stay in an almost constant cycle of maintenance, upgrades and other vendor driven changes. Very little time is left for true innovation and adding real business value. Unfortunately explaining the way out to clients whose attitude consist of "git r done" is a very frustrating task. Anybody counting how many times I've used the word frustrating.
The scenario works basically like this. Hey client, if you spend a little more time up front, you can help isolate your application and others from changes down the road. Client says, hey integration architect dude I just need to "git r done". Fast forward a year later. Hey client, we have to upgrade that application because the vendor is dropping support for that version. Client says, but I wrote a hundred interfaces directly into that app, it's going to cost me a fortune to upgrade and it's going to be so disruptive. Client then says, oh by the way I've got another app to put by next week and I just need to "git r done".
The only sound at this point is the integration architect banging his/her head against the brick wall. I'm running out of Advil.
1 comment:
Mark, I know exactly how you feel
Of course the underlying issue isn't just an integration issue. It applies all over the place and is basically a fundamental issue or architecture vs delivery
"how do you make the correct balance between doing what's best for the future, and doing what you need for today?"
I find having an architecture community who cross the technical vs functional boundary, and have a common framework is a great help in making the right calls, but of course there is loads to this such as enterprise-level capability with defined architecture patterns, architrecture governance procedures with parallel escalation paths etc etc... Good Luck!
Post a Comment