ServiceLine White Papers

Printer Friendly Version 

Recruiting, Developing, and Retaining Solution Architects – The Lifeblood of Technology Professional Services

- by Thomas E. Lah, Executive Director, TPSA

Solution Architects have become the critical path to a PS organization's ability to successfully scale the business. This article thoroughly defines the role of the Solution Architect, discusses the factors to consider when sourcing and developing Solution Architects, and presents several industry benchmarks related to this increasingly important role.

1.0 The Lifeblood of Technology Professional Services

The term Solution Architect has been used very differently by professional service organizations. Typically, this job title is attributed to very senior technical consultants who are a critical resource when scoping, designing, and ultimately delivering a complex technical solution. At times, this role is named Technical Architect, Senior Technical Consultant, or even Practice Lead. This section provides a set of definitions and frameworks that clearly define the role of a Solution Architect within a technology professional services organization.

1.1 Definition of the Solution Architect Role

The Solution Architect in a technology professional services organization is ultimately responsible for designing a technical solution that can be implemented successfully at the customer site and that meets the customer’s business needs. To accomplish this role, the Solution Architect must have a clear understanding of the capabilities of various technologies and the risks of implementing them. This person must also be comfortable translating technical capabilities to meet business needs.

In the compensation and market rate studies conducted by TPSA, the following position description is used when collecting data for a Technical Architect:

SERVICES DELIVERY: TECHNICAL ARCHITECT
The Technical Architect will be responsible for designing and delivering customer solutions for the professional services organization. This person has primary responsibility for the technical viability of a customer solution.

The Technical Architect will work with the sales staff, other delivery consultants, partners, and sub-contractors to successfully scope and deliver customer solutions. Key activities performed by the Technical Architect will include:

• Technical solution design
• Delivery process definition
• Migration planning
• Performance tuning
• Schedule management

This position reports directly to the Regional Delivery Manager.

Key metrics. Like every member of the professional services organization, the Technical Architect will be evaluated on the ability of the business unit to meet revenue and contribution targets. Additionally, the Technical Architect will be evaluated on the ability to successfully design and implement customer solutions. Specific evaluation metrics will include:

• Project Completion Ratios: the ability to help the company deliver target solutions on time and on budget
• Billable Utilization
• Project Profitability
• Customer Satisfaction

Qualifications. The successful candidate will have:

• Computing degree or equivalent programming/system design experience
• The ability to quickly learn new concepts and technologies and convert them into customer solutions
• Strong documentation skills
• Willingness to travel 80%
• Required : B.S. or B.A.
• Preferred : B.S. or B.A. in Computer Science
• 7+ years of work experience
• 3+ years working in the services/consulting industry
• Required: prior experience in a customer-facing position with a computer vendor
• Preferred: prior experience with geographically dispersed development teams
• International experience a plus

We can expand on this thorough job description by leveraging a wonderful article by Robert Bogue titled The Anatomy of a Software Development Role: Solution Architect. Mr. Bogue’s article provides a descriptive overview of the Solution Architect role:

The essence of the Solution Architect (SA) role is the conversion of the requirements into an architecture and design that will become the blueprint for the solution being created. This conversion is based largely upon the previous design patterns that the SA has been involved with in the past through reading and staying abreast of the latest techniques, or through personal experience.

It is this conversion part of the role—the role of the SA—that most often is underestimated in its complexity. Just as the ability of the Functional Analyst to create a requirements document is one part science and rote procedure so is the creation of the architecture. The rest, however, is an art form. Creating effective architectures to create a solution requires the careful balance of dozens of development concepts ranging from "Keep it Simple Stupid" to "Fail Safe."

In the process of converting requirements to an architecture there are often parts of the SA's role which seem out of place. For instance, there is often a fair amount of research that happens during this phase. The research may be targeted at testing a technology that will become critical to the architecture.

In addition to research on technologies and approaches critical to the architecture, there is often a review of patterns that might be useful to the architecture. Reviewing the pattern allows the Architect to refresh their memory on the details of the pattern and to evaluate what additional guidance they will have to provide if they choose to use the pattern.

