Strategy to Avoid Future Integration Failures

This Part-1-of-2 blog focuses on the technical part of “Michael from Pennsylvania’s” blog titled “Hardcoding is Job Security (For Everyone But You)” from The Department of First Things First.

MichaelPA’s blog begins with a scenario that explains the issue:

---

“It usually happens at 2:00 AM. A payroll integration fails. You open the error logs. You dig into the code that your expensive implementation partner wrote three years ago.

And there you find it. The smoking gun.

<xsl:if test="cc='100-2495’”>

They hardcoded a specific Cost Center ID directly into the logic.”

---

It’s natural to wonder why the Cost Center ID value of 100-2495 was placed into the code.  MichaelPA explains what many of us already know as reasons to avoid hard-coded values:

---

“…three years ago, that was the only Cost Center that needed the special tax rule. It was fast. It was easy. It worked for the deadline.”

---

The obvious problem is that one day you reorganize and that Cost Center doesn’t exist anymore (in his blog, that day happened between the previous payroll run and today.)

MichaelPA explains that because the Cost Center ID value of 100-2495 is buried in the (XSLT) code, instead of in a configuration table, a launch parameter, or an attribute, the integration didn’t run as expected.

I find MichaelPA’s blog particularly important, not only because it is a payroll integration, but because I’ve inherited this unfortunate approach to integrations many times during the past 13 years since I left Workday (where I worked in the “Knowledge Management” team, a.k.a. “Training”) and started working directly with Workday customers.

One similar failed-logic example that comes to mind was a previous “integration consultant” deciding that “working in California” was defined as “working in Los Angeles.”  In MichaelPA’s example, there was a reorganization. In this example, a new office was opened in California. Everything was working just fine back when Los Angeles was the only city in California with an office.  When a 2^nd office opened in California, the definition of “working in California” broke. 

Even worse, because the failed-logic was “hidden” in a calculated field, and that calculated field was used in more than one integration, many integrations failed.

Why use the work city field instead of the work state field is beyond me.  But, there it is, yet another problem with using logic that works initially but does not look into the future.  A near-sighted approach to problem solving might one day come back to bite you.  If your Workday team is focused on just-getting-it-to-work today, for the go-live, and you ever hear the words “we can fix it later,” your team is providing job security for those who are “fixing” a problem that could have been avoided in the first place.

Consider yourself lucky if a payroll integration actually “fails.” This means that it did not run successfully. If the payroll integration actually runs without failing, but the logic is incorrect, well, let’s not even think about what might have happened on that payroll run.

As MichaelPA puts it in his blog,

---

“If you are writing specific IDs, names, or dates into your code, you aren't building a system. You are building a trap.”

---

Also from MichaelPA’s blog,

---

“If the rule changes, a functional analyst should be able to update the table in 30 seconds.”

---

You might be wondering how can functional folk fix an integration in 30 seconds?

There are strategies to help you avoid having to find XSLT code, open Studio code, make edits, and update your integration. As your growing company grows, poorly written integrations will have to be updated. Part-2 of this 2-part blog will explain for functional folk how integrations could be written to use launch parameters, integration attributes or maps (tables) to avoid hard-coded values in integrations.