In my most recent Salesforce article, I discussed assessing and prioritising services to manage a pipeline of demand across multiple business units, dependencies and systems, framing the discussion with the IT4IT value chain.

Let’s look now at what happens after a successful release into production. 

Again referencing the IT4IT value chain, the focus is now on stages three and four of the service lifecycle: 

  • Request to fulfil / operational support: Catalog, fulfil and manage service usage, delivery and expectations.

  • Detect to correct / continuous improvement: Monitor, measure and proactively manage the resolution of incidents and outages.

If the cross-functional product team has defined, developed and delivered a robust Salesforce service using the DevSecOps methodologies and tooling strategies we all know and love, that service must now comply with expectations as defined through Service Level Agreements (SLAs), backed by benchmarked and measurable KPIs. 

Fortunately, as part of the Shared Responsibility Model, Salesforce takes care of the underlying aspects of service delivery, guaranteeing uptime, data-level security, performance, compliance, reliability, availability and durability. 
 



The IT organisation then has service specific responsibilities including guaranteeing timely delivery of service features, proactively resolving incidents, issues and problems, mitigating security risks, and ensuring dependent shared services and resources are available. 

Furthermore, individual product teams must be empowered to fix ongoing application issues, provide application first-level (and potentially second-level) support, and continuously improve a service through direct customer feedback and a regular release cadence.
 

Stage three: Operational support

 

To effectively operate Salesforce at scale, critical enterprise foundational or shared services and a well-defined operating model must exist. These underpin the platform to ensure consistency of experience and guarantee an expected level of assurance as defined by any SLAs.

The following topics are likely to be addressed by an acceptable operating model; though not exhaustive these are necessary considerations: 

Support model for service request processing

Users can be demanding and adoption can be challenging. Through services like Trailhead, Salesforce engages and empowers users in rich immersive training and guided certification tracks. 

While the idea is to empower users, there will always be requests and they need to be fulfilled in a timely manner. A process should be in place for them that starts with assessing the impact and duration of service requests so they can be resolved, potentially raised with Salesforce support or, in longer-lived requests, assigned to product or platform backlogs where they will be scheduled to sprints, reviewed by the design authority and implemented by the product or platform teams before being released as fully tested features.

The process should proscribe collaboration paths, reviews and implementation responsibility.

Support model for ‘hot fixes’

Critical defects occur, vulnerabilities are discovered – they must be resolved immediately, most likely as a ‘hot fix’. A DevSecOps-focused organisation that has already established the tools and processes to support the continuous delivery mindset is able to quickly branch, apply, test and release. It can resolve issues across any affected Salesforce orgs, and seamlessly apply that fix to development branches.

Automation

The ability to develop automation and, where possible, empower individual product teams through consistent self-service is core to effective service delivery. Salesforce provides a rich set of APIs and developer tools to automate many facets of the operating environment, from enterprise-wide sandbox and scratch org management to user provisioning and everything in between.

Security 

Security underpins every IT decision. While an organisation’s approach should make every endeavour to ensure security through design and rigorous quality assurance, there are additional platform-wide considerations. Auditing, integration and any regulatory compliance requirements should be top of mind.

Data loss

Through the Shared Responsibility Model, Salesforce provides the necessary infrastructure services to guarantee service availability and durability. However, this does not guarantee data loss incidents will never occur so business-critical data must be backed up and should be easily restored. An enterprise-wide strategy can also satisfy data-retention compliance requirements as well as allowing advanced cross-system analytics and insights.

Identity management

Managing user identities is a core IT function. It’s safe to say in the modern age, most enterprises will support the concept of an identity federation. Using a core set of managed credentials, users can authenticate and access any service they’re entitled to, through an established federation of trusted participants. Salesforce can assume multiple participant roles and supports Single Sign On out of the box. A strategic approach to managing user provisioning and de-provisioning is also advised particularly as the platform footprint scales. 

Logging/monitoring

