Forbes Magazine famously wrote that “Every Company is a Software Company.” Your company must become more responsive and agile using software and technology. And if the software doesn’t work or gives customers a bad experience, it can lead to lost revenue. This has led to the DevOps phenomenon, which is speeding up deployment of software and, consequently, the speed of software development.
Because the speed of software development is getting so fast it is imperative to manage and improve your software architecture to keep up with the speed of development. So the issue becomes how to make sure the architecture doesn’t erode over time. Or to put it another way: how can I freely make changes to architecture over time? These are common questions for software architects. Neil Ford, software architect at ThoughtWorks, states:
“You can build architectures that evolve, it doesn’t take a Herculean amount of effort. In fact, you can incrementally start applying these ideas [continuous architectural testing] to your existing architecture.”
Using DevOps to continuously test software architecture
The increasing usage of DevOps/Continuous Delivery pipelines makes it easier to improve (or evolve) your software architecture. You can test the architecture regularly every time you make changes to the code. This eliminates the worry about architectural erosion in your software.
In a DevOps pipeline, you need design rules, metrics, and tests (like Netflix chaos monkey) that continuously monitor the health of the software architecture. As Neil Ford said above, you build and use these mechanisms over time and then run them on a continual basis as you make changes to the architecture. You know immediately if your architecture is degrading (i.e. losing important architectural characteristics like scalability, security, and performance). You can fix it now instead of finding out in six months to a year when it may be too late. This safeguards your architecture and creates a protective layer around your software as it evolves.
By running the pipeline all the time, developers know if their particular architecture is doing what it is supposed to be doing. This forces every developer to think about architectural characteristics like scalability, security, and performance. If they don’t, the DevOps pipeline will immediately flag their software as a problem. DevOps architectural testing allows you to set architectural guidelines requiring that developers write code to the original architectural specification or it is not going to make it through the pipeline.
One of the architectural trends that helps with this is microservices. A microservices architecture facilitates smaller iterative changes to the architecture because of its smaller iterative deployment.
To improve the speed of deployment and get an architecture ready for DevOps, you should improve and increase the modularity of your existing software. This will allow you to break big chunks of software into smaller chunks. To do that, you need to have a clear picture of the component and modular relationships inside your codebase. This will allow you to improve the modularity of your software system. Visualization tools like Lattix Architect show you how coupled software components are to one another. This indicates how modular your system is and how easy it will be to split into smaller services.
You can also see how cohesive the application is. Many times applications degrade to low-cohesion and become a big ball of mud with no discernable architecture structure at all. Tightly coupled modules have been shown to lead to longer release cycles. Software should be designed for testing and deployability, which means architecting the software so it is loosely-coupled and well-encapsulated.
Architects typically worry about architectural characteristics like scalability, security, and performance. In the DevOps/Continuous Delivery world, these worries can be handled by verifying that the characteristics are not eroding over time. Continuously testing your architecture in a DevOps pipeline might seem like a huge effort but it can be done in an incremental fashion. This will allow you to stop architectural erosion. You will be able to pivot when the business needs you to make changes to the architecture without having to engage in a huge refactoring effort.
If you are interested in learning more about Lattix Architect or seeing a demonstration, click here.