That’s a key takeaway of a discussion that took place at the recent GOTO 2022 conference between Pierre Pureur, co-author of Continuous Architecture in Practice, and Kurt Bittner, head of enterprise solutions at Scrum.org. Designing and sustaining a well-functioning continuous software architecture requires, above all, patience, Pureur urged. For years, designing a software architecture meant designing something up front, then moving into the deployment stage. Under the traditional notion of architecture, “We don’t write a line of code until all the architecture is nailed down,” Pureur said. “The problem with that approach is, of course, it’s very hard to know everything at once. Designing an architecture when more than half your requirements are incorrect is not going to give you good results. It’s tough to predict how a system is going to evolve.” Also: Enterprise architects take charge of the digital revolution More agile approaches have evolved, making the process more iterative. Still, this assumes that, “You write code, and somehow the architecture, like a whale out of the water, kind of emerges.” But that leads to needing “a lot of refactoring and adjustment.” Agile development is a step in the right direction, but for a continuous architecture, software designers and developers need to take it a step 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 need to be involved with the design process? Also: Coding skills are in demand, but companies want more from tech professionals Six principles underpin a 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:
Build products rather than projects. Focus on quality attributes and don’t worry too much about functional requirements. Delay decisions until you’re sure that 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, nice diagrams, and so on,” Pureur said. “Yes, you have to have those things which you have to communicate as part of the architecture. As you make decisions continuously, 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’re going to go back and revisit your decisions continuously.”
