The goal of this three part series is to describe the strategy and framework for constructing an ecosystem from cloud services to best serve your enterprise. It’s also a discussion about the future role of cloud service providers and how the end user will become ultimately empowered.
Let’s start with defining what is meant by a Cloud Ecosystem:
“A Cloud Ecosystem is the organization of cloud services to facilitate the execution of business processes. Service level agreements for those relationships will be oriented around the process and not the individual services. In turn, Enterprise operations can be mapped and executed with quality standards within the ecosystem.”
Begins and Ends with Process
The measure of a well executed cloud ecosystem is how effectively it will drive your company’s most important processes. So your cloud ecosystem design begins with understanding the processes responsible for delivering your company’s products and/or service offerings. Mapping these services is essential for establishing the criteria for your cloud Service Level Agreements (SLA).
Looking at an order-to-cash process, we may find that we will work with an ERP provider, an EDI provider, an Outbound Logistics provider, and a PCI compliant credit card processing provider. All of these could be software-as-a-service provided offerings integrated to fulfill this single process.
The order-to-cash process should be familiar to most. It also is one of the most critical processes because order-to-cash is the centerpiece of business continuity. Therefore the service levels to the business will be of the highest order. As a result the ERP, EDI, Outbound Logistics, and PCI compliant credit card processing cloud services should be held to the same SLAs in relation to this process.
An ERP system manages many different business processes. So not all processes should be considered as critical as order-to-cash. This is a very important point to understanding because this is going to shape the contract negotiations with respect to the SLA.
Cloud Ecosystem Service Level Agreement
If a SaaS service offers the execution of different business processes then we should not have a single SLA representing the service as a whole. Overall uptime of the system must be in lockstep with the SLA of the most important process. However, every other process could and should require a different set of SLAs. The different SLAs will dictate the pace at which the provider will engage support staff and bring resolution. For a manufacturing company that is a make-to-stock operation, their procure-to-pay processes are not as critical as a manufacturing company that is a just-in-time operation.
The challenge is to stop thinking that you are buying a cloud service. When considering a cloud ecosystem you are buying the execution of business processes. If a cloud provider’s solution offers multiple processes, then each process must be secured with a separate SLA based on the needs of your company. Cloud providers need to understand their customer’s requirements and offer an infrastructure and support model to construct a process driven SLA contract.
I often joke that my engineer now is my attorney, not a technician. You need to work with your legal department to secure your workflows by way of a legally contracted architectural blueprint. This blueprint should bring assurance that the cloud providers can provide the level of continuity that your business requires.
Integration ITIL
The cloud provider, who will take on the task of securing each process in partnership with other cloud solutions, is the one who is really offering an ecosystem. If any part of our order-to-cash process is in failure, the primary provider (most likely the Fulfillment or ERP provider) is responsible for engaging the right internal technical teams and any other cloud provider’s technical resources involved with that process, to help bring it to resolution. This partnership is essential and genuinely strategic.
A cloud ecosystem provider needs to create partnerships (more than just an app store) of complimentary cloud solutions but with strict integration standards. These standards will map to specific SLA agreements that the client’s blueprint will demand. They need to have escalation and engagement procedures in place to be able to support the process. Finally, the architecture must be loosely coupled and service oriented. Upgrades of any cloud solution can not cause overall integrations to fail and in turn impact the very process they are fulfilling.
This may not be the mainstream method of engaging cloud service providers, yet. However, it will be a necessary shift. To create a meaningful relationship between the customer and the providers, all parties need to architect their contracts, infrastructure, and their support infrastructures around the processes. In a cloud ecosystem, it’s all about process continuity and cloud providers need to be challenged to organize their own operations to support this model.
In the next part of this series, we will look at private and public cloud ecosystems and the implications for the Internet backbone.
(2400 Views)