There is no rulebook for job titles in the IT industry. We sometimes use them interchangeably, but it’s good to be specific, so let’s examine the differences in detail.
One thing is for sure:
In a (very tiny) nutshell, software engineering is more on the technical side, and software architecture is a bit more on the business side. It’s important to bear in mind that in private companies and SMBs, these titles won’t always mean the same thing.
The corporate environment is a bit more structured and requires detailed job titles, whereas smaller teams have a bit more leeway. So in smaller companies, you might find a Principal Software Architect on outstaffing service whose job, in reality, is limited to Engineering.
Why limited? Because the Architect usually covers a wider range of responsibilities. To put it simply, in a normal team hierarchy, the head of engineering would be tasked with building a product that fits the senior architect’s vision. From an education perspective, Software Engineers with a college education know about software architecture.
Realistically, then, these titles are interchangeable. At least to a certain degree. When Engineers choose a job at a tech company, they can specialize in producing high-quality software, or planning and managing that production. This would lead to either a senior Engineer or senior Architect title as they became more specialized and gained more experience.
Lots of people like building start-ups because it allows them to take on many roles at once. In the archetypical two-person start-up, there’s the business partner and the technology partner. The tech partner does the architecture, planning, engineering, testing, bug-fixing, from the backend to the frontend.
As the software project grows, the tech partner becomes the technological manager, and then – principal software engineer or architect. Whichever he prefers, and thinks describes his job best. In reality, and in accordance with the definition (which you’ll see in a bit), he was the architect from the start anyway.
Now, a different situation. The manager needs to gather a team for a big project with specific requirements, a budget, and a deadline. Should she specifically look for a software architect? Not necessarily! A senior software engineer with relevant experience would most likely be able to take on the role of the senior architect.
One of the crucial aspects of the Architect role is that sometimes the architect isn’t a programmer. Architects don’t always code. But, as Anthony Langsworth (and many professional software developers) would argue, a good architect should be able to write code, because it:
This brings us back to the fact that a senior software Architect on some teams can in fact be an Engineer, despite their title. Anybody who designs a product or a system can be called an Architect if the role isn’t clearly defined.
Titles can mean different things from project to project. On the technical side, however, things are a lot more clear.
Borrowing from Simon Brown, the job of a software architect is to:
“[…] figure out what the requirements are and design a system that satisfies them.”
To put it another way, architecture entails planning how to put together different software components so that the finished product will fulfill its purpose.
There is a clear deliverable – the required characteristics and features of the product combined into an applicable (buildable) model of working software. It doesn’t have to be a revolutionary system, as there are many different types of commonly used architecture patterns, like Serverless, Event-Driven, or based on Microservices.
After taking care of the model, the architect is responsible throughout the project for making sure that the product meets all the requirements of its architecture. That means not just making sure that the development team is doing everything right technically, but also supporting the team, and upholding the role of the leader in the production process.
The software development engineer’s job involves less dealing with people and more dealing with code. As Samer Buna nicely put it:
“The act of engineering software is about designing, writing, testing, and maintaining computer programs with the purpose of solving problems for many users. It is about creating robust and safe solutions that will withstand the test of time and will work for some of the unknown problems around the original obvious ones.”
Sounds kind of similar to the architect role, doesn’t it? To understand the difference, it helps to see the architect as more of a high-level role, focused on the big picture. The software engineer is more focused on the nuts and bolts of the product.
The deliverables for the engineer are different. For example, it’s clean, usable code, understandable and thorough documentation, and working features.
The engineer delivers the parts that make up the components of the product’s architecture.
In a real-life project management situation, there is no time for ambiguity and confusion. My advice is: when in doubt, ask about responsibilities and deliverables.
If you’re not sure of what someone’s job title means, ask about what their responsibilities are, and what are the tangible results of their work.
This will help you bypass the title, and really understand if you’re talking to a software architect, a software engineer, or a different specialist altogether.
Talmatic is a concierge type service for hiring dedicated developers. Great developers are in huge demand, but in-house hires are expensive and freelancers aren’t always suitable for long term work. We, at Talmatic, providing access to a unique vetted pool of tech talent available for contract hire.
Our managers will contact you shortly
Specify how many developers you need, their tech stack and seniority level. We would love to help!
Specify how many developers you need, their tech stack and seniority level. We would love to help!