3 Ways Enterprise Architects Can Bridge the Socio-Technical Gap

3 Ways Enterprise Architects Can Bridge the Socio-Technical Gap

3 minutes

Written by:

Dennis BijlsmaLodewijk Bergmans

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.

Address Architecture in an Incremental Fashion.

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:

  • Address the coupling between architecture components. 
    • There is a large body of (architecture) design patterns that can be applied to reduce various forms of coupling.
  • Improve communication centralization
    • This requires especially a disciplined approach to group or reduce outgoing calls, as well as a focus on developing APIs that are cleanly separated from the implementation of the component.
  • Reduce the size of the system
    • By cleaning up ‘dead’ or unused code, reducing the scope, improving code reuse within the system or by adopting more standard (library) solutions. 

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.