Wednesday, 24 October 2012

Changing Ways... RFP'ing for services rather than technology silos

So… you run a big infrastructure group, you deal with servers, storage, networks, a bunch of different infrastructure software (database, monitoring, cap planning, message bus etc)…. The chances are that when you evaluate different technologies, for functionality or maybe based on a price that you want to chase after –  you will do it by the typical silos / disciplines… (i.e. the fore-mentioned technology silos).

Maybe there is a different approach to this… OK –  so you will never get rid of the core disciplines entirely, but if you were to take a service centric view rather than silo'd view –  you may take a slightly different approach….. Maybe you would look at the various services that you offer within an infrastructure team and decide that there are some that are more mature than others and could benefit from a service RFP (as an example) rather than break it down by its component approaches… Or maybe –  there are some engineering aspects that are just too hard –  and you would rather get someone to take this work-item and do it for you, or maybe there is an appliance based product that could fulfill the service requirement for you….

OK –  so read my previous blogs, and especially the ones based on appliance type technologies –  i think its fair to say that at this point in time, i have a pretty jaded view of functionality –  that is because either (a) the integration job that has been done by the vendor is pretty rubbish and you end up polishing a turd or (b) there is only the core infrastructure that has offered (i.e. x86 h/w, hypervisor, storage) and no inclusion of the software layer that is required to offer service –  but hey, im probably talking about vendors that manufacture and not those that offer integration services…. Its also worthy of note that you may get a consortium of vendors bidding for a given piece of work (as an example and not me backing anyone –  HP ,EMC, Microsoft may bid for a SQL service stack)

Pretty quickly you get to the point of discussing which services could you offer out, where you know clear requirements and you would be happy to say “Hey vendors, respond to an RFP for a given service stack that i may engineer and support… and give me some price and options

Next step – what are these service stacks we could articulate (and we have a mature enough handling of these services and can articulate clear requirements) and get vendors responding too.. so lets break them down to core services rather than technology silos…. here is my starter for ten…

  • WEB services
  • File Transfer services
  • Database Services
  • Message bus services
  • Mainframe services
  • Network services

these are some of the service items that believe are mature enough to take this approach at this point of time –  you will notice i have left out items such as directory services, name services etc –  this is based on the fact that there are elements of security and business logic / layout that might just make it too hard…

So once you get to a place where you decide which services you may look into –  you are then into deciding which of the sub-categories you may chase after… For this example –  I'm going to pick on database…. lets go for a Microsoft SQL stack (one that is pretty mature)…. Its well known, predictable, its a mature tech, there is lots of expertise and its a service offering that you can well define.. We know the stack, Hardware, Storage, Operating system (windows), high availability and then the MS SQL product layered… Metrics and service definitions are relatively easy to formulate –  Why wouldn't you work at this level?

Anyhow –  its a different view of taking technology requirements to market, and i am also sure its been done by a bunch of people already…. times a'changing…

Final thoughts –  if you are going to use this approach –  think about the *measuring sticks* you would use to judge responses and ensure that you are defining services appropriately. Don't go for panacea options, work with “good enough is good enough…” –  you might just end up saving some more cash along the way and delivering real business benefit at the right price (lts face it –  the business would much rather make money than keep us techie nerds in work!)

Night all!

No comments:

Post a Comment