Author Archives: admin

Just Enough Anticipation: Architect Your Time Dimension

Eltjo Poort, IEEE Software, vol.33, no.6, pp. 11-15, Nov.-Dec. 2016

A bit of planning is indispensable to anticipate events that will affect your software’s risk profile. Traditional architectural planning emphasizes the spatial dimension (for example, components and connectors) but neglects the time dimension. Consulting IT architect Eltjo Poort makes the case for an explicit representation of architectural evolution along the time axis and reports on the experiences with architecture roadmapping where he works.

Official link

Pre-publication version

Architectuur krijgt nieuwe kans (Dutch)

Eltjo Poort, Computable, 20 September 2016

Official link

‘The best architectures, requirements and designs emerge from self-organizing teams’, is wellicht het meest misbruikte principe uit het Agile Manifesto. Door de jaren heen was de gangbare interpretatie van dit principe verworden tot: ‘Hoe minder je nadenkt over de toekomst, hoe beter je systeem wordt.” Het was de afgelopen tien jaar in de software-ontwikkeling niet bon-ton om het over architectuur te hebben. Maar het tij is langzaam aan het keren.

Modelleren wordt weer oogluikend toegestaan – zij het soms achter gesloten deuren, om het stigma ‘Big Up-front Design’ te vermijden. We durven het nog nauwelijks hardop architectuur te noemen, dus ontstaan er eufemismen als ‘Design thinking’ en ‘Master builder’. Maar het besef dat een beetje anticipatie in je systeemontwerp noodzakelijk is om risico’s beheersbaar te houden is nu wel doorgedrongen, getuige bijvoorbeeld het concept van de ‘Architectural Runway’ in het steeds populairder wordende Scaled Agile Framework.

Het is dus weer veilig voor ons, de anticiperende ontwerpers in de digitale wereld, om voorzichtig uit de kast te komen en ons bekend te maken als bijvoorbeeld enterprise-architect, solution-architect of software-architect. Daarmee is het ook tijd om de balans op te maken: wat staat ons te wachten, wat speelt er in het land van de digitale architectuur? In dit artikel een korte inventarisatie van de belangrijkste trends en ontwikkelingen.

SATURN 2016 – part 2

This is the second and last part of my SATURN 2016 conference report. Since I posted the first part, the organizers have posted video recordings of many of the best talks, and more will follow on the SATURN playlist on YouTube.

Ethical and social considerations in software architecture design featured in many talks, but most prominently in three short “DEV@SATURN” talks by Michael Keeling, João de Sousa and Bett Bollhoefer. DEV@SATURN was a new feature this year: 15 minute talks in the plenary sessions, which yielded some enjoyable and interesting food for thought; I would say a successful experiment. Michael presented a reasoning framework for ethical considerations in architectural decision making, including some reusable quality attribute scenarios for environmental sustainability and fairness to customers and developers. João reported on his work to develop an Internet of Things interaction framework (“Bezirk”) that shifts the power to control data exchanges from companies and application developers to end users – an architecture that gives app users more choices than just the two bad options we are generally given now: give access to everything the app demands or the app doesn’t work at all. João received the conference’s New Directions award for his talk. Bett gave us a glimpse of the insights into mindful software development she gathered in a “Zen of Software Development” booklet (and got the whole audience to do some yoga on the spot…).

Other highlights

For me, the most interesting keynote was Daniel Jackson’s “Rethinking Software Design”. It was mostly about user experience design, and the word “architecture” only appeared once – but Daniel presented some keen insights into the impact of bad user interaction design at the architectural level. Software and solution architects generally do not get very much involved in user interaction design, especially those schooled in the SEI architecture practices, which are mostly based on the notion that non-functional requirements and quality attributes drive architectural design. But isn’t usability also a quality attribute? Bad user interaction design has a substantial risk and cost impact, and can cause a project to fail – both strong indicators that user interaction design is architecturally significant, and thus should be addressed by architects.

Another highlight was Eoin Woods’ talk on Getting your system in production – and keeping it there. 90 minutes of great practical advice. Eoin is a star at systematically presenting solutions, and illustrates each and every point he makes with an amusing (or dramatic) real-life story. Like user interaction, production is another area architects sometimes underestimate, or at best have an ad-hoc approach to. If you have a few minutes, peruse Eoin’s slides, and if you have some more time, watch his presentation here.

