Many people often only consider the number of distinct consumers of APIs or integration services when considering reuse. However, there are many additional constructs to consider when driving reusability for integration assets.
What is reusability?
Reusability is when an integration object or process is built and then used several times after its initial use — either by the individual that created it or across teams/organizations. Reusability is a non-functional requirement that every development team strives for.
Reuse increases efficiency and reduces cost since it saves development time and effort — ultimately increasing the ROI of the integration asset with each use.
Some common examples are:
- Java library
- Function or class code
- Servers hosting virtual machines
Who drives reuse within IT?
Without consumers, there is no reuse. Within the APIs and integrations space, there are different kinds of audience or stakeholders that will drive and shape the organization’s reusable components. The below group of stakeholders need to collaborate to define what can be reused and degree to which reuse can be performed:
- Producer developers: These are the developers that produce API and integrations technical assets for consumption either by self or others. They would be typically central IT or LOB IT.
- Consumer developers: These are the developers that consume API and integrations technical assets to build higher-level applications and services. They are typically LOB IT or external developers.
- API and integration architects: These are the thought leaders who shape up the overall architecture and solution direction for an API or integration.
- Enterprise architects: The broader enterprise-level architects who have greater visibility into the business capabilities, data models, and overall architecture principles and standards
Reusable components of integration
There are multiple constructs or integration building blocks that can promote reuse. The rest of this article describes the various constructs that MuleSoft platform offers to drive reusability. While the discussion is in the context of Anypoint Platform, the concepts can be generally applicable in the overall integration space.
APIs
APIs are invocable services that expose certain meaningful business capabilities.
- Reusability type: Invocable service or code called by multiple services or applications.
- Target audience: Consumer developer community. Consumers can be inside or outside the organization, self, or a third party.
- When to use: APIs are used to interact (send or receive information) with an application – typically, to perform a CRUD operation or trigger an operation within that application.
- MuleSoft offerings: Anypoint Design Center, Runtime Manager, Studio, Monitoring, API Manager, etc.
- Examples: Rest APIs: Invoice API GET, Purchase Order POST, etc.
- Considerations:
- Develop APIs that are aligned to the organization’s business model to ensure meaningful usability.
- Deploy your APIs via API Manager to track and manage the usability behavior.
- Ensure well-defined documentation and evangelization to promote the usability.
Connectors
Connectors are pre-packaged code that simplifies and hides connectivity and operational details of the underlying application for which the connector exists. MuleSoft provides a number of out-of-the-box connectors for various COTS applications.
- Reusability type: Invocable code or library used by multiple projects.
- Target audience: Producer developer community that develops APIs or integration services.
- When to use: When working with a COTS application for which an existing connector is available within the Exchange. In absence of a pre-existing connector, the developers are required to understand the inner details of the COTS application.
- MuleSoft offerings: A number of pre-built connectors offered on Anypoint Exchange
- Examples: Salesforce Connector, SAP Connector, JIRA Connector, etc.
- Considerations:
- Utilize the connectors that are available on Exchange.
- Leverage the accelerators that come with the connectors or jumpstart on the development cycle.
Code templates
Code templates are pre-built applications or portions of applications that are imported into a consuming application as-is for reuse of functionality or further customization. Templates provide developers a jump-start and faster application development:
- Reusability type: Non-invocable code used across multiple projects.
- Target audience: Producer developer community that develops APIs or integration services, API and integration architect.
- When to use: Complex pieces of code that have consistent usage across multiple projects.
- MuleSoft offerings: Anypoint Studio, Anypoint Design Center, Anypoint Exchange
- Examples: Error-handling code, lookup code, message parsers
- Considerations:
- Publish the code templates as formal assets within Exchange to enable discovery by other developers.
- Avoid copy-paste style usage of the code templates.
- Determine common functionality that has potential usability across multiple projects.
- Assign proper ownership and governance for ongoing management of the templates.
API fragments
API fragments are reusable components of RAML specifications that abstracts and develops components for designing APIs. The fragments are developed and used at design time.
- Reusability type: Non-invocable code across multiple projects.
- Target audience: Producer developer community that develops APIs or integration services, API and integration architect, enterprise architects.
- When to use: Complex piece of data objects, behavior, or documentation that could be reused.
- MuleSoft offerings: Anypoint Design Center, Anypoint Exchange
- Examples: Data objects, documentation, traits, library
- Considerations:
- When abstracting data objects as API fragments, ensure alignment with the business-centric data models. Where possible, enterprise architecture must be consulted to understand the presence of enterprise data models.
- Publish the fragments as formal assets within Exchange to enable discovery.
- Consuming projects must import the fragment, as opposed to copy-paste.
- Ensure documentation and evangelization of the fragments.
Messages
Messages are formal pieces of data objects (collection of attributes and values) that are shared between two or more applications. They are used within a context of JMS compliant messaging infrastructure, for example, Anypoint MQ.
- Reusability type: Non-invocable code across multiple projects and applications.
- Target audience: Both producer and consumer developer communities that develop or consume APIs or integration services, API, and integration architect, enterprise architects.
- When to use: Complex piece of data objects that are to be used within a messaging system.
- MuleSoft offerings: Anypoint MQ, Anypoint Exchange
- Examples: Data objects – invoice data, customer data, any request data, etc.
- Considerations:
- Ensure proper schema or structure is developed. Where possible, ensure alignment of the schemas and structure to enterprise data governance and models maintained by enterprise architecture.
- Identify message steward and ownership definition.
- Consider employment of durability and delivery guarantees — the more robust and modern messaging systems provide these features.
- Consider sizing of the messages based on your messaging system, Anypoint MQ, for example, support messages upto 10 MB size.
Queue, exchange, topics
These are the conduits within the messaging infrastructure that aid in transmitting messages between the applications.
- Reusability type: Infrastructure used across projects and applications.
- Target audience: Both producer and consumer developer communities that develop or consume APIs or integration services.
- When to use: Complex piece of data objects that are to be used within a messaging system
- MuleSoft offerings: Anypoint MQ, Anypoint Exchange
- Examples: Shipment status update exchange/topics, invoice queue, purchase order queue, etc.
- Considerations:
- Topics and exchanges are by definition reusable across multiple applications.
- Develop sufficient retries, durability, and delivery guarantees when designing such infrastructure.
- Consider deployment of the infrastructure within appropriate regions (if cloud) for appropriate latency.
Mule runtimes
Mule runtimes are MuleSoft’s execution engine equivalent of JVMs that host one or more applications for their execution. The runtimes provide necessary resources — such as memory, threading, scheduler, etc.
- Reusability type: Infrastructure used across projects.
- Target audience: Platform administrators.
- When to use: Deploy related Mule applications together.
- MuleSoft offerings: Anypoint Runtime Manager, Anypoint Monitoring
- Considerations:
- Limit the number of applications deployed within the same Mule runtime. Restart or any management activities on a Mule runtime will impact all resident applications.
- Deploy related applications together within the same Mule runtime.
- CloudHub allows for a maximum of 10 applications per Mule runtime. Higher number of applications can be deployed on on-prem runtimes but be careful when increasing application density.
- Utilize the core and memory sizing as well as licences consumed by a runtime to determine the reusability factor of the runtime.
API policies
API policies are constructs that enable enforcement of regulations, management, security, and quality of service of APIs — such as, security, traffic control, service level agreements, etc. Within Anypoint Platform, the API policies are utilized within API Manager. A policy can be utilized across multiple APIs.
- Reusability type: Configurations used across multiple API deployments,.
- Target audience: Platform administrators
- When to use: When multiple APIs share the same policy controls — such as traffic control, security, etc.
- MuleSoft offerings: Anypoint API Manager
- Examples: Rate limiting policy, IP whitelisting, token enforcement policy, etc.
- Considerations:
- Utilize the out-of-the-box policies as much as possible.
- Consider development of custom policies when the existing policies do not meet the business needs.
- Develop governance and ownership for policy definitions and ongoing management.
- Carefully consider deployment of an API proxy for enforcement of policies depending on the available Mule licenses and resources to deploy a proxy/gateway.
Common services
While common services are not something that are provided by the platform “as-is,” customers can choose to develop commonly used applications themselves and utilize them across multiple applications/APIs. Examples of such application components would be logging framework, exception handling framework, auditing framework, caching framework, unit conversion, etc.
- Reusability type: Reusable application components used across multiple API/Integration application development projects.
- Target audience: Producer developer community.
- When to use: When multiple applications share common traits and services.
- MuleSoft offerings: Anypoint Studio, Anypoint Design Center, Anypoint Runtime Manager
- Examples: Logging framework, exception handling framework, auditing framework, caching framework, etc.
- Considerations:
- Engage your architects and lead developers early-on to understand the common services requirements.
- Deploy the common services as libraries or even better as reusable APIs in which case common services could be treated simply APIs.
- Publish the common services through Exchange and ensure the developer community understands the availability of the common services.
- Ensure usage of common services either within design review or code review process.
Security groups
Security groups are used to aggregate users with similar roles and assign necessary authorizations for those roles. A security group, once defined, can be used within or across projects.
- Reusability type: Reusable configuration items used across projects.
- Target audience: Platform administrators.
- When to use: When multiple projects or applications share similar user roles and permissions.
- MuleSoft offerings: Anypoint Access Management
- Examples: Field representatives group, auditors, etc.
Return on investment (ROI) for reusability
Reusability improves a team’s ability to deliver solutions faster and cheaper. However, there are upfront costs incurred in developing the component in a manner that has sufficient in-built generality and abstraction to be used by multiple consumers. Further, the advantages of developing reusable components is only realized if there is availability of consumer base or relevant use-cases.
Teams must develop discipline to measure the advantages and ROI of reusable components. Measurement of such a KPI would enable reporting to management and proving the successes of the team.
Key metrics and KPIs
Below are some important KPIs and metrics that will help in understanding the benefits of reusability:
- Total number of reusable objects
- Reusability rate
- Consumer growth rate
- Estimated cost savings because of reusability
- Estimated time saving because of reusability
ROI calculation
Below approach could be used to determine the ROI:
- Determine the formula to calculate the benefit. A typical formula would include these components:
- Number of reusable components (N)
- Cost to develop the component (CDev)
- Expected reuse rate across consumers (R)
- Cost avoidance for every reuse (Cavoid)
- Collect metrics and determine savings
- Extrapolate over the investment horizon
- Highlight and report key metrics
Enabling reuse with Anypoint Platform
When driving reusability, the focus needs to be on identifying and abstracting the components and making it ready for broader consumption. Anypoint Platform offers a number of tools to help your organization with your reusability requirements. These tools work in unison to provide a full lifecycle management for the APIs and Integration solutions.
Login to Anypoint Platform or sign up for a free trial to begin enabling reuse of your APIs and integrations.