Event monitoring allows access to detailed performance, security and usage data across the platform. Every interaction is tracked and accessible via API. See who is accessing critical business data when and from where. Understand user adoption, troubleshoot and optimise performance to improve end-user experience.

Ideally, system and service generated events of import should be propagated to a central monitoring capability. Custom code should also include sufficient and consistent logging to make debugging as streamlined as possible. 

Similarly, any middleware-based integration should provide an appropriate level of logging for audit and management purposes.

Artificial Intelligence

In my previous article, we touched on the impact Artificial Intelligence (AI) is having on augmented and automated decision making. 

AI is a broad field with no unified standards around governance and oversight. Organisations must be accountable for their use of AI within the context of the stated problem. Models supporting AI-based decision making should be routinely tested to ensure they comply with expected outcomes, and thoroughly regulated and only used in the context for which they were designed.

This is especially important for AI algorithms using live data for continued learning. Similarly, learning models should be continuously evaluated for fairness and appropriateness based on the constraints of the business objectives.
 

Stage four: Continuous improvement 

 

In software development, nothing is ever complete – ‘done’ is very much a temporary definition. Small features and fixes right through to wholesale changes are continuously requested, new digital engagement channels are exposed, organisations’ business models change, mergers happen.

Continuous improvement is a given with Salesforce. Services are endlessly flexible and easily extended, so there’s a responsibility to balance continuous improvement against sensible but lean governance. This takes the organisation full circle, putting the cross-functional DevSecOps-enabled product team at the centre of a program of continuous improvement. The following are common strategies product teams will use to continuously improve.

Customer feedback and prioritisation

A strategic approach to capturing feedback is critical. Product teams will assess feedback, and look to address and include it in future releases. Adopting a regular cadence of iterative releases, typically multi-week cycles or sprints, means teams can incorporate feedback and get improvements out to customers quickly, reducing time to market. 

It is also a mechanism for removing or refactoring onerous or unwanted functionality. The mantra of ‘fail fast’ applies well in this scenario – it allows a service to easily pivot to meet changing demands.

Tri-annual release process

We gather feedback from the Trailblazer community through the IdeaExchange – they provide critical feedback, and collaborate and vote on ideas for future Salesforce platform features. 

Features garnering the most votes are prioritised and built into tri-annual releases. For a Salesforce customer looking to innovate, the challenge is understanding what new features are available, how features can be adopted and, importantly, any potential impact to current functionality.

There are plenty of excellent articles around best practice for managing the three major annual releases, the key point being that releases must be managed properly and consistently.

Measurable KPIs

Quite simply, the best way to gauge the success of a product is through measurable KPIs. Building in the capability to gather user feedback at design time is a sensible approach that allows product teams to continuously improve their service over time. 

But this doesn’t have to be the only metric by which a service is measured. Other common metrics include:

  • Number of defects/issues raised 

  • Mean time to restore

  • Employee satisfaction score

  • Platform/service adoption metrics

  • Time to market 

  • Cost/efficiency gains through business process optimisation 

It’s best to define the target metrics against current benchmarks, giving the organisation measures on which to improve. The product owner or a similarly focused role is then responsible for regularly reviewing current metrics and responding where a service or service delivery function may be underperforming. Performance statistics can also be aggregated across the business to provide meaningful insight to executive stakeholders.
 

The work is never really done

 

Done never really means done; the cycle continues in perpetuity and for good reason. Innovation is everywhere, customers are savvy and will continue to demand the state of the art. An organisation developing and running Salesforce services must embrace change as a natural mode. Keeping up with the pace of change on the platform is challenging enough, this is further compounded by industry demand, regulation, competition and, of course, maintaining customer-centricity. 

With a well defined, but sufficiently flexible operating model, an organisation is able to meet the demands of the business and its customers. A mature DevSecOps approach across the IT value chain using cross-functional teams with skin in the game from the outset, measurable KPIs and a solid support capability will ensure organisations can adequately scale to effectively run resilient Salesforce services.

To learn how Salesforce Architects can help you achieve your vision, download the ‘Transforming Business through Strategic and Technical Guidance’ ebook.