From developer to (solutions) architect. A simple guide.

This content originally appeared on DEV Community and was authored by Natalia Venditto

So you don't have formal CS education and have been doing development for some years, or you are a junior but your manager has already asked you where do you see yourself in tech in a few years. You want to become an Architect, but you are not sure of what it takes and you want to have a better idea of what you should focus on. You want to understand where are your technical gaps and what soft skills are required. This article is for you!

Architect is an umbrella term to designate a role that is focused on either designing or refining software solutions for the benefit of the customer. But it has different accountabilities, depending on the organization you work for.

Pre-Sales Solutions Architects

Pre-Sales Solutions Architects can also be called Customer Engineers or Sales Engineers, and are usually focused in making sure a technology they represent fits a customer's use case and their required capabilities, while they help them design a system to integrate it, or give pointers about the best application of it. They'll work on high-level diagrams, do discovery, work in scoping, and give support to Sales reps during technical alignments.

Post-Sales Solutions Architects

Some of the pre-sales Architects, also do post sales, meaning that after you're done with the sales process, and a deal is closed, you focus in helping with the actual implementation. They may just design the systems at a high level and overview the implementation, or be very hands on, and execute it together with the technical implementation team.

Software Architects

Software Architect is a very hands on role, architecting anf oftentimes implementing a software solution. Software Architects are an equivalent of the Post-Sales, usually for a product or specific technology. Software Architects are not necessarily customer facing.

Again, it's important to clarify that the designation and accountabilities for each role, may vary across the industry.

The technical common ground

No matter what type of architect, the common ground is the technical one. Architects are technical by nature, from a perspective that allows them to connect tech specifications to complex security requirements, governance nuances and privacy compliance and sovereignty, and legal liabilities. They are not concerned with the nitty-gritty details of the implementation, rather the big picture. Deployment pipelines, layers of the stack, performance at a system level, user management, locality, infrastructure components...those are the things that really interest and occupy an architect.

Process phases a Solutions Architect participates of

I work now in the role of Solutions Architect, and will focus on this particular dimension, since Software Architects are involved in processes pertaining the software development cycle, which is much more complex to describe.

Solutions Architects are usually a customer facing role and participate of and are instrumental to a lot of conversations with them. Their main goal is to discover and scope a system's requirements and/or current technical state as much as drafting the desired state and deciding or advising on the most ideal solution.

Discovery

SA's (acronym for Solutions Architect) participate of discovery. These are the early stages of conversation with a client, where many questions are asked. An SA needs to understand everything about their client, their product or project, their goals, their problems, so they can map those to tangible solution suggestions.

The most important skills at a discovery meeting are not technical: Solutions Architects need to be able to

• listen more than talk
• make good assumptions and validate them with the client
• do not propose a solution ahead of understanding well all the problems and requirements
• be very objective

Contrary to what many people think, even those architects that represent a brand, are unlikely to push for a biased solution if they assess that's not what the client needs. Not only your reputation is at stake, most architects pride themselves in promoting the foundations of a solid system

Foundations of a solid system

Solid, well designed systems share certain identical features. They all aim to be scalable, robust, resilient, recoverable and secure, among other important characteristics. Architects also want their systems to be highly available and sometimes they have requirements for them to be globally distributed, which is less of a problem today when global provisioning is guaranteed in the cloud.

Scoping

Requirements are the documented capabilities used to measure a systems success, according to whether or not they're satisfied. They usually map to those foundational concepts. Like for example, it may be a requirement for the system to have an uptime of a certain percentage (usually 99.995% for mission critical applications, which is about 4s downtime daily - you can calculate that SLA here https://uptime.is/). That requirement maps to High Availability.

The process of putting requirements and capabilities in scope, is also done by the architect, and usually (technically) validated by the customer with business objectives in mind, at some point. Backlogs are oftentimes the result of generating user stories and functional requirements directly from the scoping exercise, together with the validation and priorization of capabilities, towards a release.

What technologies should I focus on?

That is a difficult question to answer, since it will very much depend on the type of system a software or solutions architect is designing or assessing, the technologies may vary greatly. I will focus on describing a list of technologies and areas of expertise you may want to check out, if your goal is to become an architect working in web oriented solutions.

The cloud landscape

