In my previous blog post I discussed how planning is key to success. Once the planning is complete, then comes the design, which can be simple to configure with our suite of integration tools. With some practice, you can configure 8 mappings between 2 projects and 4 types using templates. This includes development of the template in just 20 minutes (I actually just did this). Since the design can be easy when properly planned, what I wanted to focus on in this post was how integration via synchronization can promote corporate standards and ALM system templates within an organization.
Working with companies large and small, I’ve seen many different ALM systems and configurations. Typically, companies have standard templates that are used between projects so that all teams have the same sets of fields and can be reported on in a similar manner. This can make integration very easy as the customization between each project is non-existent or minimal and templates can be used within Tasktop Sync to quickly add new mappings to extend your integration across the organization. Once a mapping is running and teams are happy with it, you can create a template and roll out new integrations quickly.
The flip-side of this is when there is no commonality and therefore each of the integrations must be setup independently. The power of Tasktop Sync allows this and makes integration easy; however, this isn’t always desirable for the integration maintainer and even the ALM system admins. Does your ALM system look like this:
If you notice, there are 7 different “Defects” and there may be 10 different fields for “external defect id”. This can be a nightmare for the ALM system administrators to maintain. Typically when this has happened, either the team implementing the system didn’t know what they were doing when they started, or the IT organization inherited the system from a development team that started using it outside of the context of the organization (bottom up adoption). As an example, one company had a number of acquisitions and they merged all of the JIRA repositories as they merged with newly acquired companies. This resulted in over 200 types and who knows how many custom fields that caused the JIRA administrator a lot of pain especially when they all represented a core 4-5 types (task, defect, story, epic, impediment). Teams, however, were reluctant to change to any standards since what they had “worked” and they didn’t want to change their process and the IT organization didn’t have the power to force the change.
While working with the customer, the need for integration was high and it was decided that not only could we help the teams by integrating with their PPM and development tools, but we could help the JIRA administrator as well. With this, we set forth to create a standard set of types and fields that would be synchronized and would be common among the teams. From here, we had a clean integration that could use templates to extend across the projects. What this meant is that as teams approached the IT department wanting integration, they were told that they needed to change their template to use the corporate standard or else they wouldn’t have integration. As the manual processes were problematic for the developers, teams would to move to the standard template and greatly improved the life of the JIRA admin.
Moral of the story, use synchronization to enforce standard templates and influence change within your organization!
