Maintain Your Catalyst Specialist Certification for Winter ’25
Learning Objectives
After completing this unit, you’ll be able to:
- Review Catalyst core principles and lifecycle phases.
- Define the Catalyst Knowledge Hub.
- Describe how Catalyst defines and documents business outcomes.
- Evaluate the Catalyst approach to scope, measure, and track business outcomes.
- Explain how event-driven architecture solutions are created using AsyncAPI.
Maintain Your Certification
If you hold the Catalyst Specialist credential, keep in mind that you need to complete this module by the due date to maintain your certification. Another important part of maintaining your credential is ensuring your Trailhead and Webassessor accounts are linked.
Interested in learning more about getting certified? Check out the Catalyst Specialist credential.
Protect the Integrity of Your Certification
The quality of our certification exams and the value that our credentials provide are our highest priority. Protecting the security and confidentiality of our exams is essential to providing our customers with credentials that are respected and industry-leading.
As a participant of the Salesforce Certification Program, you’re required to accept the terms of the Salesforce Credential and Certification Program Agreement. Please review the Salesforce certification exam-taking policies in the Salesforce Credential and Certification Program Agreement and Code of Conduct Trailhead Help article for more details.
Salesforce introduced great feature enhancements over the past year. Let’s review a few Catalyst topics and the latest features that are important to know about.
Catalyst Specialist Basics
Catalyst specialists help organizations achieve technology transformations using the best practices and composable solutions of the MuleSoft API–led approach. By earning the Catalyst Specialist credential, an individual demonstrates their ability to identify business outcome goals, plan engagements, and develop composable architecture solutions using the Catalyst methodology.
MuleSoft Catalyst provides a set of packaged offerings, including customer success programs, training, best practices, and assets. Users of the Catalyst approach can execute projects without starting from scratch on each solution. Catalyst is often referred to as a method or approach to deliver MuleSoft implementations, but it’s also designed for users to apply it within another framework or project delivery methodology.
Apply Catalyst Principles
Seven core Catalyst principles guide specialists in their work.
- Link technology to business outcomes: Ensure every technology initiative directly supports measurable business objectives and demonstrates ROI.
- Balance short-term and long-term goals: Deliver immediate project value while building toward a sustainable long-term vision, avoiding technical debt.
- Separate platforms from solutions: Developers focus on integration design and implementation, while a core platform team manages infrastructure to provide common frameworks and shared services.
- Decentralize governance and enablement: Enable multiple teams to design and build APIs in a decentralized Center for Enablement (C4E) to promote efficiency, innovation, and reuse.
- Adopt a product mindset: Drive innovation and software stakeholder ownership to meet customer expectations using iterative feedback cycles, like those associated with Agile and DevOps practices.
- Design for composability: Increase flexibility and agility with architecture based on composable building blocks and an API-led approach to connectivity.
- Don’t reinvent the wheel: Expedite development while reducing effort and cost using the Catalyst Knowledge Hub’s proven expertise, assets, and resources.
Four Lifecycle Phases
Catalyst aligns with the typical design, build, scale, and optimize lifecycle used for technology products. Specialists define four lifecycle phases to guide their decisions and plan corresponding individual steps.
- Plan for success.
- Establish the foundation.
- Build to scale.
- Measure impact.
Catalyst Knowledge Hub
Specialists can find templates, design guides, architectures, and examples in the Catalyst Knowledge Hub. This online portal provides specialists with MuleSoft best practices and assets to execute more effectively. Let’s review some resources in the Knowledge Hub.
Playbooks are a primary tool found in Knowledge Hub. Catalyst specialists use playbooks as a guide through the complete design-build-scale-optimize delivery lifecycle structured around Catalyst phases. Designed for MuleSoft customers, playbooks cover the prevailing types of Catalyst API-led technology transformations. Specialists use the playbooks as an outline of high-level activities and corresponding steps for an engagement to be successful.
Knowledge Hub provides other extensive resources for specialists in a searchable, filterable format, including:
- Blueprints: Detailed plans and architectures for common integration scenarios.
- White papers: In-depth documents that provide insights and best practices.
- C4E models: Center for Enablement models to help you establish best practices and governance.
- Code samples: Example code snippets to help you get started quickly.
Specialists can also jumpstart initiatives with technical assets available in the Anypoint Exchange. The MuleSoft Anypoint Exchange is a curated catalog of reusable assets designed to help developers build APIs and integrations.
That wraps up our review of Catalyst basics, including core principles, lifecycle phases, and assets available in Knowledge Base. Next up, review the importance of business outcomes in Catalyst.
Focus on Business Outcomes with Catalyst
The Catalyst approach is fundamentally outcome-based, so Catalyst specialists focus on business outcomes in each aspect of their work. Let’s review how specialists consider business outcomes throughout all areas and stages of their engagements.
Discover and Define Business Outcomes
A business outcome is defined as a change in business performance based on a specific metric, such as a key performance indicator (KPI). In this sense, business outcome refers to an end result. In Catalyst engagements, a business outcome may also refer to a goal or a desired business outcome.
Catalyst specialists research a current business situation and define what success will look like when the desired business outcome is achieved. Specialists determine KPIs and align them with stakeholder expectations to be sure the engagement will deliver an agreed-upon business value.
Business outcomes have four components, as shown in this table. Take a moment to review the detailed makeup of a well-defined business outcome.
Component | Description | Example |
---|---|---|
| A generic concept of requirements, often expressed in use cases | Reduce end-to-end processing time and improve the customer experience |
| The specific area to be changed or improved in the business | New inventory management system |
| The opportunities for broader impact of the solution(s) to technology architecture, applications, or operations | Integrations across disparate, siloed inventory systems |
| The relative worth, utility, or importance of a concept, usually a quantifiable metric | A 30% reduction in failed/returned orders due to order errors |
Examine the differences between a business initiative and a technology use case to refine and clarify your desired business outcome. The benefits of business outcomes are evaluated in separate, yet related areas.
- Business capability benefits are outcomes related to specific strategies and processes within the business.
- Platform capability benefits are outcomes related to technology architecture, applications, and operations.
Specialists can refer to the Catalyst Business Outcomes Playbook in Knowledge Hub for more details.
Confirm and Document Business Outcomes with Stakeholders
Specialists summarize the benefits of the MuleSoft platform for stakeholders in a platform vision. This document describes how MuleSoft enables business outcomes and supports architectural principles of the enterprise. It includes an executive summary of the planned platform architecture for stakeholders. Catalyst Knowledge Hub includes a document template for the platform vision.
Specialists also create a communications plan for stakeholders, which includes recommended meeting types and frequency. It's critical to identify all stakeholders, determine their interests, and meet those needs throughout the delivery lifecycle. Typically, stakeholders include executives, line of business owners, representatives from enterprise architecture and security, design authorities, product management, and IT teams. Specialists secure early engagement, and increase awareness, involvement, and accountability among stakeholders by implementing a communications plan.
Determine Engagement Scope for Business Outcomes
Specialists scope engagements to achieve business outcomes in the short term while maximizing long-term benefits. Therefore, specialists assess factors beyond the existing time horizon that may influence an existing engagement.
For example, a current business outcome may focus on a new shipping integration. The Catalyst approach considers an integration that could accommodate all shipping partners rather than a one-off solution tied to the current shipping provider. A future engagement could extend the implementation to a network of providers without having to discard work delivered in the initial engagement.
Specialists define engagement scope so that it’s clearly traceable to business outcomes. An architecture roadmap can be used to illustrate scope extensions outside the current timeline. For example, if implementing an order-to-cash scenario using an API-led approach, you could use the API Roadmap — Customer Example document in Knowledge Hub.
Changes to engagement scope are common in Catalyst engagements. So it’s important to articulate and justify their potential value with stakeholders when they occur. Teams should consider factors such as cost to implement, revenue implications of not implementing, and potential risks.
Measure and Track Business Outcomes
Realizing business outcomes for stakeholders includes measuring, tracking, and reporting results. Specialists use built-in tools and processes to ensure outcomes are assessed and reported against specific metrics. To satisfy stakeholders, specialists can follow these steps.
- Create the 180-day activity plan.
- Select KPIs.
- Develop KPI dashboards.
- Implement the MuleSoft Catalyst Metrics Toolkit.
Let’s review the key points for each process.
180-day Activity Plan
Specialists use this plan to aggregate activities into incremental 30-day deliverables and map them to steps in the Catalyst Business Outcomes Playbook. The plan can be created as a classic Gantt chart with activities, timelines, deliverables, and owners. Specialists maintain the plan throughout the engagement, managing, updating, and reporting statuses to stakeholders.
Select KPIs
The Catalyst specialist develops and confirms a list of KPIs with stakeholders. Tracking these KPIs provides a window into how well the organization is adopting the Catalyst approach and the API-led operating model.
Develop KPI Dashboards
Dashboards should provide a concise, visual representation of KPIs, so Catalyst specialists choose the option that works best for their team. Specialists can implement a simple spreadsheet or Confluence page to communicate KPI data. Or, they can work with one of the out-of-the-box solutions available through the Metrics Toolkit described next. A dashboard usually includes the KPI goal, the data, the change from a prior period and further comments. A KPI dashboard supports overall communication, allowing teams to view achievements against goals to share and promote success.
Metrics Toolkit
Catalyst specialists use a Mule app that collects, aggregates, and loads platform metrics into various visualization systems. The app, known as the MuleSoft Catalyst Metrics Toolkit, offers out-of-the-box integrations and visualization options, including dashboards and charts. In addition to platform metrics, the toolkit also extends capabilities to integrate with external applications like Jira, Confluence, Jenkins, Bitbucket, and Splunk to gather software development lifecycle (SDLC) metrics.
You’ve finished a recap of all the ways business outcomes are woven into Catalyst engagements. The next topic explores recent MuleSoft updates to support event-driven API architecture.
Event-Driven Architecture with API-Led Design
Implement event-driven architecture (EDA) as part of your API-led strategy using the AsyncAPI support in Anypoint Platform. The MuleSoft Anypoint platform makes it easy to design, implement, deploy, and govern APIs. Recently, MuleSoft introduced advanced support for event-driven API architecture, support for implementation of AsyncAPI 2.6, which makes working with event-driven APIs as easy as working with REST APIs.
Catalyst users are familiar with REST APIs and the synchronous communication model: make a request and wait for the response. Typical web users understand this process; entering a URL in a browser address bar will send a request to a server, which then sends back website content as a response.
Event-driven architecture serves use cases where there’s no need for a response from the server. If you simply want to communicate that something happened, such as “a new user signed up,” then integrations can be based on events. Event-driven architecture is referred to as asynchronous communication since the integration doesn’t need to wait for a response. Imagine an intermediary holding information until another system needs it. The intermediary, or broker, simplifies the asynchronous handling of many interactions.
Now, suppose you want to send extra information along with the event, such as, “Here is the new user’s name and email address.” Once again, the system sending it doesn’t need a response—other than a confirmation that the broker received the message. Broadly speaking, there are two types of events: simple notification events and data events, which contain more information and context.
- Notification events indicate that something has happened: a state change, such as “the order has shipped.” Notification events may be referred to as messages, identifiers, or notifications.
- Data events carry additional information related to the state change, such as the product to ship, its price, and a shipping address. This data can then be used by other systems to perform further processing or actions.
Event-driven architecture expands your options to provide solutions. For some use cases, REST APIs and synchronous communications are less efficient and have a higher chance of failure due to excessive coupling (tight interdependencies between systems) and continuous polling (repeatedly checking for updates). Event-driven architectures help organizations build real-time business integrations with low latency and high resilience.
Let’s look at the common event-driven architecture patterns specialists use for these two types of events.
Event Notification Pattern
The event notification pattern is used for notification events. It communicates a change to other systems without transferring the state itself. A typical implementation is a message sent to the broker, which can be published to another system (or a system can subscribe to these messages). The event contains a reference to the state change, but very little else.
The benefits of this pattern:
- It reduces coupling between the producer and consumer of events.
- It enhances flexibility and reusability of components.
Event Carried State Transfer (ECST) Pattern
The second pattern is referred to as the event carried state transfer (ECST) pattern. This pattern uses events to transfer data and state between services. Each service maintains a local copy of the data and state necessary for its operations. With this pattern, the emphasis is on transferring the actual state within the event.
The benefits of this pattern:
- It decouples services, improving scalability and reliability.
- It provides a consistent view of each system’s state, reducing the need for shared storage.
- Events carry both state and its data, so a receiving service doesn’t have to contact the source system to get data.
An event combining state and data is often referred to as an event payload or message payload. A typical implementation is a messaging system with complete domain objects in the message payload.
As you can see, event-driven architecture offers added flexibility to design reusable components and implement solutions. You’ve reviewed the two types of event patterns specialists can use, now let’s take a moment to see how MuleSoft supports the use of Async API.
Async API and MuleSoft
AsyncAPI is the open-source, industry-standard language used to describe messaging interfaces. Messaging interfaces are another way to refer to the intermediary systems and services mentioned earlier. Catalyst specialists use AsyncAPI to standardize how messages are structured, transmitted, and processed between different systems or services. Using AsyncAPI standards promotes the reuse of EDA solutions and provides consistency in documentation and security governance.
Out of the box, you have been able to use Anypoint Design Center or Code Builder to design AsyncAPI specs but now you can scaffold and implement those specs in a Mule project using Anypoint Studio or Code Builder. Message brokers currently supported for implementations are Anypoint MQ, Kafka, Salesforce platform events, and Solace PubSub+.
Using EDA, specialists can build scalable event-driven solutions. Using AsyncAPI standards allows specialists to create integrations that work smoothly and efficiently with intermediary systems and services.
You’ve reviewed your Catalyst knowledge and learned about some recent updates for event-driven architecture in MuleSoft. Now it’s time to test your understanding of these topics and complete the exam to maintain your Catalyst Specialist certification.
Resources:
- Trailhead: Delivering Successful Business Outcomes with Catalyst Trailmix
- MuleSoft Documentation: AsyncAPI Support to Implement Event-Driven Architecture
- MuleSoft Documentation: Implementing AsyncAPI Specifications
- Website: AsyncAPI Initiative for Event-Driven Architectures
- Website: Explaining Event-Driven Architecture