On the role of software architect

The figure of software architect is a little controversial in the software community because the analogy with the traditional role of architect is flawed. These inaccurate comparisons (software architects are more similar to town planners[1] than to civil architects) are terrible, especially in these days of “agility”. Far from a Waterfall approach, today we require architectures to be fluid, evolving with even radical changes, in particular concerning to technology decisions. In this situation, the metaphor of a professional role (the architect) that is both artist and engineer, and that provides a detailed plan for what is eventually a single view of the system under construction is quite anachronistic and dangerous.

Sam Newman in his recent book[1] introduces the concepts of evolutionary vision and coding architect. The evolutionary vision of a system architecture (and, by extension, of the professional role) suggests that IT architects need to shift their thinking away from creating perfect end products, reducing the value of a fine-grained, detailed, perfect plan. Instead, they should focus more on:

  • strategic goals that an architecture vision should/must reinforce/respect;
  • principles that align the day-to-day activities for building software systems with the aforementioned goals;
  • practices that ensure the aforementioned principles are being carried out.

The evolutionary vision provides a perspective to look at architectures as places (zones) where such principles and practices live all together (here the metaphor with the town plan). It is more similar to a conceptual framework rather than a selection of interconnected components. In such framework, strategic goals are for example:

  • “enable scalable business” or
  • “support rapid changes in order to best serve an evolving market”.

Example of architectural principles are:

  • “eliminate accidental complexity” or
  • “reduce inertia”.

Example of practices are:

  • “continuous integration, CI” or
  • “Published integration model, PIM”.

These practices (CI and PIM) can support the principle of reduce inertia (i.e. make choices that favor rapid feedback and change) which can support the goal of support rapid change. The architecture is then the description of components, layers of abstractions, and technologies, aligned with this framework of goals-principles-practices. The evolution architect is the professional figure that build, maintain, share, revise, and promote such vision.

The architect must be in some way connected with abstract ideas and principles as with the end-result: components written in some programming language. The architect should reserve some time (e.g. 0,5/1 day for week in certain periods of a project) in order to check the code, sitting side by side with programmers, reviewing source code in order to reinforce good practices or improve the design in order to align it with the strategic goals of the vision. In this way the vision becomes a “real thing”, shared and embraced by the entire team, not only by a single member. This is what Sam Newman calls the coding architect.


[1] Sam Newman. Building Microservices. Designing fine-grained systems. O’Really. 2015


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s