Architecture: What Does it Mean to be a Software Architect? - Part I

One of the goals of this articles is to help you develop those skills that will enable you to play the role of a software architect on a project. In order to help you meet that goal, we should probably provide a definition for the word architect.

I might deservedly be considered pretentious if I were to offer a "be-all-end-all" definition for the role of software architect. Instead, all I can do is offer a few thoughts. I must apologize because I cannot provide a terse statement.

Many would agree that the label architect is becoming more and more meaningless as an increasing number of organizations use the title in order to promote their sales agendas. 

Furthermore, many developers call themselves architects in order to elevate their own stature. For the time being, let’s forget about the negative connotations related to the word architect. Instead, let’s think about the role of architect, what it means to play that role, and how developers might move up to this role.

Perhaps a good place to start is by looking at the construction industry. Webster’s dictionary defines an architect as being...

"1. A person who designs buildings and advises in their construction. 2. A person who designs and guides a plan or undertaking."

I think that’s a pretty good place to start. All we need to do is swap a few words, add couple more, and this definition might work for our industry.

"1. A person who designs software systems and advises in the design of such systems. 2. A person who designs and guides a plan or undertaking related to software systems design."

Many of us are indeed architects if we use definition #1 as our standard. Even the most junior developer has valuable insights into how an organization might design and deliver software. Item #2, however, suggests a leadership role that somehow rises above mere counsel. 

The implication is that an architect has some kind of wisdom that will help the organization deliver software that not only meets the tactical and strategic objectives of the organization, but also considers the technical, fiscal, scheduling, and staffing constraints (to name a few) of the project. Such wisdom helps the organization identify the pros and cons of a given design decision and select a direction that optimizes the use of technology for the given business objectives and constraints.

If we accept that one of the characteristics of an architect is wisdom, the next question might be, "Where does such wisdom come from?" The quick answer is that it varies from person to person. Some people early in their careers have a natural talent that allows them to see how software designs might best achieve their objectives. Others, like myself, acquire knowledge over time by observing and studying how problems are solved on a number of platforms, in different languages, and by learning from our own mistakes.

Some believe that architects should be the best coders. I would argue that, regardless of the vertical industry you’re in, and whether you do corporate, commercial, government, or non-profit software work, this tenet if faulty. 

Let’s consider the world of building construction. In that world there are clear distinctions between specialists (e.g. carpenters, masons, electricians, etc.) and architects. In that world we can all understand the role of an architect, and we would never expect the architect to be an expert carpenter, mason, or electrician. Yet we all can accept that a building architect has to know enough about all of these things in order to envision, design, communicate with, and possibly direct and orchestrate the activities of such highly skilled individuals.

This analogy suggests that architecture is more focused on "the big picture", and that the architect turns to and delegates to specialists accordingly. This does not mean that the architect should ever let their coding abilities slip. 

On the contrary, the best architects keep on coding, they just may not dig into all of nuances of the latest framework, language, or platform. Most architects have learned that, when it comes to technology, specialized knowledge is a moving target and will probably be obsolete within 5 years or less. Architects are more concerned with how the current or "up and coming" technologies serve a "big picture" need.

The What Does it Mean to be a Software Architect? - Part II in this series will explore what architects need to know in order to do their jobs.