Rapid prototyping

I love taking an idea… to a prototype and then to a product that millions of people use.”
Susan Wojcicki.

When it comes to starting with an OSS build, I’m a big believer in the benefits of building a rapid prototype in one of the customer’s pre-production* environment.

Most suppliers approach their OSS implementation projects with the production environment firmly entrenched in their thinking as first priority. However, I believe that there is an alternate approach that may appear more indirect but has parallels with the fable of the tortoise and the hare.

Unfortunately, I’ve seen too many projects get stuck at the pre-implementation stage, primarily because stakeholders are fearful of making a decision on something they don’t feel completely comfortable with. Afterall, “the confused mind says no” and if the stakeholder can’t envisage exactly what final solution will look like then they often hold back the implementation rather than championing it.

My alternate suggestion is to not focus on production initially. Large CSPs will generally need a lab environment established before they’ll be approved (by the change management team) to launch a production service. As such, I feel that the effort in building the lab first before focussing on production has many benefits, including:

  1. The lab environment tends to have less change management constraints and less perceived risks for stakeholders
  2. The lab can be set up to be a close simulation of the customer’s production topology, as opposed to a demonstration in a vendor’s demonstration environment
  3. On most OSS projects, people spend too much time discussing and documenting “what if” scenarios. Many what if scenarios can often be easily ruled out through the proof of an actual build, rather than negotiating over the caveats of a theoretical build
  4. Implementers identify build issues in the safety of a lab environment so they can take remedial actions earlier, more safely and easily
  5. The customer (and implementer) can demonstrate functionality to their stakeholders faster, which is important for building momentum and support
  6. The lab environment becomes the perfect sandpit for customer staff to play and learn in, making them more valuable to the implementation team at an earlier stage
  7. Having a live working version provides the opportunity for stakeholders to become familiar, and perhaps excited, with the product
  8. CSPs can get a functionality view of the solution with a smaller initial outlay of time and budget [Note: production builds tend to be far more expensive than lab builds because they are generally higher spec and / or more tightly integrated]. Assuming they are impressed by the demonstrated functionality, there is then less perceived risk to proceed to the larger production investment
  9. I’m sure there are many other examples that you can find

* For those who aren’t familiar with the term “production environment,” large CSPs often have multiple instances of their OSS for different purposes. For example, “production” tends to be the live environment that customers are using on their network. Other environments include pre-production, lab, test, development, training, data migration and so on. The idea is that the different environments need to be isolated from each other because the data sets within them and the interfaces to them have different roles.

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

2 thoughts on “Rapid prototyping

  1. I created an OSS lab for my company before. It was very useful when we did a trial run. but due to re-organization, it was scrapped. I will use your blog to convince management to revive the OSS lab. thanks.

  2. Hi Elver,

    That’s great. I believe that sand-pit environments are where people learn about their OSS, where they can test “what if?” scenarios and where they can innovate. It can’t be done in production environments, so where else can it happen? Perhaps with your vendors – but generally their labs don’t exactly mimic your production situation (eg naming conventions, device types, service types, failover scenarios, etc) so they’re of lesser value. Best of luck with your efforts to convince your management.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.