Design, deliver, and run enterprise blockchain workloads quickly and easily.
Building apps in the cloud doesn't mean you have to live there
In an increasingly digital world, our application and data analytics development needs to become a series of small, experimental steps rather than the large, waterfall projects of the past. The initial impetus for agile development and continuous deployment was its ability to deliver higher quality outcomes.
But digitization forces the issue. Because the technology is moving so quickly, we simply can’t create a functionality specification for something that will be delivered 18 months or two years down the line. Added to that, digitization can change the way customers interact with our products. But we can’t know exactly how customers will want these new interactions to work, so we have to try something, see what customers think, adjust, try again, and so on. It's about taking a series of small, experimental steps.
This new approach to application and data analytics development impacts the platforms on which they run. In the old days, we would go to IT, stick a wet finger in the air, and predict:
- How many users would use our application and the performance strain they would put on the platform
- The countries and industries where the application would be deployed
- The resulting regulatory compliance burden
These predictions were, of course, largely a work of fiction, but they were used to scope and purchase the appropriate compute platform. With the “lots of small, experimental steps” approach, we have no idea how many users we will have—it could be 100 or 1 million. We also don't know which countries or industries will use our application.
Consider this scenario
Imagine you make tractors. You have an idea that you could use digital technology to move from selling tractors to providing a crop management service. You could put an array of sensors (wind speed, moisture, soil pH, soil type, and so on) onto your tractors. You could combine sensor data with weather data and information about the crops your customer has farmed on which fields in the past, apply some data analytics magic (creating field maps, for example), and provide your customers with valuable insights about when to do what to which crops. You could then link this service to a social sharing platform and use deep learning analytics to create insights across all your customers’ data.
While this scenario sounds great in theory, there are many unknowns. Are the sensors accurate and reliable enough? Can you process and transmit the information from them reliably? What data analytics capabilities exist, and can they be used to create field maps and the like? What will farmers, typically a pragmatic bunch working to tight margins, think about all this? You therefore rightly decide to take a series of small experimental steps, starting with a beta program offered to “friendly customers” in Midwestern USA.
You don’t want to commit capital expenditure (CapEx) to this project because you don’t know how much compute power you’ll need. In fact, you don’t even know if your “baby” will succeed. So, like many other customers, you opt to pay for your compute platform as an operating expense (OpEx).
End of story, right? Hardly.
After a few stumbling steps, your so-called baby is a success. You decide to move it out of beta. You offer it to customers throughout the Americas and in Europe. The number of users goes from 40 to 2,000—and the numbers continue to rise. At this point, something very important happens. You and others in the business decide that your baby is no longer a baby. It’s now more like a young adult, one that's important to the future of the company.
Geoffrey Moore is the author of business classics such as Crossing the Chasm and Inside the Tornado. In his latest book, Zone to Win, Moore focuses on this transition from “baby” to “young adult," showing that this transition from “experimental” to “business important” is where failures often occur. He highlights business processes, organizational changes, and resources needed to make this transition successful.
In addition, you need to consider the implications for your compute platform. Back to our agricultural scenario. When our crop management service was an experimental baby, customers didn’t rely on it. They liked using it, but they didn’t base their farming decisions upon it. When we take it out of baby mode, this changes. We need to ensure its availability and performance. We need to ensure that data is backed up and quickly recoverable. As we provide the service in more countries, we will need to adhere to their data sovereignty and security compliance regulations. And although it’s not relevant to our farming application, some industries, like healthcare, also impose significant compliance regulations.
From OpEx back to CapEx
You will remember that when we started out, we bought our compute platform as an operational expense—as OpEx. As we start to increase our customer numbers and as our performance requirements become more predictable, we may decide that we can get better price-performance by owning our own compute resources.
We also need to insulate our so-called young adult from the vagaries of budgeting. We all know how it works. The company goes through a rough patch. Even though our service is growing nicely, a companywide OpEx cut is imposed. Despite customer numbers being good, we are forced to take a little slice from the compute resource we allocate to our service. If, however, we move our platform from OpEx back to CapEx, we can insulate ourselves from these OpEx fluctuations. With CapEx, there is little to no "on-demand" need to spend money, while OpEx budgets can get pounded when an externally facing app becomes successful beyond expectations.
Moore's work shows that the state transition from experimental to business-important is where a lot of babies falter. This key transition also implies a change in requirements for our compute platform. Security requirements get a lot tougher. Data sovereignty regulations kick in. Data backup and recovery must become cast iron. And we must ensure the supply of our compute platform in the face of OpEx fluctuations.
CapEx and OpEx: Lessons for leaders
- Moving to the public cloud isn't a final step.
- Controlling costs becomes a higher priority in an on-demand economy.
- Managing backup, recovery, business continuity, and data security may still require a mix of locations, technologies, and budget expenses.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.