When you look for a good musical conductor, you start by looking for a good musician. But not every good musician makes a good conductor. The situation is similar in the professional development of architects. More and more IT organizations are understanding the importance of sound software architecture, and the architect profession is rapidly emerging as a separate discipline within IT. This presents some fresh challenges to management as they look to recruit architects from a fairly small labor pool. Even when Human Resources finds candidates, screening experience is more limited than with other disciplines. The fastest way over these hurdles is to understand that most good architects are also good developers, so probably the first place to look for architect talent is among the ranks of regular developers. Recruiters can use this insight when screening candidates, whether internal or external. However, tapping this resource can be tricky because few good developers have the characteristics of or the desire to become architects.

This article outlines what it takes for a developer to become an architect. I’ll present the perspective of a developer who might be considering such a move, as well as that of a manager assessing developers for such a transition. I’ll also provide a series of factors to consider when making these decisions.

Personal characteristics

The liaison between software development teams and management has always been a sticking point in IT. Both groups tend to think about a given problem in fundamentally different ways. A lot of science addresses how project managers should track and interpret the progress and issues of developers. But still breakdown in communication is very common and is a leading cause of project failure. A good architect is the most effective known cure for this problem. An architect’s primary responsibility is to provide shared media for communication between developers and project managers. They are responsible for fitting business rules and requirements with engineering practices and limitations to ensure success. Following are some of the key traits of a successful architect.

Willingness and ability to communicate: The most valuable principle when identifying an architect among developers is effective communication. You want to look for skilled and experienced developers who have a history of taking the initiative to communicate with business interests in projects. Architects often have to anticipate gaps in understanding before they can contribute. They have to be willing to go out on a limb to ensure a meeting of the technical and business minds. They don’t have to schedule and coordinate exchanges; this is still generally the job of a project manager. Their task is to determine the best tools and artifacts for expressing the design of a system in a way that facilitates an effective exchange. They must be able to sense when current methods are falling short and a new approach is needed. Writing skills are also important, as are drafting skills, or the ability to use diagramming or charting software.

Experience negotiating details: An architect often has to lead discussions of technical compromises for systems development. Conflicting priorities might involve practical limitations, risk avoidance, or possibly differences in requirements among various business groups. A good architect can efficiently assess the technical possibilities and chart a course for development that addresses various interests and limitations without losing the essential value of the project. This ties into communications skills discussed previously, but also taps into the architect’s technical ability. A good architect candidate would be a developer who often helps steer contentious discussions toward new ideas, and doesn’t become entrenched in one position.

Self-starter; motivated to solve design problems: An architect’s day-to-day goals are often unclear. Many developers simply look at a functional specification to carve out a task list. An architect is usually the one providing these developers the structure required to maximize efficiency. A good candidate takes the initiative not only in communicating, but also in anticipating and tackling design issues — usually without any specific directive. A developer who stays busy and engaged in the project, regardless of assigned responsibility, has an opportunity to shine among his peers.

Abstract thinking and analysis: Architects must be able to take a vaguely expressed concept and turn it into a project artifact that can be appreciated by the interested parties. They must able to appreciate abstract concepts and to communicate them in concrete terms. Good candidates among developers are often called upon, or take it upon themselves, to explain confusing issues in the development life cycle. They are quick to assess ideas and direct them into practical suggestions for moving forward.

Developers often are mathematically strong, whereas good architects tend to be stronger verbally. An “engineering mindset,” often ascribed to developers by managers, is an interesting prism through which to assess architects. Architects should have strong technical problem-solving skills, but they must also be able to grasp the bigger picture of how the people involved interact with technology. This requires a form of abstract thinking (beyond the bits and bytes of code) that can be difficult to master.

I tend to avoid elitism about what level of formal education is required to groom a good developer. I have seen amazing developers who are high-school drop-outs. However, when it comes to architecture, my personal experience as well as my appreciation of the required abilities makes me believe strongly that a good architect usually has attained at least a challenging baccalaureate degree.

Tracing the life cycle

