In Their Own Worlds

Our first example of a real-world disconnect comes from Patrick Flynn, Vice President and CIO of truck manufacturer, PACCAR. Flynn's story, from early in his career, is based on a customs -clearance project that was eventually abandoned by his employer at that time. In many ways, it represents the prototypical example of the disconnect, where each side pursues its own agenda with little regard for how it impacts their counterparts on the opposite side of the fence.

Flynn's customs-clearance system was designed to do real-time confirmation of clearance for a logistics provider. If an item needed to get from Singapore to San Francisco, for example, the system would determine the documentation that was required to pick up and export the item out of Singapore and into the United States:

It needed to know things like which data elements were required, what would be the sequence of transactions, and how we would know that something had cleared. Plus, it had to handle exceptions and special cases. A government could say, for example, "this is cleared on temporary or preliminary basis" and then say "no we want to hold this one." The basic communications standards were well defined ”there's actually a UN standard for customs clearance ”but the actual details were flexible; they were left to the participants to nail down.

In an ideal world, these business details would have been signed, sealed, and delivered before Flynn's development team sat down to write the first line of code. As the project progressed further and further along, however, these details remained elusive :

We knew there was a regulatory change coming that we would be mandated to follow. Then all of a sudden the change was off. And then it was on again ”it was a continuous back and forth. As a result, our developers were constantly forced to revise their plans. Sometimes, the change would seem right around the corner, and we'd have to compress our plan and throw out good practices. Other times, you'd sit back and say "wait a second, now it's going to be six months before we're ready to go" and so we'd sort of back off. There was never a clear definition of what needed to be done and when, and also whether certain features ”like supporting these new regulations ”were mandatory or optional. And each of these conditions has very different characteristics in terms of how you manage things.

Meanwhile, the development team was making important technology decisions on their own. They decided to build the system using Smalltalk, an object-oriented programming language that was designed for component development. From the start, Flynn remembers, Smalltalk proved to be a mixed blessing: it was great for developing the software (which was why they chose it in the first place), but it was horribly slow in a production environment, where time-sensitive communication was essential:

We had to communicate with governments , we had to communicate with customs brokerages (to actually have the ability to clear a document you have to hold the broker's license), and we had to communicate with our own internal systems. All these were timing issues that needed to be worked out with the business: when would we be able to say "yes this is clear or not" and so on.

These two decisions ”to continually evolve the business requirements and to develop the software using Smalltalk ”combined to have a devastating effect upon the project. On the one hand, Flynn's team suffered through dozens of iterations of business requirements as regulatory agencies flip-flopped back and forth. With each change, it got harder and harder for the developers to avoid rewriting code that they'd already finished. On the other hand, Smalltalk couldn't keep up with the strict timing requirements that the business required, and the system always seemed to be operating a step behind. After a significant investment and years of effort, it became obvious that the project would never work, and it was canceled .

The problem with Flynn's project was that business and technology decisions were made independently, with little concern for how each might impact the other. Changes in the business requirements were based solely on shifting regulations, and the ripple effects of those changes upon the code that Flynn's team was developing never entered the equation. Similarly, the decision to develop in Smalltalk was based upon a strictly technical consideration: how good it was for building components . But by coding in Smalltalk, the team created a disconnect between the technology they developed and the strict time requirements that were critical to the business. As a result, business and technology headed in distinctly different directions (see Fig. 1.1). "It was like trying to build a bridge from opposite sides of a canyon," Flynn concludes, "and it never quite met in the middle."

Figure 1.1. Business and technology decisions in Flynn's project were made independently with no connection to the other