A turning point
Software vendors in EI-BPM, business intelligence, data integration (ETL, data quality), and BRMS are facing a considerable industry shift that could induce a downfall: their offerings can no longer guarantee sufficient growth in a market where XML standards smooth out the specifics and projects are increasing in dimension and scope. It is no longer enough to supply technologies improving existing assets, but rather solutions designed to adaptively restructure the entire system. The change is significant: it's a new way of conceiving technical as well as business aspects. Software providers should support adaptative solutions, but their current strategy is aimed at promoting solutions supposed to deliver significant improvements without modifications on existing systems. Customers are no longer buying it, and understand that flexibility as inherent quality of software is gaining a foothold. Thus, the challenge is not to modernise the existing, but rather to replace it altogether by agile SOA, in a progressive and sustainable manner.
------------------------
The industry mastodons ISV have such enormous install bases that they have little interest in quickly responding to the need to restructure. Instead, they prefer to put the brakes on the market, and linger while smaller dimensional infrastructure software vendors reduce in market value, and then pounce at the right time to acquire them at attractive prices. To change their hand, software vendors must reposition their offerings to best respond to IT system restructuring needs. This imposes three changes: responding concretely to the agility needs of Information Systems; clarifying SOA governance; and supporting public enterprise methods.
Achieving agility
The information system agility requires simultaneous action on three axes of reference data and parameters, rules and processes. It is the principle of Agility Chain Management System (ACMS): "no process without rules and no rules without reference data and parameter." The chain is only as strong as its weakest link”.
Master Data Management (MDM). Streamline management of reference data and parameters, allow implementation of service configuration models to contextualize execution.
Business Rules Management System (BRMS). Rules rely on reference data and parameters. Pre and post-conditions of organizational services are located in the rules management system.
Business Process Management (BPM). Processes use the rules to drive the different stages of activities. Orchestrated services are contextualized by the MDM and the BRMS.
The ACMS connects BPM with the BRMS and the MDM. The order of implementation of each component is the converse to operation of the chain. First, reference data and parameters must be rationalized then beneficial rules should be added. It is impossible to create flexible rules if they manipulate poor quality and scattered reference data and parameters, without knowing their quality. Once the connection has been made between MDM and BRMS, one can deploy agility using processes which benefit from rules for managing the sequences between stages of activities.
ACMS is at the disposal of business applications, but should also support SOA software suite configuration and administration. It is not acceptable to manage the ESB configuration transcodification tables, data mapping programs, routing and security, data integration tool filters… via technical data entry interfaces -- sometimes directly in XML, Java or text files -- without rights and version management. ACMS is used to manage the SOA platform and business applications with a rights management system that combine intervening business and technical profiles (development, production) with version and deployment management.
Clarifying SOA Governance
SOA governance has become the latest buzzword, but it can be confusing to software vendors. It seems to rediscover the need for a repository that describes the architecture (component, service, orchestration, utilized resources, etc.). Initially situated in the operating area (run time) with the registry (UDDI), the offers have their eyes on the conceptual area (design time) with the repository. For some, this design time stage is limited to verifying the WSDL conformity with the WS-I basic profile! What does this have to do with design? Everybody has to add a lot of meta-data (a term that's rarely defined) in order to describe the service compositions, while these are already described in the UML models. The software providers confuse "Cosmetic SOA" (adding services to existing systems such as a revamping) with restructuring the existing system (Overhaul SOA). In each case, governance is very different:
- "Cosmetic SOA" governance is not strategic. In essence, service agility depends on the quality of the patrimony and it should be said that there isn't much to govern. Because we don't conceive of a new system, the UML modeling is limited and meta-data very limited, except those which are already recognized in the ESB-type intermediation layers and some SLA in the exposed services.
- "Overhaul SOA" governance supports modeling of the future system and should integrate UML CASE. Unfortunately, this is not the case if you hear how software vendors describe SOA governance.
Indeed, most meta-data comes from UML modeling. The remainder comes essentially from the SLA concerns. Thus, the repository described by SOA software vendors (design time governance) is not strategic because knowledge of the architecture is already fixed upstream in the UML modeling, then recaptured in the IDE. The repository would be usefull if there were perfect integration in the UML CASE and in the IDE but this is not possible: a new generation of CASE and IDE would be created! The only possible scenario would be the creation of complete connectors between all tools, each with their own repository. They also would need to be synchronized. This idea of "meta repository" has never worked and will bring us once again to an impasse. Better yet, the repository will be minimally used to handle technical data of interest to the technicians for impact studies that complement those already available in the CASE and IDE, for example for version configuration. By the way, the repository allows you to prepare the registry feeds. This element, run time governance, contains the service contracts enforce in production (the SLA). Combined with a production management tool, such as WS-Distributed Management, the registry is required. Nevertheless, its usage perimeter is weak, including in "Redevelopment SOA", because the services under the SLA constraints are coarse-grained, when exposed to the consumers. The others, which are greater in number, will not be placed in the registry. It's neither possible nor interesting to manage thousands of SLAs at such subtle levels.
The challenge of SOA governance is not the meta-data which remains a modeling concerns and interface with IDE. Real governance refers to functional and technical data management that will react to the internal behavior of each service : functional parameters, reference table filtering, multilingualism, technical infrastructure parameters, etc. This configuration time governance – oriented toward reference data and parameters management – leads us to the MDM (Master Data Management) component in the ACMS agility chain. It should be in the hands of the business team because they are affected by the services' functional configuration. The technicians (development and production) also use MDM, in this case, to value technical data, particularly configurations of the SOA platform, such as ESB, mapping and transcodification tables.
The services' execution contexts are then managed by MDM. These contexts do not only concern the services directly exposed to the user (coarse grained), and those present in the registry (SLA), but also all services (meduim and fine grained) that require execution variants be taken into consideration.
The figure above illustrates the real SOA governance chain. It also shows the breadth of services that can be found in the different governance components: UML CASE, IDE, repository, ACMS and registry.
Supporting public enterprise methods
ACMS and real SOA governance make up the foundation of the SOA platform that underpins redevelopment information system. By the way, an enterprise method should supply the guidelines for the design of the future information systems. This method ensures that the modeling requirements don't confuse the business issues with the organization issues (separation of concerns), defines the operational guidelines to find the right services based on requirement (SOA logical architecture), takes into consideration the MDA for UML model transformation and generation of code, etc. This enterprise method has no value if it is not shared and free of utilization.
All proprietary methods prove a break for the launch of redevelopment projects. The software vendors should support public enterprise methods by training their teams in a way that best serves their clients. Unfortunately, either vendors propose nothing for the methodological aspect, or they invent proprietary "methods" that have no chance of being retained by companies for redevelopment projects. We can’t recreate information systems with partial methods that rely on a single software vendor.
Examples of public methods are TOGAF (open Group) and Praxeme.
Summary
In order to survive, SOA software vendors must quickly design offerings to address redevelopment information systems projects. Enterprises understand that the existing information system can’t evolve with successives layers, and that it is better to face redevelopment information systems head-on before IT specialists – often the creators of these systems – leave for retirement
Software companies should allow their business approach to evolve and tackle progressive information systems redevelopment. For this to happen, they should also take ACMS into consideration, fully understand real SOA governance and support public enterprise methods.