Just Enough Anticipation Architect your Time Dimension Eltjo Poort Architects in the digital world, such as software, enterprise or solution architects, derive their role name from architects in the civil 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 realization, making key design decisions and drawing blueprints. There is at least one aspect, however, in which the civil construction world is very different from the digital world: IT-based solutions such as application software, IT infrastructure and IT services are subject to change far more frequently then buildings. After all, bits and bytes are easier to change than brick and mortar, right? The role of change in the digital world is recognized in the ISO/IEC 42010:2011 [1] definition of architecture, which explicitly mentions evolution as part of architecture. Change is also the central theme in modern software development practices 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. Our recent experiences indicate that change and evolution should be given their proper place in the digital architecture world, and time should become a first class concept for architects of software, infrastructure, services, enterprises, and so on.

Issues with time-agnostic architectures Nowadays, many software-intensive systems are part of a complex application landscape, forming systemsof-systems or software ecosystems with myriads of interdependencies between commercial and custommade software, hardware platforms and organizational entities, all with their own evolution cycles. We now see such landscapes in all industries: my own experience ranges from banks and insurance companies, transport and logistics, to safety and justice and other public sector domains. In such a landscape, a timeagnostic architecture is a very perishable good: its best-before date is often only weeks in the future. Some issues that we have observed are:   

Architecture documents that are perpetually “almost finished” (causing delays in projects dependent on them) or are already obsolete when they’re issuedDevelopment based on architectural decisions that have already been revoked (to address changing circumstances). Difficulty planning ahead, caused by lack of insight into time dependencies of architectural constructs.

© 2016 IEEE, pre-publication version of Poort, E.; "Just Enough Anticipation: Architect Your Time Dimension", IEEE Software vol. 33 no. 6, p. 1115, Nov.-Dec., 2016 1

One way to address such issues is to design the solution’s evolution into the architecture. This is one of the practices we started to develop in situations with many logical dependencies, both inside and outside our own solution scope. As part of our Risk- and Cost-Driven Architecture1 approach, we started creating architecture documentation that not only describes the as-is and tobe situations, but explicitly identifies and deals with architecturally significant events on the way from as-is to to-be. Such events can be changes in the logical dependencies, such as a feature becoming available on a service, or an external system changing its behavior; but as shown in the examples below, they can also be other occurrences that affect the risk, cost or business value of our solution. Explicitly anticipating such events not only helps address the issues identified above, but turns out to be instrumental in fulfilling architecture’s role as a risk management discipline, by addressing timetriggered risks. It also increases the practical value of the documentation in cases where the to-be state turns out to be a moving target; when the world keeps changing, documentation that acknowledges change stays more relevant than documentation that doesn’t.

Architecting time: an evolution viewpoint According to the ISO/IEC 42010:2011 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 4+1 view model [2] gives five good examples of viewpoints that do this for common stakeholder concerns in software development. How about adding an “evolution viewpoint” that is specifically designed to show how the architecture addresses the impact of changes in the solution’s environment? Rozanski and Woods [3] introduce an “evolution perspective” in which change is explicitly considered in the architecture. One of the activities related to this perspective is to characterize a system’s evolution needs. An evolution view does this by first identifying future events that will have architectural impact on the solution, and then showing how the architecture anticipates these events. Considering architecture as a risk- and cost-management discipline [4], we are interested in the events’ architectural impact in economic terms: business value, cost and risk. Translating the direct “technical” impact of the events into those economic terms helps in communicating about them with business stakeholders, and it also helps to select the most important events if

Dealing with dependencies Popular architectural styles like Service Oriented Architecture (SOA) and its microservices [2] variant reduce the pain caused by ever-changing dependencies by decoupling subsystems or components. SOA decouples applications in an ITlandscape by hiding their internal behavior behind service interfaces. Using the right tools and protocols such architectural styles achieve independent deployability at the technical level, but these assets can provide only limited relief when it comes to logical dependencies: after all, consumers of a service can never use a feature that has not yet been implemented in that service, and if they need that feature, they have to wait, and may gracefully fail in the meantime. In other words, logical dependencies are related to the arrow of time.

1

Risk- and Cost-Driven Architecture (RCDA) is a set of solution architecture practices and principles used in CGI for designing IT-based solutions for clients in a lean and agile manner [2]. © 2016 IEEE, pre-publication version of Poort, E.; "Just Enough Anticipation: Architect Your Time Dimension", IEEE Software vol. 33 no. 6, p. 1115, Nov.-Dec., 2016 2

we cannot deal with all of them. Typical examples of events with architectural impact are: TABLE 1 EXAMPLES OF FUTURE EVENTS WITH ARCHITECTURAL IMPACT Event Competitor releases next generation product Microsoft Windows XP support discontinued Corilla license contract expires New version of Java EE (Enterprise Edition) Project to build System Y finishes

