Link: Gartner Survey Reveals Western European Employees View IT as a Technical Resource, Not a Digital Advisor

While employees are feeling more and more computer literate, they’re valuing the IT department less. Once again, IT has to reestablish itself as a source of innovation instead of cost-cutting, light-bulb illuminators. “Keep moving and get out of the way,” and all that.

n=” online survey gathered data from 1,000 employees in Western Europe from organizations with more than 100 employee.”

Source: Gartner Survey Reveals Western European Employees View IT as a Technical Resource, Not a Digital Advisor

Link: Forrester/IBM Report: ‘Great’ apps monetize five times better than good ones

Survey commissioned by IBM to find out what makes mobile apps great. Then, of course, it seeks to tie more success (revenue) to that greatness.

n=”1,000 consumers in the U.S., Canada, U.K. and India.”
Source: Forrester/IBM Report: ‘Great’ apps monetize five times better than good ones

Coté Memo #081: The best steak I’ve ever eaten, and the slow train problem

Tech & Work World

How Microservices Fixes the Slow Train Problem

I write little columns for the internal Pivotal newsletter we have sometimes. Here’s one that’s about to go out.

The ideas of “dependencies” and “coupling” are important touch points for understanding and conveying the software delivery benefits of a microservices approach to architecture.

“Coupling” between services means that changes to one service have a big impact on another service. Coupling is considered bad in software architecture. Among other reasons, strong coupling usually means that each service can only be released as “fast” as the slowest changing service. For example, you might have an identity service and a reservation lookup service. Let’s say the reservation service can be updated weekly – the team working on it is fast! But, the identity service releases takes six months. Thus, the reservation service is forced to deliver on a six-month schedule.

Among other things, microservices remove the release cadence dependency. The goal is to allow each service to evolve as fast as makes sense for the business. Of course, there are some “new problems” to address:

  1. Ensuring backward API compatibility is a good idea. If we remove or change parts of identity services’ API and don’t change the reservation system, things break. Thus, it’s good to slowly remove functionality (or never do that!) with lots of testing, with the ability to rollback changes if/when things go haywire in production.
  2. Services should be able to isolate failures in order to “quarantine” errors in other services. If there’s an error in the identity service in production, we’d like the reservation service to gracefully fail. Operations patterns like the circuit breaker included in Spring Cloud, help manage these types of operational complexities.

Another benefit of decoupling services comes from shorter release cycles. The longer you wait to release code, the more code you’ll bundle into a release. Six months worth of code, across multiple services is a lot. When errors occur in production – and they will! – finding bugs in this ball of yarn will be much harder than finding the bad code in, say, a week’s worth of code.

Train Tracks

Think of it as train tracks. If five tracks all converge at one point, a problem on one of the tracks can cause confusion and delay for the other trains’ schedules—they’re strongly coupled. If each of the five tracks operates on its own schedule without having to converge, then of course there is no cascading schedule problem.

New Pivotal Cloud Foundry Release – a $100m/year business

Pivotal Cloud Foundry diagram

Pivotal Cloud Foundry 1.6 – there’s a new version of the product I work on (well, not coding, but you know, in my capacity of whatever it is I do). Check out my quick summary of what’s in it and, from the dormant analyst in me, an attempt to write-up the customer momentum we have.

I notice that most coverage of Pivotal doesn’t really focus on the business side of things, which is going excellent – like, we make real money and all that! Other than being nifty, I like that aspect because it means people (“customers”) find our work actually valuable enough to pay for.

If you’re interested in more “market talk,” check out the podcast I did with James Watters on the topic, GM of the business.

And, here’s some more coverage of Pivotal Cloud Foundry 1.6

Shameless Self Promotion

Quick Hits

Fun & IRL


I that steak at Roast in Detroit. I think it might be the best steak I’ve ever had. Would eat again, many times.



Don’t be a jerk, leave us a five star rating in iTunes – Software Defined Talk #49

Screenshot 2015-11-17 14.58.01


After discussing a new podcasting network based on annoying listeners as much as possible (one word: walnuts), we discuss the latest in OSS FUD, what Atlassian’s IPO will mean for related tech companies, and Chef’s product portfolio expansion into two new areas.

Listen above, subscribe to the feed, or download the MP3 directly.

With Brandon Whichard, Matt Ray, and Coté.

SPONSOR: check out Coté’s three part webinar on getting your cloud strategy right: the cloud native journey. It’s divided into greenfield projects, legacy projects, and tackling IT department transformation. Don’t screw up your cloud strategy, let your competition do that instead. Check out the series at

Subscribe to this podcast: iTunes, RSS Feed

Show notes

BONUS LINKS! Not covered in episode