You can see a business need developing. Maybe it’s a startup with a new product that the company depends on, or an enterprise business releasing a new product or feature to the mass public. Whatever the case, developing an application that serves said business need in an optimal way while maintaining quality code—this is no simple task. But who is responsible for designing the development plan or the project roadmap that will serve the business needs? Who is qualified to make such decisions?
These questions both have the same answer: a software architect.
But what exactly is a software architect?
A software architect is usually a developer with extensive end-to-end product experience, in addition to knowledge and skills in some non-technical areas that we’ll get into below. The software architect role is not even necessarily a full-fledged position: Instead, it’s more of a title that is given to a developer who has what it takes to take a business idea and turn it into a complete product.
Thus the software architect’s role is a blend of a senior developer, a team lead, and a CTO—but the proportions vary wildly throughout the industry. Let’s dive into what they typically have in common.
1. Software Architects Have an Eye for the Type of Client
A great software architect has an eye for the type of client they are working with. Some clients don’t have a clear vision of what is possible. They have no long-term plan for their product, constantly changing requirements and structure.
It’s the software architect’s job to have an accurate view of such approaches. This means presenting possible future plans and designs that could serve the development team to prevent breaking changes.
Or the early introduction of some features that may require heavy refactoring in the codebase or even data migrations if presented late. For example, a migration from a NoSQL database to an SQL database might take weeks or even months to prepare for. The scripts and procedures to maintain consistency of the data and a rewrite of the back-end functionality to work with the new database is not an easy task.
The other type of client is the one who knows exactly what he/she wants. They have a clear roadmap for the product and a clear vision. They still fall short on some things, and business usually forces the roadmap to change sooner or later. But at least they have a plan.
This type makes the life of a software architect much easier, but it introduces some challenges. Firstly, the software architect needs to make sure that the roadmap actually has a reasonable timeframe (discussed below). Secondly, sometimes it introduces constraints like the integration with a badly documented API just because it’s cheaper for the business to use that service for example.
2. Software Architects Understand Business Requirements
A top software architect is able to communicate effectively with the business owner, the CEO, or the client. They are able to tease out exactly what the client has in mind for the output while keeping the technical difficulties and challenges in the back of their mind.
Software architects are able to effectively:
- Discuss requirements and challenges with technical and non-technical clients alike
- Simplify and draw a conclusion to the client’s requirements
And on the development side, they are able to:
- Draw a sketch of the relevant data models and how they are connected to one another
- Understand the best language(s), database(s), and tools that best serve the project’s requirements
- Dig deep into the requirements and extract the tiniest details to explain and discuss with the development team
Without these skills, a software architect will be building the wrong product from the beginning—an expensive strategy, to be sure!
3. Software Architects Excel at Time Management
A great software architect is also able to manage their time effectively. A software architect doesn’t have to be a team lead: They could be the sole developer of a product or a member of a team of developers.
That said, a software architect acting as a team lead will know how to quickly learn the capabilities of the team they’re leading. They’ll be able to reasonably estimate the time needed for the development of the product, taking into account emergencies, delays, or other problems that may arise. In other words, they’ll be able to give a best-case- and worst-case-scenario estimate for the time needed.
As for software architects working as team members, they are responsible for listening carefully to the estimated time proposed by the team lead and the requirements to be delivered and setting a personal timeline for delivery. They are also responsible for pointing out to the team lead any points they might have missed and/or anything unclear in the requirements given.
4. Software Architects Are Usually Polyglots
Software architects understand that there is no tool that does everything right. Nothing suits everything perfectly. The same concept applies to programming languages, frameworks, libraries, and databases.
Although most popular programming languages can get the job done, they’re not always the best choice for developing the product at hand. Take Node.js as an example: Certainly, it’s a great tool for almost all applications, but it’s not always rainbows.
Having to deal with things like the event loop and blocking code might sometimes slow execution if used in the wrong way, harming the resulting user experience. So while Node.js may be an architect’s personal favorite to develop with, they might put it aside in favor of a Golang-based approach when concurrency is involved. Likewise, they might recommend a Ruby on Rails back end when the client is in a hurry and doesn’t need fine-tuning: Rails’ copious use of magic means it serves as a very effective rapid development framework.
Not only is it a matter of choosing the right programming language, but also about deciding which database to use. Software architects’ first decision is whether to go with an SQL database or a NoSQL database. That depends on multiple variables that are set during the software design phase.
Even after that choice is made, another choice has to be made: Which exact database will be used? Should you go for PostgreSQL or MySQL, if you’re using an SQL database? Should you go for MongoDB or CouchDB, if you’re comparing NoSQL databases?
This is just a simple example that can sometimes be solved by personal preference or the comfort of the development team. But sometimes it will depend on other, non-trivial factors. For example, if you need to store time-series entries you would better off using a database that is optimized for that, such as InfluxDB. It’s no longer a preference, but instead a need: for the sake of performance, scalability, and future-proofing.
The bottom line is that software architects don’t confine themselves to a certain programming language or paradigm and use it everywhere for everything they do. They understand that every tool is suitable for a certain job and instead of being repulsed by change, they embrace it.
Software architects are aware of their wider developer community and its adoption of new trends. They don’t follow trends blindly but instead keep an eye out for potential solutions that can disturb the industry. They may even become an early adopter of a certain technology, in some cases: Flutter was adopted by some companies to develop cross-platform mobile applications before the release of its first stable version.
This isn’t only about new trends, but also about awareness of current technologies. Sometimes a technology gets overtaken by a competitor that serves the same purpose but delivers better features or experiences. For example, Docker Swarm was in a tight race with Google’s Kubernetes for a few years, until it was obvious that the community was more interested in Kubernetes.
A great software architect is aware of such changes in the community. They know it would be pointless to look for developers or DevOps engineers with experience in Docker Swarm when it’s clear that Kubernetes is taking over and sticking to the current technology might be more harmful to the company and the product more than the good it is delivering.
6. Software Architects Know When to Break Code
Sometimes a product is already built, and in many cases, its existing functionality needs to change. This could be a management decision, a decision made for security reasons, or a number of other reasons.
Other times the code might be good, but the app’s popularity is growing really fast and there is an increased demand on the features to be delivered.
These are some scenarios that a software architect might be challenged with. And their solution might be summarized by one word: “breaking.”
Breaking the code can have two definitions.
The first type is the introduction of solutions that change how the application behaves. It could be for the sake of code readability, the ability to debug faster, or for the performance and/or stability of the app itself.
For example, Stripe used to support cryptocurrencies. An app using Stripe had to have a chunk of code written in its back end to handle transactions with such currencies. When they decided to end support for cryptocurrency payments in 2018, they broke their codebase. They also started a race-the-clock situation for all clients that had implemented the cryptocurrency API—they suddenly faced a deadline either to stop accepting such cryptocurrency payments or migrate to a different payment gateway, at least when handling that kind of payment.
The second type of code-breaking is related to splitting up the codebase. Sometimes applications get so big that they become slow, or too incoherent and dependant to work with. Other times it’s simply the fact that one feature of an application is used more than another.
Facebook, for example, has separate back-end applications for chat, news feed, games, and other features. Imagine that Facebook had a surge in usage for their chat application. If they had to scale everything related to Facebook just to serve the demand for the chat feature, that would be a really expensive scale. This is why each large feature of an application is usually supported by its own set of back-end services. These microservices can scale fast with a low initialization footprint.
7. Software Architects Know How to Be Cost-Effective
A software architect can also be responsible for making decisions about your app’s deployment. If you’re a startup and you still have a small number of users, it doesn’t make sense to start deploying your application on six different servers distributed in three different regions with three replicas of your database. It’s also illogical to deploy your application, database, and user-uploaded files all on the same five-dollar server with no backup.
Both approaches are wrong. The first is overkill and the second is far too risky. Software architects can predict the size of hardware needed to run your application and use it in a safe manner, without spending too much money on idle servers.
But being cost-effective is not just about deployment and servers. It can also be about the development team that is going to work on the product. We’ve seen it happen where a team of four junior developers was hired, estimated some work would take two months, and delivered the product in eight. Meanwhile, the quality was low and the code was undocumented—a burden for the team that would end up maintaining it.
Great software architects know that it’s better to hire two seniors who will develop the application in a clean, structured way in three months. Sure, everyone has to start somewhere, but the point is, a software architect team lead should have the ability to know when and where to invest the client’s money and resources, and when it’s simply a waste.
8. Software Architects Have an Eye for User Experience (UX)
A software architect is not simply a coder, but instead, they are able to put themselves in the end user’s shoes. They have an accurate idea of how the user will behave. Software architects are also able to gauge how easy is it to deal with the system. Although the main responsibility for that point lies in the hands of the UI/UX designer, it’s still coupled with how the system works in the background.
The development team always knows their way around the app they’ve built, which sometimes makes them forget that new users will need to adapt to new icons, UI flows, or features added to the app. The challenge is to make this adaptation as smooth and short-lived as possible. This happens by following market trends in design. After all, what’s considered “intuitive” is an ever-changing target, complicated by expectations created by other apps the user interacts with.
But even within that, there’s room to make things as simple and consistent as possible. For example, we’ve seen an app in production where the user’s name acted as a link to open the user’s profile, but the user’s picture was left with no action when pressed.
The default behavior that people are used to is that when you press on a user’s picture or the name, you open the profile or a summary of the profile. This is the current standard since it makes it easy to access relevant profile info. But in the example above, on a relatively small screen, it was hard to press on the name and sometimes required multiple presses to get it right. Such a design might even suggest to users that there is no way to navigate to a profile through this context.
Another UX snafoo we’ve seen in production is attaching the functionality of the navigation drawer button to the floating action button (FAB). This is just counterintuitive. A great software architect will catch such issues in the design stage.
In terms of UX, a software architect basically follows one rule: Make it as simple as possible.
The Software Architect in a Nutshell
Software architect is not a title that just any developer can hold, and now you’ve seen the criteria that sets one apart. Software architects have a huge responsibility for what is delivered to the client, and also for making everyone’s lives easier. Choosing a great software architect for your next project is a key ingredient in delivering a successful product—so choose wisely.
