Monday, August 29, 2005

Check out Max!!!

If you haven't already, read Max's comments on Revolution....Rock on Max!!!

And while checking out Max...check out Rudy,Roger, Jon, Ron, and Nancy!!!

The dialog begins!!!


Nancy August 29, 2005 at 5:16 AM  

Max’s remarks put me in mind of a war story. When I was yet young and spry, I was assigned to be the one and only Programmer Analyst in charge of a computer system written for a sort of client/offshoot of U of I Med Center. Their (unnamed) offices were in Springfield, which meant I got to fly back and forth from Chicago to meet with them. Seemed like quite a gas until I did meet them.

Their system was a nightmare. It had been written by one person who had since left, devolving the job to me, and he had apparently written it to model the user’s business processes accurately. He wouldn’t have had any choice, because the three major areas of the user’s department wouldn’t speak to one another. They did duplicate work because they didn’t trust one another to handle the work correctly. The way the system was written, several people had full-time jobs entering data into the (very cool at the time) Model204 database, and what did they get out of it? Like, one report. Tons and tons of data getting dropped in there, indexed 40 ways from heaven, and almost nothing out of it. This was not really the programmer’s fault.

But when I met with a table-full of the area reps, they were frothingly angry at all the pointless effort, and they wanted some results back, fast. Due to the emotional intensity, it took a little while to realize how the current form of their computer system had evolved. The division was a sort of Mom-n-Pop shop, created and run by just “Pop”, and he benevolently allowed his organizational areas to sort of create themselves, and permitted the kinds of personal ownership (and silo-ing) of tasks and information that led to a real hell of a mess in the database. The office workflow made NO sense, as I recall; there were duplications and flowbacks. But the programmer (me and the other guy) were powerless to change those kinds of things. So my job was merely to try to eke out some more useful information, to make all the hours of data entry worthwhile, and correct data corruption as it (frequently) occurred.

Please don’t think I’m saying we at ASU are just a “Pop” shop, because I’m not. We’re far more sophisticated than that. But I think our silos, ownership issues and duplication of data and effort need evaluation, per Max’s note. Our future success will depend on ironing out some organizational wrinkles.


PS: Love love LOVE the diagram.

Roger,  August 29, 2005 at 8:36 AM  

Wow! This is some heavy, but interesting dialog that has been initiated on Adrian's blog.

While I agree that we have been doing continuous improvement for several years, it is not as unified and systematic as it needs to be. We lack a set of common standards that need to be followed by ALL developers, regardless of whether they work for the central or a distributed IT shop. As Data Administration has shown us, there are several data sources that could be patched together to get the desired results. The same data can be obtained through the enterprise by using SISREP, Data Warehouse, Affiliate, Directory Services and other data stores. God only knows what the diagram would look like if we included all of the distributed "shadow" systems that store name, address and other data on current students.

If we are to follow Adrian's CPI approach, I believe that central IT needs to encapsulate the inner system and provide a set of common database and business rule objects for all developers need to use and adhere to. This would serve several purposes: 1) Ensure consistency between applications; 2) Minimize the redundancy of data; 3) Provide a set of tools that can enable a developer to ramp up and become productive faster; 4) Lessens our dependence on the legacy SIS... how?

The CPI approach we are currently following perpetuates our dependence on the legacy SIS. We have several applications being built independently, all using a different data source and methodology. A CPI approach built on a set of common objects that can be swapped out would significantly lessen the dependence on our legacy SIS. Also, to unify as many of these apps together into the myASU portal would provide a great service to the university community.

Ultimately, an ERP is the direction that I think we need to move in. This will force standards and get all departments operating on the same page. However, if ASU as an enterprise is not ready, for whatever reason, to embrace a full blown ERP implementation, Adrian's approach offers the next best thing. In fact, it too may be perceived of as being a revolution.

One other comment... we have a lot of disparate 3rd party products being acquired and used in the enterprise. At the scope of a shrink wrapped desktop piece of software, not a problem. However, when we start talking products like Vignette, EMC/Documentum, Verity's Teleform or LiquidOffice, I hope we can find better ways of collaborating and sharing to acheive an economy of scale and standardization for the university.

My 2 cents worth.

BLS,  August 30, 2005 at 6:12 AM  

If you don’t know history you’re doomed to repeat it…continuous process improvement…takin’ about a revolution (different revolution song)…and of course “closing the gap” are all good starting points.

