The role of the software architect

I looked at my LinkedIn post DRAFTS and found an article I wrote in 2016 but never published. It is as true today as it was SEVEN years ago when I wrote it. The role of the software architect is important. Below is my original unpublished (unfinished) article (about seven years before chat GPT, so no AI was involved in writing this, I promise):

I’m often asked “what does a software architect do?”. Rather than answer the same question again and again, I’ll capture here, in broad brush strokes the role of the SA.

TL;DR: taking in a lot of parameters, having built over a long time a substantial knowledge base and experience, and analyzing it for the purpose of teaching, learning-from, negotiating-with and influencing the organization to make good decisions.

Good decisions are those that first and foremost help the organization be more profitable in the short and long-term. By having an agile, scalable, available, secure and easy to use platform, the organization is much more likely to achieve its objectives.

Realizing that there are multiple ways to materialize a goal, deciding on the most appropriate method involves a clear understanding and analysis of the desired business outcomes within the context of the various constraints that inevitably exist.

As a concrete example, consider what is hot topic these days - the move from a monolithic design to a micro service architecture. This is but one of many topics that require a deep understanding, and a deliberate plan of action.

At a high level, most organizations have embraced the micro service architecture approach. The benefits of such an approach include:

• Independent and relatively fast evolvement of features. One does not need to wait for all others to introduce improvements
• Ability to test individual parts of the system
• Ability to use the best tool for a given job (language, DB, queue, etc.)
• Natural human to code assignment, affinity and domain understanding
• Horizontal scaling can be achieved per component
• Easier to replace system components (interchangeability)
• Higher scalability due to multiple data stores dedicated to a subset of the whole system
• Easier integration due to isolation and clear contracts between components (no integration at the data layer)
• Security sensitive functions can be hardened and audited independently from the entirety of the system

There are also disadvantages to the micro service architecture model which include:

• Operations requiring joining disparate data from multiple services add complexity and additional “moving parts” to the system
• Inter-process communications are substantially slower than in-memory calls
• Increased number of technologies make it harder and costlier to operate centrally. Necessitating operations to be distributed to service developers
• Bigger effort is needed to understand the system as a whole because of the combination of multiple collaborating systems
• The security attack surface is increased, multiplied in scale by the number of services making up the entirety of the system
• The potential for duplication of effort is increased (setting up database backup, replication, monitoring, building components with the same functionality in multiple languages for example)

The above is not meant as an exhaustive list of pros/cons, but top-of-mind subset of the list. It is generally (yet not universally) accepted that the benefits outweigh the disadvantages. With that in mind, there are multiple ways to achieve a micro service architecture. Some decisions that need to be made include:

• Can the organization adopt a 100% cloud-based infrastructure, or are there reasons to adopt an on-premises or hybrid infrastructure (e.g. contractual obligations, legal, security, performance, etc.)
• If an organization can adopt a 100% cloud-based infrastructure, should it design with portability (across cloud providers) in mind, or is it acceptable to drink the Kool-Aid of a particular cloud vendor (knowingly being locked-in)?
• If a hybrid approach is unavoidable, how should portability between the on-premises and cloud-based infrastructure be achieved in a prudent manner?
• What inter-process communications protocol to use? (REST/HTTP as opposed to a binary format? A HTTP approach may potentially introduce unacceptable latency when multiple services are combined to serve requests, understand what constrains there might be and the pros and cons of various approaches)
• How should related data be sent from service to caller (fine-grained REST calls vs. GraphQL or similar coarse-grained document-based request/response for example)
• Should a worker model be utilized where workers pull tasks from a queue as they are ready, and place their output/response back on a queue when done, or should services expose an API (REST or binary) and serve requests in accordance to the logic implemented by their fronting load-balancer

All of the above questions need to be clearly asked and fully answered and on top of that, there are the technology selection decisions that map the most appropriate technology for the desired benefits within the organization’s set of constrains. These include:

• What type of database should be used for a certain domain? Some types include: Relational, Key/Value, Graph, Time-Series, Document-oriented, Data warehouse, In-memory, Column-oriented, and more
• For the database types that are chosen for a certain domain, what database software to use?
• Assuming a container-based deployment model, which orchestration system to use?
• What API gateway software to use?
• What message queueing software to use?
• What language is best suited for a certain type of service (e.g. Node.js is good for I/O intensive apps while the Go programming language is well-suited for CPU intensive apps. These are just two highly generalized example and not meant as authoritative or applicable in all scenarios)
• Should a “server-less” (like AWS Lambda) product be used, and if so, which one?
• What logging system to use?
• How to capture metrics?
• And much more

With the philosophy that there is no one single tool which is appropriate for every job, it makes sense to adopt the right tool for the job, however, having architectural oversight and input steers the organization into having a much less chaos. I’ll use an analogy: A city planner and the department of building and safety do not design every aspect of a city, street and house. Instead, the city planners design and maintain over time, an overall architectural structure that works. Streets wide enough for the expected traffic (in theory, I’m in L.A. after all), enough parking spaces, not co-mingling residential single-family homes with industrial or commercial structures, etc. The building and safety department ensures that certain standards are adhered to, so that bad things don’t happen (as often as they would have otherwise, should standards did not exist or were not enforced).

One could argue that chaos does work, but I’d point to cities without zoning, planning, and common set of services in developing countries where people operate diesel generators, drill water wells and there is no sewer system or telecommunications infrastructure or services to speak of. Do people live there? Yes. Would you want to live in a chaotic city without a plan and without a building and safety department? Most likely not…

To conclude, the functions of the architect include applying a big picture view (with a good understanding of the parts that make up the whole) and influencing the organization by whatever means in order for it to make correct “zoning” and “safety” decisions as it evolves and grows. Always keeping in mind that those decisions are there to support the growth, sustainability and profitability of the business.

While a big picture view is important, it is also important to innovate, understand emerging technologies and potential threats (security, technology deprecation, ability to be competitive), identify incorrect past decisions and their potential negative ramifications and to bring teams together, and to learn from everyone and help to continuously evolve the collective intelligence of the organization.