Let's Get This Party Started - A Short Look Back at the Evolution of Configuration Management

The year was 1989, the end of a wildly successful decade.  Too bad I was in college or I would have taken advantage of the 80's to become a mega-zillionaire and build my own Caribbean meditation retreat.  Failing that, at least the 80's produced one of the first successful (but sometimes pejorative) “Stone Soups” of IT,  - The IT Information Library, or ITIL.  ITIL is loosely (and I use the term loosely) a compilation of what we had in the past called SOP’s, Standards and Procedures, Run books, and what have you.  It basically said; you need a help desk (and someone to actually staff it).  You need to know what and where all your stuff is.  You need to try to do something about problems that keep coming up.   Other stuff.



Yeesh.  We need a bunch of books to tell us that?  Didn't we already know all that?  Well, then, why did Data Processing Shops (I'll use some classic, period-accurate, nostalgic terms) still have problems keeping their "onlines" up? 


Turns out, the books left the hard parts up to the readers, for example, how to actually implement anything.  The books, preferring to remain timeless, don’t discuss any technology. 



To the ITIL founders' credit, they did try to show how some of the small organizations within DP (DP = IT) fit together, again loosely.  It was a kind of cartoon version of IT and how its existence was rationalized, linking daily activities with how and why they mattered in a business sense.  To understand the emergence point, why IT evolved, it is helpful to understand what it was like before.  


The CIO of the distant past was a well-understood persona (and often at that time called something like the Data Processing Manager).  He probably owned IBM mainframes.  And boy did IBM know how to sell to this person.  When the IBM salesman showed up at your door, he told you what you were going to buy, you signed the contract, the IBM truck backed up to your data center and unloaded rows of lovely water-cooled DP goodness.



ITIL was brought about and an evolutionary shift in buying behavior and selection criteria took place (this is an extensive topic which cannot be discussed at length here). No longer were CIOs fed a hardware and software plan that they did not really need.  Smaller business had to pay attention to what IT was asking for.  And so the evolution began and businesses got smart and started to ask questions such as:"How much does it cost to keep our Accounting Department running compared to how much it costs to keep our Complaint department running?"  How do I know what to charge back to my users?  “I don’t know” got to be a less and less acceptable answer.  


Despite this, it still wasn't so easy to talk about "process" in IT in those days.  Process??  A curmudgeonly System Programmer might say the "process" is, Mr. MBA, that I yell over my cube wall to the Accounting Programmer or whoever and tell them what to do.  I don’t need a “process”, you’ve got to be kidding me.    No really, this was a pervasive, uncommonly-questioned way of running IT; driven by the dominance of a  polarized selling motion (albeit a very successful one), and an enormous difference in subject matter expertise between the IT providers of the services, and the business who paid for and consumed the services.



The Business Process Engineering Wave of the early 1990's cost many DP managers their jobs.  It cost IT professionals their comfortable, dareisay cushy, jobs as mainframe stewards and forced them (including me!) to re-learn much about IT. Especially, about how to think about and address all those uncomfortable business questions like "What did you do today?" 


So what DID you do today? What are we doing today in this evolutionary shift of how we leverage IT to run our business? Is ITIL really that important or just “Kool-Aid”? Add a comment and let me know your thoughts? To be continued…


Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Jody Roberts is a researcher, author, and customer advocate in the Product Foundation Services (PFS) group in HP Software. Jody has worked ...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.