“I just wish someone in IT could make the calls on technology.”
That was the statement from one of our product managers, having sat through a long testy meeting where technical directions got brought up and debated at length. Testy enough that our architect at one point stated:
“So I’m just a researcher, well then see if I help any developers in the future.”
The end point was that the product manager just didn’t care, she just wanted someone to be the final arbiter.
We have a sort of classical dysfunction when it comes to deciding on architectural decisions:
- Our CIO often tries to set technical architecture without much consultation which often goes over fairly poorly.
- Our architect group is out on the bleeding edge researching the newest ESB offering or enterprise rules engine. They forget they have to actually sell/convince all the rest of the development organization that their ideas have real value for the business and are not just chasing the newest technical toys.
- The application development division wants much more input into the process and the ability to give real feedback on what directions we head. Since there’s a lot of developers even if you just count leads this lends itself to more of a consensus model which takes more time. And developers want tools and architecture that make them more productive and able to deliver high quality code, not just resume fodder like experience with SOA business activity monitor.
The reality in the last few years that I’ve worked at the organization is that we’ve been able to swing the pendulum back towards the real needs of developers in most cases. Powerpoint slides with lots of wonderful layers are nice, but they don’t produce working applications. Still we constantly battle to not have tools and architectures imposed on us.
Anyway the product manager made a great point, we really need to present one answer at the end of the day to the business.
Grow up you big baby.
From what I’ve seen IT decision making is usually pretty predictable. Managers want it done fast and worry about the long term later (i.e. never). Architects want it done buzz words and standards compliant and want to follow a process with enough books on it. Developers want to either use technologies that they know (30+) or technologies that they don’t know (30-). Administrators don’t want it done in the first place. And users don’t have a clue as they thought the current system was working ok.
Oh, I’ve experienced the sort of management by magazine that drives many technical organizations, I’m just hoping to turn around the tide, one little beachhead at a time.