Request your demo of the Sigrid® | Software Assurance Platform:
Architects are responsible for creating a set of governing principles that drive an ongoing discussion about business strategy and how it can be expressed through IT. But often, communication problems arise between architects, development teams, and management.
Since the early 2000s, Software Improvement Group’s (SIG) certified software analysis laboratory has analyzed over 12,000 enterprise software systems totaling over 100 billion lines of code. Based on this experience, SIG launched a novel Architectural Quality Model to quantify the aspects of socio-technical software architecture. In this blog post, we will explore three incremental modernization principles that enterprise architects can use to improve collaboration and continuous architectural improvement within their organization.
Addressing technical debt at code level is often done using small, incremental refactorings. Such an approach leads to lower risk, as the scope of changes is smaller. In many organizations, architecture changes do not follow this agile approach and tend to be structured into “projects” where large changes are made over a period of time.
Incremental architecture modernization removes some of the risks associated with architecture changes: small, incremental changes have a smaller scope and, therefore, lead to less stability risk. Moreover, it avoids a situation where architecture modernization is directly competing with functional changes.
Changing the architecture in an incremental way often seems unfeasible. And indeed, you will not be able to solve the problem of thousands of unwanted dependencies between two systems in a single sprint or iteration. But you can divide the overall goal into smaller parts: for example: first investigate dependencies between subcomponents and strive to change those within a sprint.
The system properties in the SIG Architecture Quality Model map directly to architecture modernization techniques that can be applied in this way:
To ensure these architecture improvements remain a point of attention, these aspects also need to be incorporated into the definition of done for each sprint. This allows for architecture to remain a topic of continuous consideration, to avoid architectural decay over time. Defining explicit goals, for example, using Sigrid’s objectives dashboard helps to track incremental progress while keeping the eventual long-term goal in view.
An evolving architecture means it is not possible to fully define the architecture up front. Nor is this desirable. Having independent systems and components should facilitate the teams working on them to adapt those systems and components, without the need for a central decision authority to approve every single change. Teams should be able to guide their own architecture as long as they follow the general direction laid out by the organization’s architecture principles.
These architecture principles should help guide teams in decision-making without dictating or micro-managing every single aspect. For example, defining a list of which services are allowed to communicate with each other easily becomes unworkable. In a landscape with hundreds or even thousands of services, this list will quickly become extremely long. Moreover, the list will keep changing as the landscape is continuously evolving. Having to approve every modification to the list quickly becomes a bottleneck, especially when the person needing to approve the change is not a member of the team.
It is, therefore, better to define general guidelines and principles and then let the teams decide how to achieve them. As an example, communication between services could be allowed assuming they only access each other via REST APIs. Obviously, some sort of feedback loop is still needed to make sure the principles are actually applied in practice. This is where SIG’s architecture quality model can help: low ratings can indicate that a principle is not followed, or that a new principle needs to be defined.
Software architecture is often a series of trade-offs. However, for people not involved in the original decision, it is often no longer clear what the trade-off was or how that trade-off led to the decision.
One approach to capturing these decisions is Architecture Decision Records (ADRs). Note that ADRs are not some kind of technical rule, they are essentially a document. But having such a document can be a useful communication device, as it creates a history that allows people to keep track of trade-offs made in the past. The code and architecture themselves can only communicate the current state, but not how that current state came to be.
Note that recording decisions doesn’t make them permanent or immutable. It is still perfectly fine to revisit architecture decisions, especially during changing circumstances. In fact, having an Architecture Decision Record makes it easier to revisit decisions, since there is a clear overview of which decisions were made and why.
Effective collaboration requires a strategic, principle-based approach where architects define flexible guidelines that steer teams without stifling innovation. Capturing the rationale behind architectural decisions through methods like Architecture Decision Records ensures a clear understanding of trade-offs made over time. Additionally, addressing architecture incrementally, akin to code-level refinements, offers a practical way to manage risk and avoid conflicting priorities. SIG’s Architectural Quality Model can serve as a valuable tool, aligning system properties with specific modernization techniques. By integrating these principles, organizations can cultivate a culture of continuous architectural improvement, preserving system integrity and agility for the long haul.
To learn more about how enterprise architects utilize Sigrid to improve architecture quality, go to: www.softwareimprovementgroup.com/enterprise-architect/
Author:
Head of Product
Author:
Senior Researcher at Software Improvement Group
We'll keep you posted on the latest news, events, and publications.
