Developers vs Architects: Cage Match

Architects are not developers

I have a difference of opinion with some of America’s largest companies. In many places I’ve been over the years, architects report up through the development organization. There seems to be this view that architecture is an extension of development. Or rather, it seems to be the case that developers have been re-titled ‘Architect’ in order to justify a higher pay grade or to avert the move of their cubicle to Kolkata. Why does architecture often report to development?

Response to stimuli

Development is all about implementing a plan to address a given set of requirements. The developer isn’t designing something and finding a use for it (although that does happen wherever IT fails). They are responding to needs and stimulus from the business via program and project management. They don’t operate in a ‘build it and they will come’ world unless they’re working for free. They are implementing a certain solution in response to a given need. There is an identifiable end-state, or objective that the developer is working toward. The developer knows when he is ‘done’ with a given set of tasks.

Architecture is not simply responsive, it is proactive. It engages the business directly and speaks the language of the business. Architects understand how technology can address the needs of the business. There are some architects, like Enterprise Architects and Business Architects that go one step beyond and actually excel at understanding the business problems themselves. The Architect is adrift in a sea of constant change. There is no ‘end’ to the work of architecture. It is an ongoing job of alignment because the needs of the business are in a state of constant change.

Seeing the forest in spite of the trees

Rarely is there predictability in the shifting nature of business need. How could one expect a discipline built on logic, sequence and methodology (such as development) to be able to meet the needs of business without someone there to help interpret the context and the actual need as it undergoes continuous change? Architecture is not a mere byproduct of the need to be a little more strategic about development. It is an integral part of the process of translating and aligning business need to technical solution.

Perception is not a skill taught in CS101

Naturally there are various types of architects and some are more concerned with tactical matters than others. But at the end of the day architects aren’t concerned with coding. Not even Application Architects. Execution of code development happens with a fairly good degree of automation and process. There’s a reason why commodity functions like code development are sent oversees to be performed on the cheap; they are predictable, repeatable, franchisable, and occur within well-defined SDLC methodologies.

Architecture is concerned with context. Context is dependent on perception. It is learned and honed through exposure and experience. You don’t graduate from college as an IT Architect. It is something you become over time as you encounter, observe and absorb repeating patterns of solutioning. These and other soft skills such as communication and consensus building are key differentiators between an architect and a developer.

Free the architects!

Given this, why on earth would an enterprise place its architects in the AppDev organization? There they’ll be suffocated by groupthink geared to see solutions as the reason for existence and always the first step in addressing business problems. They’ll slowly begin to lose the context, the big picture. They will become glorified developers with a higher salary and a few more titles. I don’t even think Application Architects ought to be in AppDev. The discipline of architecture simply requires a different view of the world that vanishes from sight when the architect is mired in the muck and the lost in the weeds.

Importantly, when placed in a J2EE development organization for example, the architect begins to see every solution as a J2EE solution or at least through a J2EE lens. More ominously, they begin to see every solution as specifically an IBM WebSphere solution, for example. Why? Because developers tend to be experts in one or several areas of technology. They are ‘certified’ in Java or .Net or whatever. A J2EE developer has no incentive or comfort level in suggesting a solution based in .NET. They won’t offer up something for which they have no skill. The architect in this environment will begin to think the same way. Witness the multitudes of Developer-cum-Architects in IT shops across the country that can never grow beyond Oracle or IBM or what-have-you. They can’t go beyond what they know. Certainly this isn’t everyone, but I know I’ve met plenty in my travels.

Architects are not developers and don’t belong in development organizations because they are required by job function to think about problems and solutions differently.

Am I dumping on developers?

No. Designing a building is different than constructing it. Certainly designing an entire city is different than constructing a single building. Architecting applications, solutions, business segments, or the enterprise is not the same thing as developing them.

Those who code, code. Those who can’t (or won’t), architect. It may be apocryphal, but there is an element of truth to it.

Architects are generalists while Developers are specialists. For that reason they don’t belong in the development organization.

Disagree with me? Think I’m going too hard on the poor, underpaid developers by calling their work a commodity? Think architects should report to the AppDev VP and not someplace else? Have a good idea where they ought to be in the org chart? Let’s hear it!