Return to link

“When customers become aware of a job they need to get done in their lives, they look around for a product or service that they can ‘hire’ to get the job done.”

The Innovator's Solution, Clayton Christensen, 2003

In Professional Service organizations—especially those linked with Telecommunications and Computer vendors—it is very easy to view solutions and solution architecture solely as techniques for selling products. They are not.

Technical organizations tend to view products in terms of attributes—features, functions, settings, supported interfaces, protocols, etc. Requirements documents and proposals also tend encourage a view of products and product sets in terms of such attributes. Both views focus on what the technology will do, rather than what the customer really needs to get the job done.

Customers may have needs or see opportunities they would like to exploit. They may feel pain because something is not working correctly somewhere in their organizations. These are drivers that cause these customers to be willing to pay money for products or services—if those products or services actually address their needs and opportunities.

When customers have needs, they often do not care whether one vendor or several in combination would be required to address those problems. It may not matter whether solutions involve new hardware, software, or simply services. Their budgets and purchasing restrictions, their biases and "hot buttons" all factor into decisions about what to buy and when.

Seasoned sales people typically understand their customers' needs and biases very well. However, even if they are particularly good at seeing the big picture, sales people tend to lack the technical depth to distinguish between what is feasible and cost effective and what is possible but not advisable. They need a technical partner who also appreciates the big picture, but can interpret customer needs at multiple levels. These partners not only can understand the business context, they equally well can analyze the impact of various choices on technology selection and support.

We refer to these technical partners as solution architects because they focus their technical expertise on solving actual customers' problems. They elicit in-depth representations of business needs and ensure that solutions will be successful by constraining top-level architectures to fit those needs. That is, they limit the possible outcomes to feasible combinations of technologies that incorporate all of the business needs.

Solution architects also partner closely with program managers. Once they develop the solution architecture, somebody must carry out the actual planning, design, implementation, and operation in a manner that fully supports the customer needs. Solution architects assist the program managers in this process, making tradeoffs and choices within the context of the true customer needs, and ensuring that the as-built system is what the customer really needed.

To do their job effectively, solution architects must collaborate with other subject matter experts. In today's complex solutions, it is unrealistic to imagine that one person will have the knowledge and expertise necessary to develop a fully effective solution. Thus, the solution architect is a highly technical expert, generally with deep knowledge in at least one subject area, but who is able to understand the key business needs and build solutions that are responsive to those needs. To be successful, they must team with other subject matter experts to develop a solution. Because they see the big picture, they can trace important choices and relationships, tailoring the architectures as business needs change.

Solution architecture employs a four-view methodology, "front end loaded" to collect and factor all key business needs and associated information into the solution. The views are business (drivers, goals, "pain and gain"), functional (business context, business functions and features, quality attribute needs, etc.), technical (high level technology choices that constrain the architecture based on the business needs) and implementation (training, staging, rollout, and operational needs—all in support of the Plan, Design, Implement, and Operate phases).

The solution architect develops these four views in close consultation with the customer and, in general, with the account team actively engaged. The first two views—business and functional—require direct interaction with key high-level stakeholders to capture the true drivers in accurately. The technical view usually requires additional participation by technical people, such as IT and network operations personnel who are able to factor into the solution the existing equipment, reference architectures, and operational constraints. For the implementation view, the solution architect will consult with a program manager as well as customer stakeholders, since the PM will generally be in charge of driving the implementation phases.

The solution architect remains engaged throughout the life of the process to ensure a coherent systems view and full representation of customer needs. However, the Program Manager "takes over" as the lead during much of the implementation phase, allowing the solution architect time for other engagements. During delivery and acceptance, the solution architect often plays a more active role, overseeing the configuration and customization of the technology. By adjusting key parameters with stakeholder interests in mind, the solution architect can ensure that the as-built system meets the specific business needs.

“Competence is far more about doing what customers value than doing what you think you’re good at.”

The Innovator's Solution, Clayton Christensen, 2003

 

Home	•	Your Needs	•	What We do	•	Insights & Ideas	•	About Us	•	Contact Us
Copyright © 2005-8, Alex Conn, APConnsulting, LLC. All Rights Reserved. www.apconnsulting.com