Working in the Configure-Price-Quote space for 20 years, I’m often asked what a Solution Architect (SA) does. I always try for simple explanations, and the truth is that an SA’s role in any CPQ business transformation project is quite complex. It requires some pretty specific skills to be successful.
I’ve honed my skills for the past 20 years, and I thought it be of interest to offer a preview into what’s required:
1. Analytical skills
Transformation starts with understanding the customer’s business challenges, as well as the associated technology to solve them. It requires being responsible for designing a solution that matches not only the business needs, but also leverages the tools and technologies that are available to work with – very similar to an architect designing a building.
A CPQ Solution Architect needs strong analytical skills to get to a solid understanding of your customer’s vision. With CPQ, it’s all about improving the quote-to-cash cycle, i.e., how to optimize order-taking or contracting that uses AI to leverage sales in a multi-channel environment. To do, it’s imperative to understand a few important components:
At the same time, these processes can be used to place an order, which many refer to as quote-to-order, or to conclude a price agreement and related terms and conditions, known as quote-to-contract. It’s important as an SA to be up to speed on all of these terms and how they relate to the needs of the business.
- What business processes – at a detailed level – is the customer tackling? Some customers focus on selling off-the-shelf products – commonly known as select-for-sale – while others sell assemblies based on pre-defined components, which is known as assemble-for-sale. There are others who use guided selling scripts to configure a customer-specific solution – known as configure-for-sale – or even to engineer a whole or partial new product altogether, which many call engineered-to-order.
- What are the products or services the customer is offering to the market? It’s necessary to be able to quickly understand which products or services the customer is selling, as well as how these products are manufactured, marketed, and sold. Understanding the pricing strategy is key. In short, a CPQ Solution Architect needs to become an overnight expert on the customer’s product portfolio. Throughout my career, I’ve had the privilege of attaining in-depth knowledge on wind turbines, windows, doors, staircases, healthcare material, price agreements for chemical products, contracts for oil & gas products and services, travel solutions and insurance policies, among many others. It’s always fascinating to learn about new industries and how companies do business, so a natural curiosity and interest is important too.
To analyze a customer’s products and processes, I typically use a top-down approach with some basic problem solving. The first step is root cause analysis. A problem can be tricky to define since many people don’t intuitively describe a problem, but rather a symptom of the problem. Once the problem is correctly identified, it needs to be broken down into manageable pieces, then prioritized.
A good design will focus on resolving the “must have” issues in the best possible way, while reserving “nice-to-have” items for later or even cutting them down, if needed. More is not always better.
2. Domain expertise
It’s imperative to know your own company’s solution stack. During the requirements analysis, you’ll need to constantly perform a fit-gap analysis between the business requirements, and your solution’s capabilities and features. Identify which features are going to be of use and then determine how those features will be used, combined and orchestrated to satisfy the requirements.
Knowing your own product, however, isn’t enough. SAs also need to have a good understanding of the neighboring solutions of the larger domain. In the CPQ world, that means understanding solutions including CRM (Customer Relationship Management), ERP (Enterprise Resource Planning), PLM (Product Lifecycle Management) and e-commerce platforms. You’ll need to be familiar not only with your “own” product solution, but also leverage existing solutions in the customer’s IT landscape to satisfy the requirements – or even point out new solutions when there are clear gaps.
Finally, you need to have a profound understanding of the integration services offered by your product and a good understanding of integration technology.
3. Communication, communication, communication
The Solution Architect obviously doesn’t work in a silo – you’re a part of a bigger team and will typically work with at least 3 groups: the business team, the engineering team and the project or implementation team.
For the business teams, you’re a trusted advisor. They’re interested in understanding how the requirements will be met, the constraints, the alternatives and what the impact of your design choices will be on usability, performance, maintenance and upgradeability. When you identify a potential gap or risk, you’ll need to raise issues and explain them to set expectations. You’ll then work together with the business and engineering teams to identify alternative solutions or negotiate simplified requirements.
The engineering group is responsible for building the software solution. You’ll work closely with them because you need to stay on top of the solution’s capabilities, both current and future. Business requirements are constantly evolving, and you’ll need to be able to map future product capabilities across different phases of the project plan.
Finally, you’ll collaborate closely with the project team. The implementation consultants or developers responsible for the implementation of the solution need to understand the application framework, including which components are used and how they need to work together.
You’ll work with both experienced and junior people, so coaching and mentoring is a major part of the Solution Architect’s role. Explaining what needs to be done, explaining the tasks that comprise a certain user story and helping to estimate a certain task are all part of the big picture. You may also serve as a project manager, the main person people turn to when they want to understand what needs to be done and how the different user stories can be broken into manageable tasks.
Final thoughts …
I often tell people that I work like a journalist, asking very simple questions: What is being performed or needs to be done; how and in which manner; by whom, at what point in time or when, and the reasoning behind why something must happen. The answers are very different depending on the business, and that’s where the fun begins. Having a strong skill set when it comes to analysis, domain expertise and communication is critical for a successful transformation.
If you have questions about being a CPQ Solution Architect, drop a note in the comments, and I will personally respond.
About the AuthorMore Content by Davy Bogaert