“According to a new IDC Spending Guide, worldwide spending on the Internet of Things (IoT) will grow at a 17.0% compound annual growth rate (CAGR) from $698.6 billion in 2015 to nearly $1.3 trillion in 2019.”
That new role has less to do with managing disparate bits of infrastructure and more to do with selecting the best infrastructure strategy to provide a specific service. The toolbox they can select from includes on-premise or colocation data centers and cloud – private, public, or hybrid, on-prem or outsourced.
For as long as cloud has been around, the idea of a “cloud broker” has existed. For awhile, it meant software (or an “as a Service”) acting as a marketplace, like an App Store, that people would select IT services from.
It also can mean a market where you are continually buying the cheapest price, sort of arbitraging between the ever lowering costs of public clouds, some how magically loving workloads cheaply and quickly enough between these clouds to save money and time. You’ll hear people say “bursting” a lot here.
Of late I’ve noticed a more normal definition: the act of the IT department serving as a curator, service provider, and accountant for cloud services from vendors. I mean, that’s a large part of what IT has done all along, so it makes sense.
“The role of IT is shifting to become an intermediary between the customer and the data center and the service provider,” Bittman, a Gartner VP and distinguished analyst, said. “The service provider might be you, but it might be Google, or it might be Salesforce. It comes down to delegating responsibility.”
Today, digital business capabilities drive 18 percent of enterprise revenue, Raymond Paquet, a managing VP at Gartner, said. The analysts expect that portion to grow to 25 percent in two years and more than double by 2020, reaching 41 percent.
This led middle managers to over promise and under deliver. One middle manager told us that “you can get resources by promising something earlier, or promising a lot. It’s sales work.” This was made worse by the lack of technical competence among top managers, which influenced how they could assess technological limitations during goal setting.
As one middle manager pointed out to us, at Apple the top managers are engineers. “We make everything into a business case and use figures to prove what’s good, whereas Apple is engineer-driven.” Top managers acknowledged to us that “there was no real software competence in the top management team”.
Who knows if that notion about Apple is true or if it causes their success. The broader point of needing to understand the unpredictable nature of software is still important. As more organizations start using and making custom written software (if only to make mobile “store fronts” to their business), knowledge of the chaotic nature of software development needs to spread more beyond IT. Even IT people get it dreadfully wrong often.
So far the best tactic we have is to redefine what “success is”: it’s not delivering everything you promised on time, but being predictable about delivering something on regular intervals. That’s a vague way of saying delivering smaller batches of code into production more often. We sort of predict/hope that this results in more useful, better software overall. We’ll see.
Now, of course, part of this process is being honest about reality. The analysis of Nokia’s failures because “management” would not accept “real talk” from their employees will kill any innovation-driven business. As the company (and RIM and countless others) shows: tech companies are never so secure that they can afford to be confident in their market position.
I’ve been working on a series of blog posts on “the cloud native journey.” I put that in quotes because it’s admittedly a cheesy marketing phrase. The point of it is: if you’re looking to start using all these new cloud-based ideas for improving how your company does custom software development, what’s that look like. You know, what’s the “journey.”
At container-oriented conferences, whenever a vendor or an open source contributor demonstrates the ease with which developers deploy containers to production, usually there are cheers. But in large enterprises, especially those that maintain strict compliance guidelines, it’s IT that makes the decisions about what gets moved from development to production, and how it is done.
This is what you might call the anti-RedMonk stance. In reality, nothing is as cut and dry as developers XOR operators being king. I’ve been in many strategy discussions over the past 5 years where the people involved would love for just one of them to be rulers of the roost. It’s make setting strategy so much easier than catering to both.
In my experience, it’s more like this: developers have a tremendous amount of influence and devilish-steering over long-term IT department purchases, while IT people control the gates and money.
Developers can also just subvert IT and totally ignore them. You get speed and flexiblity, but the trade-off is inefficiencies in the long-term: everyone is doing something slightly different so there’s no economies of scale with respect to knowledge, culture, or costs. (There’s a loop-hole where you all decide, for example, to run on AWS and “bottoms-up” decide to start collaborating and “work together” and all that – I’m not sure that pans out in donkey-land without a lot of centralized change management, though see below on DevOps.)
Operators can set orginization wide standards but have to “force” developers to follow their dictates. So, if you want orginization-wide standardization and “someone else” to pay the bill and help run it, you have to go through IT. Here, you have ultimate control and “governance”, but you sacrifice flexiblity and speed. (There’s a loop-hole here where IT establishes a centralized “cloud platform” [to use my work’s parlance] and lets the developers do whatever they want in the confines/contract on that box/platform.)
Of course, many of us have been trying to reuinite this “house divided” for several years, cf. DevOps. Hopefully that’ll pan out because what we really need are both those functions working together to not build boxes or subvert corporate best practices, but to focus on building good products and IT services. Good luck!
Innovation in the container industry, the old school containers:
Our legacy way of doing business would be to send officers out to containers, container ships and they would go along with printed sheets and check lists, and they would look at manifests and they’d write the numbers down and count what’s in the actual containers themselves, and they’d make all their notes and they would do that all day long. Then they would go into the office at the end of the day and log in to an application and start entering all that data. When all of that was done, they’d click a release button to release a container and then move onto the next container. When you deal in a world of just-in-time delivery, that can be really problematic to our partners, because Dell is looking for those parts that just came in on that container ship from Europe; they can’t wait for us to clear it two or three days later.
So what we did is, our targeting analytical systems program office worked with our cargo program office to create a mobile app that would actually allow an officer to go out and data-enter that stuff in the field on the mobile device and then click the release button while still on the ship. So, a couple of things: They can use barcode scanners to get a lot of that information so it reduces the data entry, increasing the officers’ efficiency while also increasing their ability to live release cargo containers as they walk down from container to container on the ship. So that is transformative. Just a completely different way of doing business — far more accurate, far more efficient for the officers and a far better use of their time than having them sit at a terminal typing all that data in when they are tired at end of their shift.
I had lunch with Israel Gat yesterday. Lobster bisque in a sourdough bread bowl, to answer your first question. We were talking about the concept of a “software defined business” (and I was complaining about how HEB needs more of that, if only to get digital Buddy Bucks).
Well, over the next 3 years, I think much of the marketing efforts in tech will converge on exactly that. This is what tech companies will try to sell and the “thought lordship” they’ll try to deploy into the market. I think it’ll actually be to the tremendous benefit of customers, not just a hustle. Soon the egg will become a chicken, and the chicken will start making demands on the egg. Which one is egg and chicken? Indeed! One can never tell the causation directionality in these things.)
Why will tech companies focus on software defined businesses as a growth driver? Well, it’s kind of the only area for growth, at least interesting growth. Keep in mind that if you’re a big, publicly traded company, you have to grow, you need to find new money sources. Last year’s revenue can’t just sit there, staying stable. Otherwise you’re toast because investors will want to allocate their money in companies that are growing, not shrinking (they’ll dump your stock, and but another). This is true for any business, but very true for technology companies.
Here’s my rough sense of revenue streams tech companies will have:
1. Consumer churn.
You know, you get a new mobile phone ever 2-3 years. Instead of subscribing to a cable package, you subscribe to HBO Go. (You sort of end up paying the same amount, but who’s paying that close of attention when there’s so new Game of Thrones episodes to watch?) You buy subscription services. Games.
Basically, the “not enterprise” market. This is what most tech press covers and talks about; it’s (sadly?) what we think of as “tech” now.
There’s growth in here, but it’s a totally different space than traditional, let alone “enterprise” tech. Microsoft finally seems to have figured this out, but meanwhile Apple, Google, and Facebook are gobbling up all the revenue and growth…not to mention all the new companies that have come along.
2. How much more ERP can there be?
Businesses still need a lot of software, but I’d argue that “systems of record” are probably well saturated at this point and low growth. This used to be the fuel of the tech sector, but if everyone has a system of record in place…how much more more spend can there be there each year? (I’m sure we could look up some IDC or Gartner numbers about single digit growth in these markets.) Not much. One area of interest is shifting over to SaaS, or:
3. Rip-n-replace cloud.
“Well, I guess I need to replace all this ‘legacy’ stuff with cloud.” You know in storage, compute, and maybe networking. There’s lots of hardware and infrastructure software churn here. In the software category, I’d put migrating your on-premises ERP/systems of record stuff to SaaS here as well: moving to Salesforce, Successfactors, etc. In a squishy analogy, things like Adobe transforming from licensed sales to subscription sales.
This is a long term play with lots of cash; for businesses though: do they end up with anything net-new? Have you actually tried to use Salesforce? It removes the hassle of having the manage your own CRM instance, but you still have to manage how your company uses the application…otherwise it’s baffling what’s going on in there. My point is: the company ends up kind of back where it was before the great rip-n-replace, just more optimized IT, with hopefully HTML5 and native mobile apps instead of Flex.
There’s lots of “drag” (secondary spending) that gets to #3 above: you know, you’re gonna need a platform for all that stuff, and the hardware and services around it…but instead of just ending up with the same IT-driven capabilities, you’ll have new capabilities in your business.
So, if you’re a tech company, and you’re looking at the 4 sources of cash and growth above, the fourth option looks pretty good. #1 means competing with Apple, Google, and Facebook and then a dog’s breakfast of lower margin goods below the UI layer. #2 and #3 are good, known quantaties, but probably with single-digit growth, if not tricky waters to traverse in the lower cloud infrastructure layers.
Then you look at the other option: a wide open field of possibilities where you “go up the elevator” and avoid the Morlocks. Large tech companies have to do all of these, of course, but I suspect you’ll see most of the razzle-dazzle spread on the fourth.
A typical approach to digitalization in this scenario is to have a nurse carry an electronic tablet rather than a clipboard with papers, and use the tablet to enter data directly into the EHR system while conducting the rest of the process the same way as before. While “mobile-enabling” the process adds a few new benefits (more accurate data available more quickly), it does not present a fundamental change to the work. It still involves manual entry data and still takes a lot of time. Worse, Peter is still spending a significant time on activities that don’t involve providing direct care to his patients.
Instead, if caregivers like Peter and others work with a team of technical and management individuals with healthcare experience and skills, the hospital where he works could radically rethink the work and embrace even more digital technology. Such Internet of Things (IoT) technologies will vary according to the problem they need to solve, but in a hospital this could include smart beds, connected physiological monitors, and smart ventilators and IV pumps. By instrumenting the bed and a variety of other physical objects, vital patient information can now be transferred electronically directly into the EHR environment – no paper, no human data entry.
Otherwise, yeah, you’re just moving manual entry to tap entry. It might solve back-end problems of cleaning the data, cut that’s likely not enough.
Why are frequent deployments important? If you can deploy hundreds of times per day, you can recover from mistakes almost instantly. If you can recover from mistakes almost instantly, you can take on more risk. If you can take on more risk, you can try wild experiments—the results might turn into your next competitive advantage.
[Y]ou have to start with a position that all organizations (it doesn’t matter what industry you’re in) are going to be disrupted by highly agile, highly automated competitors who leverage technology to be the disruptive force in the sector. And, businesses clearly have a choice as to whether they are going to be the ones doing the disruption or whether they are going to be the ones having to respond to the disruption. But in either case, it depends on your ability to adapt, change and to compete. We live in a world that is increasingly digital and where technology is the lever through which much of that computation takes place. My advice to IT folks is that you’ve got to be able to have that conversation in the voice of business leaders – you’ve got to be able to articulate that reality in a language that can be understood. This is not a technology conversation, it’s a business and a competitive strategy conversation.