Wednesday, August 17, 2005

The Parable of Frankenstein...

(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...
It's alive!!!!

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?

6 comments:

Derwin August 18, 2005 at 5:45 PM  

You are not talking to yourself; you are making waves, probably beyond the shores you are aiming for. Is this a New American University process, or a personal approach to become familiar with IT issues outside of channels? The concern, I am sure, is whether you can and will indemnify all, should anyone inadvertently present arguments against the position of our leadership. :-)

You are presenting challenges that really demand more than a small post on a blog, or do you have the time to read, and the space to hold, the volume of discussion pertinent to the issues that you are probing?

We are going to deal with a Frankenstein's monster regardless of the specific path chosen, the question is which is the better monster? And for that matter, which is better in the context of a university in the process of redefining itself? It is much harder to change the wheels of our bus while it is cruising down the highway, with no one but those few up front knowing where we are going. But the hints suggest the tearing down of walls between the institution and community, as well as those within ... between campuses, schools and colleges, academia and administration. And if this is the case then we need to maximize flexibility. We don't need to simply change to a new system, without awareness for the need to provide an extremely malleable solution and foundation for change. We need a process so much more than a product.

The truth is that any option can be made to work, depending on what we are capable and willing to spend, in dollars, time, and political will. We are told that for an institution of our size we are on the smallish side of an IT department. The only explanation for making it as far as we have with the current systems is a reflection on the talent of those responsible for maintaining it. (And this is not a self serving statement since I am not a member of the Administrative Applications organization). The question is which of our options will put us in a better position to manage change.

So here are some thoughts. IT is one of the most dynamic industries that the world has ever seen. Experience almost counts against you if you fail to appreciate and capitalize on new technologies and approaches. At the same time you must not mistake a fad for a foundation. I'm personally betting on OOP, SOA, and the web as the best the industry has to offer, but still with plenty of room for creative development of better ways to capture business rules more efficiently . What worked five years ago, won't work today. There are no precedents. To quite an extent, the solution must be implemented by the force of collected will. Of course, I am a developer, and biased towards creation rather than purchase. But only an architect can say what should be prefab, and what should be built from scratch - provided that a cohesive whole exists in blueprint, and used to drive the decision process.

Oh, and who will unify our city-states; is anyone willing to try on Alexander's sandals?

Nancy August 19, 2005 at 2:08 AM  

Ouch... there are certainly people reading this, and thinking about it, and talking about it. Some of us, obsessively. :o)

But there are at least a couple of practical obstacles to responding. For one thing, blogging about work isn't part of my job description, to be blunt. Our time is fairly tightly controlled within assigned projects and regular duties, so those of us at the project do-bee level, at least, would have to use personal time to respond. We may not have enough of that, and enough related materials at hand, to do a good job covering issues. It doesn't help that this is the most intense, if not actually tense, time of the year for Admin computing. With Fall Semester start-up upon us, many are on alert for the kind of load-related problems that demand attention and fast response. I've been here long enough to remember one incident where student registration failure led to ASU getting featured in the news. Not how we want to be there.

Just a glimpse at this side of the tracks. I, and I think others, would love to hop into the fray of this dialogue. But there are obstacles that may not be obvious from your perspective. Maybe you would want to schedule a general meeting/brainstorming session with any staff who want to attend? That would be a way of accounting for, and scheduling, our time. Just one thought.

Nancy, needing to get ready for work

Adrian,  August 21, 2005 at 5:54 PM  

Derwin...

Thanks for the feedback. Judging from the hit counts, plenty of folks are reading, but not so many are responding. I'd indemnify all if such were possible, but communication is a risky business. That being said, I'm a huge fan of transparency, hence the blog. If a public risk is too intense, I can assure anyone who sends me email that I'll protect their identity if that is important to them.

As to whether I am serious or not about understanding these issues, I assure you I am dead serious. It's my new job you see. The blog is a forum to get started and to keep people in touch with the progress (or lack thereof I suppose). But if other venues would get the ball rolling faster, then I'm up for those too.

I agree that rewiring the house with the current on is harder than working offline, but it's the life we lead. As for the idea that only the few up front know where we're going, I must take issue. Seems to me that the vision for the New American University is a pretty explicit indicator of the directions of change.

Amen to needing a process more than a product. What I intend with the Frankenstein story is to inject the concept of risk reduction into that process. A much easier sell that way.

