Asidua

The ADI Concept

ADI is about leveraging the services of enterprise applications, joining them to build seamless (and automated) end-to-end processes. All enterprises have such processes. Some are well-documented, some already exist in enterprise systems, some may even exist as workflow. However most generally exist as islands, tied to existing people, products and departments, and the systems that support these. In order to make these processes truly end-to-end across an organisation, there is need to integrate these applications and the data they hold. Click here to view how business processes can be integrated with ADI

 

ADI is about making end-to-end processes work, especially where scale and complexity is an issue. For enterprises with a greater number of enterprise systems and business processes, the use of point- to- point paradigms rapidly becomes a near impossible scenario to manage. ADI introduces an approach which is tailored to scale from simple to large and complex scenarios.

 

ADI is about using vendor messaging platforms. One of the main elements of ADI is to deploy a message broker to provide a central information bus used by all applications. Such platforms are typically available from middleware vendors. Unfortunately, none of these platforms work out-of- the-box, and must be extensively customised to support the business processes required.

 

ADI is about making integration work on real enterprise scenarios. At Asidua we are well recognised experts in vendor platform customisation. Over many years of delivering such solutions for our clients, we have come to understand the major obstacles that will be encountered and how best to overcome these. Typically, we recommend the following questions be addressed when building any solution:

• Is the process in question optimised for automation?
• Can the automated solution be effectively managed - especially if it fails?
• Can the automated process be tested fully?
• Is the resultant solution flexible - can it be readily extended

Only by answering these questions correctly, do we feel that an integration solution is really truly effective. To do this, we offer our clients a portfolio of services known as Application and Data Integration (ADI).

 

ADI is a well-defined layer of capability that allows us to meet enterprise needs. ADI allows us to insert a layer of capability between the desired business processes of a client, and the capabilities of a vendor platform supplied by one of our technology partners. We call this layer the ADI Data Flow layer. The ADI Data Flow layer is built using our own methodologies and tools, and guarantees delivery of end-to-end processes that work.

 

ADI is about having a well defined portfolio of tools and methodologies to deliver the ADI capability. Fundamentally, ADI is based on four key concepts:

1. Architect for change: by employing an ADI Data Flow layer [see diagram] we can decompose and model a clients end-to-end business processes using decoupled and reusable patterns chosen from a pre-existing ADI Pattern Library (view our ADI tools); the use of such inter-changeable patterns facilitates change at any future point.
2. Optimise for automation: each of these ADI patterns models an operation commonly undertaken during an automated business process and is itself realised by a pre-canned, vendor-specific, executable orchestration written in a platform-oriented language such as BPEL, JPD or XLANG.
3. Automate test: having an end-to-end ADI Data Flow Layer [see diagram] allows us to complete an standalone test of an ADI solution, using our own dedicated test engines to simulate enterprise applications; this can be highly automated, considerably reducing the level of downstream testing required once the solution is deployed.
4. “Build in” management: by adding audit and tracking capabilities to a vendor platform we are able to provide a view of active business processes in the context of the ADI Flow Layer. This view can be interpreted by our ADI Console (view our ADI tools) which allows a client to monitor and control automated business processes in terms of their own process definitions, rather than from the perspective of the vendor platform.