The RevOps Show

Episode 34: The Role of The Solution Architect - It's All About The Business Process

Written by Hannah Rose | Sep 21, 2022 5:00:00 PM

We’re starting today’s episode with some exciting news! Based on some research, we may have the number one RevOps podcast on Spotify! Thank you to all of our listeners for being part of this journey and listening to the show. We couldn’t have done it without you all. Also be prepared because today’s episode is Exhibit A of attention deficit Friday. Now, let’s get into solutions architects.

Audio:


Video:

 

Additional Resources:

Show Notes:

Doug posted to LinkedIn after he saw a lot of job titles recruiting for a solutions architect. He means no offense to anyone, Doug has great respect for the talent, skills, and expertise of many solution architects. That said, if the focus of your expertise is on the technologies or configuration of the product, the role is not a solution architect, rather it’s a technical or product architect role. Solutions architect centers their focus and primary expertise on designing the underlying business processes that should be driving any configuration. To end it off, combining a solution architect with a technical architect will give you fire.

What Doug is trying to get across is that technology is not a solution. Then once you put a brand in front of something, it’s even further away from a solution. So a solution by definition is agnostic.

Doug has theories as to why technology gets called a solution. Some of it is marketing, some of it is the move towards solution selling. If you think about it, the solution is really built around the idea of jobs to be done. Part of the problem is that the product becomes more and more complicated. Someone needs to understand how it’s going to fit within a customer’s existing technology. In a lot of ways that used to be called the sales engineer, and now it’s become the solution architect. That position is to be a master of that product, but it isn’t a solution architect, it’s a technical architect. A solution architect has to go beyond the product and technology and look at the business process.

This episode is a little self serving because Doug and Jess get into why Imagine is unique. Doug's favorite, unique selling proposition about Imagine is that we have a pretty good grasp on technical components. He wouldn’t put us in the best category, but our application is the best because we come from a deep and broad understanding of the underlying motions, so we are able to pick up without anyone having to say anything.

So much of tech implementation is difficult because it sounds like everyone understands each other because of the words they use. They feel like they’re talking about the same thing, but they don’t have the same meaning. One thing that Imagine does extraordinarily well is that we’re able to lead the effort. We address the difficulty up front. To be a solution architect, you need to know the problem better than anyone else. Everyone wants to jump to the solve and not fully understand the problem.

Doug had an interesting conversation with his favorite Twitter buddy, Pete Caputa. Pete started by asking, how does your marketing agency go about creating strategy with, or for clients trying to design a survey on this? Doug responded to him by asking, what is your definition of strategy? After asking Doug his thoughts, Doug responded with a link to a blog of ours on Strategy Kills. The blog discusses 3 elements of a good strategy and one of them is a strong diagnosis that clearly defines the challenge. Doug wants to emphasize here that if you’re talking about a solution, it’s a diagnostic process. A diagnostic process takes the first piece of information as a means to get to the next piece. It’s digging in and testing and trying to get to the underlying cause. The actions should be coherent, using resources, policies and maneuvers to support each other. 

The biggest strategic problem facing most organizations is how often and badly they misuse the word strategy. What is strategy? It’s the guiding policy where choices are made. Decisions kill alternatives. Strategy gives you the framework to manage tradeoffs and make decisions. Strategy can only come from within because if it is brought to you, you wouldn’t abide by it. You have to be an active participant and it has to be ongoing for it to stick.

If you take a look at how the best companies procure high impact technology, they do a business process audit and diagnostic process first to define the problem, to define the requirements of whatever’s going to be used to solve the problem. And it isn’t the technical architect’s job to say you can’t do something. The technical architect is there to say what the difficulty would be in configuring the technology in a way to make something happen.

Why do you think that the solution architect role ends up getting categorized as more of a technology or configuration focus?

Sales and marketing because they usually call your technology a solution which technology is not a solution. It is an enabler and accelerator of a solution. It’s a way to solve and manage the solution. Doug is a solutions architect first, so he will always prioritize the underlying business process over the tech which might cause him to bypass something.

The solutions architect and the technical architect reinforce each other.

What does a solution architect do and what does the technical architect do?

Depending on the conditions, the solution architect is responsible for how something can be done, what could go wrong, what else you need to consider with regards to the technology. They may be responsible for the actual configuration.

Jess’s Key Takeaways: 

  • Make sure you get to the real problem
  • The solution architect’s role is really to define what the real problem we’re solving for is; jobs to be done
  • The key element of understanding the issues as a whole and not just addressing the symptoms, that’s a main place where the solution architect comes in
  • Solution Architect + Technical Architect = Fire Emoji

Next Steps: 
View full post