Although the title ‘Solution Architect’ has been in common use for several years now, and an informal maturity of what is expected has developed over the last 6-10 years, there is still no consistent understanding of what defines the discipline of Solution Architecture.

However, nearly all the complementary disciplines interacting with Solution Architecture (e.g., project management, enterprise architecture, engineering & development, etc.) are fairly well characterised.

We can try to get closer to a definition of the discipline by looking at:

• The pattern of responsibilities attributed to the title ‘Solution Architect’
• The business functional gap that appears to have been allocated to the solution architect where other roles do not appear to cover them

Pattern of Responsibilities

Generally, solution architects have been required where:

• More than one system must be integrated to deliver a cohesive functional solution to an end-user
• A project team involving business analysts (for requirements), at least one project manager (for delivery management) and one or more development teams (for construction) is needed for the solution to be completed
• The gap in the level of detail between the enterprise and constructors is too large to be spanned by simple interpretation into technical specifications
• Specific knowledge and / or experience of highly complex or specialised technology is required, or business integration experience is demanded

This pattern generally points to project-based output by the solution architect, where the business has a specific need, articulated as requirements & a project plan, but where the technical & business integration solution requires a focal point of knowledge & coordination that the various constructors can faithfully work with.

Solution architects are frequently (and should be) involved in the early stages of feasibility, helping to refine the functional requirements that have been generated from high-level business requirements.

Therefore, within a project, the architect will be in close liaison with:

• The Customer (in order to digest, first-hand, the business requirements at a human level)
• The Business Analyst (in order to guide the development of the functional requirements within the constraints of feasibility)
• The Project Manager (in order to provide estimation of effort & risk for construction of the feasible solution)
• The Constructors (in order to refine his/her understanding of the feasibility of the embryonic solution and to capture early any technical issues that can be avoided)

Filling the Gap

The Venn diagram illustrates the logical overlap among the various domains that provide input for solution delivery.

Each domain can be attributed to the roles traditionally involved as key stakeholders in such a project:

• Business Requirements are generated by the Customer (also representing users), facilitated by the Business Analyst and generally define required functionality
• Delivery Parameters are managed by the Project Manager
• Technical Solutions are provided by the Constructors

The union of the three domains define the feasible solution options and will comprise at least part of the overall acceptable solution.

Also, the Delivery Parameters & Solution Options may be influenced or directed by Enterprise Architecture, where this facility exists within the organization.

In order to coerce the comprising elements of the separate domains to form an acceptable & cohesive solution, the role of the Solution Architect is required.

Where this role is not formally acknowledged or filled, its function will typically be distributed among other existing roles, potentially leading to:

• Poor fit-to-purpose solutions (e.g., un-usable or fall short of critical business objectives; none of the key stakeholders are experienced enough to spot a workable solution and opt for a less-than-optimal compromise)
• Deployments that run well over budget and / or time (due to the project manager not understanding the cost of specific technologies, etc.)
• Solutions characterised by a collection of insulated solution divided along system or constructor lines (no single reference for cohesive design and on-the-hoof decisions by the constructor rather than by design)
• Breaking of enterprise-wide conventions and siloed technologies (no one monitoring the fit of the solution to the enterprise architecture / blueprint)

Therefore, Solution Architecture bridges a critical gap among the key domains involved in solution delivery within any enterprise or business, operating at the project-level while keeping a keen eye on the strategic objectives articulated in Enterprise Architecture.

Also, collaboration is a vital component of the discipline, where liaison with each solution stakeholder varies with the stage of the project (e.g., business analyst & customer / user early on; project manager during scoping exercises; constructors during detailed design & construction).

What Solution Architecture Is Not

Before we finally define the discipline of Solution Architecture, let’s briefly explore what it is not:

Enterprise Architecture: Solution Architecture is not Enterprise Architecture and should never pretend to be so; Enterprise Architecture is a complementary discipline that investigates the broader business enterprise & its strategies to generate a blueprint / template / set of directorates for use by project-based Solution Architects to constrain their solution. The EA role and outputs (e.g., ‘blueprint’) relieves the Solution Architect of the task of researching the overall business strategy during a project solution design to ensure strategic alignment.

Technical Engineering: The Solution Architect generally should not be required to generate technical specifications for solution components, although s/he must be knowledgeable of what is required in technical specification and must be capable of easily reading & digesting such documentation. Therefore, Solution Architecture should not be confused with Engineering; if the line becomes blurred, then there is a risk that the architect will become bogged-down in detail and unable to make creative design decisions at the logical / integration level.

Technical Documentation: Solution Architecture should not be used as an expensive technical documentation resource, except in the case of a concerted auditing project. If a role nominated as ‘Solution Architect’ is allocated routine technical documentation work, then the resource should be recognised for what it is being used for; Solution Architecture is creative & constructive, not retrospective.

Definition

Hence, by looking at the responsibilities generally attributed to the role of ‘Solution Architect’ and looking at the set of logical business functions not provided by complementary roles in solution delivery, we arrive at the following definition:

Solution Architecture is the discipline of generating a creative & communicable technical design that aligns a feasible business solution with stakeholder expectation within the bounds of mandated delivery parameters.

Note the presence of the following keywords:

• Creative
• Communicable
• Design
• Feasible
• Stakeholder expectation

These are indicative of the characteristics of a good Solution Architect, the subject of a separate article.