The final component to the role of Solution Architect is the motivation and guidance of the development leads. Development leaders need to buy into and accept the architecture, to know how the pieces will fit together at a high level. They must also see the art portion of the architecture to get an appreciation of the subtle nuances of their portion of the architecture. It's the art portion of the architecture that makes it elegant. That elegance helps to maintain cohesion between various parts of the design and encourages simplicity. It is necessary for the lower-level design and approach to match the higher-level architecture for the solution to be cohesive. Once the development leader has internalized their portion of the architecture the SA must continuously motivate and reinforce the good work that is being done. They must continue to motivate the Developer Lead(s) to push through tough issues and create the solution.

1.2 The Solution Architect and the Proposal Process

With a thorough definition of the Solution Architect role in place, we can now turn to the role of the Solution Architect during the proposal process. A successful proposal process for a solution offering should meet the following four criteria:

1. The technical solution proposed can actually be implemented.
2. The project can actually be implemented in the time frames proposed.
3. The customer feels they are paying a fair price for the value they are receiving.
4. The company can make money implementing the solution.

Ultimately, the Solution Architect is responsible for the first item: designing a solution that can actually be implemented. However, the Solution Architect most likely does not have complete visibility into resource availability and other potential project constraints. This is the responsibility of a project manager. Also, the Solution Architect should not be responsible for determining what the customer is willing to pay for the solution. This is the primary responsibility of the sales representative. Finally, the targeted profitability for implementing the solution will be a function of the price the customer pays and the cost of the resources allocated for implementation. Once again, these are parameters over which the Solution Architect typically does not have strong control. So in conclusion, a successful proposal process should involve three key resources: The Solution Architect, the project manager, and the sales representative. Each one of these resources has unique responsibilities to assure that the proposal is successful. These dynamics are summarized in Figure 1: Iron Triangle of Proposal Success.

Figure 1: Iron Triangle of Proposal Success

1.3 The Solution Architect and the PS Hourglass

The final step in an overview of this role is to discuss where the Solution Architect skill set fits into the overall professional services organization. In Mastering Professional Services (Lah, 2005), a concept was introduced concerning the notion that Solution Architects have become the critical bottleneck in scaling technology professional service organizations:

The problem with subject matter experts is that there aren’t enough of them. When you shake the recruiting tree, twenty don’t fall out. Get used to this shortage—it will be getting worse in the next ten years.

To help offset this shortage, a professional services organization must think about managing an hourglass. Figure 2 introduces this model. At the top of the hourglass are front-end sales resources that sniff out new deals and verify initial deal qualifications. Is the customer serious? Is a budget established? At the bottom of the hourglass are junior-level delivery staff or subcontractors that are qualified to deliver components of the complex technical solution. In the middle of the hourglass are the subject matter experts. The trick is to shield these hard-to-find SMEEs from involvement in every sales call and every project status meeting. In other words, keep the SMEEs away from the edges of the hourglass. Figure 3 shows how sales-channel partners and delivery subcontractors are used to expand both the top and bottom of the hourglass. This expansion is all about creating leverage for the expertise locked in the bodies of the SMEEs. Figure 4 is a detailed breakdown of how geography-based sales staff partner with subject matter experts to manage service opportunities.

Figure 2: The PS Hourglass

Figure 3: Expanding the Hourglass

Figure 4: Managing Opportunity

I believe a common mistake being made within many product companies is in their general approach to building the PS business. The product company attempts to build out practices by hiring senior partners who then add junior staff beneath them. This is the classic PS pyramid model David Maister wrote so eloquently about in Managing the Professional Services Firm. However for a product company looking to build out their PS Organization, this model often doesn’t work. The leverage point is no longer senior partners who sell but subject matter experts who design.

The criticality of the Solution Architect role outlined in Mastering Professional Services is validated in TPSA benchmark data. The TPSA benchmark study asks the following question:

What delivery positions do you consider core to your professional services organization and need to be sourced directly?

