If you walk into project meetings and are greeted with welcome smiles, hearty handshakes, and appreciative nods, the chances are pretty good that (a) you’re not an IT architect, and (b) the room isn’t full of developers.
IT architects face many challenges, not the least of which is that among developers, architects are often seen as ineffectual and disconnected impediments to meeting project deadlines. Architects get no respect. What they do get is resentment and resistance.
Oracle ACE Director Lonneke Dikmans, managing partner at Vennster and an experienced architect, runs into that resentment in almost every project. “Usually it is resentment toward my role as an architect, the one who makes all solutions difficult,” Dikmans says. “It is sometimes hard to deal with, because not everybody is overt in their resentment.”
So what did architects do to deserve this treatment? “It’s often based on the fact that the architect group is viewed as issuing technical edicts to the developers, while the architects have little or no accountability for specific projects,” says SOA architect and developer Jeff Davies, a senior principal product manager at Oracle.That view of architects has roots in the differences in scope and responsibility that separate architects and developers. “Architects may have a broader set of concerns than developers, who are usually under pressure to deliver functionality and resist impediments to that goal,” says Randy Stafford, an architect with the Oracle Fusion Middleware A-Team.
Although the different roles have different goals, that difference in perspectives is not necessarily a bad thing. “It ensures that all the angles are covered,” says Dikmans. “If there were only architects, we would be stuck in Utopia. If there were only developers, we could end up with a mess because of a lack of cohesion and direction.”
So what can architects do to bring the two sides together? One obvious bit of advice is to avoid fulfilling a stereotype. “Resentment or anger from developers could be a sign that the architect is of the 'ivory tower’ type,” says Stafford. “He may not be respected by the developers because he’s not shoulder to shoulder in the trenches with them facing the real consequences of his decisions, and he may not have the technical chops to deal with details confronting the developers.”
So, architects, get down in those trenches. “To avoid the ivory tower reputation, be sure to contribute to each project and add value by direct participation,” says Davies. “Architects can be great mentors, but only if they are truly helping developers and the business meet their respective goals.”
Becoming a great mentor means developing people skills that can transcend the organizational chart. “The architect’s leadership skills become important,” says Stafford. “Architects need to be able to convince developers to implement their guidance through some kind of rhetorical influence, because they probably don’t have managerial authority over them.”
Bottom line: if you’re not prepared to be a leader, you’re not prepared to be an architect. “Software development is a fundamentally social endeavor, more than a technical endeavor,” says Stafford. “I would advise aspiring architects to study seriously the literature on leadership.”
But even with top-notch communication, leadership, and technical skills, the gap between architects and developers may simply be a fixture of the IT landscape. “I don’t think you can head off the problem,” Dikmans says. “It is part of the game.”
But that game can be won—with clear objectives and an open mind. “Make sure you pick your battles,” advises Dikmans. “Developers can be right, too! Beware of ivory tower architecture and be willing to go into details and into the content, not just the rules and concepts. We are not the IT police. We are supposed to guide IT.”
So be that guide. Put these recommendations into practice, and in time you may find that your share of welcome smiles, hearty handshakes, and appreciative nods is on the rise.
GET more architect information