Part of the Industrial SOA article series
Why is everyone talking about cloud computing? Drawn-out, expensive IT projects that are planned and implemented with few benefits for the business stakeholders are commonplace. In contrast, cloud computing offers business users the chance to immediately implement services with usage-based billing that are tailored to their requirements, often without the need to consult with the IT department.
However, aspects including security, architecture, availability, and standards are often not evaluated. Cloud consumers find themselves at the mercy of the cloud provider. Scenarios that require changing cloud providers after a cloud provider goes bankrupt, and the associated moving of data and/or applications, have not yet been sufficiently tested. Business continuity should play a key role from the start of a cloud evaluation process.
One of the greatest challenges here is the integration of existing data and systems into the cloud solution. Without integration spanning clouds and on-premise systems, processes can only be executed in isolation, leading to cloud-specific silos of isolated solutions. Important information for users is not available across processes and systems. Problems that would have occurred in the company's internal IT are now shifted to the cloud provider. To prevent "legacy clouds" or solutions that are hard to maintain, it is important to manage the entire architecture proactively and, in particular, the integration into the cloud. Even if cloud providers want us to believe otherwise, not every aspect of IT can be outsourced to cloud solutions!
Cloud computing is a model for usage-based network access to a common pool of configurable computing resources (e.g. networks, servers, storage systems, applications, and services) that can be provided and used quickly. IP-based services are requested via self-service and used online independently. A prerequisite for this is a broadband Internet connection with low latency. The IT resources are bundled into pools and provided as required. Billing is based on the services used.
In cloud computing, the following models are differentiated on the basis of horizontal scaling:
In deployment models, distinctions are made according to availability and installation location. Public clouds are services that are available to the public on the Internet. Private clouds are internal company services. Hybrid clouds and community clouds represent mixtures of these models, such as when Amazon computing power is used in the event of a failure or overload of an internal company cloud application.
Large companies for which IT plays a central role or represents a competitive advantage often build internal company cloud solutions in their own data centers. Small and medium enterprises frequently use public cloud services. A further distinguishing feature is the applications' focus. In the business-to-business segment, private clouds are predominantly used, while the majority of the business-to-consumer segment uses public clouds (Figure 2).
The key challenges of a cloud computing solution are security and quality aspects, including performance, latency, and availability. Integration, adaptation, agility, and the possible relocation of the solution play a major role during and after the implementation phase (Figure 3).
These aspects can be addressed with an SOA-based architecture. (Indeed, some experts and analysts believe that SOA is a prerequisite for the cloud.)
The National Institute of Standards and Technology (NIST) [REF-2] is the leading organization to define cloud standards. The integration challenge between clouds and how it can be addressed by SOA is one of the key areas. NIST defines the integration between the cloud and on-premise environments as cloud broker services. Cloud brokers are categorized in three different types:
The necessity of using SOA in a cloud environment should become apparent in this example of an order-to-cash process. In our example, dog food is advertised in Salesforce, purchased via Amazon, and billed in a local finance system. The overall cooperation between sales, logistics, and accounting, and the associated integration of process data plays a key role (Figure 4).
On the side of the business departments, the following questions may be raised during the process: Which products are of interest to the customer? Which products have they bought in the past, and which products are they considering? Depending on the customer's credit line, is the delivery prepaid or invoiced? What is the availability and shipment status of the products?
Linking the different cloud systems with the local IT systems is necessary to answer these questions, which have a direct influence on the process. A common metric and definition is required in order to compare the data. It is best practice to establish a master data management (MDM) program that lays the foundation to common access to core entities of the enterprise such as customer, contract, or product. This principle of MDM also applies to cloud-based processes. In our example MDM defines a customer in all systems and therefore the customer can be identified. This integration takes place on multiple levels:
At the data level, we differentiate between the concept of data integration at regular intervals and data integration in realtime. Point-to-point integration and data cleansing at regular intervals could include, for instance, the daily data transfer of sales data from the Amazon shop to the Salesforce CRM system. By contrast, data integration for transferring sales data to the accounting system for invoicing is performed in realtime.
Effective business processes are changed directly by business departments on an ad hoc basis (according to their rights and roles) in order to satisfy changed requirements. In our example, the marketing department decides to sell products on both Amazon and on eBay, motivated by the free-of-charge delivery. For process integration, this means the incorporation of a further SaaS solution into the process flow, based on common data objects. We can therefore use SOA concepts like enterprise business objects, which contain data such as customer definitions, and the enterprise business services, such as the update to a customer file. The various cloud solutions often define these business objects and services differently, which is why a common meta-model that integrates the process is required. The following are required for the object model:
All objects should be held in a common repository and data dictionary. A model designer can be used to amend the objects. In the future for complex objects, a model matcher based on conventions, catalogs, dynamic typologies, and search agents might be used (semantic SOA).
Decision rules that can be abstracted in a rules engine can therefore be changed by business users at any time. This is a fundamental aspect for process agility. In our example, a customer's order is not sent until open payment of 150 € is received on his previous order. This threshold can be changed by the business users at any time, for example if the total amount of open invoices is very low or high. Rules engines and task management solutions are used in particular for SaaS cloud applications that are not individually programmed. However, the various cloud applications use different rules engines, so a common standard and an overall meta-model for defining objects and rules could resolve this in the future.
The same applies to task management. If a product was not delivered, customer service intervenes manually and offers the customer free express delivery. The resulting tasks must be performed both in the cloud solutions, such as Amazon, and in the local accounting system. One solution would be the introduction of uniform, service-oriented task management or case processing in a general process portal for identifying and handling processes. The traceability of processes is important here. In our process, this refers to the order status or where the order was lost, and determines who is responsible for the additional shipping costs. The process owner is defined across all clouds. If anything is ambiguous, it ends up in a central error hospital or a clearing house for processes. As an outlook, a centralized cloud service for task management, logging, and an error hospital may be a solution.
Security standards play a decisive role in compliance with security provisions over system boundaries:
Every company needs to ask itself whether it can afford to lose complete control over its data, or whether it's better to maintain control. In our process example, the decision was made to shift the CRM and shop customer data to a cloud solution. The accounting data continues to be managed in the company's own data center. For the definition of critical company data and the evaluation of a cloud solution, the following procedure has proven effective:
In a SOA architecture, the services are available via IP and can be reused. Protection of critical data and processes starts in the DMZ and is based on an enterprise gateway (Figure 5). Requests are intercepted by the gateway before processing, and the rules (policies) to be applied are checked and forwarded to the Web services virtualization level.
The Web services virtualization level is generally a federated enterprise service bus that routes the call to the correct Web service. The gateway can be also be employed as an XML firewall in the DMZ, and is able to uncover specific Web service attacks and defend against them, including XML content, XML schemas, and DTD, cryptographic, and SOAP attacks.
Incoming messages are intercepted by the gateway, checked using policies, and then processed if necessary. A policy consists of a set of filter criteria that trigger specific actions. These filters are pre-defined and offer various functions, such as checking the size of an incoming message or an authorization. In our example, the size of the incoming message from the Amazon Shop system is checked. If it exceeds the limit, a notification is issued and further processing is halted.
The gateway can be integrated with a secure token service (STS) in order to use the latter's functionality. In addition, a secure socket layer (SSL) ensures protection of the messages on the transport level.
The implementation of company-wide standards plays a central role for both SOA and cloud computing. SOA governance can act as a precursor to cloud governance. The formalization of services and contracts in the SOA architecture serves as a template for formalizing cloud services. Structures and workflows between the business users and the IT department that were established as part of the SOA implementation serve as the basis. For the management of the processes, the attention is on system-wide solutions.
An administration concept rejects or allocates resources to the processes across various clouds and systems. A monitoring dashboards incorporated analytics for both clouds and on on-premise systems. They are incorporated with their existing management tools and notification systems, allowing dependencies of processes and systems to be represented.
In the future, business users receive consistent process information and process monitoring in realtime (business activity monitoring across cloud processes). All available processes are executed in process portals and their recyclability is ensured. Business departments request and use system resources independently. IT continues to have ownership of the IT and is responsible for its management. The usage costs are presented in a transparent manner to the business department based on the process.
Companies that are planning to introduce cloud-based services can establish the basis for this through a SOA architecture. As service contracts are formalized, the foundation is laid for SOA and cloud governance. The SOA integration platform plays a key role in integrating the existing application into cloud services and between clouds. Canonical data models combined with ontology and semantics establish the basis for linking data and processes across systems and clouds in the future.
The assets of this integration platform and the cloud solution are managed dynamically, although a multi-tenanacy capability is required to secure the data. A distinction is made between data access and data management. The security of the processes must be assured across all systems and clouds and implemented throughout the entire lifecycle. Business-critical systems require a highly available, fail-safe, low latency, and scalable platform. Last but not least, upcoming problems are detected and remedied in advance. In the event of any damage, the system can carry out repairs autonomously.
A quote from Paul Fremantle summarizes the motivation for SOA and cloud-based systems: "Cloud-based systems must be built on SOA and modern Enterprise Architecture principles if they are to be effective."
Why is SOA integration and the concept of cloud service brokers key for cloud computing? To answer this question, let's quickly visit IT's history. IT started with custom-built solutions. To start a proprietary hardware system like the Zuse Z10, the operator had to load the proprietary software, including the operating system, on punch cards. In the automotive industry, mass production made cars widely available and the same occurred in the IT industry. Mass production and standardization first separated hardware from software, and continued to create standard layers like operating systems, databases, and middleware.
With service-oriented architecture, components were broken down into services and became re-usable and integrated across multiple platforms. This approach is similar to the platform approach in the automotive industry, where several models share the same components such as engines. Cloud computing is changing the IT paradigm. IT systems are utilized by several users or companies. In our automotive industry example, users no longer buy their own vehicle, but use car-sharing services. The car-sharing company brokers the cars between the different drivers. Similarly in IT, a cloud service broker mediates, integrates, or brokers between different clouds. Existing legacy IT systems that need to be aggregated with new cloud-based solutions or different cloud solutions that need to be intermediated are resolved by the use of a cloud service broker.
Cloud computing can change the IT industry and how IT is used, similar to how oil is being replaced in the automotive industry. Electric cars are becoming more mature and adapted even as we use gas-based cars in the meantime. Where IT is concerned, we will run legacy mainframe solutions on-premise for a long time, while the latest solutions continue to make use of more cloud technologies and SOA technologies becomes the bridge to the cloud.
The opinions expressed in this article are those of the authors and not necessarily those of Oracle.