Architects 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:
|Competitor releases next generation product
||Our own product will be harder to sell if we do not match their new features
|XP support discontinued
||Vulnerabilities no longer patched
|Corilla license contract expires
||Opportunity for cost reduction by switching to open source alternative
|New version of WebSphere
||Opportunity for maintenance cost reduction by using new features announced for next version
|Project to build System Y finishes
||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.
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.