Once upon a time (1999) a bright guy had a bright idea. “If we expose our back office capabilities as services,” he said, “the business will be able to use them to deploy new capabilities quickly in ways we can’t imagine today.” People listened, and before long this bright guy (not me) had a small team of bright guys working with him to come up with a way to build some services. They started with operational data – since this was a huge telecom, they wanted to make it easy for mobile users to know how many minutes they’d used, had left, etc. This service was a huge success, and before long the business wanted more services that were disembodied from the back-office system that provided them.
Before long, an Enterprise Integration group was born. It provided two hundred different services, including billing, provisioning, account servicing, and others. It had four hundred employees, all of whom were happily engaged in maintaining and extending the service offering of Enterprise Integration. It was a happy world. The major telecom could roll out new apps quickly and cheaply, because most of their back office capabilities were already exposed. But the greatest asset of enterprise integration wasn’t just the services they owned, but the canonical model it created.
The EI canonical model was the embodiment of this happy big telco’s business. It was its bread and butter – the way it did business. It was the telco’s very soul, laid out in simple, human readable interfaces.
Good times never last forever, and by 2002 this telco discovered it was in trouble. It couldn’t spend money like water anymore, and it started to look for ways to cut back. The billing system was an obvious place to start. It was an ASP, and at $1 per account per month, it was costing this very large telco a heckuva lotta their sweet moolah. Everyone knew it needed to be replaced by a system the telco could own and support in house. The business case was solid. Replace the billing system with one you could own and support in house, and even if it cost $1,000,000 every month you would still net a gain of about $80,000,000 every month. Heck, you could sink $100,000,000, maybe $200,000,000 in the implementation project and still come out way ahead on the ROI.
Fortunately for this telco, they had a solid integration architecture, decoupling the billing system from all the systems it supported. They could just rip it out and put in a new one, support the old interfaces, and move on happily with their lives. Everything would be grand. That’s the way the technologists sold it anyway. “It’s all the same data,” they said. “It won’t matter if it’s structured differently, we’ll just find ways to transform it to match what the new billing system is expecting.”
The sales pitch was bought, and the integration began. The new billing system was installed and loaded with data. Business users started experimenting with the user interface, designing workflows and figuring out how to do their jobs with the new stuff. Everything seemed great, until they started trying to plug the new billing system into the old billing services, of which there were about eighty.
Then, things started to go downhill. It wasn’t the architecture. The architecture was great. It didn’t matter that the new system was java whereas the old system had been exposed through C++ API’s. All EI had to do was create adaptors, transform the canonical model into the new systems API, and off we go. Piece of cake, right?
Wrong. The canonical model wouldn’t map. The new billing system was fundamentally different from the canonical model, and for good reason. It solved problems that hadn’t existed when the canonical model was created. Those problems couldn’t have been anticipated when bright guys defined it. The ground had moved underneath them, and they couldn’t move fast enough to keep up. They couldn’t change the canonical model to meet the new demands of the business. They had too many clients and too many services to move everybody over to a new canonical model. They were being buried under the weight of their own canonical model. They thought they owned the model, but in the end it was clear – the canonical model owned them.
$100,000,000 later, Enterprise Integration finally owned up to the truth. They couldn’t make it happen. The vendor of the new billing system was sent packing. The telco’s stock dropped even further, and eventually the disappointed telco, stuck with their $1 per subscriber per month billing system FOREVER, sent almost their entire IT department to big blue, outsourcing nearly every IT job in the company.
Be careful what you wish for. There’s no such thing as a perfect architecture or a perfect canonical model, particularly in a world where the problems change as fast as, and sometimes faster than, we can solve them. Don’t build an enormous asset that has to last forever to have a good return. Keep it simple. Keep it cheap. Do it fast. Or don’t do it.
Dave Christiansen is the founder and managing editor of
TechDarkSide.com. He manages projects for a Fortune 100 financial services company and writes and talks about project management. He can be reached at email@example.com.