Alexander's sandals eh? What a classical reference! I'm thinking that this SIS conundrum could use a bit of Alex's approach to the <a href="http://en.wikipedia.org/wiki/Gordian_knot>Gordian Knot</a>...<br/><br/>----------------------------<br/><br/>Nancy<br/><br/>I appreciate the pressures of real work. Hence the Stone Soup analogy. Food is tight in the midst of a famine -- time is tight in the midst of the start of a term. Nevertheless if each person can give a little, perhaps much can be gained.<br/><br/>And the carrot you've brought to the pot today -- the suggestion of a general meeting/brainstorming session -- is a tasty morsel indeed! <br/><br/>Who would I have to set that up with I wonder? How much time would we need? How many people do you suppose would like to attend? Where should we hold it? What format would work? Ask around a little (you know, during lunch or something :) ) and advise me. <br/><br/>I love big groups...

mdj44,  August 22, 2005 at 3:39 AM  

Random Thoughts on the Frankenstein Monster –
I like the Young Frankenstein version the best [Also it is in my top ten list]. In the end the Frankenstein monster is a successful business tycoon and he gets the girl. Granted it is a little frightening along the way – but it is filled with humor and fun.

I like the Van Helsing version too. The movie itself is a little weak. However, in this one the Frankenstein monster saves the hero (ASU?) so he can save the world. The real enemies in this one are the blood suckers – of course we do not have those around here.

Many Frankenstein monsters have been resurrected over the last few years and much has been learned. Many villages in Arizona, Wisconsin, Kansas, California, Minnesota, Michigan, Ohio, Illinois, Mississippi, and Florida to name a few have built monsters and most quite successfully. They have learned that you don’t build the monster behind the castle walls but you build the monster in the middle of the village in the open market for all to see the progress. If the stewards are smart [and ASU has smart stewards] then the villagers are allowed to help build the monster. Existing parts (like DARS) that the villagers are familiar with can even become part of the monster. Granted villagers are sometimes scared when the are shown the monster because it is different but as they see it being sewed together and animated they begin to understand that it is nothing to be afraid of.

Some villagers refused to come to the open air market but it is not because they are uninvited or not wanted. They think that the monster is unnecessary and/or too costly. These villagers are needed also as they keep the pro-monster villagers honest and force them to look at real answers to all questions – just not the easy ones. They might make the monster building longer and a little harder but the end result is a better monster that can serve all.

mdj44,  August 22, 2005 at 5:24 AM  

Random Thoughts [Some people think that is all I have] on the Development Curve –

Examining the development curve for the Student Information System (SIS) at ASU shows that ASU follows the traditional functionality curve – increasing functionality over time. The increasing functionality has kept pace with the rate of change at ASU for 25 years until recently. The pace of change and need for additional functionality has increase dramatically in the last few years and the current rate of SIS functionality increase has not keep pace. There is a gap between current functionality and the needed functionality and it will only increase over time. Hence the need for “Closing the Gap”.

The type of ERP system that ASU would plan to install would have increase functionality and flexibility. That is the nature of the monster over a legacy system. A new SIS would have functionality that the current ASU system does not have like flexible scheduling, student relationship management, and self-service enhancements. However it would not be finely tuned to ASU business processes and vice versa so it will be different. That takes time – look at the last 25 years for the existing SIS. It will be change.

If a new ERP is installed there is an effect called the ERP acceptance curve and it is very similar to what you show here except the y-axis is the level of acceptance instead of functionality. Not every one suffers the level of acceptance decline when a new ERP is alive but enough people do that is a very real effect. Whether you call it less functionality or less acceptance it is a problem. One of the roles of the implementation team is to shorten the depth and time of the curve. It needs to be more than saying “they just don’t like change” or “they didn’t implement all the features”. There are practices that can flatten the curve [like building the monster in the middle of the village] but it will never entirely go away.

I just want to put a slightly different label on it.

Max

oasis blog » Blog Archive » It’s ALIVE! August 20, 2006 at 4:52 PM  

[...] Remember Adrian’s post almost a year ago to the day - The Parable of Frankenstein.  I do!  It was and is a great story.  We are now building the monster in the center of the village (actually the center of Computing Commons Building) and the heart has started to beat and brain waves are flowing.   It is a monster only because some of us do not know it yet and that makes it somewhat itimidating.   This will all change soon.    [...]