(with apologies to Mary Shelley.)
NOTE: I am just trying to get a point across with a little humor here. If you can't take a joke, don't read this posting. There are no secret or veiled references to individuals at ASU or elsewhere, so don't look for them. I mean no disrespect. Also, please note that I am not a qualified fiction writer or satirist.
Proceed at your own risk.
Once upon a time, in the furthest reaches of Transylvania, a happy village had an unhappy problem. Seems the village's IT system was getting a little long in the tooth. Each year it was harder and harder to make necessary changes to it. The villagers' processes had begun to suffer, as the system became more and more difficult to adapt to changing needs. Many of the villagers' hopes for amazondotcomifying their portal were stymied, because they were unable to efficiently pull or push the back end information they needed to make things cool.
This caused the ordinary villagers some concern, but overall they were still very happy. Customers still visited the village to take courses and get degrees, goods were bought, bills and parking tickets were issued, checks were cashed, grants were awarded, degrees conferred. If the villagers dreamed of more from their IT system, still they remained content that at least life would go on as it always had.
The Stewards -- those with the responsibility for keeping the IT system running -- felt differently. They were much more concerned about the state of the system, for they knew things which made them afraid. They knew that where once many of them had command of the ancient tongue -- now long since out of fashion -- that was used to control the system, now their numbers were few. Further, they knew that some of the bravest and brightest of that number were nearing retirement. The Stewards worried about how much longer things could go on as they always had.
Several of the Stewards had heard tell of a way of modernizing their legacy systems using a software stack from one of the Outside Vendors. It was said that these Vendors wrote systems that served many villages' IT needs, helping these villages create software solutions to fit their needs based on common software modules built on the latest technology. These Outside Vendors existed for two reasons...
- ...to bring the best practices of the other villages with them, embodied in the software they would use to replace the villagers' legacy data systems,
- ...and to make money for themselves.
It was said that some; many; perhaps even most of the most prestigious villages in Transylvania had dealt with their legacy problems by using one or more of these Vendors to rework their systems. True, there were also many rumors that all was not well with some of these villages, and that mysterious plagues had visited them during their multi-year rewrites...
But the Stewards saw little choice. And so a bargain was struck, and the Stewards, together with a team of the brightest villagers, and the team from the Outside Vendor repaired to the castle for the long process of creation.
< whaddya think...pretty good story so far no? I mean, better than you expected given the author right? No? Keep reading, it gets better >
Not much came out of the castle for a long, long time. Lights could be seen burning in the towers until late, late at night. The bright people from the functional units of the village visited the castle to talk with the Stewards and the Vendor, sometimes for weeks at a time. Of course, the Vendor's trucks came by once a week, regular as clockwork, to transport another load of the village's treasure back to their headquarters.
At first optimism reigned. However, as the old IT system was still in place, and because most of the Stewards were busy in the castle, things moved forward even slower than before. The longer the people waited the more restless they became. Still, they consoled themselves with the knowledge that deep in the castle, a team was working for them, working to create a wonder.
Then one night, after several years, (a little longer than expected), in the midst of a great and terrible thunderstorm, a strange sound was heard from the castle. It was the clank of a pair of giant chains slowly raising an enormous platform to the highest reaches of the castle's loftiest spire. The platform, now raised, rocked unsteadily in the gale until, suddenly, a titanic bolt of lighting struck the tower and the platform, raising an eerie glow over the entire scene.
And a joyful cry went up from deep within the castle, a cry born of utter exhaustion and redeemed effort, which floated down over the village...
The people were drawn to the castle by the cry, and ran toward the glow just as the Vendor's truck drove away with the last payment from their treasury. They had suffered privation for some years, but now, they knew, the long wait was over. They streamed into the castle full of hope and expectation.
But their joy quickly turned to horror as they looked the new system in the face for the first time. They searched for signs of familiar or desired functionality, but in place of smooth skin covering sinewed muscle, great gobs of missing functionality seemed to ooze from open wounds. The villagers recoiled and fled...
"Wait", the Stewards cried, "You don't understand him. Our creation would never hurt you. He's just not finished yet. Give us more time and we can teach him to behave as you would have him behave..."
But when the villagers returned, they were back with flaming brands, intent upon destroying the very monster the Stewards had created to help them.
The Vendor does not use the village as a reference site.
Ok, Ok, it needs work, I know. But I think it will serve my purpose. This week I've been talking with people who are fed up with getting ready for a wedding only to get stood up at the altar rail. Some of these folks have had two, three, or even more tries, putting together elaborate justifications for replacing the SIS and other systems, working with folks from around the U to devise new solutions, only to be told that the project would not be funded "this year." It's an understandable frustration that's deeply held by sincere people who have nothing but the University's best interests at heart.
Yeah, whatever. What's this all have to do with my little Frankenstein story? Well, everything. Because I'm afraid that even when its done well, ERP development has a lot in common with my little parable. It's just the paradigm. By it's very nature it's extended, off-line development of the kernel of a system, which once up, is re-extended to cover the functions of the system it's replacing. Once its been brought up to about the functional level of the old system, then the system is finally ready for extension into the improvement zone. The curve looks something like this:
The standard development curve is the one commercial software, like say Photoshop, has to hit to stay in business. It's a steady stream of new versions, without a lot of delay in between, each one better than the last. Every so often, in every software development house, small or large, the same conversation we're having about the SIS system arises, about the need to rewrite the "back end". This conversation is ubiquitous and inescapable because software ages. Over time it just gets rotten...to the core...(just like Crabby Appleton)
Anyway, in a commercial software house -- ie. one with paying customers who have a choice of products -- when the "we must rewrite the backend" conversation comes up, the first solution offered by the technical team is usually the Frankenstein proposal:
"We'll go away, off-line, for a long period of time and create something unsullied from scratch. Yes our first release will have to have less functionality than the current release, but subsequent releases will be on the new platform and so will advance much faster. In the end this is better for us as developers and ultimately it will be better for the consumer.
Fortunately for most companies, there are also sales teams. And when the sales team hears the Frankenstein proposal they go ballistic. "How are we supposed to sell this new but unimproved product, even when it does come out?" they cry. "All our competitors have to do is stick to the standard development curve and we'll never sell another copy!!!"
It does sometimes happen in commercial houses that the sales guys lose that fight and the developers get their way. The best example I can think of is when Mentor Graphics tried the Falcon project in the late 1980's -- a complete rewrite of the, at the time, world's leading ECAD system. They wrote it over again in C++. They even had Bjarne Stroustrup on as a consultant. A true example of the Frankenstein syndrome. Mentor lost many customers. Ouch!
Usually, at commercial companies though, the sales guys triumph in these conversations and send the development team back to the drawing board to develop a plan that follows the standard development curve -- a plan that provides a seamless stream of goodies for the users in a steady stream of releases with not a lot of space between them -- but that also addresses the underlying structural deficiencies. These plans are a lot more difficult for developers to devise -- sometimes in fact they simply can't be found (which is bad news if you're a commercial firm). But when they are found, the risk goes down a lot...and the villagers end up a whole lot happier.
Which brings us back to the altar. Nothing scares a bride or groom off like risk. Well, OK, risk and expense. And the Frankenstein model is a tough sell to a big organization like a University. With a ticket in the many tens of millions of dollars you need to sell everybody on the leadership team, because those millions will have to come out of their collective hide. So they get nervous when they hear that they won't see results for years, and that the first ones they do see they probably won't like as well as what they had before.
"But", you say, "other Universities have done it... other University's have found the money and the will to take those risk".
Which is true. Lots of other U's (and lots and lots of other companies) have bought ERP systems. Many did it in response to crises, like system failures or Y2K. That's the easiest way to decide I think. (Picture Butch Cassidy and the Sundance Kid on the cliff with the rushing river hundreds of feet below and the Pinkerton's right behind them. Butch is ready to jump, but not so much with Sundance. "What's wrong?" says Butch. "I can't swim!!!", says the Kid. "Ahh hell Kid", says Butch, "the fall'll probably kill ya!")
If the system is just plain broken, then the "all the kings horses approach" doesn't sound risky -- it sounds just about right. So that's how some have made the decision to do it.
Others have done it because the vendors are great at selling stuff. It's what they do. They have to to stay in business. And the Frankenstein model is the one that works for them. That's why they're comfortable with it. They get their money early and often, as up front as they can negotiate it. Their last truckload of major dough pulls away just about the time the villagers with the torches are showing up.
Or not. Hey...I'm just one guy, with one opinion. But I would sure like to hear from someone hear at ASU who says I can get you to Oracle, or PeopleSoft, or SCT, or SAP, or whatever modernization platform will stand the test of time, but on the standard development curve, not the Frankenstein plan.
Now maybe I'm being overly pessimistic. Its late. I have a long drive ahead of me tomorrow. 'Cause Max and I are headed to Flagstaff, to Northern Arizona University, so I can learn from Max's former compadres how they managed their PeopleSoft implementation.
I hear the villagers stayed in town and were pretty happy with what came back from the castle. I also hear it didn't take that long.
I'll let you know what I find out.
In the meantime, I'm still looking for diagrams. I have one so far. When I get another couple, I'll post them.
is anyone actually reading this or am i talking to mysef?