ESBs Are Made For This

This is written from the perspective of an Enterprise Architect tasked with enabling an organization’s effort to be more competitive by adopting Agile. The company has turned to SAFe (Scaled Agile Framework) as a way of scaling Agile since initial attempts at Agile were not successful despite lots and lots of scrum master trainings.

I’m told that our SAFe implementation depends on the flow of information between people from different parts of the organization. People need that information in their tools, and knowing that these groups all use different tools, that means integration.

As Senior Director of Integrated Things for VeryLarge Corp that’s right up my alley – and I know that my team can pull it off. Some of these tools are familiar to my team; we’ve already connected a couple of them to satisfy one use-case, so I’m feeling confident. ESBs are mature and the team is solid, and knowing that the team has deployed ESBawesome successfully, this is looking like it’s in the bag.

I’m going to fail. Here’s why:

ESBs Are Made For This

Choosing an ESB for this is so easy. I want ESBawesome, since it’s got good backing, super adoption and a great community. It has got all the “ilities”. High Availability, Reliability, Scalability, Fault Tolerance, Security, Tracking, Monitoring… ESBawesome has it all.

With the tick boxes checked, looking further I can see that ESBawesome already has a connector for some of the systems that we use: Atlassian JIRA and ServiceNow. And because of their API flexibility, ESBawesome can integrate anything. They even provide an easy way to generate connectors!

ESBawesome also fits in well with VeryLarge Corp’s integration strategy; we’ve already got it deployed and we have a team built around it.

Team Capacity

The integration team’s backlog isn’t looking too bad. They’re due to come off their current integration project, integrating the inventory-checking module with POS, and should be ready to start in about 6 weeks.

Except that we’re having some troubles with an upgrade of Atlassian’s OnDemand JIRA service – where some of JIRAs changes regarding date handling in their REST APIs have caused 100’s of errors in our JIRA – ServiceNow integration. That, and we have to investigate why we’ve occasionally started seeing “Not authorized to perform action: Invalid key” errors from Rally. Oh, and we’re currently blocking an upgrade of IBM RTC from 4.0.1 to 5.0.2 due to some changes and their client libraries from the old version not being compatible with the new version.

Wow, I’m having multiple problems with the integrations that we’ve recently created. Not only were the integrations tricky in the first place, maintenance is way harder than we thought. These are costing my team more than anticipated, and as a result it’s looking like a potential multi-month delay before I can even get started on this new integration effort.

Komma igång

It’s three months later and we’re finally getting started on our first SAFe integration use-case: quality group defect sharing with development. We’ve got our ESBawesome ESB application building in our CI environment, and we’re deploying it continuously to a staging environment. We’re operating at 40% capacity because the team is still dealing with the RTC upgrade, but we’ve got a great start in large part because of our previous ESBawesome experience.

To make the integration fault tolerant we’ve got to be sure to implement the ESBawesome “reliability patterns” correctly. We’re using Oracle as a back end relational database to help with that, but currently we’re waiting on IT to set us up with an account with sufficient permissions to create the tables and sequences that we need.

The ESBawesome reliability patterns also call for a proper JMS queue, and we’ve finally got one going. It’s not the same one that we’ll use in production, but it’s good enough for development. Hopefully things will just work when we switch over.

Connecting the Systems

So the JIRA connector for ESBawesome isn’t all it’s cooked up to be. That is, it’s not really that bad but it’s definitely not designed for the kinds of use cases that we have in mind. The problem is that the low level APIs of JIRA (and the connector) don’t deal with JIRA issues as a whole – things such as watchers, links and comments are separate API calls.

Our first integration is all about connecting defects from the QA team with the development team. To do that we need the whole JIRA issue to reflect the state of defects filed in HP ALM. Propagating only some of the state just won’t do, so we have to deal with complexity such as a failure to update an issue with links after successfully creating it in JIRA. We’re still trying to wrap our heads around how to manage such partially successful state replication.

On the HP ALM side the ESBawesome connector is coming together slowly. We’ve had troubles getting the ESBawesome annotation-based REST connector to work for some of HP ALM’s API calls, since we’ve discovered that some of the assumptions about REST APIs aren’t holding true for HP ALM.

Success

It’s now four months since we kicked off this project, and the team has caught it’s first whiff of success. We’ve got issue creation in JIRA working! We had to hard-code some values for some of the required fields in JIRA, but it works!

The next step is to make it easier to add new projects. Our teams in JIRA have all customized their projects with different statuses, fields and severities. I’m surprised at the lack of commonality among our 3000 JIRA projects.

At the moment, each time we add a new project we have to hard-code more values and field-specific logic into our ESBawesome application. The team knows this won’t scale so has started creating an XML file to configure these settings. With 3 projects integrated, the XML file is over 4000 lines. It’s going to be tricky editing this file each time we add new projects, but we’d prefer to do that than have it hard-coded in the application.

“ilities”

The team thinks that it has the fault tolerance and reliability aspects of the integration solved with the Oracle database and JMS.

