If money were no object, the most idyllic place I could imagine would be a mid-century modern Frank Lloyd Wright style house, designed to fit perfectly into a cliff overlooking the vastness of the ocean, treating residents and guests to breathtaking views.
If I were to acquire such an imaginary bespoke architectural wonder from the 1950’s, I would certainly want to make lots of updates before I could call it a permanent residence. I’d probably need to run all new electrical and plumbing services to bring it up to current city code, and wire the whole house up with a fast internet network, smart lighting and climate controls.
Maybe a new overlook deck, or dig out some space under the foundation to add a garage and a bowling alley. It’s my dream, after all… Then, I wake up as the whole house comes crashing down into the sea.
In some ways, our critical applications are like custom houses built on a cliff—subject to forces of nature like wind, water and erosion—but also susceptible to failure due to architectural drift as changes to the infrastructure impact the resiliency of the entire system.
How can we keep up with our neighbors, if we can’t safely manage the architectural drift that happens throughout an application’s lifecycle?
Learning from pre-modernization architecture
Architectural debt is a unique form of technical debt, because it represents the negative interest accrued due to infrastructure and system design decisions, rather than inefficiencies and bugs in volumes of code. Often, this kind of debt is not a result of the original architecture being bad or flawed in any way.
If you look at my colleague Jason Bloomberg’s previous post on architectural debt, the ‘least possible architecture’ would be the most suitable architecture for adaptation, and leave room for change to naturally occur.
When approaching an existing application architecture it’s useful to do a little prep work before arbitrarily deciding how to break down silos, or morph monoliths into microservices.
Determining design intentions
Why was the original architecture put in place, and what were the key design considerations and customer requirements that led to the software’s initial development?
The concept of ‘intent-based computing’ has largely fallen out of fashion today, but the original business intent of the architecture is worth reviving for this part of the journey.
For instance, scalability may have been an incredibly difficult aspect to achieve 10 or 15 years ago, before elastic cloud infrastructure and microservices were commonly available to the company, so resources or memory may have been allocated exclusively for specific services.
Or perhaps, secure authentication and encryption was once more important than ease of data transfer for a privacy-intensive application, leading to a throttled, slow performing app that can’t keep up with today’s expectations.
If you are in doubt about the value of looking back at the original intentions of software architects in order to figure out what’s next, look no further than the many service interruptions that recently made news at Twitter. When the company cut ties with many of the developers and engineers that were responsible for the original design of the massive social network, user access to their new Spaces feature was denied when it was exposed to peak-traffic events.
Configuration drift versus architectural drift
Companies will constantly update and modernize their applications to fix problems and meet present-day needs, often tracking and monitoring code and component changes in a configuration management solution or CMDB.
That’s still useful for catching configuration drift within Java code and IaC (infrastructure as code) that changes from previously approved and released specifications, but it doesn’t actually address architectural drift.
An architectural drift catastrophe recently happened at Southwest Airlines. The budget carrier continued patching their reservations and routing systems for years, rather than rearchitecting and modernizing their integrations with the FAA and other service dependencies. More than 16,000 travelers experienced flight delays and had their plans disrupted over the 2022-2023 holiday season, and the failures could cost them as much as $825 million dollars in lost revenue and refunds.
The best practice of continuous modernization would be to shift-left a layer of architectural observability, so that team members can discover aspects of the application design that are no longer serving their necessary purpose in the application that is currently undergoing build and release cycles.
Without architectural observability, things like low-utility services, redundant classes, intra-service dependencies, and dead code could survive within the application environment without necessarily setting off any alarms in the CMDB.
After all, those problem elements were once specified and approved by some person or process!
Establishing a continuous modernization culture
Corporate architectural review boards inform software design and development projects with their preferences and recommendations, then get out of the way of the coding and integration work.
By this approach, application modernization could be thought of as a one-time event or an episodic update project, rather than a continuous cycle of improvement.
Today’s application architects play roles more like coaches or counselors who seek to bring out the best in development and operations teams. Often they are no longer even titled as architects at all—because they are also builders and maintainers—colocated within DevOps and SRE teams.
Using the free quickstart vFunction Architectural Observability service, teams can get started by discovering technical debt risk, and prioritizing which applications would be most useful to modernize.
Then the new Continuous Modernization solution from vFunction provides the modern software delivery team with a unique capability to shift-left architectural observability and continuously monitor an application estate for changes and telemetry that could indicate emerging architectural issues.
With Continuous Modernization tracking against a baseline set of expectations and visualizing the running services and components within an application suite, development leaders can pinpoint flaws and bring an analytical perspective to maintaining the ‘desired state’ of the architecture, even if it changes over time.
The Intellyx Take
Wouldn’t it be wonderful if we could build applications with a singular architecture that is elegant enough to stand the test of time?
Unfortunately, like our ideal house, changes and usage patterns will inevitably erode our critical application suites, and they’ll fall off a cliff if the ideal state of the architecture isn’t tended along with its day-to-day maintenance.
There is, however, an upside to all of this risk and instability. The presence of architectural drift can also signify an organization that delivers new application functionality at high velocity, in order to become more responsive to changing customer needs.
When continuous modernization goes hand-in-hand with continuous innovation, we’re always living in our desired state of architectural bliss.
©2023 Intellyx LLC. Intellyx is solely responsible for the content of this document, and no AI bots were used in the writing process. At the time of writing, vFunction is an intellyx subscriber. Image sources: Modern house on cliff, craiyon.ai. Screenshot, vFunction.
