Architects Should Code

Following the typical journey made by several architects, I too have started mine through coding software, when I was 10 years old, exploiting a Commodore64 I received as gift from my parents, originally intended for playing videogames: natural curiosity and some basic rudiments of hacking brought me to write my first program in BASIC, that had the function of adding two numbers.

Over the years I have developed those skills further, even employing them in unthinkable applications (such as writing my own VST plugins for producing music), eventually ending up studying software engineering and making a career in the industry, as developer and later as architect.

At the moment of jumping the line that separates software development and business architecture, becoming a Solution Architect I experienced several issues, since I had no access to the source code anymore, and I still had to organize solutions from the perspective of deliverables to higher functions of the organizations (Product Managers, PMOs, VPs, CTOs), employing non-technological language to explain technology challenges, which in the first part of that transition was extremely frustrating.

Jumping the Line

Despite of this transition to a more business-oriented function, I was still in the position of having to discuss with several teams of developers, to understand the scope of their work, the external integrations, the intentions of the architecture they (voluntarily or not) had established, and potentially bridging their efforts with the management functions of the organization, who had to ultimately allocate resources for those architectural components.

In few months my mindset about software development changed radically, once exposed to the organizational challenges of complex and large organizations, their strive to acquire resources, the aim for being competitive in difficult and challenging markets, and then I focused my attention more on the business aspects of the architecture, that I considered the foundation stone on top of which other activities (such as software development) were justified: the Zeal of the convert, one might say.

As a curious person I then intensified my knowledge and skills in Architecture (“that big thing, whatever it is” q.), standards, frameworks, tools, methodologies, shifting my focus from the code that I used to write (or at least review) on a daily basis: in fact, for about two years I stopped writing any single line of code, and I stopped caring for the low-level details of the technology (eg. memory allocations, language improvements, new tooling), that now became some sort of irrelevant information, in the scope of higher-level architecture choices.

The principle that the higher you go, the less details you want has a rationale in the amount of information overload one might experience, if one would receive all the detailed information of anything happening in a large context: dealing with 10 different teams at the same time, while reporting to several management functions (CTOs, CIOs, VPs) and middle-management (Product Managers, Program/Project Managers), having to digest several sources of information, crunch them and produce myself some more, I thought that having to deal with the challenges of the code would have killed me.

Back to Code

Anyway, it happened that I found myself in the situation of dealing with an architecture that touched two major concerns of Organization Structure and Access Control, to establish a forest of secured identities, in a complex SaaS context: after the analysis of the requirements (behaviors, security, products, finance, etc.), I did my researches on standard models, processes and technologies, scanned the market for potential vendors, taking down a rational target architecture for the matter (not very agile as you can already spot).

It came the moment to face the (three) development teams who were supposed to integrate the technology in the existing environment, and eventually implement additional components to support it, trying to gather their inputs and feedbacks on the feasibility of the architecture (or rather: trying to explain them how beautiful that solution was…): unfortunately, their response was negative (or rather, mixed, with skeptical notes), and their initial approach was to get themselves out of their own issues, such as being under pressure for delivering that architecture, by implementing their own solution, without dealing with any of the principles, standards, technologies and best practices I had proposed.

Needless to say I was disappointed and caustic, frustrated by the situation and foreseeing the typical scenario of reinvention of the wheel that causes a lot of embarrassment to organizations, wasted time, wasted resources, and shifts focus from core values to accessories that are not providing any real returns (opening to further issues): in that situation I really didn’t understand how the developers couldn’t foresee the rationality of the architecture, and the benefit that would have brought to them.

Full of frustration, after more than a month of discussions, back and forth between management, vendors, developers, I then decided to download a free IDE, and I started coding (in C#), during my free time, a Proof-of-Concept (POC) to demonstrate graphically and with code the logic and behaviors that I had intended, although through the mocking of the final providers.

I must confess that the exercise was fun, but also quite hard at the beginning: few years without dealing with debugging, continuous delivery, library scanning, performance tuning, made me feel again like the teenager me, who approached Visual C++ for the first time.

While I was writing the software solution I intended, I then realized some flaws in the model that I had designed before (eg. the role of client applications, or the relationship between organizations and users and others), and then I realized myself the flaws in my communication to the developers, and the messages I was giving them, based on some abstractions, assumptions and theories coming from practitioners and vendors who were dealing with a different reality than the one we were into.

Turning Point

Given the experience and the findings, knowledge and value extracted by the return to coding, should now I recommend every architect to go back to development to better provide to an organization? Well… giving a typical architecture answer, I would say: ‘it depends’.

Reading the master-piece “Domain-Driven Design” by Eric Evans on the matter of designing and development, it is recommended to keep a separation between the designer (eg. architect) and the development team, unifying those parties in a common scope through models, ubiquitous language and other elements: I believe it still makes sense, even for lower-level architects who have to deal with more technical details, but I also believe that more business-oriented types of architects should not lose the touch with the technology, its capabilities, its challenges, and complexities, to better evaluate the alternatives provided in some solutions scenarios.

In more agile and lean organizations, the differences between architecture and development functions are minimal, and in most of the cases architects are involved in coding on a daily basis, applying their experience, design skills, modeling (process, application, data), infrastructure knowledge, and more, without any separation between them, the developers and the management: that I believe provides effective results, but it requires a small organization, using a single technological stack where everyone can relate to the code produced, the components employed in the architecture and the final goal. This kind of agility is naturally not possible in more complex scenarios, where for example every department employs different technologies, or where the development departments are the result of mergers between organization with heterogenous technological stacks.