White paper

Why models are the only way to scale

software delivery toolchain integration
 Based on an average IT practitioner team of 1500,
organizations can save up to $10 million a year in
manual overhead through integration*

INTRODUCTION
When it comes to enterprise software delivery, no single tool or product suite can support the
specialized work of all the varied teams that develop and support a product feature or service. All
these specialists who help plan, build and deliver software require their own role-specific system
to work in.

Integration, therefore, plays a critical role in tying all these tools together and making them work
like a single well-oiled machine. Information flows automatically from tool to tool, specialist to
specialist, “pushing work along” to the next step in the process.

Integration also enables organizations to aggregate data across lines of business or departments,
creating visibility for the managers and executives who need to see the big picture of how IT and
software delivery generate revenue for the business.

The benefits of integration are numerous:

Despite the well-documented benefits and criticality of integration, enterprise-level integration

continues to present big challenges for many organizations.

The main reason being that the traditional approach to integration – i.e., point-to-point
integration between two tools - cannot handle the size and complexity of the work that
enterprises are undertaking.

The average enterprise and agency needs to flow rich product lifecycle data across a
software delivery value stream that comprises:*
• 100-1000s of projects • With 30-100 fields each
• In 5-10 core tools • And 100s of possible values and states
• Housing 30-40 artifact types

* Based on Tasktop calculations.

Model-based Integration is the only way to efficiently

synchronize such large volumes of sophisticated data while
maintaining its integrity and supporting cross-tool reporting.
Point-to-point integration: the easy way to waste lots of time and money
Simply put, when we talk about integration, we’re talking about moving data between two systems of record
(or “repositories”). The data exists in these repositories as objects termed “artifacts”, which are work items
such as features, stories, test cases, defects, and requirements. Or in other words, information that specialists
need to share with each other in order to collaborate on a product’s development and support.

Crucially, any integration requires 'field mapping'. Field mapping defines the shape the artifact should take
on when it flows to a different tool, namely the mapping between fields and values in both repositories.
Before we expand on what model-based integration is and why it’s far superior to point-to-point, it helps to
understand the limitations and fragility of a single point-to-point mapping.

Setting up point-to-point mapping

The exercise of mapping a single pair of projects between two repositories requires a great deal of thought
and consideration.

Stakeholders need to decide what data to flow and under which circumstances, in a process that usually
takes significant calendar time. You’ll need to decide which fields are worth synchronizing, and then map
them to each other individually, e.g. 'Name' after maps to 'Summary', 'Description' maps to 'Details', 'Priority'
maps to 'Severity', 'Comments' maps to 'Notes', 'Resolution' maps to a Customer field, and so on.

Then, for each possible field value in one repository, you will need to determine the equivalent value in the
other repository. For example, you’ll need to define how 'Priority' values "1-5" map to 'Severity' values "high-
low". You’ll also have to decide how a specific status in one repository should affect the status of an artifact
in the other repository. For example “ready for test” in an Agile planning tool will set the status to “New” in a
test management tool.  

Once determined, it can take approximately three hours to implement the desired behavior and field
mapping in the integration of a single project pair. The process must then be repeated for each project pair,
for each artifact type.

When integrating ten projects with two artifact types across a single pair of repositories, you can be
looking at more than 50 hours of point-to-point mapping. For three repositories and four artifact types,
those same ten projects can take more than 200 hours to integrate.

Maintaining point-to-point mappings

Work doesn’t stop at setup. Integrations require updates periodically, as needs change, workflows evolve,
new tool versions are released and APIs change.

Perhaps once a year you need to add a field to an artifact, e.g. "Service Release", or change a workflow (new
status value "To Triage"). Or perhaps you have a more frequent field value update to make (adding a new
release value to a dropdown list every two weeks).

These types of updates will require amending the field mapping for each project pair and artifact type,
generating approximately 400 hours of maintenance effort per year for those same ten projects.
Scaling point-to-point mapping
For each new product the business wants, organizations typically
create new projects in their tools, which means periodically you’ll
need to add new projects to your existing integrations.

Even if they are similar or identical to the configuration that you’ve

already created for a different project, you’ll have to configure the
new pair and define the field mapping. Scaling from ten projects to
25 projects can take an additional 300 hours to set up.

Data consistency
When you’re configuring tens of mappings between individual
project pairs, it’s extremely hard to maintain consistency. Even
with the best of intentions, you’ll forget what you’ve already done
and do it slightly differently each time. Alternatively, you may find
yourself toggling back and forth between an old and new setup and
making small copy/paste mistakes. Most likely, it will be someone
else entirely doing this new configuration, who won’t have the
previous context and will apply their own perspective.

If there’s nothing to enforce consistency and uniformity in the

