The Never-Ending Narrative of Architecture

All of my creation is an effort to weave a web of connection with the world: I am always weaving it because it was once broken.

Anaïs Nin by way of @RuffyanMe

When is an architect’s job done? Is it upon completion of the “design phase”? Is it when the project is complete?

In my opinion, the best definition of the architectural process (see slide 16) is Tom Gilb’s: “A continuous, and lifecycle long, activity of finding means for ends”. The activities facilitated by the application are unlikely to be static, so it is unrealistic to expect it to remain the same. Even where the business doesn’t change significantly, our understanding of it may:

I bet the users are very grateful at first, but then they come to rely on it. And, what’s more, they like the system less and less over the course of time. Every time the USPS changes the price of postage you have to go into this system and made changes, and, what’s worse is that the part that generates the documents seems to break every time there’s a new version or even an update to Word.

Erik Dietrick, “Beware Mindless Automation”

Even if a particular business process was unchanging and its automation was executed perfectly, the platform on which it runs will not. Failure to plan for platform evolution is planning to fail due to lack of maintenance.

In short, an application is a relationship. Unless you plan to never see its users again, it’s a long-term commitment, not just a project. So long as the application exists, there is a need for the architect role to provide advice on the evolution of the product and its platform. Without this continuity of vision, the result is likely to be the “Shantytown” pattern described by Foote and Yoder in “Big Ball of Mud”:

All too many of our software systems are, architecturally, little more than shantytowns. Investment in tools and infrastructure is too often inadequate. Tools are usually primitive, and infrastructure such as libraries and frameworks, is undercapitalized. Individual portions of the system grow unchecked, and the lack of infrastructure and architecture allows problems in one part of the system to erode and pollute adjacent portions.

If the architectural process can be described a narrative, it should also be seen as a story consisting of several component stories, carrying the product from cradle to grave(*). Maximizing cohesion within a given narrative (release) is important. Likewise, benefits will accrue from maintaining continuity from one narrative to the next.

The connection between the application and the ends it serves is seldom static. The longer the web is left unattended, the more likely it is to break. Much can slip through a broken web, and each escape widens the breach.

Maintenance can seem costly without the perspective of the cost of replacement, not to mention value lost to obsolescence.

* It’s not exactly “never-ending”, but I like alliteration, so the title stands. 😉