When expected Q4/2017

4/2014

Impact type Business value + Risk Risk

5/2017

Cost

11/2015

Cost

Q1 2017

Business value + Risk

Impact Our own product will be harder to sell if we do not match their new features, which would cause us to lose revenue. Vulnerabilities no longer patched; implies security risk, e.g. risk of intrusion and data leaks. Opportunity for cost reduction by switching to open source alternative. Opportunity for maintenance cost reduction by using new features announced for next version. System Y (which is interdependent with ours) will require interface features that are currently not supported by our solution. We need to build these features or our solution will lose its business value.

As you can see from the examples in Table 1, most of the events are associated with risks. This is inherent to the definition of a “future event with architectural impact” in two ways: first, in a view of architecture as a risk- and cost-management discipline, an item’s architectural significance is closely related to their risk (and cost) impact [4]. Second, any point in time at which a significant change in the cost or value of a solution occurs has a deadline-like nature, and every deadline brings a risk of being too late. In fact, a project’s risk register is often a good source to look for such time-triggered events that need to be anticipated in the architecture. The second step in documenting the evolution view is to identify backlog items for the solution’s evolution, which will potentially end up on the solution roadmap. At this stage, it is important to understand the dependencies between the solution architecture and the architecturally significant events identified in the list above. The backlog items should be linked to the components, modules, functions, nodes and other architectural elements they touch in the design. Based on the dependencies between architectural elements, backlog items and events, the architect can engage in economic reasoning about the roadmap with relevant stakeholders like product owners, project managers and product managers. Figure 1 shows a timeline on which these improvement items are visualized, including their dependencies on each other and on the significant events. The diagram makes use of a color coding scheme for backlog items devised by Philippe Kruchten [5]. The economic reasoning is made possible because we have previously identified the risk, cost and value impact of the future events on the solution. For example, the team may decide to take on some technical debt2 to make a release deadline in time for new reporting regulations coming into effect, if their analysis shows that the potential drop in value of the product (if the deadline is missed) is greater than the 2

Technical Debt [6] is a metaphor developed by Ward Cunningham. The increased cost of modifications due to work left undone in a system (e.g. refactoring, upgrading) is compared to the interest payed on a loan; doing that work is equivalent to paying back the loan. © 2016 IEEE, pre-publication version of Poort, E.; "Just Enough Anticipation: Architect Your Time Dimension", IEEE Software vol. 33 no. 6, p. 1115, Nov.-Dec., 2016 3

interest incurred by the technical debt. For more details about such reasoning, refer to [6], which describes these activities as steps to achieve “informed anticipation” in software architecture. Like other views, the evolution view can be a chapter in an architectural description document, or a standalone artifact specifically prepared for interested stakeholders. Since it is designed to deal with change and to work in volatile environments, a more dynamic medium such as a project or product wiki may also be suitable. Anyone who has concerns related to change and planning is a stakeholder of the evolution viewpoint: specifically project/program/product managers, product owners and architects/designers/developers working on other solutions in the same interdependent system of systems. It helps the managers and product owners plan ahead, and by acknowledging future events in the time dimension it helps fellow workers that depend on your architecture by telling them what aspects of the architecture will change (e.g. integration hub, interfaces) and when. The view provides important input to project management tools like risk registers and Gantt charts, and to product owners populating and prioritizing sprint backlogs in agile projects.

Experiences in architecture roadmapping The approach described above has been part of the “Architecture Roadmapping” practice that we have used in CGI since 2012. The main objective of architecture roadmapping is to find the right balance between overanticipation and under-anticipation in implementing architectural constructs in a solution. Architectural constructs are under-the-hood parts of a solution: things like abstraction layers, firewalls or caching mechanisms, which typically are not visible to end-users but needed to achieve quality attributes like modifiability, security or performance. Over-anticipation typically manifests itself in architectural constructs that over time turn out to be less valuable than the trouble of creating them was worth (a phenomenon called YAGNI3 in agile circles, “You Aren’t Gonna Need It”). Under-anticipation often occurs when the implementation of architectural constructs is left too late, causing the solution to accrue technical debt, and making it increasingly difficult to add new features in an evolutionary manner. Naturally, the time dimension plays a crucial role in achieving the right amount of anticipation in architecture roadmapping.

3

http://martinfowler.com/bliki/Yagni.html

© 2016 IEEE, pre-publication version of Poort, E.; "Just Enough Anticipation: Architect Your Time Dimension", IEEE Software vol. 33 no. 6, p. 1115, Nov.-Dec., 2016 4

