Wednesday, August 24, 2005

You Say You Want a Revolution...Well, you know...

I love music... Really.... Love it. I'm a frustrated guitar player; I like to sing; I'm an eclectic fan of all kinds of different stuff, from Blues to Bluegrass, from Mozart to Phillip Glass. But my mainstay is the music that now goes by the name of "Classic Rock". The Beatles. The Who. Dylan. James Taylor. Crosby, Stills, Nash and "not-so-much-anymore" Young. All the usual suspects...

A lot of times pieces of these songs get stuck in my head and I can't get them out. I sing them while I'm out walking around campus (which might account for the extra "personal space" I seem to get?) Anyway, I've learned over the years to listen to those snippets, because sometimes it’s my subconscious trying to tell me something.

The past few days the internal tape loop has been running fragments of a real classic, Revolution by the Beatles -- John Lennon style.

Everybody in the Western Hemisphere knows this one by now: audio snippet

You say you want a revolution… Well you know…we all want to change the world
You tell me that it's evolution… Well you know… we all want to change the world

Revolution is a conversation about change. The unheard participant in the dialog is calling for something radical -- full of frustration about the present and passion for the future (leaving aside all that "talk about destruction" for now). The singer, on the other hand, has heard it all before. I imagine he also had a hand in the lyrics to the Who's Won't Get Fooled Again.

Well, you know...
The song's message is all in the "Well, you know's". Hey, we've all been there. After working time and again to make a positive change, all the while struggling to keep the old way running -- warts and all -- a person can just get tired after a while. Then some new guy comes along talking about the future -- without the veteran's scars -- well it can feel a little like the same old record.

One of the hardest things to do is undertake significant change while maintaining existing operations. Imagine what it must be like at Kodak.
In an effort to survive in the new economy, some industrial giants have tried to chart an evolutionary path that combines their industrial core with new post-industrial businesses. ...
Kodak is ... attempting to reinvent itself... through ... digital cameras and digital printing...trying to transform itself from "film dinosaur to digital powerhouse." ... [But] By pushing digital cameras, Kodak will in effect be hurting parts of its traditional business...

All your resources are pointed firmly toward making film, improving film, marketing film, selling film. Running a lean operation, you don't have one person to spare. You see a disruptive technology coming a mile away (Kodak began experimenting with digital cameras in the 1960's) and know that to adapt you will need to develop a whole new business, with new technologies, partners, distribution mechanisms and margins, all the while keeping the existing business not only alive but growing. Meanwhile, your competitors -- new entrants into the photography business -- get to skip the film stage entirely and go straight to digital. But your stockholders, your employees, your customers, all of them have you LOCKED INTO making film. You can't just give up on it and try something new. To survive, you have to do both, making the problem that much harder. Yike!

It isn't that people don't believe in change. They do believe. They believe passionately, and have often poured energy for years into trying to bring it about. But the trickiest part can sometimes be getting their organization in position to accomplish needed changes while keeping the wheels turning. And since you usually can’t let the wheels come to a halt, even for a second, it can seem like change will never come.

No wonder people grow skeptical.

You say you’ve got a real solution…well you know…we'd all love to see the plan
Well, I haven't got the plan. Not yet anyway. If you've been following the blog though, I think you can see where my bias is running. At the moment, to address ASU’s legacy backend troubles, I favor a continuous process improvement approach over a wholesale rewrite.

A CPI plan would:

  • continue to improve existing self-service, web-based systems connected to legacy systems through screen scrapers and other ‘ugly hacks’,

  • bring additional self-service, web-based systems on-line using legacy system access mechanisms,

  • develop, where possible, companion, stop-gap, “bag on the side systems” to accommodate things which cannot be implemented in the legacy systems,

Think ResLife, but aggressively and broadly pursued. Letting the legacy IDMS continue to manage the "statically scheduled" courses, while handling the 10% of courses that require flexible scheduling through an institutionalized, centralized Continuity with access to the SIS. Not these solutions exactly, necessarily. The exact hacks I leave to the experts. But I think you get the idea.

