I’ve got a concern, and I want to share it. You might or might not even care about it, that’s fine. You have your concerns and I have mine. Yet, we are able to interact with greater wholes while remaining decoupled. That’s how software architecture should manifest: with clear and unambiguous separations of concern. To build a robust, scalable, and agile architecture, “you gotta keep ‘em separated”.¹
We all know that in real life, the pressures of money, time, and scale all drive compromise that result in that hated but oft-used term, technical debt. Unfortunately the type of compromise that is usually made results in the blurring and even gross cross-contamination of architectural concerns, platform, and application layers. This results in an inability to extend, scale, and even maintain the system, a result that nobody wants.
A result that has left the world with a host of systems in various states of decay. That’s the bad news. The good news is that there is a cure for both the existing systems and a pragmatic preventative for new systems being born.
For existing systems, we here at Ten Mile Square have written much already (and likely more) on how to cure technical debt. In this post, I’m going to focus on prevention that you can actually implement in the real world.
Here’s a high-level recipe that will help you steer clear of painful conversations and sunk cost decisions down the road:
- Understand up front what the business architecture is. What types of problems are you trying to solve with the application of technology? How is this likely to evolve over time? Yes, this is likely to be subject to cross-winds and even outright changes in direction in fast-paced new product development, that bit of info, in fact, is one of your critical inputs by which to be informed.
- Clearly delineate what you think the architectural concerns needed by your system will be. Some will be obvious, some will need to be teased out. Need an immutable audit capability? That is a discreet concern from say, logging or authorization. Need a bi-temporal information capability for regulatory requirements? This one would be critical to know up-front.
- When you make a technical compromise to meet external demands, make that compromise within a concern and, if you can, isolate it. Put it behind an interface (or the equivalent of your development platform), use modern language constructs and patterns, such as lambda, closures, etc.
- Communicate the compromise and get buy-in. Make sure your team and stakeholders know about and understand the compromise, especially the tradeoff and long-term impacts. It may be you can prevent it at this juncture as your stakeholder may decide the extra cost associated with no compromise is worth it. (Not all stakeholders are nearsighted).
- Document the compromise. Do it in the code, and do it in the work request completion (i.e.: issue if you’re using Jira). If you have it ready, include information about the idealized implementation if there had been time, money, etc.
There is another aspect of this that is a more cross-cutting ingredient: if you see something, say something. If you see your fellow product collaborators unconsciously making decisions that lead to fuzzy system architecture, speak up and clearly identify the issue. Even better, if you have a better solution, propose it.
Working on solving technical debt or building out a new or next-gen architecture and need to get it right? Drop us a line at Ten Mile Square, we’ve got a decade of successful software architectures behind us and more on the way. We’ve helped some of the biggest brands you know modernize their software architectures. Brands you are now getting to know were architected from the ground up with our help. When you need to get it right the first time, call Ten Mile Square.
¹ from Come Out and Play, written by Bryan Holland, performed by The Offspring