Why Build a Reference Environment?

If you are selling cars, it is as simple as "why don't we take her out for a spin?" to show off the car.  When talking about changing the way things will work, it's not that simple.  Folks don't just want to see a simple demo.  Oh, they do expect you to make it look simple, but what you focus on can't be the easy stuff. 

For instance, its simple to demonstrate executing a COBOL program via a CICS transaction.  That's core to what our company does.  But  when a customer wants to see things like "interfacing with a scheduler" and "managing our printers" and "how will operators will manage the platform", you have to have something a bit more robust.  Otherwise you end up doing endless proof of concept (POC) projects to move things along.

A reference environment  lets you demonstrate how the end result will look without having to say "I'll get back to you" or "there are a number of ways that might work".   It allows your customer to focus on the "how do I take advantage of this?" versus "will it work?".  Think of it as a pre-fab POC you can use over and over. 

Its why I've been building one for the last few months...(read more here).  Keep this in mind when you try to sell the boss on the idea of turning that COBOL application into the next killer app based on web services and the .NET framework.  He'll be more inclined to consider it if you have an example.