Spent last night working on designing the next components to ITIL solution using SharePoint my team has fielded as a Federal Department. The first module tracked service requests from a catalog of service. These services are higher level than the MOF services than the Microsoft System Center tracks and reports. I had previously passed along to my friends and contacts last year the request to have some form of System Center – SharePoint integration. They managed a first release several months ago; however, I may have to build my own as the level of service abstraction does not match what I’m using. 
Fortunately, System Center uses SQL so using SharePoint 2010’s Business Connectivity Services (BCS) should make the connection easier. The issue is that System Center defined services are servers and application programs. These are the lower level of abstraction than what I use in the ITIL solution fielded. The service catalog I created two years ago has services that are more recognizable to business people. The architectural issue I deferred was creating an operational Configuration Management Data Base (CMDB), thinking Microsoft would eventually move up to the abstraction layers to supporting Service Level Packages (SLPs). I instead created a static model using lists that related all the components into a service level package that defined each advertised service in the catalog. MOSS 2007 was a little under-functioned to support building a truly operational catalog. However, since services are slow changing objects it was a good compromise. With 2010’s enhance capabilities building abstraction levels similar to the abstraction levels I had conceptualized for Activity Directory during my CIO Workbench/Digital Nervous System projects should require less code. Presently I’m evaluating whether to have the catalog an extension of the MOF database and expose it thought BCS or create a separate database that references or has an ETL routine that synchronizes with the MOF database. The later approach while more complicated would provide a more robust solution and isolate it from changes Microsoft makes to MOF over time.
Other enhancements that 2010 has brought, Records Management feature, enables the addition of tracking requests and fulfillment robustly enough to create an invoicing system for chargeback models. The Service Bill of Materials (SBOM) prototype was stripped down to a development LOE estimator only, however, I kept tracking efforts with the original module with the objective of adding that as part of the Order Management model. Behind the scenes the prototype estimates; service creation LOE, capacity requirements and eventually capacity forecasts of inflight SharePoint Service requests. The model is general enough to be able to adapt it to other software environments.
The approach I’ve been taking is similar to what I’ve done with my Intellectual Arbitrage Group applications hosted on Microsoft Office Online Templates: no or limited coding so the solutions are subject to limited revisions as Microsoft evolves its product lines.
Leave a Reply
You must be logged in to post a comment.