Won’t Get Fooled Again – A Story of Productization

Once upon a time, I was part of an organization that was selling application performance management tools. Our company was the leading provider of that market category and the product was clearly one of the top technologies in play. Being part of the competitive and market intelligence group meant that I and my team members were called in to help in competitive situations. I was called into many deals where our prospective customers were saying that they loved our product, but that the higher-ups said that their main enterprise management vendor (in this case IBM) was willing to give us their application performance management toolset for FREE as part of all the other software they were consuming. Needless to say, this was a challenging prospect to convince the senior IT execs at those companies that free was actually more expensive than buying our product. In fact, I put together a “how to sell against free” sales tool for our team. This all played out ten years ago, but the lessons from that experience are directly applicable to many of the challenging choices that IT ops and developers face when selecting tools and especially how they put together the “last mile” around their strategic DevOps and cloud automation purchases. What seems like a fast and inexpensive approach of building integrations (such as do it yourself, or paying professional services consultants to build you something to your exact specifications) are often sub-optimal choices in the medium and long term. When I was managing a large group of IT tooling folks (lots of software DNA in that organization), I promised myself that I won’t get fooled again with a quick and dirty fix for what should be a core competency of the organization – complete automation.

Deploying the Last Mile of your Cloud Automation Solution

What does that mean? So, you have decided to build a private or hybrid cloud. You have decided to purchase the big guy’s software package. In fact, you may have purchased the entire suite of products to solve many of your operational and automation needs. The software has great promise, and is on version X.Y, where X is a pretty big number. There are thousands of customers who use this software. As you have begun deployment, or even discovered in your POC, fully automating the provisioning and deprovisioning process requires identifying and automating all the adjacent tool domains, such as IPAM, backup, network services, configuration automation, antivirus and so on. Being able to automate all of this in a fashion similar to the way your new core product does for cloud automation is key to success. This last mile of automation often can make or break the success of the deployment in the eyes of your customers, the IT staff or the application folks.

Setting Yourself Up for Success

The first success factor was to ensure your complete provisioning (and deprovisioning) is automated. Identifying the key IT processes that need automation and ensuring those integrations and set-up in your cloud automation tool is the second factor for success. These automation frameworks have a variety ways to integrate to third party products. You obviously have a variety of options: do it yourself, have professional services build it for you, or go with a productized solution. Don’t get me wrong, these three options have their pros and cons, and in some cases one approach stands out in a unique way. The point of this blog is to dissect the decision you will make and understand the long-term consequences.

Do It Yourself

Pros: Full control, complete visibility into progress, potential to leverage previous organization IP.

Cons: Can lose the knowledge of how it was built with staffing changes, increasing support and maintenance time requirements, requires time commitment when deployment to next version occurs, limited ability to develop/test/deploy to production changes that are needed.

Professional Services

Pros: Simple one throat to choke for the integration, ability (through a SOW) to get exactly what you want/need with nothing extra), leverage previous customer use cases and best practices.

Cons: Expensive one-off development, new or unanticipated use cases will require change order(s), any maintenance or support for new versions of either the target endpoint or the core automation product will require the purchase of additional services, difficulty in handling change management multiple times during the year.

Productized Solution

Pros: Usually supported on multiple endpoint and platform versions, leverages a greater number of customer use cases, receive normal expected maintenance and support as part of the “20%” support.

Cons: Perceived high cost, tied to vendor release cycles, one-off feature requests will require “influence”.

The big question is which one does my organization go for. As the title of this blog suggests, don’t get fooled by the allure of any of these options. There are tradeoffs in each approach; I can’t tell you the right one to go with, but personally my preference would be to establish a close relationship with your product vendor and leverage productized solution. Then again, why would I be a #prodmgmt guy and suggest otherwise?