Link: Internet of Things Spending Forecast to Reach Nearly $1.3 Trillion in 2019 Led by Widespread Initiatives

“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.”

I think IoT is becoming mor like IoEverything.

Source: Internet of Things Spending Forecast to Reach Nearly $1.3 Trillion in 2019 Led by Widespread Initiatives

The many meanings of “cloud broker”

From coverage of a keynote at Gartner DC:

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 last bit is what feels like s more dramatic change: IT being called on to help run the business, not just keep the lights on.

Business people need to understand how software development works

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.

Cloud Native Journey Series

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.”

Cutter Survey

All four parts are now up:

  1. The introduction to the series
  2. The Purity & Tyranny Of A Blank Screen: The Greenfield Journey – see also a recording of my webinar on this section, also the slides.
  3. Dealing With The Stuff That Makes All The Money: The Legacy Journeycheck the recording of the webinar on this section, too. Also, the slides.
  4. The Cloud Native Journey: Enterprise Transformation – check out the recording of the webinar on this part. Also, the slides.

There’s also a PDF of the whole thing if you prefer that format.

Tell me what you think of it!

“The concerned citizen super coder,” or, transforming how the US government does software, Diego Lapiduz – Lords of Computing Podcast #008

Summary

What organization could be larger than the US Federal government? Not only that, the chance to transform how software is done in the government has perhaps one of the largest possible impacts of transforming any “IT department.” In this episode, Matt and Coté talk with Diego Lapiduz who works in the GSA’s 18F organization helping government agencies develop their software in new, more agile and cloud-driven ways. We discuss the background of 18F and the broader government initiatives to transform how software is done and also walk through some of the learnings 18F has had in trying to make such a huge transformation.

Subscribe: iTunes, RSS Feed

Show-notes and Links

Who run IT-town? Ops or Dev?

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!