Customer centricity and the need for speed requires organizations to rethink processes, leveraging their vast amounts of tools and technology for change and adaptation to customers needs.
IT organizations face a continuously growing amount of activities due to new products and services offered to their internal and external customers and this will increase in the future and at the same time requiring all tools to work on centralized data.
What are the foundations of a composable service organization?
Let’s discuss the foundations of a composable service organization and what they entail.
1. Sourcing activities
Efficient business requires all kinds of assets like applications, databases and servers but also employee phones and printers and many more. Those assets need to be monitored, managed and maintained. ITIL-based processes to perform these tasks cover areas of incident handling, asset, change, or problem management to name just a few of the common ones.
To meet the growing requirements of internal and external customers service delivery is often multi-sourced to various specialized providers to serve the needs in an efficient and customer-centric way while keeping the overall service management in house.
For these outsourcing actions, extensive contracts between organizations and providers are negotiated with roles, responsibilities, SLAs, task descriptions, security requirements, data privacy terms and much more to separate responsibilities between “what needs to be serviced” (organization) and “how is the service being delivered” (provider).
2. Increasing complexity
This leads to a potentially large provider landscape where suppliers perform their contracts by using their own applications connected to the organization’s central systems. To always have the “big picture” at hand on an overall contract level, central tools remain the source of truth for an organization. This means these tools need to be kept up-to-date with any provider activities, e.g. an incident or a change being rolled out.
This central asset builds the foundation of the organization’s capabilities for transparency, to change and optimize (or automate) processes, and steer providers where needed.
Connecting the dots between these systems might not sound as a too complex undertaking as there are interfaces provided by tools and technologies, so let’s put in some code in between for connectivity and transformation or attach this functionality to an existing tool acting as the overall glue.
Consider the following. What if:
- An existing service provider is being exchanged due to end of contract?
- A redesign of a currently deployed process is required?
- A new product is launched, flanked by a new service offering?
- A component in the service management architecture is going to be replaced?
- Tickets need to be automatically enriched by data from internal or third-party systems?
Changes like these can have huge impacts on surrounding elements of the overall architecture. Existing point-to-point connections need to be rewritten, tested, and deployed; you need to adapt to new processes using new interfaces; and APIs all add in additional complexity.
3. A robust and scalable approach
Aiming for a strong approach offering the flexibility to minimize these efforts. With APIs as reusable building blocks built on a platform that allows development and execution of end-to-end integration, an organization can be prepared for and adapt to future changes.
Let’s look at an alternative approach to centralize these integration requirements:
This chart shows a service architecture with MuleSoft acting as an abstraction layer in front of all your providers for collaboration and automation – building a foundation for your service activities. Many pre-built connectors to Salesforce ServiceCloud will allow you to easily connect your provider landscape and start automating your processes. Centralized governance and security are just two more aspects to consider.
Any other application can be attached for composability to this integration layer for data enrichment or automation tasks like these:
- Services for auto-provisioning of infrastructure
- Chatbots for further automation
- Automated data change on systems of record for GDPR-related processes
- Data warehouse connectivity for centralized analysis, SLA reporting, and invoice cross-checking
- Employee onboarding requirements like hardware ordering and provisioning or access-management
With this foundation, your organization can incorporate more use-cases for automation, e.g. using MuleSoft Composer, staying flexible without spreaded custom code for connectivity across these systems, and requiring significant efforts to develop and maintain.
Conclusion
Wrapping your central service related applications and creating an abstraction layer brings in flexibility to any kind of contracting with your providers, giving the providers the ability to smoothly connect to your application landscape and to deliver on the agreed contract.
This adds agility and speed for processual changes, and security by granting access only to resources needed. Surfacing service-related data in other applications like data warehouses for SLA reporting or invoice cross-checking, putting in place an end-to-end GDPR request for the “right to be forgotten”.
MuleSoft brings in the required capabilities for a composable service management and delivery. Read more about MuleSoft and Service Cloud and about ServiceNow and ServiceCloud together with MuleSoft.
