Solution architecture Checklist!! 2020
In 1996 US software development, 31% of projects failed entirely, 53% failed partially and only 16% succeeded.
After analyze why this was happening, the engineer found that the management methodology called “waterfall” plays a very important role. Waterfall software development follows a very strict way to develop a business software solution. It can take up to months to gather requirements and planning and faults, which will only visible in the testing session. For avoiding this, modern development moves toward iterative approach and more flexible methods like scrum, kanban.
But the methods are not the only things what was responsible, another problem was, understanding the business requirements and give the developer the right guideline according to requirements.
In the late 1990s, there were two roles:
=> Enterprise Architect, who knows all the processes and detail business requirements. This role usually uses a framework like TOGAF.
=> Developer, role mainly focuses on solving mathematical/computational problems.
These two roles have completely different mindsets and different ways of looking into a problem. For solving this communication gap, from the early 2000’s a new role emerging, called solution architecture, A bridge between business and technology.
Checklist for solution architect:
Gathering requirements:
In any software development project, there will be specific requirements sets, stakeholder, business analyst provide these requirements to solution architects.
Requirements are usually divided into the following category:
=>Functional: All functions/services like user log in, user roles, create a report, send an email.
=> Non-functional: Speed, maintainability, security, and others.
=> Constraints: Budget, manpower, time, licensing.
All of the requirements gather by the business analyst and serve to solution architect.
There is another level of complexity can emerge when a new solution needs to be implemented inside the existing corporate architecture. In this case, solution architects need also to gather information about current enterprise technology, business and strategy architect to fit the new solution into them.
Choosing Technology and Pattern:
This is the FUN part!
As a solution architect, it is more often that handle different domain of technologies and their effectiveness. In the beginning, it is really overwhelming to see through this spider waves of the tech stack, Each one has various pros and cons.
Selecting the right tech stack and pattern is vital for any project. Depends on project tech stack and pattern usually team build together.
As a solution architect, you need to select a technology stack, Database, Pattern, Standards and more.
My advice, test any selection before decide, sometimes slightly different options can boost/harm the whole project onward.
A solution architect should have an idea about modern, reliable tech and their subsets, also need to think about money/usability metrics. Ask below question before selecting any technology:
=> Is this serve the purpose?
=> Is the old legacy system compatible with this technology/pattern?
=> Is this a stable solution?
=>Is this opensource/paid and how much does it cost?
=> Is there enough manpower available in the market? talk with HR and get the data from current market supply/demand, also try to predict the market, one good way predicts development market is following different survey conducting by StackOverflow/Github.
=> Is that maintainable?
I have seen the rapid adoption of modern technologies in various fields and an eye-popping growth in them. So be brave in choosing but also care about the current job market. Sometimes, the same result can be achievable by different technologies.
Communication:
The most important part of an architect. You need to communicate through technology and a business person more often. These two have two different worlds and a different mindset. Being good in technology is not the only thing you need to survive. A solution architect communicates through all the teams, from stakeholder to QA, analyzing different requirements and pass information and guidance through teams. It is really important to make a positive mentality all across.
Another really practical advice is” Do not afraid of office politics if it is there, rather handles it in a professional manner”. There can be a difficult situation in a large enterprise when all departments are connected with each other and each department trying to get the best for them.
Some must-read Book:
“Software Architecture in Practice Book by Len Bass, Paul Clements, and Rick Kazman”
“Design Patterns: Elements of Reusable Object-Oriented Software Book by Erich Gamma, John Vlissides, Ralph Johnson, and Richard Helm”
“Patterns of Enterprise Application Architecture by Martin Fowler”
Clean Architecture: A Craftsman’s Guide to Software Structure and Design ( by Robert C. Martin Series)
Certificate matter:
From my personal experience, certificates are the trophy of one person's skills/ability. The certificate helps a lot to get a new job, but in real-world problem scenario experiences and hard work help to achieve the result.
Below two certificates can be a milestone in your software architecture career.
AWS solution architecture path.
Azure solution architect expert
