As Information Technology (IT) has taken an increasingly central role in providing solutions to Business needs, the demand to improve the reliability & quality of these mission critical solutions has also increased.

This has led to a consolidation of the responsibility for solution design from artisan to the dedicated role of architect, mirroring a similar industrial evolution in the Construction Industry over the centuries.

However, irrespective of the recognised need for a design role, Solution Architecture is still largely poorly understood, undermining its value to technology-dependent organisations. This has a direct effect on business efficiency and, thus, the economy.

Those unfamiliar with Solution Architecture may be forgiven for regarding the discipline as too technical for ‘lay’ people to understand. This is a perception sometimes encouraged, unconsciously or otherwise, by the terms & presentation used by its practitioners.

The notion that Solution Architecture is too complicated for ‘the rest of us’ to comprehend is absurd since no one would suggest this about civil engineering architecture, itself a highly complex & technical profession.

Dispelling this lack of clarity is important for two reasons:

• If no one knows what you do, you can get away with anything; without a way to measure role effectiveness, organisations are exposed to exploitation by ‘cowboys’
• If no one understands the value of architecture, no one will buy it; without understanding value to the organisation, senior management cannot be expected to endorse architecture, leading to poor funding or constraints on the role preventing effectiveness, eventually manifesting in poor technology implementations

These are clearly bad for Business and the profession.

The objective of this article is to use the simplest terms to introduce readers unfamiliar with Solution Architecture to the profession by:

• Defining the role of Solution Architecture
• Identifying the attributes of a good architect
• Outlining the role of solution architects within the organisation

What Solution Architecture Does

Most people can appreciate that, before starting to build something, it often pays to think about what’s being built and how it can be built.

Similarly, construction in the ICT  industry requires thought, analysis and design, the product of which is ‘the solution’. Ideally, the solution is defined by business requirements (what is needed), project constraints (such as funding, resources & time), and available technology options.
The overlap of these three influences is the logical solution, as illustrated in the following Venn diagram:

The selection, design & specification of the solution are the responsibility of the Solution Architect. In the simplest terms:

For complex technology solutions, this set of responsibilities cannot be duplicated by any other role, a role that returns dividends on the investment of time & money.

Attributes Of A Solution Architect

Based on our simple definition of solution architecture, architects must be conversant with both members of the business community (managers, analysts, etc.) and with technologists, in their native terms, whilst utilising keen creativity to generate effective design.

To fulfil these expectations, the solution architect must possess excellent communication skills coupled with deep technical knowledge through the medium of creativity. Creativity is an essential personality trait that allows the architect to leverage experience & knowledge as design.

This section will explore these fundamental attributes of a Solution Architect so that:

• Those unfamiliar with solution architecture can appreciate its value to their organisation
• Those seeking to hire an architect can identify candidates with the necessary skills & attributes, tempered by the specific needs of their project or organisation

Knowledge From Experience

Solution Architects are nearly always hired for their technical expertise. Technical expertise can be decomposed into the three dimensions: technology, domain & depth of experience.

The ‘depth of experience' dimension can be measured in time practised or a certified qualification; we won't be exploring this any further.

Civil engineering architects who design skyscrapers are required to solve very different engineering problems to those who design dams. This division of problem solving also applies to Solution Architecture, where these divisions are called ‘Architecture Domains'.

The following diagram illustrates how Architecture Domain and Technology intersect to produce the technical expertise for a given solution architect.

An architecture domain reflects the ‘how' of solving a type of problem, whereas the technology refers to ‘what' is used to solve a specific problem.

Architecture domains are classifications of the patterns & methods that can be applied to a type of problem-solution ‘space'.

Domains have matured informally over a number of years along the lines of the ‘way of thinking' (philosophy) needed to solve problems or commonsense technology boundaries typical of the solutions. Recent efforts have started to formalise these specialisations.

Examples of architectural domains are (not an exhaustive list):

Architects specialising in a specific domain will usually adopt a related title (e.g., Software Architect); these can be generically referred to as Domain Architects.

