Most vendors & hyperscalers have a published design framework, such as the ‘Well architected’ or ‘Cloud adoption ’ approaches.
These can be used to guide an architect through common considerations and silos while developing a presence of the respective platform.
There are also architecture methodologies such as Agile, Zachman, & TOGAF that an architect could be expected to a hereto. However, from a field perspective, the objectives are always very similar.
A solution architect is responsible to guide a company to safely place data on a platform, and provide an application/environment/solution to a known SLA.
Regardless of the methodology, a solution architect needs to;
- Gather what is important, and needed, understand what the issue & status / business need.
- Understand the commercials of business costs, risks and people involved.
- Protect data and devise a solution with a form of transition that minimises impact.
- Understand operational impact
The aim for a solution architect is to;
Develop an agnostic approach that fits into business, technology that will integrate with multiple vendors, projects, companies.
How does a solution architect use a design methodology?
What methodology or framework do you use?
This a common interview question for a solution architect position. It is important to a business, specifically project teams and leaders from a business perspective that a solution architect is more than tech-savvy but can also slot into a live project, provide tangible value and communicate with others effectively. This aspect is very often over-looked by technical specialists seeking to transition to a more design focused role. A design methodology can be used to provide an architect some structure and process towards reaching a business goal.
Having studied a number of certifications and methodologies over the years, a run through of ‘what is actually required from a solution architect’ very rarely appears within the blueprints. Job descriptions are nearly always technology focused, or state years of experience rather than what is needed within the job function. In many cases, hiring managers may not fully understand the role themselves.
Developing your own field skills is needed and in the busy context switching life of a technical solution architect, you will need to do this between business and technical subjects/personnel quickly and with confidence.
Some project teams will start simply by downloading or buying methodology templates, or use very long in-house styled documents, others use the headings from vendor consideration pillars expecting the solution architect to do the rest.
Having a generic way of working across projects that helps to move a project from vision to implementation with smooth operational management is key. It also helps having this approach when you are working on numerous projects at the same time. You just work to your process and focus on what is needed.
You can be in a project meeting room with 5 business stakeholders and technical specialists, a very experienced technical person could be asked a question and suggest the same design choice as a solution architect would, however may not be taken as seriously as a solution architect with artifacts, using relatable terminology, and business explanations. At first glance, these skills may seem easy or irrelevant, but they are important to show value as a solution architect and prepare yourself for the project journey.
Understanding opportunities where a solution architect can add value to across the project lifecycle is useful.
An example of a generic process alongside example activities or outputs is shown in the below diagram.
