Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

The $100,000,000 Canonical Model

September 11th, 2007 · 4 Comments

Dave Christiansen, Managing EditorOnce 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 He manages projects for a Fortune 100 financial services company and writes and talks about project management. He can be reached at

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Architecture

4 responses so far ↓

  • 1 Mike Herrick // Sep 11, 2007 at 7:09 am

    Well, it starts out sounding pro canonical and then sounds very anti.
    My response would be “compared to what”? Sure they/you (don’t know)
    screwed up, but I didn’t understand how that isn’t the canonical
    model’s fault. That should have become apparent a bit sooner than
    100MM into the project?

    There are no silver bullets. But then again does quick and dirty
    really pay in this case? I mean look at the mess of a lot of IT systems –
    classic big ball of mud architecture – I mean it is freakn’ nuts how
    bad some IT organizations integrate. NUTS! We have accumulated an obscene amount of
    technical debt – so much that I think that management should be
    petrified of building a business on many IT systems.

    We all need to be agile, but we have to have a simple repeatable approach
    to doing integration. It has to be a self-sustaining community owned
    approach that won’t get shut down if certain people leave / get fired
    etc. This won’t be easy. But we all have to give it a shot.

    Canonical model is not going to solve all of our problems – I have
    done this before a couple times – I know that. But it will give us a
    fighting chance at having a reasonable integration architecture. A
    reasonable integration approach. I guess I don’t get what the
    alternative is – or do you want big ball of mud on top of a fancy new
    SOA – I’ve seen that too – not pretty.

  • 2 David Christiansen // Sep 11, 2007 at 7:11 am

    Thanks. I should have put more thought into this post, but hey, it’s a blog, not a magazine. I think I want to be more clear about the mistakes we made in this example, but I also want to point out something that people forget, that the canonical model is a model of the business, and that substantial changes in the way we approach a particular business concept (like billing) can make our canonical model invalid. In telco, shortly after Y2K, billing for mobile customers started to change dramatically. Rollover minutes, minutes sharing, pre-paid, all that stuff was so different from the traditional telco customers that the canonical model had to be re-invented. The reason is that mobile telcos used a long-distance model for billing mobile customers until 2001. Minutes had rates, the customer used minutes, we tracked them, and billed for them, just like old fashioned long distance. But then, people invented crazy stuff like family plans, rollover minutes, digital content, all sorts of stuff that didn’t fit the “minutes” model. This broke the canon. Nobody had screwed up, the world just changed, that’s all.

    I think it’s interesting that we use the word canon for this. It has a religious aspect, that indicates the “official” part of a religion that is immutable, least likely to change. In other words, once you stop believing the “canon” of a denomination, you can no longer consider yourself a part of that denomination. I think we think of canonical models in the same way, as something that will hold constant while everything around it changes. Or, if we imagine it changing we think of it changing incrementally, the way high school students are taught we evolved from Homo erectus. Study evolution in college and they teach you a completely different story – that we evolved in huge, sudden leaps, not small incremental steps. My concern about canonical models is that they don’t really help you prepare for major shifts. They enable time to market, they let you modularize large pieces of your architecture, they make it easy for everyone to talk, but they don’t adapt well to fundamental changes in the way we operate as a business. In fact, they resist those. I don’t know the solution.

    I hope this makes more sense.

  • 3 Mike Herrick // Sep 11, 2007 at 7:12 am

    There is a balancing act here – the two goal posts are “canonical model
    will save everything” and “the mess we are already in”.

  • 4 Mark Brady // Nov 9, 2009 at 10:56 pm

    Mike said it right, "canonical models will save everything". That's what I think the article is trying to fight.

    I hate to fall into buzzwords but the hypecycle for SOA and EA and Canonical Datamodels is a little taller (Hype-ier) than most. Remember when XML was the savior? "Look how flexible and it's self describing!"

    Oh, and it takes up 5x more space, and it's pretty cool for one message, but if you're store millions or billions of messages you're screwed, oh and if you want to use it to serialize data it can chew through your process space in the blink of an eye.

    Things rarely get easier. Most things just recatagorize the work we already do. Some of us are very skeptical when told, "this will make _______ go away", whether it's work or DBA's or programming or bugs… almost never does.

Leave a Comment