Robert C. Martin establishes viscosity as a ‘Symptom of Rotting Design’. Developers who need to make a change to a system can either follow the rules of the software architecture and design or implement a quick hack. If doing the hack is easier than following the design this is a symptom of viscosity. In other words: It is easy to do the wrong thing, but hard to do the right thing.
Anti-viscosity demands that following the architecture is the easiest path. High integrity is not enforced, but suggested.
- There are a multitude of rules, comprising a binding ‘architectural standard’
- Diversity in the solution space is seen as a problem and labeled ‘inconsistency’
- Innovation is driven by a view appointed masterminds
- Communication is oriented towards teams and focuses on how to do things the right way.
- Problems are seen as setbacks and associated with unprofessional behavior or personal mistakes
- Soft standards are in place – consisting of suggestions with associated goals. It is allowed to deviate from suggestions, but the goals are binding
- When developing a solution it is easy to stay within the communicated architectural ideas. Blueprints, templates, libraries and/or central roles support it
- Architectural principles and guiding values are well established and communicated
- Innovation is driven by everybody, constantly challenging the status-quo
Create soft standards and suggestions
Software developers try to solve problems. Complicated software designs or difficult-to-use APIs and frameworks prevent them from doing so. Blueprints of architectural solutions, libraries or ready-to-use artifacts make it easier to focus on the problem, not on the technology. Solutions and technical ideas are not forced onto developers though. Divergence is allowed within basic boundaries. Soft standards are established by making suggestions easy to follow.
Provide organizational support
Often software architecture is defined and documented meticulously and then expected to be followed. Software developers having ad hoc questions are referred to the documentation. Instead the organization needs to install ways to provide support to answer questions around and challenges with the existing architecture. Offering this support can enhance anti-viscosity over time, provided it is easier to follow a supported technology path than to invent a new one.
Install principles and guiding values
Hard rules define exactly what to do in different situations. They usually consist of simple if-then-else decision trees, which makes them easy to define and check. But it also makes them inflexible and rigid. We instead try to install principles and guiding values. They describe how we want to work together and what we try to achieve. The specific solution can then be decided by those doing the work.
Sector Rating Aspects
These are aspects that can be used to assess your performance and maturity in this sector. For a detailed explanation please have a look at our how to page
|Basic architecture principles are available as a blueprint||Late majority|
|Central architecture boards discuss, share and improve architecture proposals||Early majority|
|Architecture proposal creation is incentivized||Early majority|
|Specialists’ support is requested in a pull-approach||Early majority|
|Architecture proposals are used instead of hard architecture governance||Early adopters|
|A few well formulated architecture principles are used to guide decisions (principles vs. rules)||Early adopters|
|Deviations from central proposals are motivated by teams||Early adopters|
|Self-service infrastructure is offered for easy access||Early adopters|
|Software evolution is driven by architectural and quality goals, not rules||Innovators|
|Tested and validated solution proposals are offered to others in an internal marketplace||Innovators|
- Empirical Process Control: Stimulate proposals and an evolutionary creation of your macro architecture.
- Feedback & Transparency: Measure proposal quality to incentivize the implementation and maintenance of proposal-based solutions.
- Responsibility: Install identification with proposals and solutions in order for teams to realize when to not follow the easy standard path.