According to CNN Money/PayScale, software architect is the No. 1 job in America due to “big growth, great pay and satisfying work.” Add in new techniques and trends like microservices, reactive, and containerization and I think we can all agree, it’s a good time to be involved in software architecture.
Our upcoming software architecture conference focuses on the skills needed for all of those individuals working in and around software architecture, not just those with the official job title of “software architect.” And those skills are many! So, regardless of your title—solutions architect, developer, team lead, or devops engineer…
Source: How to find the right guidance on software architecture – O’Reilly Media
The role of a Solution Architect (the above quote regards Software Architects) is normally found rather ambiguous by non-technical decision makers, but whose businesses are being transformed (or disrupted!) by Information Technology. This lack of understanding often leads to lack of appreciation of the need for one, resulting in failed projects that suffered from blindsides right from the design phase.
There are two words in the term, “Solution” and “Architect”.
Why do you need an architect when you are constructing a building, especially a complex one like airports, hospitals or factories? Most non-technical decision makers have been given the impression through many movies and legendary tales that great software is written by lonely geniuses who work night and day during an intense period of divine revelation. Such works of ingenuity are very rare and mostly narrow and highly specialized in scope. More often than not, IT solutions are produced by teams of developers adhering to certain processes and disciplines. This is a very important distinction.
Continuing with the analogy, a construction team may include a few really good craftsmen – expert wood workers, for example. In the IT world these expert artisans would be equivalent to programming wizards or other niche specialists – and there are so many areas of specialization in IT.
The important thing to consider is that not all expert wood workers are good at building entire factories or airports or hospitals. These complex buildings require an amalgam of diverse skills, normally acquired not only through formal education but also through hands-on “working in the mud” experiences which include not only working with technologies but with other people – your customers, developers, project managers, users, etc.
Like a building architect, a solution architect must not only be good at designing the entire solution, but also at implementing it. Furthermore, the solution architect must be able to communicate well with various types of audiences – elderly and not-so-technologically savvy decision makers, authoritative project managers who may have the ability to keep pushing the development team to meet deadlines but do not have the necessary skill sets to assist the team (for example, on how to protect the developers from working under unsustainable pressure by prioritizing work according to the technological risks and payoffs at particular stages of a project), young and extremely confident programming wizards who may be sold on particular technologies. The solution architect must ensure that the design will work, that it can realistically be implemented, that compromises are made where necessary to kitigate risks and are understood and optimal, the technical decision is shared or at least understood by key decision makers including all its ramifications, and equally shared and committed to by the development teams, not just shoved down to them.
Many decison makers need to overcome the impression that great solutions are developed by a genius holed down for a week in some basement. In many cases, expert artisans may not understand the architectural issues involved although they may be unbeatable experts in their own field of skills.
As opposed to “Software”, a Solution Architect has overall responsibility for the entire solution, not just its software component. That includes hardware, networks, storages, virtualization, fault tolerance, telecommunications, mobile components and other ancillaries that may be involved such as sensor and instrument interfacing.
To summarize, a Solution Architect is a person to whom a business owner or the CEO or the CIO may turn to and say “I don’t know much about technology but I know that we need to be able to do this with IT. I have a business to run (or the CIO might say, I know the tech but have too many things on my plate), so can you please take care that we get what we need at the end of the day with this sytem.”
The Solution Architect is the person who puts design, people, processes, risks, etc into a blend that works optimally together to deliver the business case for having the solution in the first place.
For a real world example, here is the job specs for the last time I was engaged as a Solution Architect. It doesn’t say much but it embodies the message mentioned above.
Reporting directly to the Project Steering Committee, the candidate shall be handling the following scope of work:
- responsible for the underlying architecture for the entire solution
- have ownership of the implementation of the project plan
- overseeing the work being done by any other engineers/developers working on the project
- carry supervisorial responsibilities in delegating work to development team members
- provide assistance and technical support to engineers/developers on the development team
- act as a mentor for engineers/developers on the development team
- assist the Project Manager in ensuring that the projects come in on time and under budget
- serve as technical adviser to the Management
- provide technical perspective on requirements and design
- as an interface between the engineers/developers and management