Business Leaders: How Do You Know If Your Enterprise Has Accidental Architecture?

By Mike Pleimann and Garey Hoffman

A well-known website crashed a few weeks ago, and it made the news. We won’t disclose the company name, but it’s a very popular site and that crash affected millions of people. Fortunately, due to the heroic efforts of the support teams, it was operational after about 12 hours. Unfortunately, it lost a mountain of revenue.

We know the cause and the extent of how deeply this problem is entrenched within this organization. And, we have seen how organizations like this arrive at a place where they see symptoms like this system crash. It was likely a result of years of “architecture by accident.” In our observation, this architectural anti-pattern is common in organizations of all sizes, from small startups to large enterprises. Most experienced technologists understand that a system’s architecture is created on a set of goals, trade-offs, team structure, and the constraints under which it was built and is maintained. Without a deliberate architectural strategy, atmospheric pressures result in Accidental Architecture.

Agile Methodology Over Time

Failure to plan system architecture — and neglecting the execution of those plans — plays a substantial role in the growth of accidental architecture. While Agile methodology encourages adaptability, collaboration, and continuous improvement — which are excellent means of responding to change — this philosophy isn’t meant to replace real architectural planning.

The natural tendency of systems to become more disordered and complex over time advances more quickly in software than in physical systems. This advantage of software systems in allowing more flexibility also allows more chaos and unpredictable system future states. Think of this as gaining one pound a year, and in 10 years you realize you’re no longer able to fit into your favorite jeans. This is the impact of accidental architecture: critical systems can become unstable and difficult to maintain in a way that goes unnoticed for years.

Recognizing the Symptoms

Major system crashes that impact millions of users aren’t the only symptom of accidental architecture. Below is a list of symptoms. You may recognize signs of your own business and architecture listed here:

1. Perpetual First Aid
   The organization must constantly pay for the rising costs of non-stop bug fixes, customer churn from software defects, and cyberattacks.
2. Hero Technical Team
   The technical team must routinely rise up to handle frequent (and risky) incredible technical challenges just to sustain normal business operations.
3. Innovation Gridlock
   Implementing new business features takes longer than the market will bear and brings new, unexpected system failures upon release — resulting in more reputational damage.
4. Application Monster
   The application user interface is unnecessarily complicated or just doesn’t make sense to users. New users are frequently overwhelmed, lost, or confused. Typical symptoms can include randomly logging out users, data inconsistencies in different parts of the system, difficult navigation in commonly used areas, time-consuming training, and user circumvention of the system to do their jobs a different way.
5. Molehills into Mountains
   Technical changes or system updates that should be straightforward are monumentally complex. Also, the risk of failing is so high that making changes is actively avoided or simply not approved by leadership.
6. Vendors Threaten to Not Support Key Dependencies (or Worse, They Do Support It!)
   Third-party tools, libraries, services, or service providers threaten to end support for dependencies. Or, they charge huge premiums to continue to support obsolete versions. Or, they simply stop offering support at any price.

These technical symptoms are frequent root causes of the painful business symptoms above:

1. Big Ball of Mud
   A modification in one area of the system requires substantial change in one (or more) additional areas of the application. Relationships between system areas are not well understood.
2. God Objects
   Software code (especially classes or services) that tries to do too much — or must do too much — just to make the application function. Or, there are attempts to make code “reusable” in multiple parts of the overall system.
3. Circular dependencies
   The system consists of chains of components depending on each other in a circular and sometimes non-trivial fashion (A ➞ B ➞ C ➞ A).
4. Code Duplication
   A severe example of Code Duplication occurs when functions (or classes) are duplicated, modified slightly, and then re-inserted into the application. Generally, the reason this occurs is due to a poor understanding of how a modification to the original code would impact existing use cases (e.g. no regression testing is available).
5. Scary Migrations
   Migrating to a new version of system dependencies takes years and brings inordinate risk. A common example is moving to a new database version that is several revisions ahead of the current installation.
6. Cockroach Defects
   There are bugs that were supposed to be fixed that reappear. They are seemingly impossible to eliminate. This is typically caused by automated tests that are ignored or skipped, dramatically increasing the risk of system rollbacks after deployment.
7. Software Bloat
   Each release of the system demands ever-increasing resource allocation (memory, processing, storage, etc.) driving up the cost of operations. Related symptoms include: reducing overall system performance, increasing system resource requirements, or increasing deployment time.

If these symptoms sound familiar to you, it’s likely your organization faces the challenges of Accidental Architecture. There is hope. The next article in the series will serve as a guide for business and technology leaders to restructure their architecture practices and refine their approach to achieving Intentional Architecture.

Be sure to follow and subscribe to be notified of the next installment. Please visit Object Computing’s website to learn more about our services.

Mike Pleimann has 15 years of experience as an Application Architect and almost 25 years in software engineering. Currently leading the Application Architecture team, he combines technical proficiency with managerial skills to guide teams toward success in large-scale software architecture and engineering programs. As a seasoned leader in the field, he brings a wealth of knowledge and strategic vision to his projects in the telecom, collections, defense, and gaming industries. He is dedicated to crafting robust, scalable solutions that are fit for purpose and has consistently earned accolades from clients and peers. Mike holds a BS in Computer Science from Missouri S&T.

Garey Hoffman is a Partner and Vice President of Engineering of Object Computing. Hoffman plays a pivotal role in overseeing and driving the technical aspects of the organization. He is involved in managing a team of skilled engineers, architects, and technical professionals to deliver quality solutions and services to clients. He is also responsible for aligning technical strategies with business objectives, ensuring the successful execution of projects, and maintaining a strong focus on innovation and emerging technologies.