Hope you’re still reading. Don’t think I don’t know how many peoples' blood I just made run cold. But wait…there’s more. At the same time, I’d want us to pursue a strategy of replacing, incrementally, from below, the legacy systems that the continuously improving portal is built upon. Not so much rewiring or replumbing as “re-foundationing” the house, while we live in it.

Continue to suspend disbelief for just a second more. The last piece of my pipe dream is that the CPI project to enhance the portal will serve as an agile form of business process re-engineering. As the portal services expand, improve and integrate, they will define -- through the middleware layer that connects them to the legacy systems -- a specification that will drive the configuration of the systems chosen to replace the legacy stores.

In short, I favor surgery over monster building. Always have, particularly when the patient is more or less healthy to begin with. Unlike monster building, in surgery, the patient stays alive during the procedure; we use as little anesthesia as possible, so most of their systems continue to function most of the time.

Is surgery more difficult to plan? No question.
Does surgery take longer? All told, it probably does.
Does surgery cost more? It might, after all is said and done.

Is it possible that this so-called surgery is really like the “ColdStone Creamery Diet Plan” (you know where you eat at CSC every night and still lose weight) -- too good to be true? Yeah, that’s possible too.

But when you talk about destruction, don’t you know that you can count me out…
“So…”, you ask, “if its harder to plan, might take longer, might cost more, and may well be impossible, tell us again why it is that you favor it?”

Well, here’s what I like about it. With a CPI plan,

  • the system continues to improve, month over month, year over year. That’s easier for the "wide" people to sign up for;

  • the business units get a stream of things they can use starting now and continuing for years, instead of waiting for several years with nothing;

  • the initial outlays of cash required to begin are smaller;

  • the process of development is more gradual, lowering the risk;

  • the backend replacements occur in smaller chunks, further lowering the risk;

  • we get the opportunity to experience the functionality and improve it incrementally.

A CPI strategy would allow us to aim for the goal of amazondotcomification right now. It would allow us to:

  • put a cross-unit portal team in place to develop needed tools and standards,

  • use those standards and tools to integrate ASU Interactive cleanly into (how come it isn't's with the extra dot?) where they belong;

  • create a bunch more self-service web services and integrate them into the portal too;

  • integrate the work AFIT is doing with Vignette;

  • hide/encapsulate more of the complexity of our legacy systems;

  • integrate university wide document management and workflow into the portal.

A CPI strategy isn't necessarily all "roll your own" either. It probably would entail the use of vendor supplied modules -- for SIS, for HR, for document management, for workflow, for Financials. But a CPI plan won’t freeze improvement for 36 months or more.

My thin slice tells me everyone’s ultimate goal is more or less the same -- as a unified portal for the affiliated (students, prospective students, applicants, alumni, sports fans, faculty, staff, donors, friends). providing “insider access”, much like once you have an account. A tool that provides administrators with the information necessary to run the place. And not just info, but self-service tools too, for staff, students, everyone…all of it integrated and clean.

For me, the goal is an integrated information system that is so cool that when someone tells you they went to ASU today it comes to mean the same thing as someone saying they went to Bricks and mortar won't even come to mind. A portal that makes real the promise of "One University in Many Places"; that is capable of seamlessly supporting 100,000 off-campus students and another 100,000 on.

That’s what we all want. And we all know that we need to get started now. But a standard ERP implementation won’t help some of our units fast enough. They can't wait. That's why I'm leaning the direction I am.

You ask me for a contribution…well you know…we’re all doing what we can…
Churchill once told his cabinet, and his people, he had nothing to offer but blood, toil, tears….and sweat. He must have lived in Arizona.

