Ideally, a cloud-optimised solution is a set of interrelated and interconnected services which are good cloud citizens (or highly cloudable).
This blogpost describes a pattern Cloud-Aware Processes and Services (CAPS) to deliver cloud-friendly solutions instead of monolithic applications. The importance of this pattern is demonstrated by the recent post “All cloud roads lead to applications” http://news.cnet.com/8301-19413_3-20075526-240/all-cloud-roads-lead-to-applications/. This blogpost is based on the materials from my book http://www.improving-BPM-systems.com/book.
BPM helps to deliver cloud-friendly distributed systems
Enterprise BPM systems/solutions (see http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html) architected with a multi-layer implementation model (see the figure below) can serve as an example of cloud-friendly distributed systems.
In this model, each layer is a set of services, each of which addresses particular concerns. The services are cloudable.
The business data layer comprises many pieces of information – names, dates, files, etc. – which are stored in existing repositories (e.g. databases, document management systems, web portals, directories, e-mail servers, etc.). Services at this layer are stateless, contain no business logic (although they may contain some access logic) and, usually, co-locate with their underlying databases. They are highly cloudable.
The business objects layer comprises the many objects specific to a particular business, e.g. a business partner, a product, etc. This layer hides the complexity for manipulating the objects, which are actually collections of data together with any dependencies between them. Again, services at this layer are stateless, contain no business logic (although they may contain some technical transformation logic), and are implemented as simple compositions. They too are highly cloudable.
The business routines (or regulations) layer comprises the actions which must be carried out on the business objects to perform the business activities. Services at this layer are stateless and implemented as complex compositions. The latter are defined in a normal programming language (e.g. Java, Python), an interpretive language (e.g. Jython) or, even, in BPEL. A specialised environment (actually a service called a “robot”) may be needed to execute these services, but this “robot” is rather cloudable.
The business execution layer carries out the business processes. The principal service at this layer is a business process execution engine. It executes business processes which are rather explicit compositions (e.g. SAP uses a BPMN subset as a language for executable business processes – see http://improving-bpm-systems.blogspot.com/2011/06/first-impression-sap-netweaver-bpm-tool.html). Any business process execution engine is a stateful service, but each business process instance can be executed independently. Hence, this service is cloudable. Also, business processes are modelled taking into consideration the concept of idempotency (see http://improving-bpm-systems.blogspot.com/2011/07/1-relationships-between-enterprise.html).
The business monitoring layer analyses the execution of the business processes. A large amount of data (events and audit trails produced as the result of execution) is treated to extract any correlations and meaningful information. Services at this layer are both stateful and stateless, but they mainly operate in the “background” and thus are rather cloudable.
The business intelligence layer implements enterprise-wide planning, performance evaluation and control actions applied to the business processes. Services at this layer are cloudable.
A tip to remember the layers is the following: Data, Objects, Routines, Execution, Monitoring, Intelligence – DO-RE-MI.
The multi-layer implementation model and some technologies
The figure below shows the relation of the multi-layer implementation model to some other technologies. Normally, some services are accessible from a portal or workplace. They “float” in an Enterprise Service Bus (ESB). The latter is used only for service-to-service connections at the technical level. Ideally, an ESB should be based on a solid computing basis which can be provided by a grid, modern virtualisation infrastructure or cloud computing.
Extra considerations about the composition of services (or integration)
Some of the services mentioned above can be qualified as compositions of other services. In addition, interactive services from a portal or workspace are also, in general, compositions. For example, a user may invoke different services whilst staying on the same page (thanks to AJAX).
Any composition of services may manipulate business data and thus may disclose them. The following considerations may help to reduce the risks related to data disclosure:
- prefer stateless services for compositions;
- remove the business logic from stateful services (e.g. business execution shall not contain any business logic, only routing logic – follow the practical process pattern DBL, slide 22, http://www.slideshare.net/samarin/towards-executable-models-within-bpm-presentation);
- pass references, not values;
- encrypt data and keep structure in clear text;
- keep robots in the GOLD, ORANGE or GREEN zone types, and be ready to move them to the BLUE zone type (for information about zone types, see http://improving-bpm-systems.blogspot.com/2011/07/1-relationships-between-enterprise.html).
To greater agility
The multi-layer implementation model is a tool which helps an enterprise to design process-enabled solutions
- in business terms, but not in terms of IT tools,
- via the combination of services,
- in a structured way, and
- with a high level of built-in flexibility.
- Business Architecture (via BPM and executable business processes),
- Application Architecture (via SOA and the multi-layer implementation model) and
- Technical Architecture (via cloud computing).
Thanks,
AS
Posts
1 comment:
I read this and i agree with you. I am always looking out to Business process management
Post a Comment