What is a Fractional
Salesforce Strategist
Introduction
In recent years, the fractional expert model has gained popularity in the C-Suite with fractional Chief Information Officers (fractional CIOs) and fractional Chief Marketing Officers (fractional CMOs). The fractional model enables organizations to get targeted expertise in situations where they don’t need a full-time or permanent resource. The fractional model is fairly common among organizations undergoing periods of rapid or intensive change; for instance, companies that are scaling or undergoing business transformations like a merger/acquisition or a major product launch.
The fractional model can also be applied to Salesforce Architecture work. Many organizations are already familiar with the idea of having a part-time architect on a vendor-led implementation project. But the fractional architect model is actually quite a bit different than simply a traditional consulting architect model. This article will provide an overview of the Fractional Architect model, when it should be used and best practices for structuring these types of engagements.
What is a Fractional Strategist (and How Does it Differ from a Contract/Consultant Strategist)?
The defining characteristic of fractional architect engagements is that they’re deliverable focused. In contrast, the scope of a traditional contract or consulting architect is often hourly based (“we’ll need 20 hours a week for 3 months.”). The scope of fractional architect engagement is on deliverables. For example:
An assessment of existing configuration/customization (and technical debt) of a particular org or business process
A roadmap for future state business capabilities or technical capabilities
A blueprint for improving a DevOps process
A solution design document for a project
A technical design document for a project
For many organizations, having clear deliverables helps to ensure that their budget is tied to specific outputs. Architect talent can be scarce and expensive, so optimizing their time and budget is critically important.
A seasoned fractional architect will have experience, a point of view and a process for creating their specific deliverables. They should provide exactly the right expertise for the client’s particular job (more on this later under “Types of Services”).
How It Works: Clear Process, Clear Deliverables
Fractional architect engagements should have a clear process and clear deliverables. A fractional architect should be able to articulate the following:
The Process: the steps the fractional architect will follow through to create the deliverable
What’s Needed from the Client: What information the fractional architect will need from the client and what time commitment will be required from the client’s team.
The Deliverable(s): the deliverable (often a document or a diagram) and the specific information it will contain
The engagement should also have a clear duration and budget associated with the deliverable.
To illustrate how a fractional architect engagement could be scoped and structured, consider this sample engagement summary below. This sample contains a high-level statement of work for a Technical Debt Assessment for the (fictional) Company XYZ.
Technical Debt Assessment — Scope of Work (SAMPLE)
Overview:
Company XYZ is an enterprise software vendor that uses Salesforce Service Cloud to manage support requests associated with their flagship product: EnterpriseSoft. Their Salesforce org was launched about 12 years ago. In addition to customer support cases created by the internal support team, cases are created via a customer-facing Experience Cloud site. Company XYZ uses email-to-case. The system also has a nightly data load of customer subscription data from the Company XYZ ERP system, which is loaded via MuleSoft.
Company XYZ’s support staff have reported that Service Cloud record pages and reports have been taking an unusually long time to load. They have also reported that in the last year, creating and managing cases has become more time-consuming as the number of required/validated fields has increased. Some EnterpriseSoft Support team members have mentioned that many of the required/validated fields are not relevant for the EnterpriseSoft product.
In addition, the Company XYZ IT team has reported that legacy metadata and code in the Service Cloud org makes new projects more time consuming to deliver than in the past. Company XYZ suspects that the issues above may be caused by legacy technical debt that has accumulated over the years.
Purpose:
The purpose of this Technical Debt Assessment is to identify root causes within the architecture of Company XYZ’s Service Cloud org that may be contributing to the pain points identified above. This assessment will focus on the processes and architecture that support Company XYZ’s EnterpriseSoft product; all other products and lines of business are out of scope for this assessment.
The Process:
Kickoff Questionnaire
Discovery Session with Support Team (half day session, on-site)
Interviews with Salesforce Administrators — focus on pain points of maintenance
Review/Analysis of Org
Creation of Assessment Deliverable (Findings & Recommendations)
Readout of Deliverable to Stakeholders
What Company XYZ will provide:
Access to your production org; Access to a full sandbox
Sample payload from daily ERP integration (provided securely via Company XYZ’s cloud storage platform)
Existing Documentation: technical specification, process flow / workflow diagrams, end user training guide
Roadmap: Company XYZ’s 12 month Capability and Technical Roadmap
Company XYZ’s involvement / time commitment:
Pre-Discovery Questionnaire (~90 minutes to complete)
Discovery session with Customer Support team: this will be a half-day, on-site session and will include 5 representatives from the Customer Support Team (including one manager, one tier 1 support team member and one tier 2 support team member)
Interviews with the internal Salesforce team (4 team members, 2 hours total each). These will be performed remotely via zoom.
Ad hoc meetings as necessary (not to exceed 5 hours of Company XYZ’s staff time)
Participation in readout of final deliverable (90 minute session)
Deliverables:
The following deliverables will be captured in a document at the conclusion of the engagement.
Findings: Findings will be categorized according to the Salesforce Well-Architected framework categories: Trusted, Easy, Adaptable. The observations will include the following:
Review of current state Object Model
Assessment of org metadata, in particular configuration of the Case object (record types, page layouts/lightning pages, validation rules)
Report of underutilized managed packages, reports, fields
Assessment of org with regard to Salesforce Data Volume Management best practices
Review of sharing settings and possible performance impacts
Assessment of automations, including custom Apex Classes/Triggers and Flows
2. Recommendations:
Recommended system changes associated with the findings/topics listed above.
Review of Company XYZ’s 12 month roadmap, in order to align architecture
Important: this initiative includes assessment & recommendations only. This initiative does not include implementation of the recommendations.
Types of Services
There are a number of different types of engagements and deliverables that are a good fit for a fractional architect engagement. The following are a few examples:
Discovery: Assess the client’s objectives and problem space, and consider potential projects or solutions. Discovery engagements often include workshop sessions, interviews, and current state capabilities & technical assessment. Deliverables include synopsis of high level objectives, risks, preliminary requirements/user stories and potentially technology selection.
Capabilities Roadmap & Business/ROI Case: A roadmap of future state business capabilities. This is sometimes paired with business case development: creation of a business case for possible projects/initiatives and associated communication materials (powerpoint deck, etc). Sometimes the Architect will be responsible for delivering the business case / senior leadership readout), sometimes internal champions/stakeholders will be responsible for delivering the readout.
Enterprise Technology/Systems Roadmap: A roadmap of technology improvements / projects to support business capabilities. Roadmaps may include ballpark duration/effort/cost estimates for planning and prioritization purposes.
Project Scope for Request for Proposals (RFP): Development of a project scope document used for a Request for Proposals (RFP) solicitation/bid process.
Solution Architecture for a Project: A solution design for a particular project. Solution Architecture may include development of requirements or user stories, or may take existing requirements/user stories as an dependency/input.
Technical Architecture for a Project: A technical design for a particular project. Technical architecture would take solution architecture as an dependency/input.
Operationalize / DevOps: An assessment of a Salesforce team’s current state DevOps process and a roadmap/recommendations for future state improvements.
Technical Debt Assessment: An assessment of an organization’s technical architecture and configuration/customization. Technical Debt Assessment should include analysis of an organization’s associated pain points along with recommended technical improvements to address them.
Data Model Assessment and Recommendations: Review and assessment of current state Salesforce object model. Recommendations for how to improve/optimize data model according to Salesforce Well-Architected principles and the business impact of improvement. Recommendations may include a high-level data migration specification and plan (although a detailed migration specification and plan would often be a standalone initiative/deliverable).
Journey Map: Development of an organization’s customer journey map. This may include a current state journey map and/or recommended future state. Journey Mapping initiatives may include Discovery sessions, interviews and/or customer research.
Enterprise Architecture Landscape: A diagram and assessment of an organization’s enterprise architecture (including but not limited to Salesforce) and recommended future state.
Many of the services above require specialized architecture skills. For example, an Enterprise-grade Technology Roadmap would be a good fit for a Technical Architect, while a Business Capabilities Roadmap may be a good fit for a Solution Architect. It is important to make sure to choose a Fractional Architect with expertise in the particular kind of service you need.
With this in mind, the fractional architect model can be useful for organizations that already have architect team member(s), but need architectural expertise outside their existing architect team member’s skillset. For example, an organization may have an experienced Solution Architect, but may want a fractional architect who is a certified technical architect (CTA) to design the technical architecture for a critical project.
Conclusion
Building and maintaining a high ROI Salesforce org requires specialized expertise, oftentimes for targeted, time-bound deliverables. These types of deliverables may not fit well in a traditional full time, permanent or dedicated engagement model, and may be a better fit for the fractional architect engagement model. As such, organizations should consider adding the fractional architect model to their mix of talent acquisition strategies.