Your Software Architecture May Be Failing You

Vision, interrupted

Some number of years ago you discovered a gap in the market. An opportunity to solve somebody else’s business problems effectively with a simple software system. You built that software system and everything started to work. Cash flow problems yielded to recurring revenue; sales increased automatically; you took your first vacation in years.

But recently things stopped flowing.

You may have noticed:

You can’t seem to hire or keep the right engineering talent.

You can’t deliver features and fixes fast enough to meet your customers’ needs.

You can’t get new customers up and running quickly or smoothly.

Growth is being held up and with it your vision of gaining enough traction to attract investor interest or a buyout is being held up too.

What’s most confusing is that the symptoms seem unrelated. But you might be surprised to discover there’s a single, likely cause.

Two Core Aspects of Your Software

Software is 1) behavior and 2) architecture.

Behavior describes what the system does. Macrobehavior is a rollup of all the functionality. For example: a software suite that helps you manage ISO compliance.

Microbehavior describes individual features or feature sets. For example: audit management, or feedback management.

Architecture refers to the structure of a software system. It dictates how the different functional elements (microbehaviors) will relate. Good architecture considers the planned behavior of the system, but also the underlying business goals, such as scalability.

A common analogy for software architecture is building architecture, in that both provide the blueprint for how something will be built.

The parallels between construction and software development can be helpful for simplifying concepts. But where building architecture seeks to create solid, lasting structures, software architecture is meant to be malleable, to allow for the possibility of change after initial construction.

The goal of software architecture is to minimize the human resources required to build and maintain the system.

We Favor Behavior

Most software engineers aren’t trained in architecture, and because of this most engineers focus only on the behavioral aspects of software.

But another reason engineers tend to favor behavior over architecture is because it’s demonstrable. Shipping a feature that stakeholders can see and use (and doing this quickly and often) is the most measured and most highly rewarded developer activity.

Here is where problems begin and quite possibly here is where you, the business driver, may be complicit.

With success, the mandate often turns to delivering more and more features more and more quickly. So developers do this by ignoring the very architectural principles that make it easy to maintain or change the system in the future, because proper planning takes time they don’t (believe they) have.

The Signs of System Degradation

Without advanced programming expertise or experience architecting software, it’s difficult to look at code or system behavior and determine the quality of the system architecture.

Instead, quality reveals itself over time.

If your system has been poorly architected or poorly maintained (or both), it’s likely that “cracks in the foundation” are beginning to show.

Practically speaking you might be noticing:

• Bug outputs or regression issues are increasing with each release
• The level of effort required to implement new features is also increasing
• Your cost per line of code is at an all time high

From a business value perspective these issues are likely expressing themselves as:

• Existing customers are frustrated or even switching to competitor solutions
• New customers can’t get onboarded quickly or smoothly
• Prospective customers want features you don’t have
• You’ve lost pride in your own product

How to Get Back on Track

Whether your system is (or once was) well architected or whether architecture was never properly considered, it’s actually maintenance or lack of maintenance over time that’s led you to sleepless nights and fear of the whole ecosystem crashing down.

Typically it starts by ignoring maintenance within a single sprint (a weekly or bi-weekly concentration of development activity where no changes or new items are allowed to be introduced) and the intention to refactor (i.e. make up for it) in the next sprint or the next release.

But then the next sprint fills up with other priorities and soon the technical debt has piled up well beyond the point of being able to refactor the code in a timely manner.

Eventually you’re left with replatforming as your only choice. The high cost of replatforming correlates exactly to underinvestment in maintenance through the years.

So your best bet for stability is to invest ongoing in maintenance. But if you’re past this point, it’s still possible to develop a plan for getting back on track.

Building a Technical Roadmap

A Technical Roadmap is the path from where your software is today to the software you want. More importantly, it’s a path to stabilizing and scaling your product business.

Your Technical Roadmap can be a companion to implementing a new system architecture safely or a standalone plan for addressing core problems.

The benefits of a good plan include:

• Minimize bug outputs and regression issues
• Faster rollout of new features
• Safer to / able to migrate to new technologies (libraries, servers, etc)
• Hire and retain specialized developers more easily
• Convert and onboard new customers faster

If you have an in-house CTO or Technical Lead, talk to them today about building an actionable technical roadmap for your product.

You can also read more here about how technical roadmapping has helped other organizations claw back technical debt, attract new customers, and quadruple their valuation.

Should Your CTO Know Better?

If you have a CTO or Technical Lead on staff, you might be wondering why they haven’t flagged failing architecture as the underlying cause of your operational and sales problems, as I’m suggesting here.

There’s a lot of reasons for why this might be, and most of them are not malevolent.

For starters, if your in-house technical expert has been with your company for a long time or was closely involved in the build process, it’s probable they are too close to the solution to be objective.

It’s also possible that they cannot as easily correlate slowing sales with technical debt. Put another way, they hear you expressing business problems but they’re too busy with “their own” problems, like being able to find or retain quality engineers who want to work on the software.

In some organizations, the CTO is less an appointed executive or leader, but rather a loyal employee who “grew up” in the organization over the years (from developer to developer manager, etc). It’s common among CTO “graduates” to feel less confident in pushing back on business leaders in critical conditions such as these, and even more common when the business leader is putting constant pressure on the engineers to deliver more and more features.

For this reason it can be beneficial to engage an outside audit or enlist outside help building your technical roadmap.

Bottom Line

The purpose of software is to stay soft. You want to be able to adapt to changes in the market and deploy those changes quickly and cost-effectively. This is the benefit of having and maintaining good system architecture.