Solutions Architect

A Software Solutions Architect has skills and a great amount experience in sharing and communicating ideas both verbally and in writing to executive staff, business sponsors, and technical resources in clear concise language.  Thouroughly familiar with software engineering and software engineering processes, the Software Solutions Architect is the person who organizes the engineering effort of a project by working closely with programmer team leaders. The Software Solution Architect is responsible for the the overall vision that underlies the projected solution and transforms that vision through a clear and concise design. The Solutions Architect becomes involved with a project at the time of inception and is involved in the the Functional Analysis (FA) and developing the initial requirements. They then remain involved throughout the balance of the project, often, as the Project Manager in the same way many building Architect firms remain the construction project's Manager.

The Architect's role is to convert functional requirements into a technical architecture and design that will become the blueprint for the system being created.

All too often, "Solutions Architect" is a role fulfilled through internal promotion offered to the best developers in an effort to retain them and to offer clients the services of a Software Solution Architect. Unfortunately not many developers have the broad-based experience and skills that make them a good Software Solutions Architect.  Many Start-ups mistake strong technical skills for compentancy in other areas.  Most younger programmers have only had one or two minor jobs if that many. They come straight out of school and have not yet had the time and opportunities to learn the skills that a Solution Architect needs to know to be effective.

This mistake is most often seen in smaller web development companies. At the beginning of an internal project the owner or CTO tries to take on the role of Solutions Architect because they have intimate knowledge of the business. The problem with this is that they can only play the role and cannot do the job. Typically when this happens they create a gap in the development process, one that either leads to delay after delay,  projects being dumped or just plain failure.  To try and band-aid the whole in the development flow they consistently expect their programming staff to do the tasks that a Solution Architect should be doing.  Sometimes they hire Senior programmers with the mistaken understanding that it is the role that is missing in the development cycle. This does not work and in most cases because programmers are very sensitive to being forced to do things that are really outside of their domain and knowledge it causes friction and disapproval of the managements decisions. They are even more sensitive to pet projects that have no clearly defined requirements and design and get handed off from programmer to programmer because of  managements lack of comprehension of the true cause of the projects development failings.

It is important to understand that misinterpretion of roles and job specification  can lead to the failure of many projects  because the developer assigned to position may have no understanding of business concepts, organizational skills, interpersonal communicative skills, and understanding of internal politics between business and IT departments. Remember the stereo-typical asocial programmer that lives in his mother's cellar? Yes, they do exist. Imagine having someone like this in a position where they are expected to speak to the organisation and it's clients. The larger question is if they are doing the SA's job do they have time over to do any actual programming?

The Software Solution Architect who is assigned to work with the business stakeholders, business analysts, and the engineering team should be the one whom best fits the client's business domain. This is to assure consistency in the transformation of business requirements into technical specifications.

This process is just part of the Software Solution Architect's role, which is very often misunderstood and underestimated in its importance and complexity. Just like in architecting a high-rise building, creating effective architectures to create a software solution requires the careful balance of dozens of engineering concepts and principals. In the case of software architecture, concepts such as domain driven design and design patterns are essential parts of creating a proper solution.

Getting everyone on the development staff on-board and satisfied with the architecture is a critical component of the software development life-cycle. Challenging and inspiring co-workers to learn and do new things and being able to see what resources are available internally is a constant goal.

As a Solution Architect I frequently do research on the better technologies and engineering practices that result in the most cost effective, long lasting solution. I take a look at both commercial and open-source offerings. I take the time to learn new technologies by deploying, prototyping, and testing new and old technologies. My clients get a solution or solutions that will provide a long-lasting, maintainable platform that meets, or exceeds, in the areas of performance, adaptability, and reliability.