Integration Project Methodology
Issue and Task Tracking
EnterpriseWorx uses a task tracking system to manage all project related tasks and communication. This ensures that all tasks are tracked within a project and the status of tasks can be seen at all times.
Based on the nature of the project, a couple of software project management methodologies may be employed to manage the project:
In cases where the project requirements are well documented and known up front, a waterfall method may be employed to manage the project.
If the requirements are not well known up front or are likely to change over the course of the project, an agile approach to project management will be used. This will take on the form of a scrum project where the project will be broken down into controlled sprints with progress being evaluated and tracked after each sprint. This is the preferred method used by EWX whenever possible.
Adopt The Client’s Method
Where EnterpriseWorx resources are being employed within a larger project, EnterpriseWorx resources will fit into the client’s SDLC.
Identify Integration Requirements
The integration requirements of the enterprise are identified by meeting with business users, functional analysts and/or system architects. Ideally system integration should be set up as a top level project with the view of creating an enterprise service bus capable of being re-used across the system landscape to provide the greatest ROI.
If the integration requirements are initiated as part of a particular project due to budget constraints etc. the implemented solution would be designed to allow maximum
future re-use and expansion opportunities in creating an ESB.
Analyse Enterprise Applications and Integration APIs
Once the integration requirements are established, an analysis of the application landscape is done to identify the integration APIs and other integration options provided by each application. Integration options provided may include SOAP web services, RESTful APIs, flat file interfaces, Enterprise JavaBeans, Enterprise messaging etc. If no integration options are provided for an application, the feasibility of implementing an integration point for the application will be explored.
Analyse Application Data Structures
A data modelling exercise will be done on each application to identify the data stored in each application in order to identify the source of business information needed by other applications.
Required high level business services are identified and documented that will achieve the identified integration requirements.
Once services have been identified, these will be modelled using the data model produced during the data structure analysis phase.
It is recommended to adopt a canonical data model where possible for the integration framework to allow the most re-use of services and to provide a standardised integration model across all underlying systems. This will also lessen the amount of data mapping between different services if a consistent data model is used wherever possible.
Analysis will be done and documented at this stage to identify the target system(s) that will be needed to fulfil the service interface and any data mapping that will need to be done between the integration data model and the target system’s integration API.
Identify or Implement an Integration Platform
If there is an integration platform in place in the enterprise this will be utilised and the relevant standards implemented by the enterprise will be adhered to in adding the needed services to the platform.
In the case where no integration platform is in place, a study will be done to identify a suitable platform such as an ESB that will fit within the current landscape based on the current skill set available (this may be .NET or a Java platform). The current recommended platforms / frameworks are JBoss ESB, Mule ESB and Spring Integration.
In simple cases and where there are stringent performance requirements a point to point integration may be more suitable for certain system integrations.
Implement Necessary Integration Points
Where it has been identified that there are no current integration APIs for a particular system and where possible, custom development will be done in order to expose the functionality of a system for consumption by other applications.
Custom batch offline integration scripts may also be implemented based on the particular integration requirements.