Enterprise, Solution and Software Architecture

Are we actually really “Architects” at all?

I’ve recently read “Building Microservices” again to consider its concepts from a new perspective. Within this excellent book there is a passage around the “Evolutionary Architect” that raises a very interesting question. Sam Newman suggests that we shouldn’t consider ourselves as “Architects” at all, and that our role is more akin to that of a “town planner”. How many “Enterprise Planner” or “Solutions Planner” roles have you seen? The answer is probably very limited, unless you purposely went searching for the role. Sam makes a series of assertions which I’ll summarise below:

Information Technology requirements shift more rapidly than they do for people who design and build buildings

Tools and techniques shift rapidly, paradigm shifts occur probably every 3-5 years, we’re under a constant battle to stay current within the market. (My apologies for anyone in the buildings Architecture sector, due to a lack of knowledge this may very well be the case within your sector).

The structures and services we create are not based on fixed points in time, we adapt as the organisations strategy adapts. Our IT Architectures are a living organic entities, systems continue to evolve, buildings largely stay fixed in time.

Once software gets in the hands of the customer, it has to react and adapt, rather than it being a never-changing artefact

Newman suggests that Architects need to shift their thinking away from creating the perfect end product, instead focus on creating a framework in which the right systems can emerge (emergent design), and continue to grow as we learn more and more about the domain.

A town planners role is to look at a multitude of sources of information, and then attempt to optimise the layout of a city to best suit the needs of the citizen today, and for future use. Much of this is centred around the concepts of “zones”, in that cities have a number of zones such as Industrial and Residential zones. This essentially follows the Concentric Zone Model developed by Ernest Burgess (1925).

The idea of this model is that cities are usually centred around a Central Business District as its core, with a succession on zones. Now you’re probably asking, what has this to do with IT Architecture? Well to overlay the concepts from these models into Information Technology, you’ll notice these concepts fit extremely well in conceptualising IT Architectures. Think of the Concentric Zone Model in relation to Shearing Layers by Frank Duffy and Pace Layering by Gartner. To summarise, Pace Layering classifies systems within your Enterprise as Systems of Record, Systems of Differentiation and Systems of Innovation, over a number of layers. These layers serve different purposes and have different rates of change. Systems of Innovation are likely to have high rates of change and would deliver your value proposition to Customers, whereas Systems of Record will have a lower rate of change and will be utilised as the platform of your organisation.

Moving back to the town planner analogy, the role of an Architect is create a set of zones (or platforms) for structures (or application components, processes, services) to develop. Then it is up to the builders (or developers) to decide what exact buildings get created (or systems), but there are restrictions (or governance): if you want to build a factory it will need to be in an industrial zone. Similarly, you wouldn’t situate operational solutions within your Systems of Innovation, they’d likely be a combination of sitting in the zones of Differentiation and Record.

Newman suggests that rather than worry too much about what happens in one zone, the town planner will instead spend far more time working out how people and utilities move from one zone to another and does his/her best to anticipate changes, but accepts that trying to exert direct control over all aspects of what happens is futile. This aligns well with Tom Graves notion of Architecture as an emergent property rather than Architecture as a possession. Architects or planners have a duty to ensure that the system is habitable (for developers) and only getting involved in highly specific detail in limited cases providing autonomy to the builders.

So with all the above fresh in your mind, do you see your role as an Architect or a Planner? Dare we change our job roles from Enterprise Architecture and Solutions Architect to Enterprise Planner or Solutions Planner?