A Solution Architects differ from a Domain Architects in that they are commonly responsible for the design & specification of an end-to-end solution, tying together patterns from more than one domain.

Therefore, experienced solution architects typically have expertise in more than one domain. For complex design projects, one or more domain architect(s) may be needed to support the (principal) solution architect, responsible for end-to-end design.

Also, architects will have detailed expertise in a range of specific technologies (e.g., J2EE, Oracle, etc.) that can be directly mapped to their domain(s) of specialisation. The technology may be vendor-specific (e.g., Oracle) or more general (e.g., Web services).

Qualification of Knowledge

As the profession has matured, formal definitions of the methods & processes in developing solutions have become available. These are referred to as ‘frameworks’ or ‘methodologies’, and may be generally adopted as the way architecture is ‘done’ within an organisation as a whole (defined by Enterprise Architecture).

There are several institutions that have formulated courses to qualify architects in one or other framework or methodology. As with any qualification, these allow employers & colleagues to readily estimate the work-product quality & efficiency they can expect of an architect.Examples of (enterprise) architectural frameworks include TOGAF™ (currently in revision 8.1) and the Zachman Framework.

Examples of methodologies include the Unified Process (most often seen in the form promoted by IBM® Rational® as RUP) and SSADM (currently in its revision 4.2). It’s worth noting, however, that, although helpful in achieving consistent & reliable results, these frameworks should never replace the creativity of the architect.Architects may also have acquired qualifications from technology vendors (e.g., Microsoft® Certified Architect) that focus on the technologies of that vendor, improving the speed & quality of designs when incorporating the vendor’s technology.

Arguably, however, this could result in narrow design ‘vision’ by the architect, who may tend to design solutions compatible with the qualifying vendor. The product of this design approach is commonly referred to as ‘closed architecture’.

Knowledge Acquired By Research

There isn’t an architect out there who knows everything; therefore a good architect will compensate for this by:

• Knowing when s/he doesn’t know (and is big enough to admit it to him/herself)
• Finding a source that does know
• Knowing how much to trust the source that says it knows (and persisting with ‘discovery’ until confident that there is nothing more to know)

Research is an invaluable skill for an architect looking for information, complemented by good judgement to know when to rely on a source; the Internet has proven itself an indispensable research tool, supplemented by applications such as Google & Wikipedia (and, of course, SolutionArchitecture.org!).

Communication Skills

All projects start with a need expressed as requirements, whether these are articulated in a formal document or presented as a chaotic jumble in an email. An architect will be able to:

• Read requirements and immediately grasp at least the gist of what is needed
• Challenge ambiguity and assist in the refinement of requirements
• Determine the feasibility of technology to satisfy requirements
• Specify the solution in terms that are clear to the readers

These functions depend on the skill of the architect to build & maintain good relationships, write documentation and present effectively to an audience.

Relationships

Architects are very much an integral component of the relationship chain from problem to solution. They must be capable of earning the respect of those who rely on them:

• The customer needs to trust the architect with their vision or to solve their problem
• The constructors needs to be confident in the technical choices of the architect & his/her ability to specify a cohesive end-to-end design, especially where design crosses several teams
• The project manager needs to know that the architect is reliable & accurate when making planning estimates

The mix of human natures in the span between ‘the business’ (customers & users) and technology constructors is complex, requiring the architect to know how to interact with each. This demands a high calibre of social skills, similar to those of a project manager.

Persuasiveness & negotiation skills are also valuable assets for an architect. These are best complemented with logical argument supported by well-researched facts & excellent presentation.

It’s natural that everyone wants to appear to be the originator of the solution, especially when the kudos value is high. With everyone fighting for a prize that is generated from within the architecture function, the skill of diplomacy is a strong bonus. Egotistical architects are never popular.

Documentation

All architects must be able to articulate their designs so that both constructors & customers can understand them.
If the customer doesn’t understand what has been designed, then probability determines whether s/he will be disappointed by the result.
If the constructor doesn’t understand the design, they are likely to ‘patch’ what they believe the design to mean, resulting in a potentially chaotic implementation.
The following are key to effective communication of design:

