Solution Architecture dot Org - A Rough Guide to Solution Architecture | ...

http://www.solutionarchitecture.org/Workshop/Professional-development/...

A Rough Guide to Solution Architecture

Written by John Critchley

Wednesday, 07 February 2007 11:32 Article Index A Rough Guide to Solution Architecture What Solution Architecture Does Attributes Of A Solution Architect Knowledge Communication Creativity Solution Architects in the Organisation All Pages 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 whats 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:

Solution Architecture bridges the design gap between business needs and what technology has to offer.
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.

1 of 4

6/17/2011 3:16 AM

Solution Architecture dot Org - A Rough Guide to Solution Architecture | ...

http://www.solutionarchitecture.org/Workshop/Professional-development/...

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): Software Architecture

Designs the functions & modular constituency of software solutions (e.g., a commercial Java desktop application is likely to have been designed by a software architect) Designs the structure of information and the user interfaces & functions to access that information (e.g., Web application user interface design for site navigation) Designs & specifies the hardware & commercial software installations that support an organisations IT infrastructure (e.g., Web servers, database servers, application load-balancing, etc.) Designs & specifies the network infrastructure (routers, firewalls, exchanges, etc.) required to support an organisations IT capability and is a discipline complementary to that of Systems Architect Specifies the processes, methods & constraints on the accessibility of information stored on an organisations IT infrastructure and continuously monitors & audits for security threats

Information Architecture

Systems Architecture

Network Architecture

Security Architecture

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

2 of 4

6/17/2011 3:16 AM

Solution Architecture dot Org - A Rough Guide to Solution Architecture | ...

http://www.solutionarchitecture.org/Workshop/Professional-development/...

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). Its 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 vendors 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 isnt an architect out there who knows everything; therefore a good architect will compensate for this by: Knowing when s/he doesnt 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. Its 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 doesnt understand what has been designed, then probability determines whether s/he will be disappointed by the result. If the constructor doesnt 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 theyre getting; what does the Constructor believe theyre 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.

3 of 4

6/17/2011 3:16 AM

Solution Architecture dot Org - A Rough Guide to Solution Architecture | ...

http://www.solutionarchitecture.org/Workshop/Professional-development/...

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 theres a will, theres 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 customers desired building style. Also, its 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.

4 of 4

6/17/2011 3:16 AM