Good architects generally have gained experience at organizations with a well-defined software development life cycle (SDLC). Architects must understand the most important operating procedures of their profession. This does not necessarily mean, for example, working at a high Capability Maturity Model (CMM) level. A good architect can come from an organization that uses the Extreme Programming (XP) approach of multiple small iterations of the SDLC. It is important to be aware of traditional software development practices, such as Michael A. Jackson’s methods: Jackson Structured Programming (JSP) and Jackson System Development (JSD) (see Resources). The study of Jackson is as important to an architect’s professional growth as the study of Donald Knuth is to a programmer’s. An architect can be partial to any of the classic and long-tested software systems development methodologies.

The SDLC can also form a useful agenda for assessing the suitability of an architect. Each SDLC stage has characteristics that provide clues. There are many small variants in the SDLC, but in this section I use a common basis for almost all methodologies. The following list details the SDLC stages and outlines the traits of a good architect candidate for each stage.

Analysis: During analysis, a good architect engages with nontechnical interests to understand requirements and the environment in which the development will occur. The architect brings extensive software experience to the task of risk assessment. Look for a developer with proven experience helping business understand what the technical staff needs to interpret requirements properly. And look for a developer who has anticipated issues at the early stages of development.

Design: During high-level design, a good architect gathers the abstract elements of the problem space and communicates them so the development team can draft schematics of the system to be developed. Architects lead the careful mapping of requirements to features in the resulting systems architecture. They tend to take a less central role during detailed design, but are still needed to vet the elements of particular modules against the imperatives of the system as a whole. Look for a developer who is good at getting the team to anticipate the implications of design decisions on the finished system. Also look for a developer who is good at determining the best artifacts for communicating design to technical and nontechnical audiences.

Implementation: During implementation, architects guide the project to ensure that it stays true to the systems architecture. They are the front line in assessing technical change requests, and they determine how the design can best be adapted to accommodate such requests. The architect also stays in close touch with the developers’ progress and especially tracks the status of integration points between modules in the system. Look for a developer who often leads discussions, bridging multiple subsystems. Also look for a developer to whom the project manager can turn for quick assessment of risks associated with changes and emerging issues.

Testing: The architect directs systems-integration and user-acceptance testing and leads the assessment of ongoing test results for accurate communication of progress. Look for a developer who understands failure modes and is good at translating the results of test review into action plans.

Maintenance: During maintenance, the architect will lead discussions about systems integration. Whether accommodating IT infrastructure issues, or ensuring technical cooperation between departments, the architect must understand the application completely, must quickly learn the architecture of sister applications, and must communicate integration points and risks effectively. Look for a developer who has systems-integration experience and who has demonstrated rapid mastery of the big picture. Systems integration is a unique task.

Back to top

Advice for grooming architects

Some organizations groom architects more effectively than others. Fostering an environment that encourages the evolution of developers into architects can be a sound strategy, considering the difficulty of recruiting such a new specialty. But it is important to avoid penalizing developers who are neither willing nor suited to this path. An organization should create multiple career tracks for developers, including those who prefer to remain developers. Senior developers are indispensable to the architect. They can implement the most critical modules in the system. And through code review and test support for other developers, they help ensure overall software quality, without which even the best architecture is useless.

Organizations should institute personnel-review procedures that encourage developers to consider their career goals, including architecture as an option. Managers should be encouraged to look for architectural talent among their staff. Mentoring programs should be implemented that let architects work with developers who want to become architects. Developers should be encouraged to participate in the professional world by joining associations, writing articles, and attending conferences. Participating in this way helps developers understand systems from a new perspective and helps them better communicate that understanding. It can also seed important, innovative ideas that improve productivity.

Back to top


Once a developer takes a step on the path to architectural expertise, many resources are available to help, including many from IBM. Sometimes the hardest part of the journey is taking the first step, and this article provides some clues and cues managers and developers can use to assess who should be encouraged to become an architect.




Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.


About the author

Photo of Uche OgbujiUche Ogbuji is a consultant and co-founder of Fourthought Inc., a software vendor and consultancy specializing in XML solutions for enterprise knowledge management. Fourthought develops 4Suite, an open source platform for XML, RDF, and knowledge-management applications. Mr. Ogbuji is also a lead developer of the Versa RDF query language. He is a computer engineer and writer born in Nigeria, living and working in Boulder, Colorado, USA. You can find more about Mr. Ogbuji at his Weblog Copia.

Source: http://www.ibm.com/developerworks/library/ws-soa-proarch1.html