The role, skills, and duties of a software architect
Iren Korkishko
Oct 24 '17
Updated on Dec 07, 2018
・6 min read
Almost every project needs an expert to make high-level design choices and define software coding standards, tools, and platforms. I talk about software architect, a person who will optimize your development process and your business as a result. Who can become a software architect? What software architect’s skills are the must? What are the software architect's duties?
In the software industry, the role of a software architect is interpreted in many different ways. In some cases, an architect may work in an established enterprise company and hand down instructions on technology stacks to the developers. At the other extreme Agile development, a team may work without the involvement of an architect. Let’s find out when the software architect is needed.
The role of a software architect
- A software architect needs to interact with clients, product managers, and developers in order to envision, model and provide initial models and designs that can be built. This role also may cover the meeting potential or current customers.
- A software architect has to constantly review the code to ensure the quality of the design by avoiding complexity, advocating clarity and to do this with the team. This usually requires hands-on work in terms of developing prototypes, contributing code or evaluating technologies.
- The role of a software architect includes collaborative working with a degree of humility and providing mentoring as required. Such collaboration also allows the architect to become familiar with the skills and interests in the team and to share their knowledge with the rest of the team. Humility is required to ensure that all the team is listened to, as they may have more specific experience or knowledge for the problem at hand.
- A software architect is a guiding star that shows to the business which technologies it should be using and what new technologies it should be considering, and why.
Taking into account all of the main aspects the software architect role includes, its obvious that this person should have knowledge in programming, management, psychology, communication and even finance. So, what are the main skills and qualities this specialist must have?
The main characteristics of a software architect (according to Nikolay Ashanin's list and my observations)
Broad and deep technical knowledge. This should be obvious since one cannot become a software architect with a musical background. The architect usually has knowledge in several technological stacks at a decent level and should have a good understanding of a few other ones. The software architect should also be prepared to compose a large number of technical documentation, reports, and diagrams.
Responsibility. A software architect should understand those architect decisions are usually the most expensive. A person in this position should take the most responsible approach to his work and to the decisions made. If the developer’s error costs a couple days of work of one person, then the architect’s mistake can cost person-years on complex projects.
Communicability. A good specialist should be able to talk with customers in the language of business, managers of all levels, business analysts and developers in their languages. To explain all the action correctly, a software architect has to grow a natural charisma and ability to convince people. Usually, architects are laconic, eloquent and competent speakers. While software architects participate in discussions they should be able to persuade the others.
Management skills. This includes both organizational and leadership skills. The ability to lead a team, which may be distributed and composed of very different specialists.
Stress resistance. A software architect works with different people from different areas, rapidly changing demands or even with changing business environments. Therefore, it is necessary to be ready for stress and to look for some ways to escape negative emotions. Work is always more pleasant when you’re happy.
Analytic skills. One of the most important tasks is the ability to represent an abstract problem in the form of some finite real object of the system, which can be evaluated, designed and developed.
Resourcefulness. Once the software architect gets the problem, it's not always obvious that in future the taken tech stack will be able so solve new challenges. In this case he/she should be very ingenious to create something simple, secure, fast, reliable and fancy that will be working even with the unexpected input or with multiple errors that might be created by someone else in future. He/she should be able to invent the new use of tools known before.
Intuition. Even if the software architect knows how the suggested architecture works, there's something more than experience he/she should be following. The ability to predict the future issues with the use of analytic skills not always helps. So that is why a good software architect has to have an intuition.
Main responsibilities of a software architect
The most important responsibility is the complete technical support of the project from the moment of inception, through product release, to development of enhancements. The other responsibilities considered among the main ones are:
● Identifying business requirements and requirements of the stakeholders on the project
● Designing the entire system based on the received requirements
● Choosing the system architecture and each individual component of this system at a high level
● Choosing the technologies for the implementation of each component and connections between the components
● Architectural review
● Code-review
● Writing project documentation and its support
● Creating unified development standards in the company
● Controlling the architecture during the next iteration of the system release
A lot of them are named, but there are more to be named! A softeware architect should handle also:
- correct using the architecture;
- timing and deadline;
- synchronization of the software with the system architecture;
- performance quality control;
- inputs to issues like the tool and environment selection;
- interaction with management and stakeholders;
- disputes and tradeoffs;
- technical problems;
- the plan for evolutionary paths;
- the plan for new technology insertion;
- management of risk identification and risk mitigation strategies associated with the architecture.
So, to become a software architect, you need to pass a long way of learning and improvement. Understanding several technological stacks is a must: server languages, iOS, Android and more… And, don't forget hybrid, plus Flutter (that might become very popular soon). You have to read a lot of professional literature and find some mentor to ask questions. Don’t underestimate the influence of different courses and workshops. Be aware that the path of becoming a software architect will take at least several years.
Do you need to have your own software architect?
Not many companies can allow themselves to grow their own specialist in software architecture. That makes sense only if your main field is software development. Otherwise, you’ll ask for advise or collaborate with software development company to provide your project with their software architect. Startups have no time to grow their own software architects and no money to invite an experienced one. And a startup of two people, for example, cannot afford to have one team member focus on just the architecture. Everybody has to share the task and wear multiple hats.By the way, according to the gained experience, sooner or later this kind of startups hire more specialists in case of success, or die in case of fail.
The question of having your own software architect depends on many aspects like:
- What industry does your business belong to? (banking, technology, telecommunication, broadcasting, etc …) Most technological problems are already solved, what most businesses need are implementers.
- What is the size of your organization? Does the team of two need a software architect? Really, when was the last time you’ve heard of a successful small business/startup that had a dedicated software architect?
- What is the size of your development team? If we take an example of another case, let’s say, a big business with software department. How does having a dedicated software architect role benefit your department?
- What is the expected output of your team? (software products, services, innovation) To create a simple website you definitely have no need for a software architect.
- Do you already have a development team or are you building a team?
- And lastly, the duration of your project. If you develop a product that needs a software architect only for the first launch (where every single detail should be working properly) - think twice before hiring this magician. You can simply outstaff such specialist for creating the architecture of your product. Then, it will be enough to involve several engineers to maintain it.
Thanks to Nikolay Ashanin for his awesome article 'The Path to Becoming a Software Architect' that inspired me and from where I took some great thoughts!
So having your own specialist for high-level design choices is not always a good idea. However, in most cases, an outsource company has all kinds of specialists to develop the project of any complexity.
(open source and free forever ❤️)
Thanks for this article! I liked it. My career path has been one towards software architecture.
I highly recommend this video on Deliberate Architecture. He makes so many good points along the way. But the crux of it is that a software architect is responsible primarily for designing qualities into a system of software that match the business needs. Some example qualities (with a range of grades): reliability, operation cost, performance, maintainability, scaleability, security, usability, etc.
There is a lot of experience / education that goes behind knowing how to achieve different combinations of qualities. And it does require soft skills to draw out the required qualities from the customer. Because if you ask the customer, all of the qualities are supremely important. :) But in practice, they really only care about a few of them enough to spend extra money in those areas.
Anyway, just thought I would add that.
Thank you! I'm glad it resonated for you. Moreover, I appreciate the information you've shared. It's really useful.
Thank you for the article!
I believe that every software engineer makes architectural decisions daily. Small or big. Often without realizing that.
I share more about this in my presentation: slideshare.net/IvanBabak/think-com...
Thank you for the comment and for your presentation! It will benefit my article and will definitely help those who're considering about becoming a software architect!
Thanks for the article!
This comment just struck me as I know many software architects and amazing engineers with off-topic degrees and backgrounds.
For example Chad Fowler is someone I think would fall squarely into the 'Architect' role but has a degree in music! :)
Haha! Thanks! :) Sometimes things we try to show in examples might be inappropriate for some (really great) exceptions. Talking about the background I show the situation when the people from the other fields trying work in IT with no IT background. I could say medicine or art background instead of music, so this example has no purpose to offend musicians. And I'm pretty sure that a person you're talking about has also a degree in engineering (apart from music).
First of all, thanks for the great content.
Second, I just want to point out that despite the therm Architect remind us of buildings, software is more like a garden, since is never completely finished, it is always growing, evolving and changing in different ways.
Thank you for the comment!
It's all true about the term Architect!
I think I've never seen someone with such technical and human skills unite. I don't doubt great professionals like that really exist. But my point is: if that software architect does not know how to share it's knowledge and delegate all of his/her responsibilities to your team in a properly way, it would probably end up in a team with only one "super hero". Is the team in a comfort zone environment when the important decisions are only made by one person ? Will the team be more prone to collaborate with each other or give visibility to that software architect that is doing a great job ? What if the software architect goes to another company, probably the team won't know how to take high level decisions without their Gandalf.
Having a professional like that in a team is very good. But if that professional does not know how to stimulate a Software Architect journey in the team members, this person is not doing a great job.
Great comment! Thank you!
In my article, I paid more attention to skills that are a must, but I did not cover the field of knowledge collaboration fully (which is, of course, an utmost important, and I've mentioned it). Another point, that the teaching and collaboration is mostly the tech lead field. I completely agree with John Van Wagenen who wrote dev.to/jtvanwage/a-common-technica... - that is about sharing and collaboration. But the duties of a software architect (in a perfect world, of course) includes all those things I wrote, so he or she is not obliged (and even don't have time) to teach let's say a Ruby programmer, how to choose a software development methodology. If the software architect will spend the time on this, the project will unlikely be completed successfully. This is the matter of the obligations and productivity. So, definitely, a software architect should be a mentor, but the most important for this specialist is to be a real professional who can architect, carry and successfully complete the project with minimum time and maximum profit.
Thanks for writing. I agree with what you say. I felt that one quality is missing:
A good architect knows how divide a project in a modular fashion. This helps making for smaller units of development that are easier to manage.
Nice article, but I'd actually define an architect's responsibilities much more narrowly. Gathering requirements isn't part of the architect's job - that would typically be a business analyst. Similarly, I would expect a technical lead to run code reviews, not an architect. Granted, the same person could wear all of those hats (and in many cases they do), but I view them as separate roles requiring very different skill sets. As an example, I would expect an architect to design a system built in Ruby, even if they've never written a line of Ruby code.
Maybe it's a difference in our definitions of "Software Architecture." Personally, I like this one:
The other thing I'd add is that the system design should account for all requirements - business requirements, user requirements, functional requirements, and non-functional requirements. That last one is critical from an architectural point of view as you're talking about things like scalability, reliability, maintainability, etc.
Great comment, Jesse! I liked a lot of what you wrote. And agree upon all the points!
Sadly, in many companies, they put a lot of decisions that should be made by a technical lead or a business analyst on the architect's shoulders. That is why I put this scope of not-very-architecture-related issues to be known by a software architect.
Thank you for this. It's what I just need at this moment.
I would like you to help me clarify something, though. You wrote: "In some cases, an architect may work in an established enterprise company and hand down instructions on technology stacks to the developers. At the other extreme Agile development, a team may work without the involvement of an architect."
My question: is the Agile development process, and "processes" in established companies mutually exclusive? Put differently, is the Agile development process exclusive of an Architect role?
Just going to offer an alternative POV here.
I have been in an official "Software Architecture" role in a larger company, had to work with software architects in an large enterprise where I worked at one point, and am now a Senior Developer at a small startup. I have been through very rigid waterfall methodologies, and am now involved in very agile DevOps style delivery at my current job.
Through this gamut of experiences, I feel what the most important thing is not necessarily who does software architecture, but that it is thought about and agreed upon before too much development is done. Sure in an enterprise situation, where they can hire someone to "pass on" instructions, the formal role of a software architect can definitely work. In my current position of fast moving, rapidly iterating and evolving code, we have a lot of conversations about software architecture and figure it out collaboratively, which also works.
If software architecture is not considered, or is not agreed to, then a whole slew of problems can arise, that can be worse than if you simply make a wrong choice in the architecture. The most severe I have seen are things like: no scalabilty (as opposed to limited scalability from a wrong decision), unmaintainable code (resulting in massive rewrites), and various culture problems.
So I guess, depending upon why you are asking the question, maybe the answer is "make sure software architecture is considered, and pick a method of making sure that happens that works for your and your team".
Thank you for your comment and your question!
The situation you asked about cannot be considered as the confrontation of the method to the need of a software architect. I'd say, that it is rather an experience that while using an Agile method you don't use a software architect. These two options are not mutually exclusive. You can read about the agile method in my article dev.to/iriskatastic/top-6-software...
You can use a software architect, but it more depends on a complexity of the project. If there's nothing new to implement and you don't need to solve new problems or face something outstanding to develop - you can avoid asking the help of a software architect. In other words, you need a software architect for high-design choices. If there's nothing difficult or you repeat the project you've done before you can use the waterfall or the agile method with no software architect.
Thank you for the clarification. That helped.
Nice, but where can I find such a creature? Sounds like a god among mere mortals :))
Well, honestly, due to the misunderstanding roles and obligations, a lot of companies delegate the duties of software architect to a senior developer. That is a good idea in case of a startup, small business with few developers or just a business where the development task is not original and do not demand the high-level design and new architecture.
But if the need of a software architect really appears, then most of the businesses look for outsourcing. Outsource software development companies do have these specialists to provide architecture. As far as they specialize in this field they have time and resources to grow their own professional software architects.
Whaaaaat?! IMHO my system's structure (all applications that are part of the value chain of my business and how they interact) is the most valuable asset of my business! What company would outsource the role of its creator, a.k.a. the software architect?
You also wrote that a software architect "interact with clients" and I fully agree. But that's just one more reason to NOT outsource this role.
Thank you for your point! That is also true for some companies. But if you're asking 'what company would outsource the software architect role', I will reply - many of them.
As I mentioned in my article, there are many startups that just being started and they can't afford hiring the software architect full-time. But to get off the ground they need the architecture to be considered. That is why such companies outsource the specialist from trusted companies or partners they work with. And this is a good practice.
If we talk about the established enterprises this also takes place in case they do not need the software architect on a daily basis. These businesses usually develop some additional software to the existing product and for this reason, they outsource a software architect.
Nothing strange. This is a common practice too.
I know but the article is describing a perfect world, and a perfect human.
I just hope that the software architects can learn from the Constructions Architect-Engineering physics world relationship and do not make the same mistakes (applying text books and imagination on real world code and apps to a degree that is not feasible or reasonable).
If you want to review code and tell the Devs ops what to do I hope he knows what he is doing and been went trough a lot of projects.
First of all, thanks for this nice write up! Learned a great deal of stuffs.
Here's a query that I have in my mind. What should be the approach when starting a completely new product/service. If it's an established company, then it should already have software architects. What about startups? Would you suggest recruiting an architect from the very beginning or rather build a team of junior engineers, build up the product and then recruit an architect to refactor the existing system?
Thank you for your comment!
When we talk about startups, they do often produce not very complicated software (commonly). So for startups, it's not very necessary to grow or to hire an own software architect. Besides, the size of startup teams often small, and they need to think about developers at first. If the need in a software architect appears, they tend to outsource such kind of a specialist.
On the other hand, if this startup works with something really challenging on a daily basis, they, probably, have to have their own software architect. But this is possible only if the software development team is complete and has all the needed engineers. Do you agree that if you don't have a backend specialist in your company, you unlikely will hire a software architect? So start with junior engineers and then complete your team with a software architect. But that is my opinion.
I've heard about situations when the team started with the software architect who helped to complete the team according to the project needs. So it really depends.
I'd say, that before considering to have your own software architect you need to understand how often you will use him (or her). If this need will cover only one your project - you'd better outsource. If you're planning to deal with different complicated projects that need high-level design and new approaches - you can think of having your own specialist.
Great article!.
Is good to know that I'm in the rigth path to become a Software Architect. :D
This article is amazing. I'm interested in pitching a software architect role to my company and your knowledge will help me define the responsibilities of the role. Great job!
Thank you for the comment, John! I hope you'll find a great specialist using some information I provided in my article! It's very nice to hear the material will have a practical use. Just remember that the scope of duties and skills may vary because every single person tends to have a different mindset. So it's always up to you. Even if the person that applies to your open position doesn't have mentioned experience or skills, be kind and give the person a try. Because all the skills can be learned in the process.
A software architect must also be a continuous learner.
Thanks for the article! Great contribution!
Awesome article.
This is great, thank you for posting!
Thank you for the comment! Nice to hear that the article is useful.
Hello im doing a project in school about being a software architect. I was wondering if anybody knew any important skills that a person should have to be a succesful software architect.
Hi! That is just great! I hope you will share this project as soon as it'll be ready!
Well, in my article I tried to collect and describe some of the most important skills for a good software architect. But, to be honest, this list must be much longer. And what is a pity, this 'ideal' software architect who has all the mentioned skills is a rare person to meet.
This is way too similar to the article on Medium by Nikolay Ashanin, published 23 days before this.
Hi, Sope! Thanks for the comment! Yes, Nikolay, as long as Valentina Donchenko (dou.ua/lenta/articles/software-arc...), Simon Brown (infoq.com/articles/brown-are-you-a...), Mike Rosen (cutter.com/article/10-key-skills-e...) and others inspired me to make this material.