To code or not to code?
18th March 2020
Author Junaya Raika
Reducing tech complexity to enable digital innovation
To code or not to code? That is the question, and not to code is usually my answer, because I can’t code to save myself. I’m what’s known as a CRM “functional lead”, meaning I rely more on my business skills and a deep knowledge of out-of-the-box CRM capabilities, than I rely on any ability to write code!
Clicks not code, low code or no code, have become mantras at Davanti over the last five to ten years, and it’s a principle we’re seeing increasingly adopted by our customers, too – especially some of the early adopters of Salesforce whose environments have become so heavily customised that it has become cumbersome and expensive to maintain and scale their technology with the demands of the business.
Junaya Raika, Senior Manager and Salesforce Functional Lead
Whether it’s a customer that we’ve worked with since the beginning of their Salesforce journey, or one that we’ve partnered with recently, it’s commonplace to see heavily coded solutions implemented to solve complex requirements.
And we’ve definitely been responsible for some of that complexity. When I look back at some of our early implementations, there are many lessons learned from a simplification point of view. And that’s not to say complexity isn’t always justified (if you’ve ever worked within utilities or with a telco, you’ll know what I mean), and there are absolutely legitimate use cases for code, which we’ll discuss in another blog. But the reliance on Apex triggers and Visualforce to meet complex requirements is definitely on the downturn.
The Salesforce ecosystem – the teams implementing the solutions, and the cool new platform tools and features that Salesforce is constantly releasing – are combining powerfully to reduce the need for all of that complexity, enabling our customers to rapidly enhance and scale like never before.
So what is it about the industry, its practitioners and the platform that is evolving to deliver these awesome customer outcomes?
I’ve put it down to a few key things:
A focus on strategy
Clearly defined business goals – you just have to start there. This is all about outcomes, not technology.
What are the problems you are trying to solve, and what opportunities do you want to unlock? What’s in it for you? Acquisition? Revenue Growth? Compliance? Cost-saving? Retention?
And, most importantly, what’s in it for your customer? How does this initiative add value for them? Where in the customer lifecycle should we focus first, and what is the roadmap for continuous improvement?
Are you ready for the change?
Working alongside our customers to help them shape up and imagine what their future business should or could look like is one of the most exciting parts of digital transformation.
A focus on the process
Traditionally, process maps were the domain of business analysts, but for software developers process maps serve many purposes. And who doesn’t love a good whiteboard session?
- It defines the scope of work. Identifying where the process starts and stops provides the borders of what is in and out of scope.
- It enables a shared understanding across project teams of the stakeholders, users, workflows, customer touchpoints and other systems involved at each stage in the process.
- It can highlight areas of risk and complexity that require a deeper dive.
- It provides a structure for identifying feature sets, and later relating detailed requirements back to the process.
It’s so tempting to just jump in and start building – that’s the fun part, right? But seasoned functionals and architects will advocate that design upfront produces much slicker solutions.
Depending on whether you’re designing a comprehensive solution blueprint within a waterfall-style implementation, or solutioning user stories within an Agile delivery – your design document could be anything from a one-pager upwards and could contain one or more of the following:
- Feature set. What out-of-the-box feature/s will meet the requirements? Here we can leverage knowledge from the wider practice and the Salesforce community to see how we’ve solved similar problems before. No point reinventing the wheel!
- Data model. The data entities (objects) and relationships that are going to store your data throughout the interaction.
- System flows. Each key step in the process, decision points, sub-processes, channels, actors and integrated systems.
- What is our happy path, alternative paths, and edge cases, and how will we handle them?
- Business rules. A rationalised representation of the business rules that need to be supported in the system and the data validations to enforce them. (Think tables and matrices.)
- Data specifications. If you are designing as part of a discovery phase of a project you may not have this level of detail yet, but if you do then you’ll be figuring out where in your data model to build your fields, bearing in mind Salesforce provides lots of different ways of surfacing data across multiple objects by referencing the source through formula fields and related records etc.
- Data insights. How does the business measure performance and success and what data points will combine to provide those insights?
A design-first approach can deliver the following benefits:
- The thought process that you undertake while drawing up your design can draw out questions, unknowns and potential issues that you can go back to the business and discuss. This will happen during build also, but early identification is always good.
- It allows you to carve up the design into distinct build tasks and assign them to the appropriate resource, e.g. functional, technical or perhaps an integration specialist.
- It helps avoid rework. There’s nothing worse than having to unpick the solution because it doesn’t cater for all of your scenarios, or your data model doesn’t meet reporting requirements.
- It avoids over-engineering, and supports you to implement well organised processes, streamlined naming conventions and helps reduce confusing clutter for future administrators and developers.
- Documenting your design as you go saves time at the end of the project (when you’re under the pump getting ready for go live!). Design documents are often helpful resources for testers, too, as they contain scenarios, business rules and system logic.
I have built my technology career around my ability to help our customers optimise their business processes by understanding their goals and pain points, aligning them to Salesforce capabilities and then going about designing and delivering appropriate solutions.
The core Salesforce Clouds offer out-of-the-box capabilities that are designed around sales and service best practices, and have evolved over decades in response to real-life customer problems and feedback.
The Lightning Experience drag-and-drop interface offers much greater flexibility when building applications and has reduced the need for custom UIs. And when the need to extend beyond the standard functionality does arise, the Lightning component framework provides the ability to build custom components that can be re-used anywhere in the application and displayed on any device.
From a workflow point of view, tools like process builder, Lightning flow, assignment rules (to name a few) enable functional developers to implement processes and automations that ensure users are working productively and are aligned to business priorities.
More of our customers are asking us to help them reduce their technical debt, improve their customer data, and replace their clunky legacy systems with low-code applications and sound data architecture. This provides them with a foundation upon which they can leverage the innovative capabilities that Salesforce offers, like Einstein, CPQ and Customer 360, and is key to enabling their future digital strategy.
Regardless of where you are at in your journey towards becoming a digitally savvy, data-driven organisation, we’re keen to help you make sure that the next step is in the right direction.
It is not in the stars to hold our destiny but in ourselves. – William Shakespeare
Junaya Raika is a Senior Manager and Salesforce Functional Lead.
After returning to the workforce in the early 2000s (after having twins as a very young mum), Junaya had the good fortune of going to work in a tech start up that was 100% paperless. This set her on the path to becoming somewhat of a CRM evangelist in subsequent jobs, eventually leading to a consulting career working with Salesforce CRM.
Junaya’s functional lead role is central in a software implementation, as it provides the vital link between business and technology teams.
A functional lead understands business problems and processes and can translate them into solution designs, and equally can communicate technical challenges back to non-technical stakeholders and support them in the assessment and prioritisation of risks and issues.