“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.