“In addition, the government plans to increase PaaS spending from $227.1 million in FY15 to $231.3 million [in FY16].”
We’re still in a phase where categorization causes weird slices of spend like this, but there you have it. More figures on “cloud” spending in the piece.
Source: IDC: Federal government seeing cloud spending push
A bit broad, but still legit if you scope the audience right.
Source: Cloud Computing Trends: 2016 State of the Cloud Survey
“The world isn’t about to end, however. Yes, Forrester reveals in its “Understanding Shifting Technology Acquisition Patterns” research note that lines of business are taking on a greater role in technology purchasing, removing IT from the purchasing process in 6.3% of new technology purchases in 2013, rising to 7.2% in 2015, while IT-only purchases will fall from 23.7% (2013) to 21.6% (2015).”
Source: Don’t make the mistake of thinking the CIO is irrelevant – TechRepublic
“The cloud email market is still in the early stages of adoption, Gartner said, with 13 percent of identified publicly listed companies globally using one of the two main cloud email vendors, Microsoft Office 365 or Google Apps for Work, respectively. With the majority of companies opting for smaller vendors, the cloud email opportunity is still ripe for channel partners… According to Gartner, 8.5 percent of public companies in its sample of nearly 40,000 public companies globally use Microsoft’s Office 365 service, while 4.7 percent use Google Apps for Work.”
Seems pretty crazy, but I’m sure there’s sunk costs, security and data handling issues, and, well, sometimes it probably is cheaper.
Source: Gartner: Cloud Email Adoption Still in Early Stages
Matt and I talk about lessons learned from almost a year of helping transform IT at Allstate. When it comes to scaling up agile and cloud-think the real challenges are in functions other than development, like budgeting, planning, training, hiring, and how the overall IT department is organized. We discuss those topics – esp. budgeting! – and also how to set one’s personal expectations about going on the transformation journey. Then we discuss an upcoming column on mine in The Register on the benefits of small batches thinking.
Listen above, subscribe to the feed (iTunes, RSS Feed), or download the MP3 directly.
Show-notes and Links
- After a year, the question becomes “can it scale?”
- How do we do: Budgeting, training, hiring, how do we organize teams
- We only plan with good information, not bad information.
- You need to establish an overall vision, but avoid being too specific on tactics. For example, with a claim application, we know the general product, the vertical, the line of business we have roughly an idea of what claims are, who the customer is, and what that experience is like. Delivering a better experience for claims, what that feels like, and how do we measure it – these things we don’t know perfectly up-front, so we have lots of discipline around iterating and experimenting to deliver good product.
- How budgeting changes in this small batches approach.
- With a lot of this, you can’t talk someone into doing these things up-front. They have to experience it first hand: you have to walk them through it.
- “Sometimes ‘nothing’ is a big win.”
- Coté’s DevOps columns at The Register.
- Not mentioned, but good thinking to be had in Larman’s Law
- Matt Curry: @mattjcurry
- Coté: @cote, cote.io
A little while ago I was on The New Stack Makers podcast with Alex Williams, talking cloud and Pivotal. Check it out:
Here’s what we go over:
In this podcast with Michael Coté, who works at Pivotal in technical marketing, he and The New Stack founder Alex Williams talk about current production systems and development environments for building applications. According to Coté, Pivotal describes these new systems and environments as “cloud native.”
Over the course of this interview, Coté discusses best practices and illustrates three requirements for cloud native development and deployment: utilizing the patterns of microservices architecture, implementing a DevOps approach, and striving for continuous delivery as the primary vehicle for software delivery.
Check it out!
After covering out genius new business model, we talk about Twitter, how Wall Street values tech companies, the Austin startup scene, follow-up on kick-off meetings, and recommendations.
Listen above, subscribe to the feed, or download the MP3 directly.
With Brandon Whichard, Matt Ray, and Coté.
SPONSOR: Interested in speeding your software’s cycle time, reducing release cycles, and a resilient cloud platform? Check out the free ebook on Cloud Foundry or take Cloud Foundry for a test drive with Pivotal Web Services. See those and other things at cote.io/pivotal.
Subscribe to this podcast: iTunes, RSS Feed
…or: “Knowledge work is a lot more like cloud than traditional IT.”
Of course, it is most certainly not in the interest of knowledge workers to go to their bosses and declare that they have “spare capacity.” At best, they might then be judged in performance reviews as having an easy job and being not very productive. At worst, the bosses might decide that these employees could be cut. Thus it is to every knowledge worker’s benefit to look busy all the time. There is always a report to write, a memo to generate, a consultation to run, a new idea to explore. And it is in support of this perceived survival imperative that the second driver of productivity—knowledge transfer—gets perverted.
The rest of the piece is good stuff. Notice how much of the thinking follows the same pattern of opex vs. capex thinking of cloud, and the somewhat similar notions of continuous delivery. I’d also add that if you follow a small batch (smaller amounts of work delivered more frequently, rather than big projects delivered once), you’re given more opportunity to re-allocate your “knowledge workers” to different projects. As the author points out, this means you have to rejigger how HR/roles and responsibilities work; staff policies don’t currently favor moving people from project to project like you see in (management) consulting.
Couple this with the “you need to constantly be coming up with new businesses” pressure from Transient Advantage, and you have good operating theory.
That’s a big chunk of change. Developers don’t pay for anything, eh?
Source: JFrog Raises $50 Million To Provide The App Store For The Internet Of Things
I started a new column at The Register, on the topic of DevOps. I used the first column to layout the case that DevOps is a thing, and baseline for how much adoption there currently is (enough, but not a lot – a “glass almost half full” type of situation). I was surprised by how many comments it kicked up!
Next up, I’ll try to pick key concepts and explain them, along with best and worst practices for adoption of those concepts. Or whatever else pops up to fill 800 words. Tell me if you have any ideas!
(You may recall had a brief column at The Register back when I was at 451 Research.)