shape the data takes on as it flows across repositories, there will
be a lot of variability in what flows and how it flows. When you
try to measure, explain and communicate on what your software
delivery organization is doing, your reporting will be extremely
compromised.

So, while the integrations are essential, the mechanics of an

integration seem to dictate that an unsettling amount of time and
resources are required to set up and maintain them and that data
consistency is in jeopardy.

Model-based Integration:
A Revolution
Model-based integration is a fundamentally different approach to
integration that meets the needs of Enterprise IT.

Model-based integration enables:

• Rapid time to value in integration setup

• Minimal overhead in integration maintenance and scaling
• Powerful reporting and analytics that inform decision-making
• Flexibility in the face of constant change 70 percent
of large scale
How does Model-based Integration work?
software delivery
The answer is, through models. A model is a shared definition organizations
of a unit of work for the purpose of reporting and measurement
that extracts the most important data in each system of record integrate at least
and distills it into a standard shape and form, namely a fixed set four artifact types
of fields and possible values.
across a minimum
of three tools.
Models standardize the information exchanged by integrations into archetypes of business value, which
express the organizational consensus of the data package that needs to flow between tools and be
measured by stakeholders.

Models are defined upfront and in advance on the integration platform to prevent ad-hoc, subjective or
arbitrary data selection and field mapping. As data flows between two repositories, it goes through the
model. A good analogy to help understand how models work is the act of translating between people who
speak different languages.

If you have two people that speak two different languages, you need to translate only between those
two points. If, however, you have three different languages, you have three points of disconnect in
communication that need to be translated. If you have six, you have 15, if you have 10, you have 45
and so on.

As you can see, resolving these point-to-point disconnects individually quickly becomes unsustainable
given the sheer number of them that can arise. This is how models save the day, acting as a “universal
translator,” overcoming all of the communication disconnects that are present by translating between all
of the points at once.

The beauty of models is that they do not force change on the software delivery teams, nor disrupt their
work. Instead of forcing everyone to use the same tools, processes and systems, models guarantee agility
and autonomy to the teams.

The most popular models in software delivery are:

Defect* Problem* Feature* Request Release Folder
Story* Test Case* Epic* Task Changeset
Ticket Requirement* Build Vulnerability Alert

* Highly popular model

Model-based Integration vs. Point-to-point Mapping
Earlier in this document we described the significant effort required to set up and maintain point-to-point
field mapping between integrated project pairs. Model-based integration reduces this setup overhead by
75 percent and maintenance overhead by 90 percent.

These huge savings translate into faster time to value (TtV) for your products; integration setup will no longer
be a hindrance to project kickoff, and small changes to running integrations can be done in a matter of
minutes. In addition, you don’t need a team of admins to do the work - a single admin should suffice.

To further understand how models eliminate the overhead of point-to-point mapping, let’s take an example
of four projects in Repository A that need to be mapped to four projects in Repository B.

In Point-to-point Mapping: With Model-based Integration:

Each project pair is mapped individually, Groups of multiple projects in each
resulting in four mappings. repository are mapped to the model,
resulting in two mappings.

A B
A B
A1 B1

A2 B2
A1 A2 B1 B2
A3 B3
A3 A4 B3 B4
B4 Defect
A4
Model

Now, imagine you’ve recently added two projects, representing two new products in your systems.

In Point-to-point Mapping: With Model-based Integration:

Each additional pair must be The two additional projects are added to
mapped individually. the project grouping. They are automatically
mapped to the model.

A B
A B
A1 B1

A2 B2
A1 A2 B1 B2
A3 B3
A3 A4 B3 B4
A4 B4
A5 A6 Defect B5 B6
A5 B5 Model

A6 B6
Models vs. Templates: Overcoming the Insufficiencies of Field Mapping Templates

Some integration solutions try to solve the scalability challenges of point-to-point mapping with field
mapping templates.

A field mapping template, similar to a PowerPoint template, provides a starting point for your field mapping.
However, templates don’t solve the scalability challenges of integration at scale.

Models Templates Why?

Reusable Templates must be defined per repository pair and per artifact
in multiple Yes No type. For example, Jira Story to VSTS Story, ALM Defect to VSTS
integrations? Bug, ALM Defect to Jira Bug.

Isolates Templates create brittle point-to-point relationships between

relationships Yes No project pairs, easily impacted by changes in other tools and their
between tools? ecosystems.

Normalizes and
Templates do not standardize data as it flows between tools,
optimizes data for Yes No
requiring extensive effort to produce reports.
reporting?

Any change to artifact fields, values and workflows will need to

Saves time in
Yes No be implemented one-by-one in point-to-point mappings (or the
maintenance?
template must be reattached altogether).

