From first principles, a business solution (assuming that one does exist) should look like it is the answer to the original business problem, although it may not be the only possible answer. The role of the Solutions Architect, hired by an organisation with a business problem, is to develop a solution, or set of alternative solutions, to solve that business problem. However, before developing any solution, it is imperative that the problem be understood, and so the first and arguably the most important prerequisite to developing the solution is for the Solutions Architect to adopt a business analyst perspective and apply systematic deconstruction techniques to the problem as presented.
Once analysed, the business problem is made available to the scrutiny of the stakeholders and can then be agreed by all. This stage in the development of a solution is of utmost importance because there is always room for misunderstanding … and it’s possible that the analysis shows that there may not be a problem at all.
The problem definition provides the outline framework for managing the solution. In a predominantly waterfall environment, where the cost of errors and misunderstandings increase with time, it is crucial for the problem to be understood at the outset. Whilst an agile approach can reduce this risk, it is still vital that there is a clear direction. Agile can provide a development framework capable of responding to the changing needs of an organisation but without an architectural vision, its direction is not guaranteed.
There are many approaches to “getting it right”, and an even wider array of qualifications attesting to the fact that one can indeed “get it right” when demanded by the situation but do the plethora of specialities and qualifications relating to those specialities imply a change in the underlying technical processes or in the mindset of the practitioner?
The solution architect function – taking ideas, operational needs and specific requirements and turning them into specifications of features and services that can then be developed and delivered – has existed in one form or another for many a year whilst the “Solution Architect” as a job title has not! The question is: does the appearance of “Solution Architect” as a role imply that the responsibilities of the modern “Solution Architect” are broader than that of the pre-dating solution architect function? There are certainly more certificates to be had, but does the expansion of the qualification landscape necessarily indicate an equivalent expansion within the related technical knowledge base?