Moving from Project to Service Focus

I've recently moved from a shared service organization into a customer facing IT group.  It didn't take too long to realize that the customer facing IT group was very project and solution focused.  There was very little Service orientation - that is, once a solution was created it went directly into 'support', which meant keeping the solution up and running and maintained.  Then the team went onto the next project.  The issue with this approach is that there then ends up being little re-use, service improvement, or strategic thinking.  If you wanted a change, you then have to start another project, with all of the associated overhead.  Sometimes a project is just an application and this way of thinking is fine.  However, in many cases, a project leads to a service and should be managed as a service, with a clear service owner, customer boards, roadmap planning, meaningful service metrics, continuous improvement, SLAs, etc.  Below is a model I am proposing as a strategic shift to enable re-use, speed and customer focused services rather than a pure application focus.   Post a comment - would like to hear your thoughts.  

8V Spider - Big Data Assessment Model

I was sitting on a plane a couple of weeks ago and my new boss is going to give a big presentation the following day to help people understand 'big data'. 

Well, everyone talks about the 3 "V"s of big data... Volume, Velocity, Variety.  I remember reading an article about a 4th V - Veracity: http://dsnowondb2.blogspot.com/2012/07/adding-4th-v-to-big-data-veracity.html

If we're going to add 1 V, why not a few more... and while we are at it, let's put it into a model that helps us make some decisions.    So I call this the 8V Spider model for assessing big data projects.
 
Well it turns out that the model only made it to the appendix the following day, but was recently circulated for use in an industry presentation, so I thought I ought to describe it here in case anyone is interested.

So we should all know the Volume, Velocity and Variety elements already.  And if you read Dwaine Snow's article, you'll have a good idea of the Veracity component. 

The trick behind the model was to get the wording right so all of the V's would be at the outer most point of the scale.  So how Valuable is the data - that is, can you really leverage the data as an asset - that is, as if it were currency?  This may of course take some manipulation and analytics to turn raw data into value, but you get the point. 

One might challenge the difference between Variety, Veracity and Variability.  So Variety implies various types of data - structured, unstructured, semi-structured.   Veracity really addresses data quality - if you get the data from facebook or twitter, how good is the quality really?  So now we are left with Variability - is the data standardized - are there industry standards for this type of data that can be used across multiple data sources - ontologies and semantics.  Are there standards for naming compounds and associated attributes, for example?

Visualization is an interesting one - is the data easily visualized - either directly (an image or a chemical structure) or indirectly, through statistical graphical tools?

There is a bit of a debate on whether Viscosity refers greasing the gears of the engine - that is, is the data actionable - can it be used to improve processes?  See http://blog.softwareinsider.org/2012/02/27/mondays-musings-beyond-the-three-vs-of-big-data-viscosity-and-virality/ and http://h30507.www3.hp.com/t5/Around-the-Storage-Block-Blog/The-best-big-data-presentation-I-ve-ever-seen/ba-p/119375  For now, let's assume it refers to actionable.  If you have data that allows you to make decisions because it is trusted, then we are referring to it as viscous.  A bit of a stretch, I now.

There are a number of additional V's out there, but the point isn't how many V's you add to this model, it is the model itself. 

So, as with all good radar / spider web diagrams, you can show the extreme case against other various use cases.  In this model, we have a little data coming at us fast from a a number of different sources (structured, semi-structured, unstructured), but relatively good data quality and standard.  It is of high value and can be readily leveraged in decision making. 

Once you characterize the data in this way, you can begin to create technology solutions to process the data appropriately - e.g. architectural patterns.

More to come.