Architect the Solution
When starting a new integration project, first identify the business problems for which you need to provide solutions. In conforming to the Agile Methodology, create the requirements document but only invest as much time for the team to understand the objectives and the required outcomes. Make sure to update this requirements document as you progress.
Business Requirements
Identify the business problems to solve and state it in a non-technical language. For example:
Objective: We need to begin using new accounting application in Q1 of the next fiscal year
Capture the business processes that the new system will perform as a workflow diagram. Include human interactions and interactions with other applications.
The ‘orders-to-cash’ workflow is described as:
• Salesperson updates an opportunity in CRM to 'closed-won'
• CRM automatically generates a Purchase Order and sends to customer
• Customer signs Purchase Order and replies
• CRM sends event message to Finance
• Finance automatically generates Invoice and sends to customer
• Customer replies with payment
Document the requirements that will determine success from a business perspective and not from a technological perspective. For example:
Success criteria: We need the new application to:
• Contain seven years of historical data
• Balance and match the last three years of historical data with the old application
• Balance and match the remaining current fiscal year data in parallel with the old application
The Business Requirements Document is used to explain and get buy-in from business stakeholders and provide context to the implementation team for the technical requirements.
Technical Requirements
After documenting the business requirements, compile the mapping documents that bridge the gap from architecture to design. Essentially, this means showing the direction of data and the link between the required entities and their fields on each side of the workflow.
You must document to the extent practical; rules for data governance, hierarchical relationships within each system, master schema taxonomy, access for design and runtime users, and the promotion life cycle from development to test and to production.
The Technical Requirements document will be constantly updated as unknown requirements are discovered. The next sections provide best-practices and examples for managing these concepts effectively using Actian DataConnect.
Last modified date: 10/22/2024