Software architect role is the vaguely addressed topic or at least its detail. In most organization this is one of the not so well defined role. Presumably ends up with either a best developer in the team. Team lead, Manager who was a mediocre developer and now doesn’t wants to code. Someone who loves modeling and good at their presentation skills and not so good writing code. In some organization this role just doesn’t exist. So in this article we will try to uncover the dynamics , traits that are vital to be a software architect.
Many experts believe, a crisis is building on the horizon because improperly trained software engineers. This reminds me of the below quote and this is my personal favorite.
For a number of reasons, especially when small start-up’s or large enterprises are in rush with who hits the market first mindset. Leaving behind not just quality but also security, data integrity not addressed at large.
The crisis may be caused, in part, by the increasing complexity of software projects, the difficulty of managing distributed work, and compressed development cycles. The focus on software architecture at the academia tends to be technical in nature, e.g. tools and techniques, software design & architectural patterns, etc. Recently, there have been efforts to focus on other skills that the architect needs; however the descriptions have tended to be broad without focusing on the operational details necessary to succeed. For example, a guideline might require documentation of the architecture, but exactly how to do that is left to the architect. Unfortunately, without experience or a prior apprenticeship on a successful project, many architects “crash and burn” on their first big assignment without knowing exactly why they failed in their duties.
Individuals promoted from team lead or developer to the role of architect are often completely unprepared for the dynamics of the position. They are often referred as accidental architects
So the question arises here — What constitutes a software architect?
In a nutshell — A software architect is someone who is good at 3 different aspects namely; interpersonal skills, business or domain acumen last but not least solid software engineering skills
In this article, we’d look at misconception of software architect, mistakes of an accidental architect preferably top 5. Then lets describe important technical leadership and interpersonal skills needed to succeed as a software architect.
Misconceptions
Design patterns is software architecture:
When you speak to someone who happens to be an accidental architect. The first thing you’d hear is we follow “MVC”, “MVVM”, “MVP”, “Reactive” etc and all the design pattern’s you could name it. Good architects know when and where to use what. If this sounds surprising, hear me out for the right definition. Design pattern’s is about giving structural conformance to your architecture. Yes architecture is design, But not all design is architecture. We see this word applied more and more frequently to any form and aspect of design.
A few years ago, Mary Shaw pleaded: “Do not dilute the meaning of the term architecture by applying it to everything in sight.”
Architecture is one aspect of the design, focusing on the major elements — the elements that are structurally important, but also those that have a more lasting impact on the performance, reliability, cost, and adaptability of the system. Architecting is choosing the small set of mechanisms, patterns, and styles that are going to permeate the rest of the design and give it, its integrity. Architecture is the tool that allows us to master complexity. It cannot be the whole design. It has to limit itself to a certain level of abstraction but still be concrete enough to draw definite conclusions. It is not just “high-level design.”
What shall the architect focus on, then? There is no universal answer. For any given project, a decision needs to be made about what is architecturally significant so that we can draw that thin and elusive line between architecture and the rest of the design activities.
Implementing the latest and greatest technology
Sadly this is a big misconception. Keeping yourself updated with the latest technology is one thing. Looking at your ongoing project as a playground to test your newly learnt skill is a bad thing. Architecture can be simple yet elegant and robust without having the state of art technology implemented.
Simple can be harder than complex: You’ve to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains – Steve Jobs
As an architect you’ve to question yourself the following before you make that decision of adding a new framework or implementing new technology
- Is this new framework or technology going to have a steep learning curve on my team? End of the day the time, resources is a cost to your application development. Is this absolutely necessary? What is the business value? Some study shows that about half of the users end up using only about 30-40 percent of features in any given software application. The rest 60 to 70 percent remains unused. Additionally as an architect it is very important to find the right balance between technologically driven and thinking from a business standpoint.
- Maturity of the technology itself is crucial. It should be right there in your decision making tree. You don’t want to be in a situation where you’ve adopted some open source framework and after a while the author of the framework stopped working on it or there isn’t going to be any updates. Additionally you don’t want the community of developer to be a limited group.
Focusing solely on the technical aspect
Sadly this happens most of the time because either you as an architect don’t feel it necessary or your business doesn’t feel a need for your involvement. Yet every bit is as important. Such things as the marketing view of a system, licensing terms, branding, deployment, billing. All of these issues have important technical and business implications. As an architect need to think about this stuff, or otherwise a technically capable system could fail to be good business decision.
Architect’s don’t code
If you’re an architect and thinking that you shouldn’t be coding. I’d say stop calling yourself a software architect. You need to be wake up from your slumber. Non-coding architects, sometimes called “PowerPoint architects”, “astronaut architects” or “ivory tower architects”, may use excellent talking skills to convince non-technical stakeholders of their expertise while delegating the unsolved, real problems to developers. Architect is a leadership role. Any leadership role demands leading by example. If you don’t practice what you preach, rest assured you will not earn respect from your team. This will not help the cause of influencing your team.
If you don’t code there is no way you can prevent architecture erosion. A software architect is like a good salesman. Who should be able to sell his architecture not just in powerpoint but also through code – Haseeb Afsar
For organization I’d say get architects involved at an implementation level. They will scream and moan but it’s for their own good. They don’t need to be writing (necessarily) an equal share of production code but they need to get their feet wet from time to time and need to be aware of how changes in their design affect the project.
Team’s best developer naturally is an architect
This is one of the most common misconception you’d often see in organizations. Your best iOS/android/C++ developer naturally doesn’t become an architect. Why is that true? As mentioned earlier an architect is made up of 3 aspects — Business/Domain Expertise, Interpersonal & Solid Software Engineering skills. Also one key aspect which is overlooked, a software architect is agnostic of technology. A software architect shouldn’t be one dimensional.
Technology, programming languages are just the tools and means to achieve your objective that is to build a reliable, scalable software. A true software architect is agnostic of the technology stack.
Additionally software architect is about leading a team of engineers without authority. He/She will be to do that only by leading the team with empathy, earn respect as a leader. It’s not about showing the team you’re a kick ass developer. It’s about showing the team what is a better solution and why they should pursue that. Strong leader’s influence heart’s to meet their objectives. Rather making an obligation on people to do the same.
Now as we’ve looked into the common misconceptions, mistakes of a software architect. There are few more which we won’t able to discuss in this article. Let’s look into the leadership, interpersonal skills of a software architect.
Leadership
You need to be an example for your team, be a person they would like to be. It is also about defining and communicating vision and ideas that inspire others to follow with commitment and dedication. You need to provide direction, and to lead, you need to know where you are going and make the decisions that will get you there. Understanding people is key here as you need to know how to explain your decisions. Let’s look at some of the key influencing factors that illustrates effective leadership in the role of a software architect.
Effective Communication: Having talked with many software architects, I heard that it is one of the most important characteristic of this specialist. During the working day, they have to talk with customers in the language of business, managers of all levels, business analysts and developers. If you have a natural charisma and you know how to convince people, then this will be a huge plus, as it is very important to explain your actions correctly. Architects are laconic, eloquent and competent speakers. The software architects with whom I spoke have highly developed skills in communication and persuasion. Another reason why this characteristic is most important is that the architect in this role participates in most discussion making processes, and often compromises must be reach that are acceptable and beneficial for all involved parties.
Broad and deep technical knowledge: This should be obvious since one cannot become a software architect with a medical background. In addition, the architect usually has knowledge in several technological stacks at a decent level, and should have a good understanding of a few other ones. To elaborate more on this if you’ve someone who is good at only one of the following iOS, Android, Javascript, Python, Swift or any one programming language isn’t qualified to be an architect. He should have fair bit of understanding of the full stack to make complex technical choices.
The software architect should also be prepared to compose a large number of technical documentation, reports and diagrams. If you are a software architect then you should’ve a solid foundation in computer science fundamentals such as Software Design Patterns, Architecture Patterns, Algorithmic design and transforming design into code, modeling UML, Big O notations etc. Fundamentals are very essential especially for the role of software architect because in an ideal world architect shouldn’t be married to one specific technology rather the fundamentals as it is technology agnostic role. A Software architect should be as comfortable architecting mobile application as web versus embedded application. This validates the fact fundamentals never change and thats why it’s vital to have someone with solid software engineering skills which can be applied across a broader spectrum.
Responsibility: You should understand that architect decisions are usually the most expensive. Therefore, 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!
Stress resistance: You will have to make decisions because in this role, you will be asked to do so and you will need response. You will be working with different people from different areas, and you will have to deal with 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 it brings pleasure. So if you choose this role only for the money, title, then think again.
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, is essential.
Flexibility: It is about adaptability, about willing to change, about lifelong learning, about accepting new things. Really, don’t underestimate the ability to adapt to changes. In today’s rapidly evolving business environment, the ability to pick up on new technologies and adjust to changing business surroundings is critically important. Flexibility is an important soft skill, as it demonstrates an ability and willingness to acquire new hard skills and an open-mindedness to new tasks and new challenges.
Interpersonal skills
It is all about cooperation, about getting along with others, being supportive, helpful, collaborative. You should be effective at building trust, finding common ground, having emotional empathy, and ultimately building good relationships with people at work and in your network. People want to work with people they like, or think they’ll like – people who are easygoing, optimistic, and even fun to be around regardless of the situation. Because at the end of the day if you can’t connect with someone, then you will never be able to sell your idea – no matter how big or small it may be.
Critical Thinking: The ability to use reasoning, past experience, research, and available resources to fundamentally understand and then resolve issues. For example, Bill Gates reads 50 books each year, most of them nonfiction and selected to help him learn more about the world. Critical thinking involves assessing facts before reaching a conclusion. Software architects are sometimes faced with a handful of possible solutions, and only critical thinking will allow them to quickly test each scenario mentally before choosing the most efficient one.
Problem Solving: Employers want professionals who know how and when to solve issues on their own, and when to ask for help. Problem-solving does not just require analytical, creative and critical skills, but a particular mindset: those who can approach a problem with a cool and level head will often reach a solution more efficiently than those who cannot. This is a soft skill which can often rely on strong teamwork too. Problems need not always be solved alone. The ability to know who can help you reach a solution, and how they can do it, can be a great advantage. It is also about being able to coordinate and solicit opinions and feedback from a group with diverse perspectives to reach a common, best solution.
Time management: Time management is more than just working hard. It means making the most of each day and getting the most important things done first, priorities. If necessary, the ability to delegate assignments to others when needed is a part of it.
Final Thoughts
- An ideal software architect is not one dimensional. Software architect is made up of 3 aspects Business/Domain expertise, Interpersonal (Presentation, Articulate, Leadership, Collaboration, Critical Thinker, Entrepreneurial Mindset etc), and last but not least solid software engineering skills.
- A software architect should be agnostic of technology. This trait is vital which enables the software architect to choose the right technology for the right use-case.
- A software architect role is a technical leadership role. It is important to practice what you preach, lead the team by example — Show your development how to transform your design into code. Don’t limit yourself to UML’s and presentations.
- New technologies doesn’t have to be part of the architecture if its not required. Software architecture is about keeping things simple and minimizing dependancies.
- Software architects in large organizations could cast a broader scope net during solution architecture development to include organizational change management engineering by using the same principals they are using on the software side, then the overall system (of both applications and users) could achieve a higher level of success.