Successful Architects Follow These 3 Solution Design Practices
If your customers weren’t already thinking about going digital before the pandemic, they almost certainly are now. So, you have customers ready to jump on the digital train and the implementation journey is just beginning!
While this is certainly a step in the right direction, that new Salesforce licenses purchase is just the beginning. And exciting as this journey is, the reality is that it’s very easy (and common) for implementations to go south.
Organizations don’t thrive just because of luck, or chance, or by making a purchase alone. While many customers believe that all their problems will be solved by moving to the cloud, technology is just part of the process.
The key to success in digital transformation lies in a sound solution architecture. And architecture, friends, is an art. Great architects understand that in order to fully capitalize on a Salesforce investment, there’s a specific set of practices to be followed.
Let’s discuss a few crucial best practices that will help you take your next Salesforce implementation from being an incremental improvement to truly transformative.
1. Embrace transformation
Transformation is uncomfortable, and not for the faint of heart. I’ve seen executives’ smiles drop when I say “I recommend this new approach (instead of the one you’ve been taking for the last 25 years)”.
“But we’ve always done it this way! Besides, our head of finance will never give us the green light for this new process.”
As a proponent of change, you may encounter so much resistance that you might be tempted to accept business requirements as they are. But if your stakeholders’ current technology and processes were working just fine, why did they spend so much money on a new product? In the midst of all the noise, the organizational hierarchy, and its impenetrable politics, it’s very easy to to architect a design that works against the natural capabilities of the product — a design that adds to technical debt rather than eliminating it. If you find yourself developing an architecture that greatly deviates from out-of-box capabilities and industry best practices whilst driving up project cost and risks, it’s time for a transformation intervention.
So how do you bring digital transformation to life?
Put yourself in the shoes of your stakeholder. I know you’ve heard this before, so let me clarify what I actually mean. Talk only in terms of your client’s interests. You’ve learned the organization’s lingo, and experienced a day in the life. Use that to show them the impact of transformation to their bottom line. How will a process change impact their revenue, give them a competitive advantage, or save future admin headaches? Your conversation should always be customer-centric, so be sure to relate your design decisions to KPIs, and always focus your conversations on alleviating customer pain points.
Take a look at this architect value map for some examples of how to connect value with metrics.
Another persuasion tactic is painting a compelling picture. Give them a taste of what they’re asking for, and then highlight the pros and cons. A good time to do this is in a proof-of-concept (PoC) during the architecture phase. This enables you to show your client not just what they’re getting, but also all of the implications of taking a particular design approach. These implications include the cost and time needed to implement the approach, the extra training required, the maintenance, the impact on performance, the new person they may have to hire after you roll off the project because no one on the current team knows how to code… and the list goes on. Illustrating the long term benefits of a process change versus the cons of a heavily customized solution early on with a demo or PoC can be very convincing.
It’s tempting to “lift and shift” old requirements into a new system, and use whatever means to do so. But just because you can, doesn’t mean you should. Don’t shy away from tough conversations. Your client will thank you when they learn how such conversations lead to significant improvements in those “little” areas like maintenance and scalability. For a solid solution architecture, maintenance and scalability are requirements, not afterthoughts. The quality of your work will diminish quickly if your solution architecture is not adjustable or adaptable.
Use a capability map to help visualize the target state of your organization. Capability mapping can help you keep your project on track, conduct a gap analysis, and avoid technical debt to ensure you’re always moving forward.
2. Design for the majority of use cases
We’ve all been there. Too late in the game, we found out that a “key” process for our client was not natively supported by the product. In order to support the requirement (as is), they’d have to purchase the “Plus” version of their licenses, not to mention the solution would be fully custom and would require pushing out the timeline by at least a month.
Escalations galore ensued. We spent a couple of days doing damage control. It was then that we started asking more questions. “Well, how often do you go through this process? How many people really depend on it? How many deals really depend on it?” It turns out that this (allegedly) very important process wasn’t actually needed all that often, and not much revenue came from it!
If you haven’t encountered a similar scenario yet, it’s only a matter of time. Use a strong (but polite) line of questioning to help your customer see that it doesn’t make sense to spend thousands of dollars to implement something that will hardly be used. Not every requirement needs to be solved by technology. Define a clear process for handling an odd use case for the rare occasions it appears, by keeping parts of it manual with help from a small mid-office team.
This story about discovering critical information late in the game highlights the importance of the architecture phase. Many clients don’t see the value of spending months in planning and design, and it’s an area where they often try to cut corners. Don’t skimp in the early days; the architecture phase is where you can and should make these kinds of discoveries, so that you can be transparent and manage expectations upfront.
3. Have an end-to-end mindset
Details are important, but make sure they don’t derail you from the big picture.
Let’s take the example of Salesforce CPQ. CPQ is one of the many solutions in a client’s toolbox that helps them run their business. It’s very common for enterprise companies using CPQ to also have a real-time connection with product, pricing, or inventory management information stored in an external system. As an architect, it’s essential to make sure these integrations are not just smooth, but also technically viable.
Be sure to think ahead about all the integration touch points and account for them in your design.
Build wide and shallow as you set the foundation of your solution, and don’t forget to unit test as you go with real examples. If an integration is key, don’t wait until the last minute to make sure all of the players in the quote-to-cash process play nicely. Test early and test often to ensure that your quote can move seamlessly from creation to billed with all of your integrations in place. Your client won’t be happy if the sale made by their reps using CPQ can’t be fulfilled or turned into an order.
Summary
An excellent solution design does not mean every single requirement was implemented, as is. Being a champion of transformation, striking a balance between technology and processes, and having a strategic vision will help you set the foundation for success, ultimately enabling your customers to reap the full benefits of their Salesforce implementations. Lean on your experiences and knowledge to become a trusted digital advisor, and help your clients make evidence-based business decisions that steer them in the right direction.
About the author
Garima Totlani
Previously a Senior Revenue Cloud Consultant, Garima is responsible for enabling the EMEA Partner Ecosystem in the areas of Revenue Cloud and B2B Architecture. Connect with her on Linkedin.
