Good Engineer, Excellent Engineer, Architect

I know many different engineers — many of them very good, some of them outstanding, but only a few of them have traits of good systems architects.

Let me explain. Engineers' focus area is systems construction. They naturally need to become experts in answering a “how to build a system” question by defining the target system structure and performing modular synthesis. They (Engineers) were able to focus purely on excelling in systems construction because they used to have other roles like Analysts or Product Managers to cover another important aspect of the system: the functional (systems behavior) aspect, answering a “what should be built” question.

We also used to have a few Architects in this setup trying to balance function and construction aspects to make their system a good fit for its supersystem: enterprise capability, business process, or even customer “job to be done.” So Architects must juggle both in their heads, applying both engineering and analytical skills and balancing the efforts and priorities between them.

This team composition of Engineers, Architects, and PMs/Analysts worked well, but unfortunately, it made our Engineers a bit narrow-focused. Most Engineers don’t really want to accept the increase in cognitive load related to mastering functional/logical architecture design. In brief, they try to resist learning these new tricks.

Funny fact:

All Engineers actually perform logical/functional design implicitly when they break down the User Stories from their backlog. Making it explicit can help you to share, validate and document this process and of course it gives you better chance to improve it.

Engineers who do “green boxes” in their heads will always be behind.

Modern “customer-orientation” practices help Engineers accept the importance of understanding (and modeling) systems' behavior.

But still, good Engineers focus on quality attributes and non-functional requirements, and only outstanding Engineers also notice the correlation between logical (functional) architecture efforts and the rate of accumulation of technical debt.

Nevertheless, it is a great temptation for Engineers to avoid functional analysis by taking someone’s decisions as the input for systems implementation to jump into the technical details of the development immediately.

But times are changing, and decentralized architecture flow has become a “state of the art” practice in developing complex information systems, as well as stream-aligned teams’ topologies and autonomy.

In other words, each Engineer is the Architect now.

To become more competitive, Engineers should accept the mindset of systems architects to balance both functional and constructional aspects of the implementation of the system:

• Not only because functional design helps better understand the scope and expectations;
• and because it works as a “technical debt” prevention practice due to its ability to identify “high-cohesion” areas and highlight potentially “high-coupling” kind of dependency we need to avoid;

But it is also the prerequisite of org ownership — it can be painless and more valuable if the Engineering organization is able to apply a strategic DDD continuously to adjust itself according to the “reverse Conway maneuver.” This is only possible by leveraging the Functional aspect of the system through the functional models of your features.