A reasonable question is: "Where are the resources going to come from? If we assume that everyone is already doing the highest priority thing that they can possibly be doing and doing that thing in the most efficient way possible, then any improvement will be a pretty tall order -- more of that ColdStone Creamery nonsense.

So we'll have to challenge that assumption and find ways to improve. We're going to have to spend some money. And we’re going to have to find some things to stop doing. We’re going to have to replicate, on a larger scale, some things we know work but that we haven’t done enough of. We'll need to take some risks and succeed at them. We’re going to have to get better at doing some things that we know how to do, but not efficiently enough. Throw in a dash of economy of scale, some help from outside, and some more effective leveraging of the technical strength and business knowledge that resides outside of IT, to improve our coordination.

And most of all, we'll need some real innovation, some truly excellent, original, practical ideas.

Don’t you know its gonna be all right…
The debate is good. From the debate, the right answers will come. Looking forward to hearing from you.


pacifictoy August 25, 2005 at 7:23 AM  

Considering the previous case studies (*btw, how do you put a hyperlink in a comment?*), in which many universities spent millions to get ... NOTHING, and then spent more for lawsuits, the iterative development approach is a good approach.

Although it will take longer and cost more, it'll have a much better ROI (>0). Consider it as the insurance fee against failure.

Plus it's always good to have a smaller set of the system to work right away to provide a continuous cashflow.

Instead of a coup d'etat revolution, this is the guerilla strategy.

Adrian,  August 26, 2005 at 5:58 AM  

Use html...for example, to put in a link to, type this in the body of the comment...

< a href="" < < /a >

Nancy August 26, 2005 at 8:05 AM  

I’ve read this through a few times but am failing to see the “Revolution” aspect. Isn't CPI (“Continuous Process Improvement”) exactly what we’ve been doing for the last several years? Since Y2K, our department’s efforts have been bent on providing as many new services as possible while keeping the old ones running. This has been accomplished with diminishing experienced staff and a severely lagging payscale relative to local industry norms.

I think, rather than making our blood run cold, the statements here put our hearts in our shoes. I do find a glimmer of hope (within a shadow of despair) in this statement:

“The last piece of my pipe dream is that the CPI project to enhance the portal will serve as an agile form of business process re-engineering. As the portal services expand, improve and integrate, they will define — through the middleware layer that connects them to the legacy systems — a specification that will drive the configuration of the systems chosen to replace the legacy stores.”