The Solution Architect continues to be the most often-cited role that needs to be sourced directly:

So far in this PS Insight, we have clearly defined what Solution Architects are, the role they play in the proposal process, and where they fit in the PS organization. Now, we want to turn our attention to the three business objectives that every PS organization has regarding the sourcing of Solution Architects.

2.0 Business Objectives for Sourcing Solution Architects

Global PS organizations typically have the following business objective regarding the sourcing of the Solution Architect role:

1. Secure enough qualified individuals to enable the selling and delivery of the professional services portfolio on a global basis.
2. Keep expensive attrition at a minimal.
3. Keep the technical skills sets of these professionals relevant to marketplace needs.

2.1 Maximum Reach

Joseph Walton, an EMC executive, had one simple mantra for his service organization: ”Global, Scalable, Consistent.” In other words, Mr. Walton wanted the EMC service organization to consistently deliver service offerings anywhere in the world. To accomplish this objective in the world of professional services, the PS organization must be in a position to apply competent Solution Architects to service engagements anywhere in the world. This may involve training Solution Architects in every country where the company does business. This may involve flying Solution Architects from larger markets into smaller markets. Or, it may involve leveraging Solution Architects remotely. However this is accomplished, successful customer engagements require the insight and expertise of seasoned Solution Architects.

2.2 Minimal Attrition

The cost of attrition for any skilled position is high. Staffing firms like Adecco quote the cost of attrition at 1.5 times the annual compensation for that position. This accounts for recruitment fees, lost productivity, and lost revenue. Applying this multiplier to the role of Solution Architect is telling. We know from the TPSA 2007 compensation study that Solution Architects, on average, have on target earnings that are 30% higher than a standard technical specialist. Attrition in the Solution Architect ranks can quickly become expensive.

2.3 Relevant Skills

Finally, PS organizations need to employ Solution Architects that have the technical and business skills relevant to customers and relevant to the solutions being driven by the company into the marketplace. You could have lots of Solution Architects on the payroll that never leave. In other words, you meet the first two business objectives of maximum reach and minimal attrition. However, if these Architects have dated skills, they become an expensive liability. If Solution Architects do not have skills relevant to customer needs, resource managers do not assign the Architects to billable customer engagements. As billable utilization goes down, the profitability of the PS organization is impacted—immediately.

3.0 Sourcing the Solution Architect Role

The previous section outlines three main business objectives professional service organizations have regarding the sourcing of Solution Architects. This section discusses the process of acquiring Solution Architects and placing them into the global organization to achieve maximum reach.

3.1 Acquiring the Solution Architect

There are five natural pools where a professional services organization can look to hire Solution Architects. Each resource pool has advantages and disadvantages:

In the future, TPSA intends to query member companies to determine what talent pools are most commonly used when resourcing the Solution Architect role. That data would be an interesting insight into how much energy technology companies are investing in developing new talent vs. hiring existing talent from the industry.

Driving Maximum Reach

Once Solution Architects are hired, companies must decide how they will be leveraged. There are three places where the Solution Architect could be placed:

1. Corporate Practice: The Solution Architect becomes a roving expert who is leveraged by multiple geographies for onsite engagement with the customer. The objective is to support local delivery staff until they are competent on a specific solution. In this placement, travel requirements are high and billable utilization is often low due to the amount of global travel and pre-sales support being provided by this role.
2. Geographic Practice: The Solution Architect is dedicated to delivering in a specific geography. Travel requirements may be lower as the Architect is not required to travel between geographies. Billability will tend to be higher.
3. Centralized Competency Center: The Solution Architect is part of a centralized team that provides technical support to multiple geographies remotely. Travel requirements are low to minimal. Billability is expected to be high as the Architect is leveraged into projects across multiple geographies.

Where the Solution Architect is placed will be based on the scarcity of the expertise and the nature of the solution offering. Centralized competency centers offer the greatest leverage of the expertise but may not be practical if the solutions being supported require significant onsite interaction.

4.0 Enabling the Solution Architect