This is not to say there aren't architects still working on premise in self managed environments, but if you're planning to join the forces, you probably want to have an idea of who are the 3 public cloud providers (AWS, Azure and GCP), and their offering and topology.

You may also want to learn about cloud-native technologies, and explore what's hot and trending.

Additionally it's very useful to know certain jargon and how some mechanisms work in the cloud. Concepts like

• what is a cluster
• scaling out vs. scaling up
• what are distributed systems and how they work
• what are the caching mechanisms and the best practices in the cloud

Infrastructure and infrastructure provisioning

Provisioning infrastructure is not really the architect domain and it is usually done by the system engineers, Ops or other roles (the name may vary, depending on the organization). However, architects may have to validate or analyse the deployment pipelines and infrastructure setup before it is executed or afterward, for several reasons:

• costs assessment
• compliance with architecture definitions (security, performance, technology definitions, etc)
• risk evaluation
• reconfiguration

Although infrastructure provisioning, especially in the cloud, is provider dependent, there are some concepts you need to know and understand.

Networking

You will need to understand well how the internet works and all the layers involved. Some important concepts and focus areas would be

• the Networking Layer Model per type (TCP/IP, vLab, ISO/OSI)
• TCP/UDP/HTTP Protocols
• SSL and other Networking Security concepts (Firewalls, Keys, VPN's, VPC, Private Link, Network Peering, etc)

A book I definitely recommend to read to catchup with a lot of these concepts, is Computer Networking, a Top-Down Approach I had to read it when I was taking credits in Software Engineering, and it's one of the best books on the subject.

I also recommend you download and install Wireshark for packet sniffing or TCP analysis, to learn more about segments, headers, and other networking concepts. There are more sophisticated tools, but this one is great to get going. It's open source, free and a consolidated tool.

Hardware

Yes, you need to know about hardware. This is particularly important at the time of deciding on infrastructure configuration and if you detect performance issues and must scale up or down/out or in and system, to decide on the specifications. Concepts like

• CPU, (disk) SDD and HDD, (memory) RAM(ø)
• IOPS
• RAID architecture
• ports -very important for hexagonal architectures-

and concepts like

• big and little endianness

Unless you actually work at a data center and walk in between racks, you probably don't need to know about other components like power supplies. Just the necessary specifications to match a software requirement. Although I always advise that the more you know, the better! But you also need to know about:

• operating systems(ø)
• virtualization (most servers are actually virtual machines on top of physical servers)
• containerization and containerization and orchestration software (like Docker and Kubernetes)

(ø)I am not going to provide links to content about physical components of computers because there are way too many sources, and you only need to run a quick google search and pick the one that interests you the most.

One important piece of advise I can give you, is that whatever operating system you love the most, you probably need to be familiar with Unix and Unix-like systems and architectures, and be proficient in the use of the shell since it's the preferred means of executing code remotely, deploying packages and code and accessing systems.

Databases

The task of storing and manipulating data becomes more and more important, as applications are more and more user-centric. Storing data is not only about the software used for it. It's a key part of the success of an application. And architects need to be well aware of the

• different data models and database architecture
• tabular vs document
• graph databases
• physical requirements of the database software
• limitations of certain models in relation to scalability
• security implications of data flows

You probably want to investigate what product corresponds to what provider, and want to learn concepts like transactions and ACID compliance

You may think I'm biased, but I recommend you head to the MongoDB free learning platform aka MonogDB University, where there are tons of information on all those subjects, and a lot of it is -contrary to what many may think- very objective.

Architecture models

Well obviously, an architect needs to know about architecture! And architecture is an evolving and dynamic ground!

• microservices
• hexagonal architectures
• monoliths
• event-driven architecture
• serverless architecture

You need to know those concepts by heart and when they're the approach to follow. I am inclined to think that a good architect, just like a good developer, is never biased, and will try to find the right solution to a problem, instead of finding a problem to implement a preferred solution.

All those paradigms have software and technologies associated, that you may want to explore and experiment with. For example:

• docker (containerization/virtualization)
• kubernetes (orchestration/management of containers)
• kafka (event-streaming platform)
• serverless functions (very much provider dependent, are a way to execute functions on triggers and avoid large backend implemetations)

Needless to say that the many providers will have tools and connectors, modules and best practices or guidelines, to implement each different type of pattern according to their infrastructure architecture and offering.

Deployment pipelines and release models

Architects are usually in charge of designing deployment pipelines, that tend to depend on the application release model. If you are working with a continuous integration pattern, you'll probably have to support it with CI/CD automation tools. And the following concepts should be familiar to you

• Actions
• Triggers/Events
• Infra as code

together with relevant software (again, options may be conditioned by the cloud provider choice)

• Circle CI
• TeamCity
• Terraform

In the realms of automation you may also have to design means of performing test-automation for different areas, ranging from code sanity to performance, and have to know about the implementation and configuration of tools like

• SonarQube (code quality)
• SolarWinds (performance monitorization or observability) and the likes

Access control and governance

Architects are for sure in many cases responsible for software/platform security, if not for its implementation, for its design or assessment.

It is important for architects to understand the many means of controlling access to software code bases and data, and the services provided by the applications they architect.

Architects know well the meaning of

• authorization
• authentication http://www.bu.edu/tech/about/security-resources/bestpractice/auth/

and have to understand the different ways to implement them, at an application level and low level, too.

It is desirable for architects to understand what vectors of vulnerability their apps or platforms, or the software they work with may be exposed to, in order to mitigate risks.

Governance has many meanings and implications and it's so intersectional I can only map it to the different dimensions it may connect to.

For example, designing role based access depending on authorization granularity is part of governance policies for access, while software capabilities providing the ability to set those rules, guarantee legal compliance with standards like ISO27001 or GDPR.

The API and application layers

Most modern architecture patterns for web development are very heavily API dependent. It is very likely that the software or platform an architect is responsible for, does not only consume from dozens of API's but also exposes some of them.

Needless to say, 100% of the tools I mentioned through the article, are API based, and so are most of the services exposed by cloud providers.

For this reason, architects need to be skilled on API design and maintenance, and very familiar with concepts and patterns like

• REST APIs and JSON standards
• GraphQL
• SOAP (although less used now, many legacy systems still consume or expose SOAP services)
• And other API alternatives like Java Servlets

And before you complain about the age of some of the mentioned API architectures, remember that a lot of times Solutions Architects assist in migrating Legacy Systems, and for that, they need to know what they're facing!

In order to effectively design and maintain, or even assess in-place solutions, it is very useful for architects to be aware of and implement the Open API specification and Swagger

Architects need to design the connection and sometimes aggregation of data coming from all those API's. For that reason, they also need to understand well how to consume them and distribute them, and need to know concepts like

• north-south bound (API gateway)
• east-west bound(service-to-service or service mesh)
• proxy and reverse proxy

In terms of app development, it may not be necessary for architects to know or understand implementation details of high level languages, but most architects do anyway, since at a great percentage architects used to be developers.

High-level diagrams, UML and other types of diagrams

Architects speak in diagrams. Believe me. Oftentimes they need to represent very complex systems and relationships, and the only way to do it is being proficient at representing entities with shapes and arrows.

This is why architects learn

• UML
• Crow's Foot Notation and other representation schemas

Architects usually conduct and lead calls with customers, and they need to have great public speaking and presentation skills: from putting together impressive slide decks, to expressing complex technical ideas in a language everyone can understand.

Sales

Some organizations hire architects to be part of their sales processes, and advise sales reps and clients from a technical perspective.

Those organizations are very likely to offer training in their sales process and methodologies used, as well as ramping up the architects in a particular technology or software.

Will all my coding skills go to waste?

Absolutely NOT! I can speak from personal experience that all I have learned as a software developer, helps me quickly understand systems and decisions, analyse existing code bases and configurations, and build rapport with other architects and developers. Some solutions architects are required to build PoC's on a regular basis, and your coding skills are not only helpful but necessary.

Conclusion

Well, I know this is already very long, and this is only the tip of the ice-berg! Software and Solutions Architecture is a very rewarding career path and one that many developers follow when they don't want to move to more administrative, project or account management positions, and want to continue to be part of the technical scene.

Disclaimer: I added links to resources from pretty reputable sites, but if you want to contribute with better ones, add them in the comments!

If you have more questions, hit me on twitter, share and like!

This content originally appeared on DEV Community and was authored by Natalia Venditto