• Consciousness of the different solution perspectives (e.g., user, business manager, administrator; database developer, software developer, network engineer, etc.)
• Meticulousness in ensuring cohesiveness of design across the different perspectives to avoid ambiguities or confusion
• Continuous monitoring of design interpretations (e.g., what does the Customer believe they’re getting; what does the Constructor believe they’re building)

Typically, architectural documentation are liberally scattered with relevant diagrams & illustrations, often in a form standardised by a ‘framework’ or ‘methodology’. This improves the efficiency of specification and reduces the chance for ambiguity to creep in.

Presentation

Architects are frequently called upon to present material to group audiences, performing duties such as leading workshops and presenting design proposals.

The audiences of these can range from senior business management to graduate intern Java coders, so audience consciousness, articulation and clear diction are often in the toolbox of a good architect.

Workshop leadership requires firmness, tact & time-consciousness. During workshops, the architect will be able to rapidly detect non-issues, issues that need to be recorded & tackled later and topics that need to be addressed immediately.

Since architects must evoke confidence in their presented designs & proposals, the quality of preparation, as well as appropriate dress code, are hallmarks of a professional solution architect.

Creativity

Creativity is a difficult attribute to define, but remains, nonetheless, one of the most important markers of a good solution architect.

In short, the creativity of a solution architect will be expressed as the abilities to:

• Connect knowledge with need
• Spot & utilise patterns
• Avoid formula constraining the solution (even those of qualified frameworks)
• Spot & utilise opportunities (e.g., improve design, improve business, synergies, etc.)

The best architects will rarely state something cannot be done, preferring to adopt the mantra “when there’s a will, there’s a way”.

For problems that appear to be without solution, this is usually the product of perception, where adjustment of viewpoint or some conditions will often reveal a solution.

Value To The Organisation

Roles are only created when gaps appear that cannot be filled by other resources or roles and that to return obvious value to the organisation. With increasing dependence of businesses on the products of the ICT industry, Solution Architecture has filled a valuable role in both the product development chain and intervening between business & technology, acting an ‘interpreter’.

The interpretation demanded is that of business need (often articulated by a Business Analyst) to viable technical solution (implemented by technology Constructors). In addition, the Solution Architect has assisted the Project Manager to assess risk, identify required resources & estimate cost in the planning of technology implementations projects.

Therefore, the Solution Architect fills the void among the roles of Project Manager, Business Analyst & technology Constructor, as illustrated in the diagram below.

These roles have direct parallels in the civil engineering construction industry, with the exception of the Business Analyst, which could be associated with the role of Surveyor.

As with the building industry, without the critical role of architecture, technology solutions have a tendency of failing in their business objectives, an unfortunate norm of the last few decades of IT implementations.

Hiring A Solution Architect

Solution architects may be hired either to facilitate a specific project that includes a large technology component or to act in a permanent capacity to support on-going technical design.

Project-based solution architecture commonly utilise contractors for terms between 6-18 months, where, the scope of work is usually well-defined & approved funding finite.

Permanently employed solution architects are typically recruited by a consulting or professional services organisation, where the services of the architect are subcontracted or outsourced to service the technology implementation projects of other organisations.

In general, the skills & experience of a solution architect are usually only required for projects of defined scope & duration. This is a characteristic differentiator between Solution Architects & Enterprise Architects, where the latter is a strategic & management role.

Solution architects are often selected & hired on the basis of their reputation & relevance of the pedigree of their experience, set against the specific needs of the hiring organisation. Again, a parallel can be drawn from the civil engineering construction industry, where architects are engaged for specific construction projects and often invited based on reputation & match of experience to the customer’s desired building style.

Also, it’s worth noting that solution architects are creative, multi-disciplinary and often desire variety in their work. Project-to-project work suits this personality, although this observation is too general to apply individually. This does not necessarily apply for domain architects, especially those that are more closely aligned with a critical business function.

For example, one will often find permanently employed network architects maintaining existing, as well as building new, network infrastructure. Similarly, a software vendor is likely to retain the permanent services of software architects.