Spending from outside of the IT department

Corporate departments outside of the IT department, globally, are forecast to spend $609bn in 2017:

A new update to the Worldwide Semiannual IT Spending Guide: Line of Business from the International Data Corporation (IDC) forecasts worldwide corporate IT spending funded by non-IT business units will reach $609 billion in 2017, an increase of 5.9% over 2016. The Spending Guide, which quantifies the purchasing power of line of business (LoB) technology buyers by providing a detailed examination of where the funding for a variety of IT purchases originates, also forecasts LoB spending to achieve a compound annual growth rate (CAGR) of 5.9% over the 2015-2020 forecast period. In comparison, technology spending by IT buyers is forecast to have a five-year CAGR of 2.3%. By 2020, IDC expects LoB technology spending to be nearly equal to that of the IT organization.

Meanwhile, all in, global IT spend was estimated at $2.4tn in 2016, but that includes telco and consumer tech. And, this demographic breakdown for enterprise IT spend:

In terms of company size, more than 45% of all IT spending worldwide will come from very large businesses (more than 1,000 employees) while the small office category (the 70-plus million small businesses with 1-9 employees) will provide roughly one quarter of all IT spending throughout the forecast period. Medium (100-499 employees) and large (500-999 employees) business will see the fastest growth in IT spending, each with a CAGR of 4.4%.

Sources: Technology Purchases from Line of Business Budgets Forecast to Grow Faster Than Purchases Funded by the IT Organization, According to IDC, March 2017 and Worldwide IT Spending Forecast to Reach $2.7 Trillion in 2020 Led by Financial Services, Manufacturing, and Healthcare, According to IDC, Aug 2016.

The Economist on Amazon – Highlights

  • Video: “In 2017 Amazon is expected to spend $4.5bn on television and film content, roughly twice what HBO will spend. But it has a big payoff.”
  • Prime momentum: “Mr Nowak reckons the company had 72m Prime members last year, up by 32% from 2015.”
  • Cloud: “Last year AWS’s revenue reached $12bn, up by more than 150% since 2014.”
  • Anti-trust, in the US: “If competitors fail to halt Amazon’s whirl of activities, antitrust enforcers might yet do so instead. This does not seem an imminent threat. American antitrust authorities mainly consider a company’s effect on consumers and pricing, not broader market power. By that standard, Amazon has brought big benefits.”

Are investors too optimistic about Amazon?

Vanguard’s thinking on microservices

Breaking up the monolith with good, old fashioned, OO-think:

Instead, Vanguard has begun a journey to break apart our monolithic legacy systems piece-by-piece by replacing them with microservices over time. With a microservices architecture, we remove the business logic and data logic from our applications and replace it with a set of re-usable modules of code that are built and deployed as independent entities. We then compliment this architecture by chunking out our user interfaces into modular purpose-built components.

De-coupling for stability and resiliency, among other things:

This service-based approach to application architecture provides a variety of advantages over the jumble of code that defines a non-modular monolithic application. First, services reduce redundancy by making sure there is only one copy of application logic for a given capability – regardless of how many applications leverage that logic. In the long run, this leads to lower development costs and increases speed to market. Second, since these services are deployed independently and built in a resilient manner, outages in one area of an application are less likely to bring down an entire system. In some instances, several of our services can be down without our clients being aware of a loss in functionality thanks to the ability of our applications to automatically react to a service that isn’t available. Finally, services enable our applications to scale easier. The marriage of cloud and services means we can quickly spin up infrastructure to handle surges in the number of transactions we need to handle without needing to scale up an entire application.

Vanguard CIO: Why we’re on a journey to evolve to a microservices architecture

Australian government’s Cloud Foundry apps in production

Delivery teams are now able to build services faster and easier. In July 2016, DTA had 14 apps in production and 50 apps in development. In October 2016, the numbers increased to 47 apps in production and 225 apps in development.

Australian Government Cuts Release Time with Cloud Foundry, Iterates Faster – Cloud Foundry Live

Coté Show #22: The Regular Show, Apple’s problem’s, Enterprise tech news blows

Charles and I resurect out old podcast. We’ll shoot for once every two weeks…I hope!