getting production

IMG_0472At the close of the conference, I had the honor of receiving the first Linda Northrop Software Architecture Award, a few minutes after Linda herself gave a very nice overview keynote on the status of the software architecture practice. It felt great to get such international recognition for the hard work my CGI colleagues and I put into improving the way we do architecture, during a decade in which the whole idea of up-front design was widely discredited by the mainstream software development community. As noted above, the pendulum seems to be swinging back in the other direction now, and people are back modeling systems in order to build better software – hopefully, before long, with the door open again.

SATURN 2016 – part 1

This year’s SATURN (Software Engineering Institute (SEI) Architecture Technology User Network Conference) was held in San Diego from May 2-5. Compared to last year, the geographical context was much improved – Southern California felt a lot more relaxed than Baltimore under curfew. The conference organizers had once again prepared an excellent technical program, and as always it was sometimes difficult to choose between tracks – everything was interesting. Fortunately, all presentations were video-recorded, and should appear on the conference website soon.

The fantastic opening keynote was by community guru Grady Booch, who gave us a peek into the future of architecting. He talked about “abstracting the unknown”: architecting the kind of systems that stretch us both technically, socially and ethically. His talk set the stage for a number of central themes that pervaded the program: evolutionary architecture, ethical considerations, and the renewed recognition of the role of modeling (the real world) and intentional design in software engineering. Slides 43-45 in Grady’s presentation give an elegant summary of the modern view of why and how we architect. As for architecting the unknown, it is clear that there is much less opportunity for reuse, and that we need a method that allows our intuition to play a much more prominent role.

architecting the unknown

Grady Booch’s tips when you find yourself having to architect the unknown.

Evolutionary architecture and roadmapping was the topic of talks by Patrick Kua, David Adsit, Alejandro Bianchi, Pierre Pureur (continuous architecture) and myself, and of a keynote by IoT frontrunner Joseph Salvo. The common message here seems to be that the “dot on the horizon”, the architected future state, is becoming less meaningful in a world that changes faster than architectures can be realized. We therefore need architectures and architecting practices that are flexible and resilient enough to maintain their value in a rapidly changing business or technological context. We all reported on our experiences implementing such practices, in my own case introducing an evolution viewpoint to help achieve just enough anticipation in your architecture.

Adding time dimension

Modeling the real world seems to be a prerequisite for an architecture to have that flexibility and resilience. I remember teaching this in Object Oriented Analysis and Design classes in the 90s, but it seems that insight is resurfacing now after having been deprecated by overzealous agilistas for a while. This was the topic of talks by Amber Haley, Arila Barnes and George Fairbanks, and played an important role in Daniel Jackson’s excellent Wednesday morning keynote. George talked about the stigma clinging to modeling in some agile teams, and “modeling with the door shut” to avoid being seen practicing such a shameful activity. It was also funny to see that modern modelers are developing their own, new languages for domain modeling, where we successfully used UML in the past. It seems UML is now so much associated with technical design that people don’t recognize it as a domain modeling language anymore, and feel the need to reinvent the wheel… for similar reasons, much of what we used to call architecture now seems to be relabeled “design thinking”.


There is much more to report on SATURN 2016 – next installment coming up soon!


The Software Engineering Institute at Carnegie Mellon has selected me as the winner of this year’s Linda Northrop Software Architecture Award. I feel honored to receive this award from the most respected research institute in our profession. It is a great recognition of the work done by the RCDA team at CGI in the past six years. Thank you Philippe Kruchten for nominating me, and Eoin Woods and Tom Verhoeff for endorsing my nomination.

Architecting in a Solution Costing Context: Early Experiences with Solution-Based Estimating

Eltjo R. Poort, Eric van der Vliet, Software Architecture (WICSA), 2015 12th Working IEEE/IFIP Conference on , vol., no., pp.127-130, 4-8 May 2015

Organizations require cost estimates for delivering and operating software-intensive solutions. One of the factors impacting these costs is the solution’s architecture. Applying solution architecting practices helps improve the accuracy of early cost estimating. In CGI, we have started to emphasize the application of architecting practices in cost estimating, and this paper reports on the early experiences of this initiative, which we call Solution-Based Estimating. We present an architectural viewpoint designed to address the costing concern, and report some early feedback from projects that have applied the Solution-Based Estimating approach.

Official link

Pre-publication version

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.