n the 1927 film Metropolis, Planners decide to build a monument to mankind’s greatness, but they can’t construct it themselves. The film moves from a utopian environment where the planning of the monument takes place to a dystopian one where armies of Workers are led to the building site for the construction. The film plays out the story of these two groups and their mutual mistrust: the Planners see the Workers as lacking vision, and the Workers view the Planners as people who don’t know the realities of construction.
Sound vaguely familiar? Having been both a developer and an architect during my 15-year career in the software field, I believe Metropolis can serve as a metaphor for the divide that can emerge between architects and developers?Planners and Workers?in our own industry. Many developers mistrust architects, particularly non-technical architects who don’t have extensive development experience. Worse, I’ve met a number of architects who mistrust developers, considering delivery teams lacking in the breadth and vision to capitalize on opportunities for architectural innovation.
This article discusses the factors behind this divide as I’ve seen it. While there are many different types of architects from many different backgrounds, this article concentrates on those without extensive technical skills (i.e., those who come from a management rather than a development background).
What Is the Nature of the Divide?
We have a tendency as human beings to divide people into ‘us’ and ‘them’. In organizations we often form tribes with our peers, social structures that provide identity and support, but that also can become obstacles to effective interaction among groups. For example, differences in language and rituals, when not acknowledged, can create unnecessary divides. This is the nature of the architect/developer divide.
Developers and less technical architects often have very different perspectives. The architects often take a management/consultancy route into the architecture profession. This route provides a very different focus from a more technical career path. It focuses more on presentation skills and techniques for presenting architecture that makes an impact, often promising a step change in capability. Architects often manage multiple stakeholders, many of whom are not technical and are more concerned with business change than system architecture.
Developers, on the other hand, tend to be detail focused. They work in a domain where content is often valued much more than presentation, and the technical details are difficult to communicate to the business. Developers often focus on incremental improvements in capability, since they are nearly always working within deadlines and with existing systems that prohibit radical innovation at the code level.
This difference in perspectives can become a significant gap. Both communities value different things, use different languages, and often operate in different (but overlapping) problem domains. When the architecture and development communities work together as a team, their differing perspectives produce a better product. When they don’t work together well, communication rapidly breaks down: architects talk at one level of abstraction and developers at another, with no one closing the gap between the high-level and detail-level views. As a result, the effects of the implementation technologies on the architecture and the deliverability of the architecture itself are often not addressed, and projects start to fail.
The Developer’s View of the Architect
In my experience, developers are craftspeople who deliver solutions to the business under tight time constraints. Respect in this environment is earned from knowing the details (technical and functional) and delivering reliable software in short order.
Often, developers consider architects the antithesis of this ethos: they don’t understand the detail; they are often removed from the realities of delivering to a deadline; and they may not even have any more than an org chart ‘dotted line’ relationship with the delivery organization. Making matters worse, architects often make a few common mistakes that only reinforce this opinion:
- They use the same tools to talk to the developer as they would to communicate to the business. I once watched a highly capable architect present a solution architecture to development using a homemade notation that had no clear semantics and no mention of outstanding issues (but it had nice 3D shading on the boxes). When challenged, the architect just talked around the issue. This failure to consider the audience resulted in the architect losing the development team’s respect, and from then on in engagement was difficult.
- They propose a grand vision to a project team without providing any pragmatic interim steps. For instance, an architecture team presented a project team I knew with a new architectural strategy. The goal was to lower the cost of process change and application introduction through state-of-the-art technology and architecture. The architects presented a proof of concept, suggesting it should be how the developers architect and deliver their solution. This end state was a million miles from where the development team were. It was almost impossible to see how the current development, a vanilla configuration of a commercial package, could adopt all these new concepts and deliver on time. The development team rejected the architecture, communication broke down, and the project continued with virtually no architectural input.
- They consider the details unimportant. Phrases such as ‘that’s a detail thing’ and ‘it’s not the technology that’s important’ are counterproductive. Ignoring detailed technical issues is particularly prevalent with architects who have taken the management/consultancy route. Conversely, architects with a more technical bent may not pay much attention to application issues that are symptoms of business-change problems.
- They choose to impose architecture on projects instead of working the architecture with projects. I’ve seen many architects turn up at the start of the project, skip through some slideware, make some high-level statements, and leave the developers to work out the details?which often become significant architectural issues. Often, the architect doesn’t stay around to resolve questions, adapt the architecture to fit new constraints, or generally be of help. Architects should remain engaged throughout a project, not just in the formative stages.
The Architect’s View of the Developer
Architects are often tasked with shaping a portfolio of projects. They must take a medium-term view, define an architectural roadmap, and marshal projects to delivery within that roadmap. This can be immensely difficult given every project’s changing schedules, scope, solution, and personnel. In this environment, interactions with delivery teams can be challenging. Architects can be prone to seeing projects as problems. They often see the development community as too tactical and their vision as too narrow. This opinion is reinforced when developers make a few common mistakes when interacting with architects:
- They discount commentary that isn’t grounded in technical details as high-level nonsense. The architect may be at 30,000 feet applying a high degree of abstraction to the solution, but that doesn’t mean he or she doesn’t have a point. For instance, an architect I worked with was concerned that the error-handling implementation in a particular project didn’t have an organizational view of the error handling across the solution. The development organization dismissed the issue since each individual error-handling routine worked fine and the users had been happy with the individual error-resolution screens. However, after the issue was escalated and the output reviewed, it became apparent that certain classes of error that the user was handling should have been handled by an operations group. As implemented, the inconsistent error resolution would have confused accountability in the organization.
- They don’t talk to the architecture community. Not engaging the architecture community in an organization avoids all those pesky debates about the solution, but it increases the likelihood of architecture intervention late in the project or the project duplicating work already done elsewhere. I remember consulting with a project team who had to present its security architecture for review. After some discussion, a security architect explained the current security initiatives and asked the developers: “How is this work aligned with the organization’s PKI rollout plans?”
This not only embarrassed the development team members who had proposed the architecture, but it also resulted in additional work as alignment had to occur post-design.
- They don’t see the broader view. Pragmatic architectural decisions often seek local rather than global minima. This may involve trading off technical elegance for organization simplicity. I recall a heated debate between a development team and an architectural function in which the development team wanted to use a specific technology and the architecture team insisted they stick with the standard. The architects’ rationale was that although sticking with the standard technology would be suboptimal, it still would work and would be quicker than getting bogged down in a protracted debate with the standards community.
All the mistakes that developers and architects make can be summarized as follows:
- Not valuing the other’s point of view
- Not empathising with the other’s position
- Not seeking common ground
- Not bridging the language gap
These mistakes are insidious and create not only the architect/developer divide but also architect/architect and developer/developer divides. I could have written much the same article by considering enterprise and solution architects or VB and C++ developers.
How Do We Escape Metropolis?
In the movie, the heroine Maria finds a solution by calling for a Mediator to bridge the gap between the Workers and the Planners. Closing the divide between architects and developers requires the same: we must become our own Mediators. As a developer, my approach for bridging the gap was to learn the language and concerns of the non-technical architecture community (Agar, Michael. The Professional Stranger. Academic Press 1996.). I read the Harvard Business Review and books on business change, organizations (Huczynski, Andrzej and Buchanan, David. Organizational Behaviour. Prentice Hall 2001; Wilson, Fiona. Organizational Behaviour and Work. Oxford University Press 2004; Dick, Penny. Introduction to Organizational Behaviour. McGraw Hill Higher Education 2005.), and consultancy. In addition, I spent some time learning Neuro-Linguistic Programming and influencing strategies (Wenger, Etienne. Communities of Practice. Cambridge University Press 1999.). These resources helped me understand the different perspectives and languages I encountered when interacting with architects and allowed me to work effectively with them rather than against them (Neuhauser, Peg. Tribal Warfare in Organizations. Harper & Row 1988.).
Architects need to take similar steps. I’m not a non-technical architect, but my advice is to keep track of what is happening in the development area. Trade magazines and sites such as Slashdot and DevX can help. As an architect I follow a few simple rules when engaging with development teams:
- Be very aware of deadlines and the need to provide pragmatic guidance in a timely fashion. This means being proactive, as development teams do not always feel they have the time to engage with architecture.
- Never dismiss concerns about a proposed architecture, even if I don’t fully understand the issue at first.
- Ensure I have a network of development colleagues who are experts in technologies that I encounter.
- Always communicate precise and clear guidelines and architectures supplemented with practical examples.
At the end of the day, we are all designers; we just operate at different degrees of abstraction. Let’s eschew this tribal behaviour and work together rather than talking at or working against each other.