An example of architecture roadmapping Our competitor has announced the release of a next-generation version of their platform “BuyYourTripsHere.com” in the fourth quarter of 2017. Our team’s product manager has identified a crucial feature (F) that our own product, “AdventuresBeyondBelief.com”, needs to have in place before the competitor’s next-generation release: the ability to check if a hotel has free Wi-Fi. If we do not have feature F in place in time, a 25% market share loss is predicted, a potential drop of $250,000 in business value. F is a functional feature, but it drives architecture roadmapping because it is dependent on an architectural improvement. It requires an “under-the-hood” change (A) before it can be implemented: our hotel communication platform needs to be upgraded to the latest version. Also, the free Wi-Fi information needs to be exposed on the back-office’sintegration hub (e.g. an Enterprise Service Bus), but this cannot be achieved in time. The team decides to plan changes A and F in time to beat the competitor, and to create a temporary solution bypassing the integration hub. This temporary solution means that the team is accruing technical debt, but the interest on the technical debt is estimated to be much lower than the $250,000 drop in business value if we do not have feature F in place before the competitor. The refactoring activity (T) of replacing the temporary solution with a proper connection over the integration hub is planned for the subsequent release.

FIGURE 1 VISUALIZATION OF ARCHITECTURE ROADMAP

© 2016 IEEE, pre-publication version of Poort, E.; "Just Enough Anticipation: Architect Your Time Dimension", IEEE Software vol. 33 no. 6, p. 1115, Nov.-Dec., 2016 5

Our architects have been using the Architecture Roadmapping practice in many different contexts and domains, for time spans looking between one and six years ahead. Their anticipation documents are often quite informal, never called “evolution view” but rather “roadmap”, “decision support” or “strategy document”. The timed events they take into account in their architecture are typically:    

project or process milestones, such as delivery and approval deadlines; also deadlines in dependent projects product version/infrastructure upgrades business changes due to various reasons, e.g. changes in external agreements (e.g. Key Performance Indicators), mergers/take-overs, legislative/policy changes changes in availability of resources, including availability of expertise

All of these anticipated events generally have impact on a combination of risk, cost and business value of the solution: e.g., a delivery deadline typically has impact in terms of cost of delay and risk of losing customers, and a product version upgrade becoming available can add potential business value by adding support for new features, but can also represent a risk if the product’s supplier discontinues support for a previous version (or changes the backward compatibility policy of the product). When asked about their experiences, our architects report significant benefits resulting from making the time dimension part of their architecture in this way. The benefits most mentioned by them are improved (more realistic) stakeholder expectations and better prioritization of required architectural improvements. Both can be explained by the fact that the architectural roadmapping practice helps architects articulate the business impact of the various evolution scenarios, and discuss the timing of architectural improvements based on that business impact, rather than on generic (sometimes dogmatic) “rules” like YAGNI or “do not optimize prematurely”. A number of our architects also stress the importance of stakeholder communication to identify anticipated events.

In short Making the time dimension part of your architecture documentation in the form of an evolution viewpoint or an architectural roadmapping practice may look like extra work. However, anticipation should be a large part of your job as an architect anyway. By writing it down (for example in an evolution viewpoint or architecture roadmap), 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.

© 2016 IEEE, pre-publication version of Poort, E.; "Just Enough Anticipation: Architect Your Time Dimension", IEEE Software vol. 33 no. 6, p. 1115, Nov.-Dec., 2016 6

References [1] ISO/IEC JTC1 SC7, "Systems and software engineering - architecture description (ISO/IEC 42010:2011)," 24 November 2011. [Online]. Available: http://www.iso-architecture.org/42010/. [Accessed 23 January 2016]. [2] P. Kruchten, "Architectural Blueprints—The “4+1” View Model of Software Architecture," IEEE Software, pp. 92-95, November 1995. [3] N. Rozanski and E. Woods, Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (2nd Edition), Addison-Wesley, 2011. [4] E. R. Poort, "Driving Agile Architecting with Cost and Risk," IEEE Software, pp. 20-23, September/October 2014. [5] P. Kruchten, R. L. Nord and I. Ozkaya, "Technical Debt: Guest Editors' Introduction," IEEE Software, November/December 2012. [6] N. Brown, R. L. Nord and I. Ozkaya, "Enabling Agility Through Architecture," CrossTalk, November/December 2010. [7] S. Newman, Building Microservices – Designing Fine-Grained Systems,, O’Reilly, 2015.

© 2016 IEEE, pre-publication version of Poort, E.; "Just Enough Anticipation: Architect Your Time Dimension", IEEE Software vol. 33 no. 6, p. 1115, Nov.-Dec., 2016 7