Tasktop is the Only Model-based Integration Solution

Tasktop Integration Hub is a reliable, scalable and easy-to-use integration platform, predicated on models.
Launched in 2017, Tasktop Integration Hub is the only commercial off-the-shelf solution for software
delivery toolchain integration and value stream management via model-based integration.

Unique features include:

• Out-of-the-box models you can readily use: Designed based on our extensive experience working with
large software delivery organizations, and made possible by our systematic approach to tool integration.
You can use these models as is or tweak them to suit your specific needs. Alternatively, you can refer to
them as inspiration for new models that you’ll create from scratch.
• Smart fields: A list of curated fields that represent the industry gold standard for each artifact type.
Among these fields are smart fields, which Tasktop knows to automatically retrieve and map to the
relevant model from all the repositories supported by Tasktop Integration Hub.  
• Reusable collections: Collections enable you to group multiple projects and map them once to the
model. The savings are huge as you scale, as it takes mere minutes to add more projects to the collection.
The new project will automatically be mapped to the model.

Why is model-based integration unique to Tasktop?

Models originate from big picture thinking, from trying to solve a larger business problem. Many
organizations and integration vendors approach integration from a very localized perspective (such as
flowing defects between developer and tester for one project). If you are trying to move data between
developers and testers in a single department, you aren’t mindful of the larger ramifications. And to be
honest, that’s where many toolchain integration initiatives begin. For that reason, plenty of homegrown
solutions and commercial off-the-shelf products are not built on models. It’s quite possibly overkill for
synchronizing five projects with five fields between two endpoints.

However, you soon discover the flaws of this approach, when:

• You need to scale to many more teams, projects, tools and artifact types.
• You have sophisticated reporting and value stream management needs.
• You want your integration to go beyond synchronization to different integration styles, for example
event-driven artifact creation or update based on events from the CI/CD pipeline.

For long-term, strategic integration, models are the only viable option.

A model-based design also requires that the integration platform behavior, too, be standardized. Because the
platform will communicate with tens or hundreds of best-of-breed tools, it must ensure that each of those
exchanges conform to a strictly defined definition of artifacts.

Tasktop does this through our Integration Factory. The Integration Factory has two parts - specification and
automated testing.

To achieve uniformity, scalability and robustness, Tasktop has invested heavily in an elaborate specification
that all tool connectors must adhere to. Tasktop’s specification has nine high level epics broken down into
detailed stories, focusing on how we support connectivity to the repository, artifact types, standard fields,
custom fields, attachments, comments, person mapping, artifact relationships (links).  

The Integration Factory also has a robust automated testing capability that can programmatically test all
developed connections against the specification on an ongoing basis. Our test specification has over 1,100
acceptance criteria, and each night it runs over half a million tests on the 57 repositories and 300+ versions
supported by Tasktop Integration Hub.

Don’t jump straight in

Before selecting an integration
infrastructure, consider the following
questions:

• Does the solution have a first-class way

to define/govern your corporate common
data model, decoupled from the tools being
integrated?
• Does the solution support the enforcement
of that common data model throughout
your integration strategy?
• Does the solution support normalization
of the data from your heterogenous tools
to your corporate common data model for
easy reporting?

If you haven’t answered yes to all three, ABOUT TASKTOP

your integration infrastructure, enterprise
software delivery and digital transformation
might be in jeopardy.
Speak to use today for a highly dynamic
personalized demo of how model-based
integration can help you scale your software
delivery and improve the business value
delivered by your IT organization.
https://www.tasktop.com/contact-us
Tasktop connects the network of tools, teams,
disciplines and processes required for planning,
building and delivering software at scale.
The backbone of the most successful Agile and
DevOps transformations, Tasktop is an easy-to-use,
scalable and reliable tool integration infrastructure
that helps enterprises connect, visualize and measure
software delivery value streams.
With the ability to support hundreds of projects, tens
of thousands of users and millions of artifacts, Tasktop
automates and traces the flow of work from customer
request to finished software product.

For more information about Tasktop, please visit

http://tasktop.com
 To learn more about how Tasktop can help your business, email us at: info@tasktop.com or
call us at: +1 778-588-6896

READ OUR LATEST PUBLICATIONS

The Hard Truth About The Build Vs. Buy Decision

Value Stream Integration:
Integrating Software in Software Lifecycle
Six Reasons Not to Delay
Development Tools Integration

© 2007-2018 Tasktop Technologies, Inc. All rights reserved. Tasktop and the “Less
is More” logo (<=>) are registered trademarks of Tasktop Technologies, Inc. All other
tasktop.com
trademarks are the property of their respective owners. TSWP-1-2601
@tasktop