Check out the fuller show notes, with links on how to subscribe and such.

Kubernetes as the hybrid cloud magic maker

From 451’s report on Google Next:

Google believes that a hybrid architecture will persist in the coming years as enterprises continue to migrate workloads to various clouds. Its hybrid cloud architecture revolves around its virtual private cloud. Google VPC is an instantiation of GCP that can dedicate compute, storage and network resources to an enterprise. It is built upon Google’s proprietary private global network designed for high reliability, low latency and hardened security. Kubernetes acts as the orchestration and operational backplane for hybrid implementations. Elasticity and scale are achieved by linking to Google public cloud services.

It also has many numbers on market-share, SI/channel development, and geographic foot-print.

Source: Google Cloud Next 2017: Slow and steady race to greater enterprise public cloud adoption

If compliance is so important, bake it into the platform

Can we take that governance and work with the platform team to codify, to automate that which they were doing on a per application basis – that’s, quiet frankly slowing down the delivery of the software – can we take that governance and can we have them work with the platform team to codfiy, to actually automate on a per application basis, have them expose that as a service on the platform

Cornelia Davis on governance and cloud-native, “Who Does What? Mapping Cloud Foundry Activities and Entitlements to IT Roles,” August 2016

In other words: you should not only automate the audit three-ring binders of compliance, but enforce as much as possible in the platform.

The rest of the talk is good stuff on how think through re-arranging your organization to be all DevOps-y, with the help of Pivotal Cloud Platform to automate all the infrastructure and middleware stuff:

Cloud-Native Cookbook – beyond “survival is not mandatory”

I started a new booklet project, the Cloud Native Cookbook.

The premise is this:

The premise of this book is to collect specific, tactical advice transitioning to a cloud-native organization. The reader is someone who “gets it” when it comes to agile, DevOps, cloud native, and All the Great Things. Their struggle is actually putting it all in place. Any given organization has all of it’s own, unique advantages and disadvantages, so any “fix” will be situational, of course.

This cookbook draws from actual experiences of what worked and didn’t work to try to help organizations hack out a path to doing software better. While we’ll allow ourselves some “soft,” cultural things here and there, each of the “recipes” should be actionable, tangible items. At the very least, the rainbows and unicorns stuff should have concrete examples, e.g., how do you get people to actually pair program when they think it’s a threat to their self-worth?

As with my previous cloud-native booklet, I have this one open for comments as I’m working on it. It’d be great to get your input.

Here’s some slides I’ve been using around all this.

Pacing cloud-native transformation, and actually doing the work to increase productivity

I like to tell large organizations that compared to the break-neck pace of “the silicon valley mindset,” they can operate at a leisurely pace. That pace is usually fast for these enterprises, but their problem set and risk profile is a lot different than hats on cats. Abby has a nice, short write-up that hits on this topic among others:

By the end of his first year, Safford and his teams had built prototypes and market tests and finished 16 new software projects.

At Home Depot, they were at about 140 to 150 projects after a year or so. However, it’s common in the first year to do a lot of replatforming of “simple,” mostly cloud-native compatible apps in there. You can do these at a pretty fast clip, with the rule of thumb being 10 apps in 10 weeks. This is in addition to new applications, but explains high numbers like those at Home Depot. I suspect the Allstate numbers are mostly net-new apps, though.

Goals:

Safford’s eventual goal is to shift Allstate software development to 70 percent extreme agile programming and 30 percent traditional scrum and waterfall. Where developers used to spend only 20 percent of their time coding software, today up to 90 percent of their days are spent programming. Each of his CompoZed development labs around the world has the same startup look and feel, including scooters parked in the hallways. This is not your grandfather’s insurance company anymore.

What you hear over and over again from organizations going cloud-native is that developers were spending lots of time in meetings, checking email, and otherwise not coding (and, yes, by “coding” I don’t mean just recklessly LOC‘ing it up without design, and all that). Management had to spend much effort to get them back to coding.

As I fecklessly tell my seven year old when he’s struggling with homework: the only way to finish this quickly is to actually do the work.

(Also: nice write-up from Abby!)

Source: Don’t Forget People and Process in Your Digital Transformation