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!).