Patrick Stingley

More than a decade ago, I was one of the original authors of the term cloud computing. I had been a network engineer in the 90's and the compute cloud basically did the same thing to available CPU cycles as the telecom cloud did with available bandwidth. The sentence "Cloud computing borrows from the Telecom cloud of the '90s" were my words in the original entry in Wikipedia.

After this I worked with the White House and NIST to define what cloud computing entailed. We developed the NIST definition of cloud computing. I was never pleased with the terms software as a service, platform as a service, and Infrastructure as a Service because there was nothing about these classes of service that was intrinsically related to cloud computing. Any of them could have been delivered from a laptop just as easily as from a cloud computing data center. Nevertheless, the terms remained, so if fell to me as the CTO for the Federal Cloud, to define which services were included in each of these categories. In retrospect, this collection of services would be called a "Service Catalog" using ITIL nomenclature.

As almost any information service can potentially be delivered from the cloud I have continued my work to further refine and expand this Service Catalog.

In my organization of 10,000 people we have 14,000 computers and 865,000 software packages on our network. Even a 1% rate of change on that scale is too much to effectively manage using manual means, so I have been working on a method of cataloging the information gleaned from automated inventory reports.

It turns out that the primary reason information technology investments are made is for the services they perform, so I have used the primary services each performs as the basis for cataloging them. Ideally, a catalogue describes the relationship between items and their categories using the "is-a' relationship. For instance, Microsoft Word "is-a" word processor (the service it provides is "word processing"). It turns out that things like patches and libraries have a different semantic relationship to the categories than the "is-a" relationship. A patch is not a software package, nor does it perform the service of the package it is designed to update. (I understand that patches perform a service, which is to update software, but putting all of the patches into a single category results in a useless category.) Because of these concerns, I have been creating a semantic ontology capable of containing IT investments based on the services they perform while still allowing for different relationships for IT investments that support those investments.