Architecture is a business asset

Architecture is a business asset that deserves explicit investment and care to generate long term benefits. Let me explain.

Software architecture is as important as functionality, at least in the long run. Sounds reasonable. I asked more than 1000 technical people in the last year if they agree with this statement, and they overwhelmingly do so. But, what does this actually mean?

As the functionality of a system is recognized as a business asset, it follows that architecture of that system is a business asset as well. And they both should be approached with the same rigor.

Functionality receives significant investments in testing. Developers produce automated tests that complement the production code, while dedicated testers take care of strategic and exploratory testing. In a way, testing is like an insurance, but unlike other insurances, this one is essentially guaranteed to pay off later on. Automatic testing pays off not because people are careless, but because the system entails way more details than can fit in someone’s brain. Not everything is done automatically though. There is room for manual work of a human, too. For example, exploratory testing. We want to explore ways to break the system, and that require creativity. But, once we know how to break the system we want to delegate the regression testing to the machine. That’s because humans are notoriously ill equipped for handling regression testing.

Now, do you invest in testing architecture automatically? Most teams do not do that. That means that half of the business assets remain uninsured. Half.

Yes, we have pair programming and reviews, but those rely on code reading. This is manual work, and manual work is not appropriate for regression testing. Reviews are proper tools for exploratory purposes, but they should not be used for regression testing. In fact, developers spend some half of their time reading code. How do I know this? Several scientific articles mention it. Furthermore, I literally asked more than 1000 technical people over the past year if they agree with the statement. And they do.

So, yes, developers do spend some half of their time reading code. This means half of the budget. At the same time, developers do not talk about how they read code. In essence it means that half of the budget is being spent on something nobody ever talks about. Half.

How can you test architecture automatically? You need to first look at the code and see data. The same applies for configurations, logs and everything else around a software system. It’s all data, and data is best dealt with through tools.

Let’s consider an example. Let’s say you work on splitting a monolithic application and in this process you notice that component A relies directly on the implementation of component B, instead of only its interface. This is not a visible problem when both components reside in the same deployment, but it is an impediment for deploying them as separate services. Let’s devise a test to expose the problem.

componentA := model allNamespaces named: 'com.example.a'.
componentBImplementation := model allNamespaces 
                            named: 'com.example.b.implementation'.
classesInAThatRelyOnBImplementation := componentA allClasses 
  select: [ :each |
    each queryAllOutgoingAssociations atNamespaceScope 
      includes: componentB].

If the result of this query is not empty we have wrong dependencies. Furthermore, the concrete list gives us the places that we should work through.

This is a test. Only it is not a functional test. It is a structural one. If the architecture of the system is as important as functionality we should be in position to test it just like we can test functionality.

This particular test might look like a pseudocode, but it actually is an executable piece of code in the Moose analysis platform. This is a platform that focuses on enabling engineers to create custom analyses inexpensively. This in turn, makes humane assessment practical. Humane assessment is a method for making engineering decisions through the lenses of custom tools.

In our example, we created a custom test that can be made part of the continuous integration process and can guard what is important for our system. Testing is important, but this is not all you can do once you look at code as data. In our case, we knew what we were looking for. But, how should we address the problem of finding out what we are looking for?

Let’s consider the example of splitting a large component into smaller cohesive ones. One possible way to approach such a task is to cluster the methods inside the component by the way they are being used by external code. This is an option, but it is not always the only one. So, how do we check whether this route is possible? We can use a visualization. In our case, we depict the component methods in gray and the external entities in red. The internal calls are represented with gray edges, while the calls coming from external components are represented through red edges.

We can easily notice a strong clustering around the red nodes suggesting that indeed, we can split the apparently monolithic component along usages lines. This is a custom picture that essentially makes sense for the current problem. How much does it cost? In the case of Moose, it can costs as little as a few lines of code. Please note the missing scrollbar for the script in the screenshot below. In fact, this was a real analysis done for a real architectural decision, and most of the script deals with preparing the data to focus the picture only on the relevant parts.

These examples offer a peak of what is possible in terms of exposing high level contracts from the real system. This can improve significantly how an individual can understand a complicated system. At the same time, it also lends new tools for the team to reason collectively about a system, too.

Architecture is a business asset and, as such, it deserves appropriate attention. We already spend a significant budget on figuring the system out. It is time we spent this budget effectively.

The humane assessment method offers a structured way to approach this problem. And soon you will get the chance of experiencing it first hand in the upcoming course organized by Co-Learning during January 26-27.