I 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:
- 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.
- 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.
- 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.