I joined the MuleSoft Customer Success (CS) team in mid-2019 which was the beginning of a new adventure for me in many ways. I was out of my comfort zone — both in terms of my new role and the technology platform. Throughout my career as an integration consultant, I focused on how to get the data from source to target using drag-and-drop desktop tools. It did not take me long to realize that, at MuleSoft, this is just one of the problems we help customers solve. The focus here is to drive long-term success via strategic initiatives, rather than tactical ones.
During the first few weeks in my new role, I had no idea what the terms “application network,” “C4E,” “KPI and reuse [where SOA fails],” or “CIO dashboards” meant. During those weeks, I would tell my wife that I was concerned that this might not have been the right career move since I didn’t think I had the experience with the platform. I was nervous and coping with the challenges that came with skilling myself up on so many arcane topics.
My wife always said, “You’ll learn and grow into it, spend time reading and taking notes, and ask questions — just like we do with our doctor’s visits.” At this same time, we were bracing ourselves for a new chapter in our personal lives: parenthood. As I was reading the MuleSoft documentation, I was having similar reactions as my wife and I were reading blogs and books on parenting.
That was when it started to click. It’s simple — when a baby cries, feed them or change their diaper. How hard can it be? Similarly, how hard can it be to talk about VPC and best practices around integrating with Salesforce? Within a few weeks, I got the reality check and began learning as much as I could about both the application network and becoming a parent.
If you are new to MuleSoft, and need a place to start here are some best practices I learned while I was onboarding into my current role.
Data gathering: Requirements and NFR
Capturing as much information as possible for API design and development will ensure a platform for a successful application network. Capturing both functional and nonfunctional requirements help align the design and development of the APIs to deploy a robust and scalable application network. System designed with known security, performance, availability, reliability, scalability, and SLA requirements ensures systems useability and reliability.
Example: An OrderAPI which must ensure 99.99% availability will be designed differently than the ExchangeRateAPI which can still work with cached data and at 95% availability. Functional requirements to capture order history for a consumer on a mobile channel will be designed differently than for a back-office portal.
MuleSoft recommends capturing as detailed information as possible for every use case/API and utilizing Anypoint Exchange to publish the information for easier consumption and promote collaboration.
Embracing the change: Processes and best practices
To build a successful application network it takes more than just creating APIs. A successful integration platform includes documentation and enforcing the use of standards, best practices, integration patterns as well as by blocking the use of anti-patterns. Recommendations include:
- Embracing design first API-led approach.
- Investing in a robust exception-handling strategy.
- Designing for reuse via microservices.
- Blocking the use of monolith applications.
Key adoption for a successful application network calls out for numerous changes across business and IT, such as:
- Moving away from siloed to collaborative departments.
- Adoption of process automation tools.
- Investing in C4E and a governed SDLC.
- Promoting and socializing reuse.
Measure progress: KPIs and CIO dashboards
CIOs are under a constant pressure to justify IT investment. How can CIOs clarify and deliver on ROI projections? One method is through the use of key performance indicators (KPIs). Project, program, and platform KPIs provide insights into how value is added to the organization or how enabling improvements help the organization achieve its desired goals. KPIs are defined to measure a specific goal/objective — knowing what, when, and how to measure is critical. Good KPI systems leverage data from across business, technical, and platform domains. Some of the candidate KPIs for CIOs could be:
- Effort and cost
- Transactional data/volume
- System uptime and downtime
- SLA measurement
- Incidents:
- MTTI
- MTTR
- Severity
- Ownership
- Number of assets and reuse rate
Keeping track of KPIs ensures if the project is on the right track to meet the objectives or a change in strategy is needed to align back with the goals.
Testing
An application network is only as strong as its weakest API. In API-backed application networks, this is achieved through a series of targeted testing — testing both green and red scenarios.
Testing provides visibility into how the systems would behave in production, detect abnormalities as early as possible and work on remediation to ensure we deploy a healthy API and also ensure anyone consuming the API maintains a health state. Testing APIs for negative scenarios help design a system to prevent the entire application network from going down.
A few of the recommendations:
- Knowing what to test
- Knowing where to test:
- Pre-PROD
- PROD
- Documenting and defining green and red scenarios
- Failing as early possible
- Test for non/functional requirements
- Publish test cases and results
- Include testing as part of CICD pipelines
- Get a signoff from business
- Update test scripts
Monitoring
Monitoring an API-based application network is a key in today’s world, with a single transaction flowing through numerous systems. Knowing what to monitor plays a key role. Monitoring helps us to understand how the application network performs, potential risks, or if it is performing as expected. Monitoring provides us with visibility into the core of the application network — the infra as well as the application. Monitoring infra is crucial to ensure maximum system and service uptime.
With Anypoint Monitoring, enterprises are able to:
- Reduce MTTI and MTTR
- Gain actionable visibility into the Application Network
For example, scale for peak loads in advance, monitor the connector-level metrics and introduce throttling capability to avoid overloading the backend systems.
Reuse: Anypoint Exchange
As the application network emerges and enterprises start to utilize the platform for multiple projects/ initiatives, we tend to see redundancy in functionality which increases both time and cost and leads to chaos in change management. Following are a few recommendations to overcome these challenges:
- Identify reuse opportunities across departments and projects
- Design for reuse in mind, socialize the available products
- Ensure assets are easily discoverable
- Enable self-service
Anypoint Platform promotes reuse throughout the API lifecycle via Anypoint Exchange. The platform promotes reusability starting from design specifications all the way to deploying APIs for consuming applications that enable enterprises to save money and to innovate faster.
C4E
A successful API program is backed by a strong enablement team, this is called a C4E (Center for Enablement). This is a new organizational approach that redefines the “center of excellence” as a virtual entity focused on enablement that provides the tools, templates, and assets for accelerating the development of new digital applications.
The C4E team will guide all the business groups/teams/users/business on every topic, such as:
- Deployment models
- Best practices
- Review boards
- Evaluate and deploy tools for process improvements
With almost four months in parenthood and ten with the application network, I have learned a lot. My anxiety has transitioned to excitement; responding well to cues of a crying baby but there is still a long way to go. Speaking with trained nurses, religiously monitoring the indicators, timely communicating with the doctors is what’s working well.
Similarly, with the proper support from a strong technical team and MuleSoft’s Catalysts offering, I see myself progressing on the Dunning Kruger scale. It took some time and a lot of curiosity to learn and try new things. I highly recommend anyone starting their journey with their application network to learn about API-led connectivity, outcome-based delivery, go through Catalyst and connect with the team. I practiced the same at home by attending parenting classes with my wife.
If you’d like to learn more about CICD and other ways to enhance the speed and quality of your MuleSoft development efforts, please watch the Friends of Max video below:
