Integration requirements are critical for any Project’s success when Business Processes flow across multiple systems. As a Business Analyst it’s our responsibility to understand the end-to-end Business and Systems Process flow and document the hand off as part of the requirements gatherings process. A systematic approach to gather the requirements for integration between systems will ensure that there is a smooth interaction between the systems and hence the Business Process flow. The below Framework on Integration Requirements Analysis provides a systematic approach to document requirements for an Integration Project.
Data Mapping
Data Mapping is the systematic process of analyzing and documenting the various attributes of a system that map to the attributes of the other integrating system. The output of this exercise is a Data Mapping document which would serve as a guiding document for the development team.
It is important to understand the mandatory attributes of a system and make sure that they are mapped appropriately in order to avoid any integration failures. For example, if the Order Id is required to send data to a Finance system, we need to make sure that the Order Id field is marked as mandatory and is mapped to the respective field form the CRM system.
It is critical to understand the definition of data elements in each of the system involved in integration in order to map the appropriate attributes to each other. A single error in mapping elements across the systems can result in chaos among the Business users. For example, if the Billing start date in Finance system needs to be mapped to the Shipment Delivery Date in the CRM system and if the dates are wrongly mapped resulting in Billing start Date being mapped to Shipment Start Date, this might result in wrong billing to the Customer. Hence it is important for a Business Analyst to document the Data Mapping Document for any Integration Project.
In some cases, a conversion to respective format/value might be required at the destination system instead of directly mapping to the other attribute. We need to make sure that the appropriate conversion/ formula is documented accordingly.
Data Model
Every system has a systematic way of organizing data elements and establishing a relation between the same, which, is its Data Model. While integrating 2 different systems, the integrated systems’ Data models must be connected.
It is important to understand if the data in between the systems has a one-one or one-many or many-many relationship. Very often a single record from one system can be linked to multiple records in another system and vice versa.
For example, a single Invoice can have multiple products (ie.one to many) and if this is not documented, the Invoice amount might appear for each Product in the end Report which would give inaccurate (inflated) overall Invoice amount. Hence it is important to be specific about the Data Model relationship between the systems while documenting the requirements.
Data Source Connector (Unique Key)
In order to link the data between the systems, it is important to have a linking data element in between the systems. For Example, in order to transfer an Employee’s information from one system to another, the employee’s Employee ID could be used as a connecting attribute.
In few other, it might be essential to have more than 1 unique element, so that multiple elements can be combined to form a unique identifier. For example, to update a Product’s details on an Order it might no be sufficient to just have the Order number as a unique key. To identify each Product under and Order, the systems would need a combination of Order and Product numbers to transfer information accurately.
As a Business Analyst, we need to be cautious to determine if a single element would be sufficient to be used as a unique key or if we need to use a combination of elements to form a unique key.
Frequency of Integration
It is critical to identify the frequency of information transfer between systems. In general, the frequency would be either Real time or Batch process. There must be a balance between information availability on time vs technology resources consumed for the same. In general, real time integrations would consume more technology resources and have greater costs as compared to batch integrations.
As a Business Analyst, we need to identify the required frequency of information transfer between the systems based on the criticality of the business need. There would be Use cases where real time integration would be the only option. For Example, an integration between a Patient’s health monitoring device and Control systems needs to be real time. Whereas, there would be use cases where a decision must be made based on cost vs benefits to choose between real time vs batch integrations. For Example, some businesses need real time integration between Shipment and Billing systems whereas some businesses would be ok with batch processes.
Data Volume
It is important to identify the data volume, that flows across the systems. This generally helps the development team to identify the right technical architecture and this is one of the first few questions we get from development team when they get an integration requirement.
If the integration is replacing a manual integration, an ideal approach would be to study the existing volume of data transfer to estimate the Data load. If the integrations is a new connection between the systems, a Business Analyst might need to analyze the data manipulations performed at each system and the amount of data that needs to flow to other systems.
Security
It is important to maintain the Data Integrity and visibility depending on the User’s Role in the Organization. In most of the cases, the Security setup in one system doesn’t flow to other systems. Hence it is important to document the Security/visibility of data across systems.
Error Handling
It is worthwhile to document if someone needs to be notified when an integration fails. In general, the notification would be sent to the System Admins or a Data Management Admin
While every Integration Project might be unique in terms of requirements, following the above defined framework would ensure that majority of the requirements are captured for a successful rollout of the Project.
Author: Ashish Adike, Business Analyst
Ashish Adike is a seasoned Business Analyst with around 9 years of experience in Business Process Analysis, Requirements gathering, Consulting, Solutioning and Project Management. Experienced in working with multiple Business functions – Sales, Marketing, Finance, Operations. Strong research professional with a PGDM focused in Sales and Marketing from Indian Institute of Management, Indore. Awarded team player with excellent learning and adaptability skills.