Integration is all about getting data to where it needs to be — creating a copy of a specific set of information from one location to another — and then keeping those two copies in sync.
In software delivery tools, the data of interest exists as objects termed “artifacts”, which are work items like features, stories, tasks, test cases, defects and requirements. They are stored in the tools where the work gets done, like requirements tools, Agile planning tools and testing tools.
Crucially, any integration that flows artifacts between tools requires “field mapping”. Field mapping translates the source data to the correct corresponding fields and values in the target destination, which can be slightly different.
Here’s an example of why field mapping is necessary when synchronizing a Defect artifact in tool A with a Bug artifact in tool B:
Field mapping is necessary work to ensure the fields and values all line up and make sense. But it can also be tedious and error-prone work, especially if you have to do it over and over. Ideally, you should only have to do it once per artifact type. But only with Tasktop’s model-based integration is that the case.
But here enters a further complication: Many disciplines and their supporting tools encourage the creation of multiple “versions” of the same artifact type (read on to learn why). Does that necessarily inflate the number of times you have to configure field mapping?
Tasktop’s solution to eliminate integration toil
Every tool has its own architecture and quirks. It has its own way of classifying, organizing and storing information.
As organizations figure out the best way to leverage the tool’s default and custom artifact types to suit their business processes, nomenclature or compliance requirements, they often decide to utilize slightly different versions of the same artifact type.
Take the Requirement artifact type. Often you’ll see many “Requirement” artifact types: Business Requirements, Usability Requirements, Technical Requirements, Accessibility Requirements, Privacy Requirements and Security Requirements.
Another example: The “Custom Ticket” type, where you’ll have versions to support different requests, such as IT Help, VM Request, Hardware Request and Refund Request.
At Tasktop, we call these “affinity artifacts”, as they resemble each other very closely. They share the same schema and their fields are virtually identical. We’ve seen enterprise implementations with more than 150 affinity artifacts.
So, going back to the question: how does all this impact your field mapping effort when it’s time to set up an integration? Do you have to configure the field mapping for each and every one of those affinity artifacts individually?
If you’re using one of the prevalent integration solutions, sadly, the answer is yes. Standard integration solutions are point-to-point, which means they require field mapping for each and every artifact type within each and every project pair.
Brace yourself for hundreds of hours of extra configuration work and lots of overhead when it comes to maintaining those mappings over time. These integrations create hundreds or thousands of hours of toil, even without affinity artifacts in the mix. Affinity artifacts just exacerbate the problem.
For Tasktop users, the answer is happily different. Affinity artifacts do not create field mapping overhead, because our solution uses model-based integration. Our customers can configure field mapping just once for all the affinity artifacts, across all the projects they want.
Så här fungerar det:
Integration configuration in Tasktop is built around Models, Collections and Integrations.
- A Model is a definition of the data package that must flow between tools, namely a fixed set of fields and possible values. As data flows between two tools, it goes through the model. You’d create one model for each archetype of data, e.g., “defect”, “story”, “requirement” and “ticket” models.
- A Collection is a group of projects and artifact types within them that you want to map to a model. So you could create a Collection of 50 projects, select within them all the bugs, defects and security issues you’d want to synchronize — and map them once to the “defect” model. You can select all your affinity artifacts here too!
- En Integration is the rule-based synchronization of two Collections, one in the Source tool and one in the Target tool.
The benefits of models don’t stop there. As your solutions and portfolios grow, you save hundreds or thousands more hours. It takes just a few clicks to add additional projects and/or artifact types to a Collection. And any inevitable modification to field mapping necessary due to field changes, value changes or workflow updates (to name a few), can easily be configured just once on the model and applied to all the artifacts in the Collection.
And one more plus: Unlike templates (which merely provide a pre-populated shortcut for point-to-point mapping), models completely isolate relationships between your tools and can be reused in multiple integrations.
To help organizations get started, Planview Hub comes with several out-of-the-box models to help you get started quickly. We’ve curated them from hundreds of real-life implementations to create the gold standard of what flows in different integration patterns to set you up for success.
Related resources for learning more:
- Whitepaper: Why models are the only way to scale software delivery toolchain integration
- Infographic: Model based integration
- eBook: Integration Patterns: Architecting your value stream for speed and quality
- eBook: Which Integration Solution is Right for you?
