3 Simple Tips to Maintaining a Rock-Solid Software Architecture


CAST-Software-architecture-status-checkI have some good news and I have some bad news. First, the good news: Most smart development teams invest a lot of time designing a rock-solid architecture before the first line of code is even written for a new application. Now, the bad news: Once the architecture is designed, the conversation about it often ends. It’s built and then forgotten while the team runs off and builds the app, or when the application is transferred to a new development team.

Thoughtfully designed architectures with solid design principles might begin to degrade almost the instant they are implemented. How can a team maintain a proper architecture, iteration after iteration? There’s really only one way and that is to implement an “architecture status check” after each new component is built and integrated.

Here are three best practices I’ve seen in play at mature shops that perform a regular architecture status check. In the end, these steps ensure a resilient architecture:

  1. Check your architecture at the speed of your development cycle. IT leaders in large organizations must be certain that the software architectural design is being implemented and adhered to. But in an era when more developers are deploying and coding faster than ever, one architectural review per quarter is not going cut it. Architectural reviews need to happen at the speed of your development teams’ deployment.
  2. Don’t assume the architecture is stable. It's important that the architecture stay stable for development teams who deploy new builds quickly to meet design deadlines. They’re focusing on the coding of the new application or updates. But here’s the problem: They’re assuming that if the architecture is deployed, it must be stable. Again, if we agree that application architectures start to degrade as soon as they’re deployed, that is a flawed assumption. Define architectural guidelines at the beginning of your project, and then do consistent checks with each new iteration of your application to ensure they’re being upheld.
  3. Use feedback loops. One easy way to set up these checks is to implement a quick feedback loop at the end of each development phase about the last changes made to determine if the code is compliant with the architecture. If not, insert a remediation string. Some architecture violations will require immediate remediation because they might impact the application security or performance. Other ones can be integrated in a future dedicated sprint if you’re using agile methodology, or in another development phase. This way, your team can forget about code review and have a checker that will warn them if they go beyond a barrier.

At the end of the day, maintaining application architectures is about measurement and communication. It’s not like you have to set it up with a Twitter account to tweet the architecture’s status every 15 minutes. But architectural compliance should certainly be examined at crucial development phases and before new upgrades.

When it comes to architectural designs, “set it and forget it” is a recipe for disaster -- one that can and should be avoided. Why design the architecture in the first place if the team is not required to work within the design’s framework? Implementing a best practice of goals and checks can ensure that a properly built architecture will stay that way iteration after iteration.

Now I hear some of you groaning that checking the architecture can be a time-consuming and painstaking process. But that’s not true. At least, not since CAST released its Architecture Checker. There’s a reason why I’m so passionate about checking architecture status. It’s because I spend most of my day dealing with the issues that an unchecked software architecture causes for development teams. I encourage you to try our Architecture Checker, and if you have any questions, feel free to email me.


  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Razak Ellafi
Razak Ellafi Senior Product Manager
Razak Ellafi is a former Senior Product Manager at CAST and is passionate about leveraging Software Intelligence products to reduce software risk. During his tenure, Razak successfully launched several innovative IT governance products aimed at exposing software vulnerabilities.
Load more reviews
Thank you for the review! Your review must be approved first
New code

You've already submitted a review for this item