Supply Chain Integration

Most non-trivial applications include components developed by third parties. Often, an organization will work with a third party to either develop components on contract, or will outsource some work (such as testing) to a third party service provider. Unfortunately, these organizations don't share tools. So, if an organization provides requirements to a contractor, they’re often exported from a requirement management tool and then imported into whatever tool the contractor uses to manage their work. Similarly, when testing is performed by a third party, their systems for understanding the original requirements and managing defects are separate from the organization that’s contracted the work out.

This discontinuity of information creates unnecessary friction, until the organizations deploy this integration pattern. 

Of course, this integration pattern is actually a specialization of other patterns we see. The only difference is that the integration of systems spans company boundaries, not simply organizational boundaries. For example, a company that’s engaged with an external provider may have a centralized test management system (such as HPE QC) and the external provider either has the same system, or uses a completely different system to track their defects. When the systems of both organizations are integrated, both organizations have access to the state of the project in near real time, rather than engaging a time-consuming and error-prone process of manual reporting.

Artifacts typically synchronized:

  • Defect
  • Story/Requirement
  • Ticket/Problem/Incident/Feature Request
  • Epic, User Story, Task, Sub-task
  • Test Case