Requirements Gathering for Integration Projects

Requirements gathering is a complex process that aims to define a list of capabilities that we expect to meet, once a project is completed. Let’s explore the process of requirements gathering and how it relates to integration projects.

Simply creating a punch-list of features, capabilities, and behaviors is not enough to fully define all the integration requirements within a project.

To meet the defined expectations that you have for all of your projects requires a much deeper dive into what is truly going on, both within the organization and externally with your digital ecosystem, including trading partners, customers, and others.

The Requirements Gathering Process for an Integration Project

The requirements gathering process starts when a project is first created. In formal organizations, this begins with the approval of a project charter, after identifying a project sponsor. In smaller organizations, this can be either a tactical (reactive) or a strategic (forward-thinking) effort directed by a department head or line-of-business manager. Once the project is initiated, the project’s scope is usually defined and documented. 

In addition to the scope document, there are several input documents that are needed to properly create a requirements document. Once you’ve got the documents, you must:

1. Pull out your current system process documentation and document the current processes to use as a baseline against the proposed implementation.

2. Find all service-level agreements (SLAs) that are impacted by the systems and applications that may be affected by the proposed project.

3. Find any corporate documentation, such as lessons-learned from previous implementation projects and approved corporate policies. These are known as the “rules of engagement.”

4. Once the supporting “rules of engagement” documents are available, identify all the systems that are “touched” in the integration. This should be a subset, up to all of the systems, in your current system documentation.

5. Using a simple block diagram, draw the systems (both internal and external) and connections between systems that share data. Also, number the connections for identification and then annotate the connections with the communications methods. Inventory all the different communication methods.

Get Started on Your Integration Project Today

Understand the Data Flow

Next, it’s time to focus on the data flow. This includes all the different types of data as well as formats, such as XML, EDI, and spreadsheets. Additionally, you must be aware of how much data there is and the volume-pattern of the data.

This list can get lengthy and encompasses both B2B and A2A transactions such as:

• Inbound/outbound EDI 

• ERP/legacy interface files

• A2A intersystem data such as flat files or database-to-database movements

• Data movement, such as spreadsheets or web-form content, that is brought into or sent from the systems.

It is also critical to concentrate on the volume-pattern for each of your data integration requirements. Volume-patterns have a direct effect on throughput capabilities, which affect processor loading, disk activity, and communications throughput.

The volume-patterns help identify potential constraints in the current or proposed system. It’s unusual for businesses with even modest data volumes to receive the data spread out evenly over a 24-hour period.

It is very typical to see bursts in activity at different times during the day. For example, a company can receive 1,000 invoices a day.

At the rate of 50 per hour over a 24-hour period, this doesn’t seem to be too disconcerting. But picture a typical business day in the United States.

What if most of the POs are received near the end of the business day?

That changes the maximum system load to maybe 350 POs an hour for two hours and the remaining 300 POs are scattered across the other 22 hours of the day. 

Just asking, “How many documents per day?” is not enough to truly understand the integration requirements to process the information.

Evaluating the Business Processes

Once the data formats and flow patterns are defined, we can look at the business processes that control the flow and see how they are affected by the data volumes.

A batch interface may be visible that causes systems to block or wait until it is finished. A common example is a batch invoice generation process that takes two hours to run. Invoices cannot be sent until they are generated, so our outbound EDI invoicing process is “blocked” until the generation process is complete.

We can easily mitigate this bottleneck using database triggers to initiate generation of the EDI data when each invoice is written for a specific customer that meet your ecosystem integration requirements. That brings some alignment to the invoice generation process and allows a level of real-time processing.

An often-missed aspect when we look at integration requirements is to not look far enough either upstream or downstream from the proposed integration to identify the impact. It is important to see how the proposed integration will fit into existing processes:

• Is the integration part of a long-running process that spans departmental boundaries?

• How about company boundaries?

• What if the communications method that transports the outbound data uses a single-threaded blocking model?

As you can see, you need a genuine understanding of the business needs, performance requirements, upstream/downstream processes, and a profile of the data volumes.

***

Cleo is the global leader in ecosystem integration solutions and has the expertise and tools to help you scope all your integration project needs. Contact Cleo today for help with integration requirements examples or to get a data integration requirements template.

Discover Cleo Integration Cloud