In today's connected world we have stopped doing business within the concrete boundaries, instead businesses collaborate and share towards focused growth and collaborative sourcing. Data interfaces have become the key towards successful collaboration. Methodology used towards defining these interfaces makes it usable...
|Analyse requirements||Analyse requirements and develop use case models and analysis models|
|Prepare Interface subsystem Use case Specifications||
Prepare Use cases with system as the actor to define the system-to-system interface at business level describing the information to be exchanged in the business context.
One of the most important aspects of the use cases is to define actions the system will take in case of occurrence of various errors. These are defined as part of the Exception Flows within the use case. For some of the exception flows, a concept of compensating transaction might need to be used to nullify the effect of previously executed transaction on the target systems. These compensating transactions should be defined as separate use cases.
The use cases are directly derived from the requirements. There should be direct traceability from the requirements to the use cases.
The use cases prepared needs to be completed and signed-off by the respective entities within the Client Organization.
|Develop build/buy/ reuse strategy||
Determine whether the requirements are to be implemented using COTS products, or by reuse of existing components (canonical data structure previously prepared for other interfaces), or through new development.
For some requirements, components may already exist and can be used as is, and for other requirements, existing components need to be extended (revised according to needs), and other requirements will need creation of new (custom) integration components.
Evaluate each component both individually and in terms of how it relates to other components in the overall interface.
|Revise iteration plan||
Review and revise the functionality to be implemented in successive iterations.
One of the key output of the Plan is the interface touch dates with the target systems. This drives various connectivity establishment activities and testing dates with the respective target systems. The INTELLECT-APPS project manager typically coordinates these dates with the target systems operations/maintenance/development teams.
|Define training requirements||Define the operating environment and create testing strategy and plan. This needs sign-off from Client Determine the acceptance testing process and logistics and develop test plan|
|Revise scope statement||Revise the scope statement developed during the Plan phase|
|Define testing strategy and plan||
Define the operating environment and create testing strategy and plan. This needs sign-off from Client
Determine the acceptance testing process and logistics and develop test plan
|Review and approve system requirements||Review and approve the use case models, analysis models, and system requirements document|
|Prepare Build plan||
The build plan documents the dates when formal builds will be made and formally tested and what all functionality will be included in the specific builds.
The formal build plans provide a very good sense of progress to both the client as well as to the development team. Usually the first builds are carried out to vet out the build and configuration management processes.
|Prepare Interface subsystem architecture document||
This document provides a high-level view of the architecture of the interface subsystem and how it fits into the overall system architecture.
This document also describes the handshake from the overall system architecture components (e.g., user facing J2EE subsystem sending messages to the interface subsystem through JMS queues, database tables, memory structures etc.).
Many times some common framework items are also defined which can be leveraged by all the interfaces. For example, a common data structure for holding and routing error information can be put in place for all the interfaces. The error messages can be routed to single console (and as required to other offsite data sinks) where it can be operated.
One of the key deliverable from this activity will be a Development Standards and Guide. This document contains various naming conventions, directory structures and processes (build, promote, version management etc.) for development.
Usually this document is prepared once and followed for multiple projects. This document should be tweaked to take into considerations the special needs of specific projects.
|Execute Proof of concept||
Many a times the project may need to undertake an implementation which may not have been done before. To eliminate risks arising from such items, it is advisable to conduct a proof of concept.
Objectives of the proof of concepts should be clearly defined before starting to implement the one. Also, the proof of concept should be constructed in such a way that the components developed during the proof of concepts can be reused.
The outcome of the proof of concept is documented and measured against the objectives set prior to starting. The architecture and design is adjusted as required to meet the system requirements.
|Physical Interface Specifications||
The Physical Interface Specifications define the connectivity (physical connections, transport protocol etc.) with the target system. It also describes the enveloping standards, handling and interpretation of some of the key data elements and any related sequencing of the data elements.
Mainly this part of the specifications deals with the non-business data being exchanged between the two systems.
If any packaged adapters are being used, the adapter runtime parameter descriptions should be provided here.
|Data Structures, Mapping, Transformation and Usage Guide||
This is the most important aspect of the interface specifications. It details various business data elements being exchanged, their structure and their meaning in the overall system context.
This part of the specifications also describe the source data and it’s structure, target data and it’s structure and any mapping/transformation etc. which may need to be carried out for successful interface implementation.
|Prepare Common Canonical Data Structure||
This activity and corresponding deliverable and construction activities are optional for smaller projects involving one off interfaces. However, the team needs to analyse the existing canonical data structures prepared as part of other project implementation in the line of business applications.
Often known as Global Objects or Business Objects or simply Domain Objects, these data structures are generally super data structure capable of holding the business information. The main purpose of preparing such Common Canonical Data Structure is to promote reuse within the integration space for line of business applications and many times across enterprise applications.
Classic example of such a data structure is a Customer. Within an enterprise quite a lot of applications use a notion of a Customer and may have different sets of attribute for a type of Customer. However, almost all the applications will have some common set of attributes. When these applications need to send Customer data to each other, instead of creating point-to-point transformation between those two applications today and then in future adding many more such one-off transformations, it is recommended to transform to one common structure within the integration engine. The integration engine then transforms the common structure to the target data structures as required.
Usually this technique is much more effective when applied for a collection of interfaces for a set of business applications instead of one off interfaces.
These structures are typically designed using UML and UML tools. Many times the integration engines provide tools to manage such definitions. There are third party tools, which have come up to manage the definition using metadata.
In absence of such tools, Excel or Access also serves as very effective tools for this purpose.
|Develop data model||
Develop logical and physical data models.
This is mainly done for the supporting requirements (audit trail, management, temporary storage etc.)
|Prepare Detailed design specifications by interface||
The next step is to create detailed design specifications. All the deliverables prepared so far are used as input. Various integration level design patterns are applied depending on the scenarios. Various error handling schemes are put in place to handle and route the errors to right destination.
Distinction is usually made if the error occurred is for the message or is it occurring for all the messages. Based on the nature of the error, the system is instructed to act accordingly (either drop the message in some error queue and continue processing or just leave the messages back into the queue and shut itself down after notifying the operations etc.).
The design flows are prepared for each flow within the use case document. The flows are depicted using Visio and if required Word documentation is provided for further details.
|Prepare Test cases||
This activity typically is undertaken immediately after the use cases are written and approved by the business team.
Usually the test cases are mapped to use cases and are formally traced.
|Verify standards compliance||Confirm that the system design conforms to Client’s enterprise architecture standards|
|Revise project plan||Revise project plan based on information gathered during this phase|
|Revise deployment plan||Revise deployment plan based on information gathered during this phase|
|Approve system design||Review and approve the system design deliverables|
|Conduct Elaboration phase tollgate review||Confirm that all Elaboration phase tasks are completed, and review the deliverables|