The profession of software architect

Many certification programs that include software architecture titles in their offers certify the knowledge of an architect on specific technologies or frameworks (e.g. TOGAF). More difficult is to certify the general skills of professional software architects. This is a potential issue because technical skills cover only a small part of the body of knowledge required day by day to conduct a software project if you are an architect. To grasp this body of knowledge we must think more deeper on the architect role. Software architects are those people that make many important decisions on a system, decisions hard to change later, decisions whose effects are usually not located (and isolated) in a single software module. These decisions are very often made early on in the project lifecycle so that other roles can follow the plan. This works in a perfect world. In the real world, requirements, domain constraints and technology change so quickly that architects must either adapt the initial vision in order to  preserve a conceptual integrity of the overall design. In this moment we appreciate the true role of software architects. Quoting Martin Fowler [1]

This kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem. […] the most noticeable part of the work is the intense collaboration. [A typical working day can look like this.] In the morning, the architects programs with a developer, trying to harvest some common locking code. In the afternoon, the architect participates in a requirements session, helping explain to the requirements people the technical consequences of some of their ideas in non-technical terms, such as development costs.

I like the characterization of the architect role discussed by Fowler because it shows how the architect really works in practice, deriving responsibilities from such activity more than from “academic” theory. The production of code is definitely the most evident technical stuff software architects are involved into, but their responsibilities extend to the mentoring of development teams, to raise their level so that they can take on more complex issues. In that way, they are not the sole decision makers; they are more like expert guides that teaches other team members.

Another interesting point of inspiration provided this time by Ralph Johnson and cited by the Fowler’s article is the concept of architecture. Of course architecture is related to architects. For Johnson architecture is a social construct. Ralph starts criticizing the RUP’s definition of software architecture: “the highest level concept of a system in its environment. The architecture of a software system (at a given point in time) is its organization or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces”.

This definition is useful only for developers. In fact, customers do not share the same interests for the internal structure of the system. Hence for them the organization of modules are very likely uninteresting. They are more conscious of the user interface or the non functional requirements of a system such as efficiency or availability. So, argues Ralph, perhaps an architecture is the highest level concept that developers have of a system in its environment. However, not all developers are enough expert to understand the whole vision. Moreover, what are the most significant components of a system? The answer is entirely based on what developers thinks is more important. For enterprise applications, people tend to think that the database is the crucial decision, whereas real-time or embedded systems might include a database without considering it part of the architecture. Architecture, continue to say Ralph Johnson, is about the important stuff.

An architect should be evaluated in the environment where he works more often. Of course, there are some general design principles that form his background, but the skills most useful are not only technical. The social skills are equally relevant. Whereas certification programs teach the former, it is harder to find good sources of information to learn the latter. Experience is the main vehicle for such knowledge. Thus, mentoring is one of the most effective way to learn the architect job. Papers, videos, power-point presentations and courses made by architects for architects are also significant. Moreover, architecture bootcamps are another way to learn. Two interesting publication which shed some light on the architect role are “Software Architect Bootcamp” [2] and “12 Essential Skills for Software Architects” [3] .

Finally, also personal blogs and professional associations are good places to share ideas and experiences, meet people, and leverage the expertise of peers. Perhaps the most important associations for software architects is IASA (International Association of Software Architects). Blogs of people like Martin Fowler and Grady Booch are also invaluable resources.


[1] Fowler, M. “Who Needs an Architect?”. IEEE Software, Vol. 20, Number 5. September-October 2003

[2] Mowbray, T.J.; Malveau, R. “Software Architect Bootcamp 2/E“. Prentice Hall, 2003

[3] Hendricksen, D. “12 Essential Skills for Software Architects“. Addison Wesley, 2011


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s