Agile alertness: 6 principles to help your software design process succeed

Lately, the term “continuous” has popped to the top of vendors’ and pundits’ lists as the software architecture we all should and want to have. The problem is that many assume “continuous” means rapid delivery of software. Instead, designing a continuous software architecture calls for constant feedback from all involved in the process — architects, designers, developers, operations — and constant improvement. Software architecture can no longer be a once-and-done process.

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.

Rushing into a technology solution before asking the right questions means missing 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 in some technology. Someone told them, ‘We need to be on the Amazon cloud.’ The answer is going to be Amazon cloud, and you don’t even ask that question, right?”

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.”