One role of the Architect is is help the Team get features out the door, better, faster, and cheaper. Another role is the work to improve the Enterprise Asset.

I first came across the concept of the Enterprise Asset while reading “A Seat at the Table” by Mark Schwartz. The idea is that our IT infrastructure is pretty much the embodiment of how work gets done in an organization. “When we add all of our current IT capabilities together, we arrive at an asset that enables the enterprise to earn future revenues and reduce future costs — that is, an asset in the classic economic sense. … The asset does not appear on the company’s balance sheet. … Much of its value is hidden; its ability to support Agility, for example. But it is an economic asset nonetheless. “

While the Enterprise Asset is made up of our components, our products, our solutions (whatever it is we deploy) the real value is when you consider all these items together holistically as this is where you will be able to, for example, make trade-off decisions between competing investments. Architects apply lean and agile values and principles to support the long term viability of the Enterprise Asset.

The traditional Architecture approach is to provide guidelines and guardrails, documentation, that Teams are expected to follow. Often this does not work out. To help address, Lean and agile suggests Architects collaborate directly with the Team. By having the notion of an “Enterprise Asset” we can frame what form that collaboration should take.

In many ways the terminology of “architect” and “architecture” misrepresents what Architects should be concerned with. Unlike buildings, the Enterprise Asset is not static. It is constantly in a state of change, with all your technical people adding to, changing it, it all the time. A better metaphor for what the architect does is more of a gardening metaphor. Like the Enterprise Asset, plants grow in a landscape and require constant attention by hands-on masters mindful of the original or evolving vision. This means that, unlike building Architects, IT Architects have to be involved in the day-to-day work of the Enterprise Asset to be effective. This is not just an “agile” observation but rather a more general commentary on the effectiveness of the role of architect. The thinking becomes even more important as we expect Teams to take responsibility for all their work.

There are 3 potential interactions between the Architect, the Team, and the Enterprise Asset:

The Architect has an understanding of the Enterprise Asset, and it is probably a wider view of the system than the Team has. With this understanding, the Architect wants to help the Team do things the right way.

In the meantime, the Team is also working directly on the Enterprise Asset, and in many situations, the Team will have a more detailed understanding of their portion of the system. When the Team looks at what the Architect is suggesting in terms of guardrails / guidelines the Team will sometimes find that these are in conflict with what the Team knows is the best, or most practical, approach.

The reality of the situation might be that there is in fact a problem with either the guideline, or the system. Or it might be there is just a misunderstanding on either side. Irrespective, if the Architect is working directly with the Team, collaborating, then this becomes an issue that can be worked, thus improving both the overall Enterprise Asset, as well as the work of the Team.

If the Team is working directly on the asset and the Architect is telling the Team to do something that does not make sense, the interests of the Architect will be overridden as the Team is tasked with delivering to the customers.

The reason that Architects need to collaborate directly with Team is that the Enterprise Asset is a complex system. When working with the Enterprise Asset, a simplistic view of it does not help. Understanding is improved through working directly on the Enterprise Asset. This sets up feedback loops - what we thought was vs what is actually happening.

The reason Teams need to work with Architects is that Architects have a wider understanding of the Enterprise Asset. This means they have heuristics for understanding wider impacts on the Enterprise Asset as we make changes. Again, this is a feedback loop.

When Architects work directly with the Team on the Enterprise Asset it sets up a positive reinforcement loop. Architects working with Teams see their ideas implemented and increasing understand the Enterprise Asset. Teams working with Architects will be able to leverage the wider knowledge of the Architect and will see their impact on Architectural decisions.

One note on the word “collaboration”. For many traditional organizations “collaboration” means “we have a meeting.” Meetings are certainly part of collaboration, but really we need something more than this. When a Team is working on something that needs input from an Architect, the Architect should be pairing / swarming with the Team, potentially even working directly on the keyboard. In this way the Architect develops real understanding of the effect of changes being made the Enterprise Asset. Trade-off decisions as a result of the implementation will inform level and type of guardrails needed, and when guardrails should be ignored. The result is an improved understanding in the trade-off between emergent and intentional architecture that will lead to better guardrails with a higher probability of acceptance, and therefore improve the Enterprise Asset.

You might hear people refer to “going to the Gemba”. The Gemba is the place of work and this is the general notion that you can only have a real direct understanding of the work if you go to the place of work - sitting in your office doesn’t cut it.

In reality, an Architect’s view of what should be standardized, what we need in terms of guardrails, will also have an understanding of when that standard should not apply. There needs to be variability. The Teams are probably the best source of good variability. In fact Architects are often in danger of standardization that does not make sense to the people doing the work. The role of the Architect in this area is to help teams to understand good variability versus good standardization, with everyone involved understanding the dynamic.

In many ways, this dynamic is also a difference between “intentional” vs “emergent” architecture.