Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Applications started to use some external services as SaaS in-cloud. These services are accessible via API.

Also, external apps (e.g. mobile apps) started to use some internal services.

As data started to cross enterprise’s boundaries (i.e. between in-house and in-cloud) the security-related risks are increasing.

As inter-components communication (i.e. among applications, apps, services, legacy, COTS, etc.) become more complex (various styles, formats, protocols, etc.) the middleware become necessary to manage connectivity between service providers and service consumers.

Note: A service many be provider and consumer at the same time.

Service provider life-cycle: deploy version 1, measure version 1, deploy version 2, measure version 2, decommission version 1, archive version 1 and all realted information, …

Legacy applications and COTS started to expose their functionality as usual services.

Typically applications invoke many other services to get work done.

To simplify applications new kind of services has emerged - composite services. The latter is a service which invokes several other services with some minimum programming (low-code) between invocations. Typical scenario is the data aggregation from several existing data repositories. Another scenario is combining several operations (e.g. data or document transformation – like PDF converter) together. Usually, composite services were made with various technologies and demonstrated various quality.

Also, communication between services may be classified as flow of data (typically data exchange) flow of control (sending a command to execute something) an explicit mixture of previous two items an implicit mixture (i.e. unknown)

Such a classification is helpful when data protection is considered (e.g. exchange of some sensitive data over the Internet).

BPM-suite creates a process-centric solution as a set of services: each process-instance is a service each automated activity is a service (usually a composite one) human activity is a service (often an atomic but composite is possible as well) BPM-suite itself is a service with API and GUI interfaces

Important that BPM-suite starts many process-instances on-demand to react on particular business events. Each process-instance is a composite service. Activities as atomic or composite services which are initiated in accordance with the execution of a particular process-instance.

Many process-instances and activities must be executed at the same time. BPM-suite makes easy to co-exist them at the run-time by dynamically deploy and un-deploy services.

As process-instance and activities are deployed in run-time then they evolve faster than being deployed at design-time. Several process-instances can be instantiated from different versions of the same process-template.

Process-instance-as-a-service and automated-activity-as-a-service become fully capable to replace some (primarily ad-hoc) composite services.

Advantages: explicit implementation of composite services explicit error-recovery for invocation of other (atomic and composite) services thus enabling distributed transactions higher agility because services are deployed on demand (run-time deployment vs design-time deployment) in case of performance problem (individual invocation is slow) some explicit composite services can be re-refactored at the same time scaling-out (horizontally) is easy

Sequential eliminating of ad-hoc composite services reduce the TCO and improve agility. Good governance is necessary.

A lot of services are defined as parameterisation of BPM-suite parameterisation of BRE automation scripts (low-code)

Thus implementation of enterprise’s unique processes can be done without customisation of BPM-suite products (usually COTS even the FOSS origin).

Because there are no needs to customise BPM-suite component, it can be used as PaaS in-cloud.

Considering that some flows-of-data should be still resided in-house, a federated deployment would be wise – flows-of-control are executed in PaaS and flows-of-data over the Internet are well understood and cared.

Two parts of the enterprise computing environment – in-house and in-cloud – must co-exist seamlessly.

Also some atomic services may be moved to SOA+ESB+API component which is deployed in PaaS.

Step-by-step, the communications between services may be refactored to reduce the load on the in-house part.

At one moment only legacy and COTS may be needed to reside in-house.

They should be transformed to become more cloud-friendly: the customisation of COTS must be eliminated to allow COTS to be available as PaaS and SaaS the legacy applications must be modernised

For both cases, considering of enterprise-as-a-system-of-processes (including end-to-end processes) is the way to go because COTS and legacy functionality are parts of process-centric solutions.

Finally, off-the-shelf functionality will be provided as SaaS in-cloud and, in some cases, PaaS in-cloud.