For those not familiar with “agile” software development, check out link. They talk about valuing:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Items 2 and 4 put my heart LOWER than my shoes. Seems to me those things are precisely where IT has failed in the past. But if IBM thinks well enough of “agile” processes to publish Developerworks articles ( about making them work, I’m open to learning about it. (Please don’t anyone think I’m a died-in-the-wool IBM fan. But I do think they/it strive to balance traditional long-term business cautiousness with innovation.)

I caught a glimmer of hope from the statement “As … services expand, improve and integrate, they will define — through the middleware layer that connects them to the legacy systems — a specification that will drive the configuration of the systems chosen to replace the legacy stores.” Does this mean we can use resources to build an evolutionary but authoritative business model? I hope so.


Jon August 26, 2005 at 9:02 AM  

So…we make small changes gradually, until we have both the updated working system we wanted in the first place, plus ASU’s current business practices changed.

It would appear that with this in mind, that you’re asking ASU’s IT Department to “create a black box” from the current system, allowing a foundational swap out to take place, without disrupting the current data flow.

This would allow several possibilities:
1. Swap ANY vendor DB solution in place while still using familiar interfaces.
2. Reduced learning curve for current Staff/Faculty, etc.
3. Greater chance of buy in due to the lesser impact on Departments across the University.
4. Gradual changes to add new functionality to the currently working interface.

1. Is it possible to encapsulate the front-end in our current system?
2. If we abstract from the back-end, will we have to maintain and update the front-end each time the Vendor makes corrections/enhancements to the back-end? Case in point would be NAU’s initial implementation of PeopleSoft (talk to Max).
3. Can our current business model adapt to these changes or must we abandon them?

Radical change sometimes requires that we forget the past and embrace the future. Can we react positively to this, embrace and strive towards this, as a requirement of becoming the “Great American University”?

You say you got a real solution Well, you know We'd all love to see the plan

mcarleno August 26, 2005 at 5:34 PM  

Information technology is a path we follow not a destination in itself. Tools and systems that are open and provide best-in-class functionality are often specifically designed as evolutionary; tools and systems that provide functionality that enhances the current legacy technology without being tied to it.

Islands of automation -- that connect to the world that manages our information. These connections to open systems allow for that evolutionary approach. Seldom in this industry are those systems that offer everything -- the revolution -- best for our objectives, our destination. Expensive, compromising and lengthy such that the world has changed by the time we have finished building our view of it.

The open system approach of automation provides attachment through standards to legacy systems and provides incremental improvements through automation and integration. But since these systems are not directly tied to a proprietary approach of "managing everything" they provide flexibility to leverage cost-effective, tool-using approaches to solve complex business issues. Open standards allow for connectivity and extensibility but are not tied to legacy systems -- just because one system may change doesn't mean that all should. These "Baby Steps" to improvement overtime, like the tortoise slow and steady, offer the best chance of improving processes, reducing costs, and implementing now rather than latter -- we owe this to all of our stakeholders especially our customers.

mdj44,  August 29, 2005 at 4:22 AM  

The answer to Jon's second question above is - It depends. From an overall standpoint vendor corrections/enhancements will not cause similar corrections/enhancements to the front-end. It will require testing to make sure that vendor changes are not intrusive however. Minimizing the impact of vendor corrections/enhancements is a design consideration in developing channels for the front-end.


Ron,  August 29, 2005 at 7:18 AM  

The part about “Revolution” that I’m not getting is how do we eventually replace the outdated infrastructure (Mainframe/COBOL/IDMS/Patched-on design)? Arm chair analysis tells me that “front end first” is the most expensive approach. What is the advantage? No matter how it is sliced, our customers have to put up with change.

After doing incremental improvement for many years, most ASU/IT folks are thinking that CPI with the current infrastructure is becoming too difficult and is certainly not a cost-effective alternative for a long term strategy. I understand that IT does not have optimal processes, but incremental improvement there does not yield the exponential improvement in results that many believe are required.

I totally get WHY we want to do CPI – the natives get restless if we go off into a vacuum to create a whole new system. So, why not start the infrastructure replacement now, AND continue with improvements on our current SIS (while we still can). Because of the outdated infrastructure, we are getting decreasing returns on our software development investment; not to mention that key individuals propping up our current infrastructure are nearing retirement and the workforce is not teeming with suitable replacements. But, if we can’t afford to buy a new system today (or start in-house development), we should institutionally agree on when we can afford it (which does presuppose that there is agreement that we need it in the first place). Once we have that plan, IT can better plan on what to do with itself in the meantime. BTW, if we can’t afford it now, I’m sure Peoplesoft can put us on the installment plan… maybe we purchase it through the Room Store with no payments and no interest until 2010?

So, what do we do during while we’re waiting for the new system? Well it does depend on how long the interim is and what the end game is. I’m in favor of developing stuff that survives the transition. Writing portlets (or channels) is a good idea. We’ve been doing that, but could do better with a common institutional goal (e.g. get ASU Interactive into the portal). Another would be to replace manual processes that exist right now with workflow automation (e.g. using Vignette). If we’re buying Peoplesoft we would want to work on items we need now and are shortcomings in Peoplesoft. If we’re creating a homegrown system, we’d want to make sure we are building on the comprehensive object model for each application we do from here on out. The point is, once we establish a solid long term direction, we’ll be able to plan the short term much more effectively because we’ll be able to stop worrying about all of the contingencies we have to allow for now.