Salesforce MuleSoft Platform Architect

A platform architect must know what each component is for. You walk through design, exchange, management, runtime and monitoring tools and decide which one answers which question.

• Design Center and API specifications
• Anypoint Exchange as a catalog
• API Manager and its role
• Runtime Manager and deployment targets
• Anypoint Monitoring and visibility
• Access Management and organizations

You build A component map showing which Anypoint tool owns each stage of an API’s life.

A platform survives on its operating model. You advise on a Center for Enablement, choose hosting, identity and client management options, and decide where control plane and customer data must reside.

• The Center for Enablement and its charter
• MuleSoft Catalyst as a delivery framework
• Hosting options for the runtime plane
• Identity and client management choices
• Data residency for control plane and runtime
• Roles, environments and business groups

You build A platform foundation proposal covering operating model, hosting, identity and residency.

An API is a product with consumers. You write specifications, manage dependencies between APIs, specifications and clients, apply semantic versioning, and publish reusable assets for others to find.

• Writing specifications with RAML and OpenAPI
• Fragments and reusable specification parts
• Dependencies between APIs and clients
• Semantic versioning and deprecation
• Publishing assets to Exchange
• Making assets easy to discover and trust

You build A published API asset with a spec, fragments and a versioning policy.

Layers keep change local. You identify the APIs a business process needs, assign each to the system, process or experience layer, and choose data models that suit what each layer exposes.

• What belongs in each layer
• Identifying APIs from a business process
• Where logic and orchestration live
• Canonical and layer-specific data models
• Avoiding layers that add cost but no value
• Reviewing an API landscape for layering errors
• Naming and ownership across layers

You build A layered API design for one business process with data models chosen.

Governance should be applied by the platform rather than remembered by developers. You configure API instances and policies, choose among enforcement approaches, and match each policy to a non-functional need.

• API instances and environments in API Manager
• Enforcement through gateways and proxies
• Rate limiting and spike control
• Allow lists, header rules and threat protection
• Applying policies by layer and by audience
• Automated policies and policy ordering

You build A governance policy set applied to three APIs with different needs.

Who may call an API, and how often, is a design decision. You use client applications and contracts, access tiers, and OAuth 2.0 with an external identity provider to control consumers.

• Client applications and contracts
• Service level tiers and approval
• Client ID enforcement and its limits
• OAuth 2.0 token validation policies
• Using an external identity provider
• Securing system APIs behind outer layers

You build A client access design with tiers and OAuth 2.0 on a protected API.

An implementation has to join the platform that governs it. You link applications to API Manager with auto-discovery, decide when a virtual private cloud is needed, and plan unit testing and delivery automation.

• Auto-discovery between an app and its API instance
• When a VPC is required
• Connecting to on-premises systems
• Unit testing with MUnit
• Automating build and deployment
• Environment promotion strategy

You build An implementation architecture with auto-discovery, networking and a delivery pipeline.

Where and how an application runs decides its reliability. You choose worker sizes and counts, shared or dedicated load balancers and networking, and remove single points of failure.

• Worker sizes and counts
• Shared and dedicated load balancers
• Networking and DNS for applications
• Zero-downtime redeployment
• Predicting reliability from the deployment
• Removing single points of failure

You build A CloudHub deployment design with sizing, networking and availability reasoning.

A quality goal needs a mechanism. You apply caching and Object Store, choose client resilience strategies such as retries and circuit breaking, and judge when scaling out will and will not improve response time.

• Caching scopes and caching policies
• Object Store for shared state
• Retries, timeouts and circuit breakers for clients
• Fallbacks and graceful degradation
• When scaling out helps response time
• Measuring a quality goal

You build A quality plan that pairs each response-time and availability goal with a mechanism.

A network you cannot see is a network you cannot run. You learn which components produce monitoring data, what metrics each invocation collects, and which alerts to set at each layer.

• Where monitoring data comes from
• Metrics collected for API invocations
• Dashboards by layer and audience
• Alerts on errors, latency and capacity
• Logs and correlation across APIs
• Using analytics to improve the network

You build A monitoring and alerting design for an application network across three layers.

Take a business and design the platform strategy: foundations, API layers, governance, deployment and monitoring. You defend the design on reuse, risk and cost as you would to a sponsor.

• Reading the business and its systems
• Designing foundations and API layers
• Planning governance, security and deployment
• Planning monitoring and enablement
• Presenting and defending the strategy

You build A complete Anypoint Platform strategy for one organization, from operating model to monitoring.