Salesforce MuleSoft Catalyst Consultant

Technology choices come after outcomes. You run discovery with the customer’s leaders and teams, map the current landscape, and turn vague wishes into outcomes with measures they will accept.

• Discovery interviews and workshops
• Mapping systems, data and processes today
• Turning complaints into outcomes
• Writing measurable outcomes
• Prioritizing outcomes with stakeholders

You build A discovery report with ranked outcomes and the measure for each.

An engagement without a plan drifts. You scope phases and deliverables, decide who does what on both sides, set governance, and build a plan that steps toward the outcomes the customer chose.

• Scoping phases and deliverables
• Roles on the customer and delivery teams
• Governance and decision rights
• Sequencing work toward outcomes
• Managing scope and expectations
• Reporting progress to sponsors

You build An engagement plan with phases, roles and governance for one customer.

A methodology makes engagements repeatable. You learn how to follow the Catalyst approach to shape solutions that answer the agreed outcomes, adapt it to a customer’s size and culture, and keep its artifacts useful rather than ceremonial.

• Why a methodology helps a delivery team
• Shaping a solution from agreed outcomes
• Adapting the approach to the customer
• Artifacts and what each is for
• Reviewing work against the method
• Avoiding method for its own sake

You build A tailored delivery approach for one customer, with the artifacts it will produce.

Reuse is the aim of composable design. You learn how layers of APIs separate systems from processes and experiences, how an application network grows from reusable assets, and how to draw an architecture a customer can follow.

• System, process and experience APIs
• Reuse and the application network
• Drawing an architecture for a customer
• Designing for change in the systems behind it
• Common design mistakes
• Reviewing an architecture for reuse

You build A layered architecture diagram for a customer, with its reusable assets named.

A design is only good if it can be run. You cover security, monitoring, versioning and governance decisions that must be made early, and show how to bring them into the design before delivery begins.

• Securing APIs and the data behind them
• Monitoring and alerting
• Versioning and retirement of APIs
• API governance in practice
• Non-functional requirements as design inputs

You build A set of non-functional requirements and governance rules for one architecture.

An integration program changes how teams work, not only how systems talk. You identify who is affected, plan communication and training, and manage resistance, so what is built is actually used.

• Mapping who the change affects
• Stakeholder analysis and influence
• Communication plans
• Training and enablement for builders
• Handling resistance
• Measuring adoption

You build A change plan with stakeholder map, communications and training steps.

Reuse needs people to promote and guard it. You design a center for enablement and an operating model that tell teams how to build, share and govern integration assets across the organization.

• What a center for enablement does
• Roles and responsibilities
• Standards and reusable assets
• Funding and staffing models
• Measuring reuse
• Growing the model over time

You build An operating model for a center for enablement, with roles and standards.

A design means little until it is built as intended. You review delivery work against the architecture, handle changes with care, set clear definitions of done, and keep the design and the build in step.

• Design reviews during delivery
• Handling changes to the design
• Definition of done for integration work
• Working with delivery teams
• Quality and acceptance checks

You build A delivery review checklist that checks work against the agreed architecture.

Value keeps coming only if the solution is looked after. You plan handover, support and measurement, so what was built keeps serving the outcomes long after the engagement ends.

• Handover to the customer’s team
• Support models after go-live
• Measuring outcomes after delivery
• Planning the next phase
• Closing an engagement well

You build A handover and support plan with the measures that show ongoing value.

Work a whole engagement on paper. You discover outcomes, plan the work, design a composable architecture, plan the change and support, and present it as one story that a customer’s leadership can approve.

• Framing the customer and its outcomes
• Designing the architecture and plan
• Planning change and support
• Telling the engagement as one story
• Presenting to leadership

You build A complete engagement proposal: outcomes, architecture, change plan and support.