We are going to detail the procedures allowing to extend SOA to take into account the principle of agility, a strategic objective for the alignment of IT to the needs of the rapidly adapting enterprise.

Characteristics of agility

A commonly recurring issue in information technology is the engineering of agile systems, which can adapt fast enough to rapidly changing needs. In the last 20 years many initiatives focussing on special aspects of an information system have attempted to increase agility. In particular, we have seen the object-oriented approach for reusability of information processings and workflow engines for the flexibility at (business) process-level. There has also been considerable gain in experience in the use of rule engines, with the most common appliance areas being pricing and scoring clients. Companies have begun to realize the value added of these rule systems in terms of flexibility and easily maintainable extensibility, although fields of use stay still somewhat limited. We should also mention specific developments in the area of parameter management, especially within companies needing to customize their applications with respect to different contexts (language, legislation, distribution channels, etc.). In this regard, Guy Lapassat insists on the idea of parametrization "The parametrization of information processings is used to define the values taken by certain program data as variables which depend on processing rules. The main purpose of this repository is the ability to change such a rule (and more exactly the values of its parameters) without having to alter a program's code."

Despite these approaches, one can observe very limited agility in even the most advanced existing systems.

First, companies have been working on certain aspects of agility of their systems, but never on their totality. For example, they have been concentrating on workflow, as well as the object-oriented approach, but without integrating rule engines. Such a partial effort may not suffice because agility is a chain, and it is only as strong as its weakest link. If a properly configured process in the workflow is flexible enough but the rules for its progression across different stages are not, the system will not be agile. A modification with respect to rules will implicate considerable costs with the usual claims on development time as well as the required skills for the efforts undertaken.

Second, the technologies of the time were less mature than they are now. For example, the management of parametrization did not yet have a quality market of software vendors and adequate products at its disposal. Companies had to build their own systems for parameter management with the usual constraints on maintainability and functionality. Moreover, most of these efforts within an enterprise got insulated or isolated in uncoordinated efforts spread across different projects. Nowadays, we have commercial solutions for master data management (MDM) specialized in the management of referential data and parametrization. A company now can easily equip itself with a unified solution for the management of parametrization, and this is a considerable advance.

Finally, to succeed with agility, there is need for design concepts which prepare the terrain for components like BPM or BRMS (Business Rules Management System). Mainly due to the SOA approach as well as associated managerial concepts, we have now at our disposal proven procedures to achieve agility (see entreprise method such as Praxeme).
 

Agility is within grasp

Thus, agility is within grasp if we address all aspects of an information system at the same time: referential data and parameters (MDM), rules (BRMS) and processes (BPM), while making use of the appropriate methodology of design (see Praxeme). If only one of these aspects is neglected, none of the efforts can yield any result. This is the principle of the "agility chain", and its determinant, the ACMS (Agility Chain Management System).

The figure below illustrates the order of steps in the implementation of the technical agility enablers.


Step 1 corresponds to the gathering of referential and meta-data as well as parameters into a MDM (Master Data Management). This will increase their quality as well as centralize their management and retrieval. The BRMS (Business Rules Management System) will build up on the MDM - a rule may thus adapt to executional contexts. For example, a rule may test the total of a customer's purchase against a value stored in a table. This value may be a threshold, and may depend on executional contexts such as: organization, type of purchase, country, version, etc. Finally, the agility chain is completed by the business process management, which can harness the benefits of the rule engine and parameter management. The rule engine increases the flexibility of the process across its different stages. Parameter management enables the configuration of the process' service calls, depending on executional contexts.
 


The difference between version and variant of a service

The distinction between version and variant is a prerequisite for the understanding of the path to agility-enabling. This distinction is fundamental for extended SOA. When a service is to be updated, there are 2 options to handle this modification:

  • If intervention on the underlying data is necessary, or altering its code, one creates a new version of the service and software development is inevitable. Since the piece of software has been modified, one has to plan a whole software production process which can reveal itself to be heavy.
  • If it is possible to intervene at the level of simple parametrization, of rules or chaining of services, the tools of ACMS - namely MDM, BRMS and BPM - are used without intervention in the code. This configuration points to a certain version of the software and leads to the creation of a service variant figure below). In this case, production is considerably accelerated.

It is thus necessary to manage multiple variants per version of a service. If the tools of the ACMS are sufficiently user-friendly and secure, skilled users may create their own variants without any necessity for software engineering. The software itself has not been modified, it is thus not necessary to follow a whole production cycle. Merely parameters, rules or processes have changed, and thus the delivery time of the modifications is reduced. However, this flexibility doesn't eliminate the process of testing and in particular regression testing.

Pierre Bonnet (translate in English by Jay Zawar).
If you want to put comments, join or group.