Lately, the term “continuous” has appeared at the top of vendors’ and experts’ lists as the software architecture we all should and want to have. The problem is that many assume that “continuous” means fast software delivery. Instead, designing a continuous software architecture requires constant feedback from everyone involved in the process – architects, designers, developers, operations – and constant improvement. Software architecture can no longer be a single process.
This is a key takeaway from a discussion which took place during the recent GOTO 2022 conference between Purity Stoneco-author of Continuous architecture in practiceand Kurt BittnerHead of Enterprise Solutions at Scrum.org.
Designing and maintaining a well-functioning continuous software architecture requires patience above all else, Pureur urged.
Rushing into a technology solution before asking the right questions means missing out on features or functions that may be vital to the business, he continued. “I’ve seen teams that start with the end in mind, and they know they want to bring technology. Someone said to them, ‘We have to be on Amazon’s cloud.’ The answer is going to be the Amazon cloud, and you’re not even asking that question, are you?”
For years, designing a software architecture meant designing something up front and then moving to the deployment phase. According to the traditional notion of architecture, “we don’t write a line of code until the whole architecture is nailed down,” Pureur said.
“The problem with this approach is, of course, that it is very difficult to know everything at once. Designing an architecture when more than half of your requirements are incorrect will not give you good results. It is difficult to predict how a system will evolve.”
Also: Enterprise architects support the digital revolution
More agile approaches have evolved, making the process more iterative. Still, it assumes that “you write code, and somehow architecture, like a whale out of water, somehow emerges.” But that leads to requiring “a lot of refactoring and tweaking”.
Agile development is a step in the right direction, but for continuous architecture, software designers and developers need to go further.
They need to ask the hard questions: what does the business need? What works best with users or customers? What parts of the business should be involved in the design process?
Also: Coding skills are in demand, but companies expect more from tech professionals
Six principles underpin successful continuous architecture, Pureur explained. “None of the principles are new or earth-shattering, but together they make a lot of sense.” These principles are:
- Create products rather than projects.
- Focus on quality attributes and don’t worry too much about functional requirements.
- Delay decisions until you are sure you have to make the decision.
- Plan for change because things will change – so think “small design”.
- Remember that testing to deploy a system is almost more important than building the system.
- Organize your team with people who deal with all aspects of the system.
“People think of architecture as blueprints, beautiful diagrams, etc.,” Pureur said. “Yes, you have to have these things that you have to communicate as part of the architecture. As you make decisions, you’re going to learn, you’re going to have this continuous loop of learning, and you’re going to learn from your mistakes. You will go back and review your decisions constantly.”