Friday, March 28, 2008

Talking to your architect

How do you talk to your architect if you are a project manager or developer? In my company there is a pretty clear division between architects and the people who work on projects.
In my role as a development lead I want our stuff done with the technologies that best suit the project.
Architects, they seem to just want to muck up our projects.
--Warning, griping ahead! To get to the useful stuff look for (MONKEYSHINES)

Our architecture teams are disconnected in many ways from our development teams. To the developers, the architects don't understand the technology at all. We read their reports on recommended technologies and wonder how they can come to their conclusions. To us, we see their technical recommendations and shake our heads, it's bad.
The typical architectural recommendation involves a commercial product or two, and the first open source alternative that they can find. The architects outline the strengths they see between the products. The point they seem to always hit is support, the commercial vendor 'supports' their product and the open source alternative doesn't. Support is important, and apparently looking at the source code isn't sufficient enough for supporting a project.
It doesn't help the cause that the company has some projects that were deployed on the JBoss platform that didn't go well. Many of the developers of those projects are now architects. If you ask them, the reason that the applications crash is because JBoss is unstable. Never mind the slew of null pointer exceptions and open JDBC connections, or the fact that objects are haphazardly dumped into a session, and that the session timeout is extended to an hour for all sessions to satisfy one single use case. It's the open source application's fault, not the application's.
What makes things worse is the same architects have the final say over what technologies developers use in their projects. If a development team believes that Java Server Faces is the best technology to meet the needs of a project and the architecture team hasn't approved it yet, well that development team needs to present their case to a board of architects and state the merits of that technology over any of the other ones that the architects have previously blessed, Struts for example.
Going through the process is painful and slow for the devlopers. Developers feel that the architects put the burden of introducing new technology into the company on the shoulders of development. There is definitely an adversarial an uncooperative element to the relationship between developers and architects in my company.
It isn't good.
One of the most frustrating parts of communication between developers and architects is that the architects don't really care about the same things that developers do. The ease of implementation or the ability to maintain a technology are more important to the developers who are doing it than the architects who haven't touched a line of code in years.
Probably the biggest point of friction between our developers and our architects is the architecture team's role in deciding what software can and can not be installed on our workstations. The architects decide what text editors, what IDEs, what debuggers, performance profilers, and other tools the development team uses.
The architects don't like open source tools and will usually forbid their use by developers. Architects also forbid the use of Firefox because it is less secure than Internet Explorer--their words not mine. It's statements like that that create contempt between developers and architects.
Our developers would like to see them try and develop a web application only using IE. There are a ton of excellent plugins for Firefox that developers can only use on the sly like Firebug, YSlow, and Selenium IDE.
Ok, with that said, you might begin to see why developers try to minimize their contact with architects as much as they can. With that said, I finally figured out how to actually communicate with my architects the other day.
(MONKEYSHINES)
Communicating with an architect requires that you understand an architect. Architects are concerned with long term visions and the direction of enterprise applications. They want to know that a technology is going to meet the needs of the business and will be expandable to adopt whatever initiatives they have planned.
If you need an architect to cooperate with your tactical needs, make your points focus on the long term benefits of your approach. Make whatever you really want incidental to the long term point. For example: if I want architectural approval for my team's plan to develop a project using Grails, I would want to focus on the ability of Grails to run on existing platforms, on the ability to easily add functionality to Grails projects, compatibility with SOA, and whatever else I can find out about their long term plans. I should completely skip the things that are important to developers: ease of implementation, syntactic simplicity, etc. They won't care.
Any good salesperson will tell you that you need to know who you're talking to and speak to them. Make your points important to the people with whom you are talking and you will find that your communications are more productive.

No comments: