Lengthy design phases for software architecture and systems used to be a required step and sometimes an enterprise prerequisite before engineering teams began developing applications and systems.
Architects would review high-level requirements, consider enterprise standards, and diagram an architecture on the platforms, design patterns, and components to use in the software development process.
Some organisations take architecture planning one step further if new technologies or software components are required. They've established architecture review boards to provide transparency in decision making, highlight architecture risk, align budgets, and examine other considerations that impact sustainable development practices.
Others challenge the effectiveness of architecture review boards because they hinder autonomy, disrupt development flow, and can lead to excessive documentation.
Agile development teams seek autonomy and empowerment to respond to change rather than follow a prescriptive plan; this is one of the key values in the Manifesto for Agile Software Development. But technology leaders seek reusable platforms, development standards, and sustainable operating models for efficiency, quality, and reliability while reducing technical debt.
Balance may be achieved through continuous architecture principles. The Continuous Architecture Manifesto supports the “move from a former waterfall approach where architecture was done mainly before features were implemented to a continuous runway.”
Principles include architecting “long-term products, not just projects solutions,” and “validating the architecture by implementing.” Their principles are suited for teams developing cloud architectures, leveraging devops best practices, and using proofs of concept and agile spikes to validate their solutions.
I reached out to Pierre Pureur, software architect at Continuous Architecture, to get his insights on the manifesto and the practices.
He said, “The Continuous Architecture approach offers a proven path to create and maintain sustainable software architectures in the age of agile, devops, and cloud. It stresses the importance of essential activities, including focusing on quality attribute requirements, driving architectural decisions, knowing your technical debt, and implementing feedback loops.”
Automate dev and test environment creation
A first place to start with continuous architecture may be in fundamental devops practices such as automating infrastructure as code (IaC) to spin up development and test environments. Automation helps lock in standard configurations and patterns sought after by architects and provides the agility required by development teams.
Amir Rozenberg, vice president of product management at Quali, agrees and states, “Organisations delivering applications are dependent on and should have easy access to reliable, readily available, compliant environments to power their continuous software delivery pipelines.”
Rozenberg suggests that architects partner with devops teams to create cloud infrastructure blueprints. He says, “Devops teams should model environment blueprints to provide the proper cloud infrastructure for their business constituents, such as development teams, product managers, testers, and pre-sales in a self-service manner that eliminates protracted wait times.”
Tim Lucas, founder and co-CEO of Buildkite, agrees. “A continuous architecture, both technical and cultural, requires commitment from the development team and the business,” he says.
One key principle he suggests is “creating a dedicated role that focuses on and is accountable for developer experience.“ You can address developer experience by making it easier for development teams to self-serve the environments and deployment pipelines needed to dev and test their code.
Consider customer and user needs when defining production architectures
While devops teams seek productivity through automation, business leaders, including product managers, data scientists, and compliance officers, also seek architecture agility in production environments. That often means scaling up and down production environments due to user demand. Sometimes it means spinning up multiple environments based on compliance requirements.
Lucas adds a key design principle for production environments and suggests “investing in failure reduction because for something to be continuous, interruptions need to be reduced.”
For data scientists, integration and deployments often have different requirements than what’s common for software development teams. Michael Berthold, cofounder and CEO at KNIME, says, “The data science production process built during integration is different from what the data science team created, and monitoring in production may result in automatic updating and redeployment.”
Usage and infrastructure monitoring can trigger scaling up and down environments, but modelops monitoring may also trigger a configuration change or a redeployment. Berthold says that for data science and machine learning pipelines, “The deployment cycle may be triggered automatically by the monitoring process that checks the data science process in production, and only a grave change forces a restart of the entire process.”
Architecture must focus on future possibilities
Business leaders often focus on near-term opportunities, and devops teams make their best attempts to develop modular and extendable software components. Some best practices to support a continuous architecture include:
- Developing with cloud-native and serverless architectures
- Standardising deployment pipelines
- Supporting continuous testing practices
- Building microservices and supporting the API life cycle
- Leveraging low-code solutions where platforms simplify and help avoid customised solutions
Vince Padua, executive VP and chief innovation and technology officer at Axway, focuses on open architectures and says, “B-to-B integration and collaboration will accelerate its digital transformation built on the backs of APIs and the cloud. Because cloud-native and API-first approaches have matured to an open-everything architecture, the time and cost to innovation through partnerships and collaboration has significantly decreased.”
Many businesses are now investing in custom software for customer experiences, integrations, and digitised workflows and must consider best practices to future-proof their investments.
Padua suggests, “As the enterprise surface area is API-centric, more innovation is unlocked by unbundling and re-bundling offerings and supply chains across industries and verticals. There are significant investments and start-up growth opportunities in B-to-B offerings for travel, logistics, warehousing, manufacturing, lending, insurance, and boutique retail.”
Practicing continuous architecture requires balancing what the business needs today and what devops teams require to be productive while also having a vision of how the organisation can support future changes, extensions, and new requirements.
Part of the realisation is that the team working on today’s implementation will likely change over time, so architects seek building-block solutions that are easy to learn, allow new team members to make code changes without fear, and have sufficient test coverage to validate changes.
Continuous architecture recognises the need for developing with reusable patterns but acknowledges that creating a perfect blueprint is unrealistic given how fast business needs change and technologies evolve.