We want to use ESBawesome’s clustering capabilities for scalability and high availability, but it turns out that we have to adapt some of our application logic to make that work. We chose the wrong level of abstraction for an integration unit of work, and have found that partial failures can result in issues with missing comments and others with duplicated comments, which causes a communication break down. Thankfully we haven’t deployed into production yet and it’s not affecting any teams directly.

Our initial tests have shown that we don’t really need clustering to scale to the levels we’ll need with our 20,000+ developers. I’m cringing inside at the effort that we’re spending on this.

We’ve had to pull in IT again since we’ll need a load balancer in front of our ESBawesome cluster to handle transparent fail-over. Looks like they’ll be meeting with us some time next week to talk about environments, hardware allocation and timelines.

Domain Expertise

We’ve spent so much time trying to get the integration to work, sorting out the details with the technical bits (connectors, environments, databases, and everything else,) that we haven’t had much time to try things out with our users. Today we set up a mock trial with the quality group and it turns out that we completely missed something that’s essential for this to work with them.

It turns out that when an engineer resolves a defect, the quality team doesn’t want it to show up as resolved in HP ALM since they need to design and run tests to verify that it’s indeed closed, and create the appropriate regression tests if needed. This only happens for defects in the ‘Ready for Verification’ state – but we can’t just move defects to that state without a quality engineer verifying that the change made it into a build that’s been deployed to their QA environment. We proposed adding a new status, but that didn’t fly because it would mess with their reports, so we’re working on a way to have the “development status” show up in a new custom field in HP ALM.

Deployed!

It’s 8 months since project kick-off and we now have a few “early adopter” teams trying out the new integration.

Initial feedback has been pretty good, but we now have a backlog of over 150 defects and feature requests. Most of them are minor, but a couple worry me. I’m not sure how we’re going to deal with the loss of HTML formatting in descriptions for example, and HP ALM’s notion of comments as a single large text field is really problematic.

We had to put a few of our other integration projects on hold for awhile to get this one out the door, so we’re switching gears right now to get those back on track. The team should be able to get back to this one in a couple of months, at which point we’ll look at incorporating feedback from our users. If everything looks good, we’ll be bringing on more teams into the trial and hopefully get the green light to deploy department-wide soon.

I’m feeling optimistic – but one of my engineers has given me a heads-up that Atlassian is about to delivery their next version of JIRA. When I asked how often they upgrade JIRA, they said every 6 months. How in the world are we going to keep up?

Retrospective

Overall we failed the business. Looking back at what we accomplished, I’m really proud of my team. They overcame a lot of technical issues and really delivered. Unfortunately it wasn’t enough.

It took 8 months and a big chunk of my integration team’s delivery capacity to deliver the first integration. The delay caused us to miss our SAFe implementation goals, and we only delivered a small piece of the integration puzzle. In the meantime that my team was unable to deliver on other projects, which is costing us in lost opportunity.

Here are some of the things we learned along the way:

• Integrating teams is more complicated than we thought – the technology is only a part of integration, understanding the reasons why, understanding and supporting specific integration use cases of multiple stakeholders is the killer.
• This very quickly turned into a large development effort. Thankfully I have a top-notch team, but even they had to overcome some big problems and there was constant pressure to deliver. VeryLarge Corp really needed this up and going before we even started, and we simply couldn’t deliver fast enough.
• ESBawesome is a fabulous ESB, it really pulled through for us as a technology platform. The issue for us though was that the ESB focused on the technical problem and as a result we were in the weeds a lot of the time. For DevOps and ALM/SDLC integration there was a ton of customization and it was not straightforward. Using an ESB as the basis for our integration meant that we followed an industry-standard integration approach, but it also meant that a lot of software engineering was required. ESBs solve some of the problems, but come with their own complexity requiring a high degree of expertise.
• Connectors are a big part of the equation. ESBawesome only came with one of the connectors that we need, so we ended up building the others ourselves. It’s pretty quick to see some initial headway, but getting these right is hard. Building a connector means dealing with all of the idiosyncrasies and bugs of a 3rd party product API, which can vary from one version to the next.
• The integrations that we built previously take a lot of effort to maintain. Through no fault of our own, APIs are changing and breaking in unexpected ways. This puts a heavy maintenance burden on my team. I’m going to have to plan for even more of this as we proceed with our integration strategy – either cutting the team’s expected delivery of new features, or expanding the team to account for maintenance.

Wrap Up

This is a story based on what we learned and stories we heard from our customers and prospects over the past few years. We have something that we call the “be back bus”, an appropriate term for those situations that we see all too frequently when in-house integration teams take on the complexities of DevOps and ALM integration with an ESB or custom integration.

What we’re actually seeing now is some demand to connect Tasktop to ESBs, for organizations wanting to flow lifecycle data to their ESB-based integrations. This is what makes the Tasktop Gateway so interesting, as we just enabled this new kind of interoperability.

Tasktop is proud to be the industry-leading vendor of DevOps and ALM integration software. Our integration factory is the only one of it’s kind. We offer semantically rich point-and-click solutions to these otherwise engineering-heavy problems, enabling our customers to focus on their business problem rather than the technical problem.

I invite you to chat with us about how you can eliminate communication barriers within your organization without kicking off a multi-month software development project.