We can’t leave the topic of sourcing Solution Architects without some discussion of how to enable people in this role. Solution Architects are not born, they are developed. The questions are: what skills need to be developed, and how can they be developed?

4.1 Hard Skills

The specific technical and process knowledge a Solution Architect needs to know will obviously vary based on the technical solutions they are supporting. In the core TPSA benchmark study, we ask companies what training and certifications are most valuable to them:

What specific training courses or certifications are the most important for the success of your delivery staff?

Companies are very interested in delivery resources that have formal project management certification (PMP, PMI). After this general requirement, certified security professionals (CISSP), ITIL experts, and certified information system auditors (CISA) are the most common formal certifications.

Figure 5: TPSA Benchmark Study: What training courses and certifications are most valuable for the success of delivery staff?

4.2 Soft Skills: Creating an Attribute Inventory

What soft skills does a Solution Architect need? A common technique to identify this softer side of the skills equation is to create an attribute inventory. This is a technique that starts with the job description. With that job description in hand, hiring managers can be interviewed to determine what they really want or need out of the Solution Architect role. That interview data is used to create a detailed attribute inventory. That inventory can be validated against high-performing Solution Architects to verify these are the soft skill attributes they possess and use in the position. This four- step process is outlined in Table 1: Creating an Attribute Inventory.

Table 1: Creating an Attribute Inventory

A completed attribute inventory will document the following information:

• Key competencies the position requires
• Descriptions of those competencies
• Specific examples of how those competencies are used on the job

4.3 Developing Solution Architect Skill Sets

Once a PS organization understands what hard and soft skills a Solution Architect needs, there is the challenge of actually developing these skills in delivery staff. TPSA benchmarks the amount of time PS organizations allocate for formal skills development:

What percentage of time do billable service delivery staff spend on training and certification activities?

However, formal training and certification is not the only technique for developing hard and soft skill sets. Other development options include:

• Creation of best practice online repositories
• Shadowing of proven Solution Architects
• On the job training (trial by fire)
• Project review sessions where successful (and failed) projects are reviewed for lessons learned
• Water cooler or brown bag sessions where Solution Architects are able to meet and learn from each other’s experiences

What techniques are the most effective? TPSA has not discovered a definitive study that answers this question. This may be an area that would benefit from more in-depth benchmarking or a PS focus group to identify the most common development techniques currently being employed.

4.4 Benefits of Evaluation

Investing in the development of both the hard and soft skills of Solution Architects is expensive and time-consuming. However, TPSA would argue that it is the one-two punch of investment AND evaluation that drives true improvement in the performance of a professional services organization. What good is skills training if you have no way of tracking who knows what or how well delivery staff are mastering specific skills? From the core TPSA benchmark study, we know that the PS organizations that have formal skills evaluation processes perform significantly better.

5.0 Impact to PS Organizations

This article provides an overview of what companies should consider when sourcing the critical role of Solution Architect. Specifically, TPSA recommends companies consider the following factors when sourcing Solution Architects:

1. Solution Architects play a critical role in the proposal process. They are responsible for assuring the proposed solution is technically feasible. For this reason, PS organizations are encouraged to clearly define processes for sourcing competent Solution Architects.
2. The Solution Architect role is at the center of the “PS hourglass” sourcing model. Solution Architects have become the hardest role to source and scale. For this reason, TPSA believes PS organizations must pursue a strategy of hiring mature Solution Architects and developing new Solution Architects internally.
3. PS organizations should have three business objectives regarding their sourcing strategy for Solution Architects: achieve maximum leverage with these hard-to-find resources, keep attrition to a minimal, and make sure the skills sets of the Solution Architects stay relevant with the needs of the marketplace.
4. There are five natural sourcing pools for Solution Architects that PS organizations should explore to maximize the pool of qualified candidates.
5. Once hired, Solution Architects can be placed in corporate, geographic, or competency center roles. PS organizations should create a balanced mix of these three roles to drive maximum reach and minimal cost.
6. PS organizations that invest in formal skills evaluation perform financially better than PS organizations without formal skills evaluation.