At what point are our challenges IT (technology advances, structure, design) focused vs. policy or political challenges? Of course there are always financial challenges.

For example, just because Extended Ed wants to have a continuous/open enrollment system for the “anytime, anywhere” student that can handle different tuition calculations and have a dynamic portal and IT can build that system (in whatever flavor application that’s appropriate)…aren’t there other systems/processes/rules that have to be taken into consideration? Admissions deadlines, Student Health policies, Registration time frames, Tuition Payment deadlines and refund policies…as well as reporting deadlines, fund transfers…If we have a system that will allow a department to create a class that starts on October 1st and a student can access a portal that will allow them to get admitted/register/pay tuition on September 30th. What policies could prevent this from happening?

Putting the cart before the horse? What is the cart, what is the horse and who is driving? When does policy dictate what can change and when does administration? Maybe this is not the right place to ask these questions?

iacnld,  August 30, 2005 at 6:36 AM  

Hum.. Roger brings up the old "Shadow" systems terminology.... I've heard that quite often and wonder.... How come when they are in a small department they are called "shadow" and when they are within an IT organization they are called "replicated?" And blog watchers... yes Data Admin wants to know about shadow/replicated databases too.... but maybe not down to the level of MS Access databases just yet. That WOULD be mind blowing!
Nancy D.

kathyb,  August 31, 2005 at 6:33 AM  

Adrian, I posted this on Monday, but Nancy Lee says it doesn't look like it made it so she suggested I try again. New blog user problems I guess). Here are my comments from Monday.

As one of the SIS Application System Analysts for the past 16 years (yikes!), I took the liberty of letting the “keeper” of the ASU Data Stores diagram know about some updates I believe need to be made. The updates included changing some arrows and adding some information about data input.

A couple of observations after studying the ASU Data Stores diagram.
• There are at least six different database platforms – IDMS, Sybase, DB2 mainframe, DB2 UDB, Oracle, plus some proprietary ones.

• “Basic” student data (ID’s, names, student type) has been replicated in at least twelve different databases, probably more depending on how one defines basic student data. Actually, some are replications of replications (the data is pulled from SISREP).

No database and/or application is created without answering some basic questions – is this the best solution, does it fit into the future of ASU’s technology goals, does it meet the need of the department/college, and unfortunately often the driving force, can it be completed in the allotted time? For a number of years we have recognized that IDMS was not moving into futuristic development (it wasn’t beaming up with Scotty) and that someday it would have to be replaced. At different times, different database platforms were used, thinking this latest or greatest would be the one to replace IDMS at ASU.

Now that we see this visual picture of where we are, well it’s just downright scary, isn’t it? How many DBA’s are necessary to support this picture? How many skill sets for programmers/developers are needed? How many different licenses are needed and how many dollars are needlessly used to support this habit I’ll call “my data, my way”.

Here’s an idea that’s been around for a while; perhaps it’s time to take some action on it. Even if a new SIS is in the immediate future, our replicated data should be simplified by at least putting it all on one platform and using a uniform set of tools to access it. Just by doing that, we would cut down on the number of skill sets needed, allowing DBA’s and analysts to work on truly latest and greatest needs of the university instead of putting out perceived fires while watching real hurricanes blow by.

Rick September 1, 2005 at 4:15 AM  

I believe that there are a lot of demands for "shadow" databases of student (and other) data. I agree that it's a habit ("my data, my way"), but is it a big waste of resources? It's obvious why it happens, isn't it? Departments can't get the response time from developers in central IT, so they ask local junior developers (student workers, sometimes?) to build something that will allow them to do their work. From the outside, there's no direct connection with the true host systems, so instead we all join local data with replicants or shadows or warehouses. This leads to hybrid applications and local databases, which over time become the essential work tools for the department.

It seems to me that parallelism is the problem, as much as anything else. How many colleges have databases that hold information about faculty publications? How many departments have Web sites that have some kind of survey functionality, or a map of "how to get to our office"? These things are all being built on separate development platforms by people with greatly divergent skills, often with little awareness that other offices have gone through the process (or ARE IN the process). I am very much in favor of collaborative work and in sharing knowledge and wisdom among peers, and I wish often that there was an appropriate medium for doing this. I don't know how you can "broadcast" (or "localcast") a message that you are about to begin work on some assignment, where others could jump in and say "Wait! We've just done that! Here's what we learned!" Is this a user-group system? If so, can it be envigorated and enthused?

Nancy -- Thanks for the extended quotes from that article. It is enlightening!