Innovate on the Cheap
Innovation is inextricably linked with the old adage “If at first you don’t succeed, try, and try again!” Great entrepreneurs concur that in order to drive real innovation, corporations must cultivate originality by giving employees the freedom and resources to introduce new ideas, methods and processes.
So I began to wonder, what are some great ways that an enterprise can balance the hard costs and the opportunity costs of fostering innovation with the more practical demands of the balance sheet?
A few weeks ago, I heard James Urquhart talking to a customer about their cloud strategy and he said some things that I thought were very powerful. He was talking about the flexibility of Cisco UCS and how it allowed for inexpensive do-overs. You can buy the hardware and try something on it at small scale. If it shows promise, you can scale it up to meet the full market need. If it doesn’t work, the hardware can quickly be recaptured and repurposed for the next innovation. Repeat, redo, retry, redesign—cost effectively “try, and try again.”
As the conversation went on with the customer, we came to recognize the same benefit of a well-engineered orchestrator as the common point of interaction of all the pieces of IT.
New services in the cloud are more than just building a new VM template or vApp and then cloning it on demand. The move toward ITaaS means bringing in new purpose-built technologies (such as IT chargeback, application configuration management, network flow management, industry-specific compliance reporting, etc.), and integrating them with existing OSS/BSS products you already have (ticketing systems, network monitoring, email, etc.).
How do you choose a new virtual machine image manager? What’s the best hypervisor for your needs, or do you need more than one? How do you avoid vendor lock-in? Should you keep everything on-premises, move to an off-premises service provider, or have some hybrid of the two? What if you need to change your off-premise service provider? If there is any deployed infrastructure or if there are any existing processes where the business and IT interoperate, some of these questions apply even in the case of the ideal “cloud-in-a-box.”
Services are a combination of technologies, policies, and configurations. Implementing and delivering them manually is no longer an option, so automation is now a fourth pillar. A new requirement from the business may require a change in one technology (e.g. new supply-chain management software) and a change in a policy in a different technology (e.g. compliance reporting frequency). Automation is where these interact.
This brings me back to the idea of having a way to retry things inexpensively.
Orchestrators are everywhere, frequently embedded into specific-purpose software. The ability to run tasks in parallel, branch, loop, and so on are table stakes. Most orchestrators, though, are designed focusing on automating the completed process. While the running process is indeed the most important thing, reliability in running them is expected not admired. We designed the Tidal Enterprise Orchestrator with the user-experience in mind. One CIO I spoke to wanted us to integrate with an OSS system built by some in-house technical staff. It had a programmatic interface, so sure, we could do that. However, this hacked-together “system” was going to be replaced within 12 months with a commercial solution. Not only can we make the change to all system-wide processes in less than a day, but we could interoperate with both OSS systems side-by-side if desired to ensure they were working equally before the old one was decommissioned.
How can I replace a step in the middle with little or no impact on the rest of the process? How can I swap out the “execution environment” where a step is actually taking place? After all, the little box or icon in the workflow editor is not where the work takes place, it’s in the RDBMS, hypervisor, network switch, storage management tool, or somewhere else “out there” on the shop floor or internet. How can I try something I’ve never tried before, get to know it, get good at it, and revamp 60-80% of what I did originally once I figure out what I’m doing and how to do it a much better way?
The answers to these questions are essentially the same as the ones to questions mentioned earlier about avoiding vendor lock-in, being able to replace a hypervisor or off-premise cloud provider with minimal rework. If a cloud provider gets acquired, as we’ve seen happen recently, it may suddenly make a lot of sense to move to a different cloud provider, especially if the new owner is an old competitor. The choice of the first service provider will have become a “failure” in the long run, and being able to fail inexpensively at nearly every control point is vital, from vendors to technologies.
Cisco’s approach with Intelligent Automation for Cloud is exactly this. Make the technology easy to stand up and try out. Make incremental changes easy and non-disruptive. Make comprehensive, sweeping changes fast, and maintain the ability to leverage existing investments and working subcomponents for which replacement is not yet cost-effective. Ship canned services and processes to speed initial deployments and show quick success, but allow the customer to modify them for specific needs.
Of course the services can be ordered by the end user from the service catalog. Of course the fulfillment processes run. These are givens. But when you want to modify a fulfillment process, or more importantly add whole new services, how hard is it? Can you try it out, find the holes in the original idea, fail once or twice, and still bring the idea to life for a reasonable cost? Inexpensive mistakes and retries are key to the lifecycle of creation and enhancement of private cloud services.
If you plan to go to Cisco Live ( hash tag #cldc11) in a couple of weeks , please don’t hesitate to stop at our boothTags: