Time as a First Class Architectural Concept

20150807_164338Architects in the digital world often compare themselves to architects in the construction world. The metaphor works on many levels: architects in both worlds are responsible for conceptual (and structural) integrity, are the content leaders with overview over design and construction, making key design decisions and drawing blueprints. There is at least one aspect, however, in which the construction world is very different from the digital world: IT-based solutions such as software, infrastructure and services are subject to change far more frequently than buildings.

The role of change in the digital world is recognized in the ISO 42010 definition of architecture, which explicitly mentions evolution as part of architecture. Change is also the central theme in modern software development methodologies like Agile and DevOps. The digital architecture disciplines seem to be lagging behind a bit in this development, perhaps hindered by the metaphor that gave them their name. It is time to give change and evolution their proper place in the digital architecture world, and make Time a first class concept for architects of software, infrastructure, services, enterprises etcetera.

Issues with time-agnostic architectures

When construction of a building is finished, its architecture documentation is final: it will not change for decades. The architecture documentation was probably considered final before construction began, since in the vast majority of cases only non-architectural changes occur during the construction of buildings. It is perhaps this idea of “final and unchanging architectural documentation” that prompts managers to ask architects “when will your architecture be finished”? In view of the prominence of change in the digital world, however, solution architects can rarely give a straightforward answer to this question.

Nowadays, practically all software-intensive systems are part of a complex application landscape, forming systems-of-systems with myriads of interdependencies between commercial and bespoke software systems, hardware platforms and organizational entities, all with their own evolution cycles. In such a landscape, a time-agnostic architecture is a very perishable good: its best-before date is at most weeks in the future. This  leads to the following observed issues:

  • architecture documents that are perpetually “almost finished” (causing delays in projects dependent on them) or already obsolete when they’re issued
  • development based on obsolete architectural assumptions
  • difficulty planning ahead

Popular architectural styles like SOA and microservices attempt to reduce the pain caused by these ever-changing dependencies at the technical level, but can provide only limited relief when it comes to logical dependencies. In modern application landscapes, the only other way for architects to address the issues observed above seems to be to design the solution’s evolution into the architecture. We have to create architecture documentation that not only describes the as-is and to-be situations, but explicitly identifies and deals with architecturally significant events on the way from as-is to to-be.

Architecting Time: the Evolution viewpoint

According to the ISO 42010 standard, architecture documentation consists of views that represent the architecture from certain viewpoints. Viewpoints are designed specifically to demonstrate to stakeholders how the architecture addresses a particular set of their concerns. Philippe Kruchten’s seminal “4+1 View model” paper gives five good examples of viewpoints that do this for common stakeholder concerns in software development. What if we added an “evolution viewpoint” that is specifically designed to show how the architecture addresses the impact of changes in the solution’s environment? An Evolution view would identify future events that will have architectural impact on the solution. It would specify that impact in terms of business value, cost and risk, and analyze dependencies between the solution and the events. The view would also document how the solution (and/or its delivery/operations team) will anticipate and react to the events when they occur. Typical examples of events with architectural impact are:

Event When expected Impact type Impact
Competitor releases next generation product Q2/2016 Business value Our own product will be harder to sell if we do not match their new features
XP support discontinued 4/2014 Risk Vulnerabilities no longer patched
Corilla license contract expires 5/2017 Cost Opportunity for cost reduction by switching to open source alternative
New version of WebSphere 11/2015 Cost Opportunity for maintenance cost reduction by using new features announced for next version
Project to build System Y finishes Q3 2016 Business value System Y (which is interdependent with ours) requires interface features that are currently not supported by our solution

Stakeholders interested in the Evolution viewpoint would be anyone who has concerns related to change and planning: specifically project/program/product managers, product owners and  architects/designers/developers working on other solutions in the same interdependent system of systems. It would help the managers and product owners plan ahead, and by acknowledging future events in the time dimension it would help fellow workers that depend on your architecture by telling them what aspects of the architecture will change, and when.

In short

Making the Time dimension part of your architecture documentation may look like more work, but anticipation should be a large part of your job as architect anyway. By writing it down (for example using an Evolution viewpoint), your architecture description will stay valid longer, and you will have a ready answer when stakeholders ask you how their change and planning concerns are addressed.


Software Systems Architecture – Working With Stakeholders Using Viewpoints and Perspectives by Rozanski and Woods, specifically the Evolution perspective.

Enabling Agility Through Architecture by Brown, Nord and Ozkaya gives us the tools for “Informed Anticipation” in the architecture: dependency analysis, real option analysis and technical debt management.

One thought on “Time as a First Class Architectural Concept

  1. Ron van den Burg


    This adding of Time as a First Class Architectural Concept is greatly welcomed. Thank you.
    Time has always been a relevant factor, but not recognized as one of the main concepts.
    To broaden the above scope of ‘time’, I also see the ‘time horizon’ as having a significant impact on the architecture: are you architecting systems for a business that will set its business strategy in three years? An architect will then opt for ‘disposable software’. Or, are you architecting a solution for mass OCR scanning? Then your time horizon is limited to the (anticipated) point where it is cheaper to give your customers a computer for free to skip the printing + scanning part of the business proces.

    A second idea that this post triggers is that of ‘architectural boundaries’. The appropriateness of an architecture should not be set by the technical boundaries, but should be more restrictive. When the architectural boundary is met, the solution can still be fit-for-purpose, but if you would look at the required system with a fresh look, you would use another architecture: the old architecture still works, but is not the best architecture anymore. These boundaries should also include the time boundary: how long do you guarantee that the current architecture is appropriate? It helps in capping the amount of effort and costs on the architecting of systems up to and including the building and maintenance of the systems.
    Isn’t this what they also did in space? Didn’t they send a probe to pluto, realising that in a decade’s time a much faster probe can be built that will arrive at pluto earlier than the first one?

    So thank you for elevating ‘time’ from ‘just one of the requirements’ to a ‘first class architectural concept’.


Leave a Reply

Your email address will not be published. Required fields are marked *