Automating the three ring binder, an example from the US Government

18F is fun the watch if you’re interested in transforming to cloud. In this FAQ about, their Cloud Foundry service, they talk about how they help speed up the slow meatware process of compliance:

A typical agency process to demonstrate compliance with FISMA and gain an ATO requires generation of a gigantic, copy-pasted document enumerating the full design of the system. We document all of the federally-required controls in every section of the platform in a software-friendly way. This enables us to generate different documents suitable to different contexts: human-readable, gap analysis, spreadsheet matrix, web page visualization, etc.

Any app deployed on will be able to leverage these “parts-included” descriptions to make generating their own documentation much easier; they only need to supply information about what their system adds on top of the PaaS. For more information, you can watch the recent DigitalGov University video on “Handling FISMA Faster and Better.”

There’s a few interesting things here:

  1. They automate as much of the process as possible, doing the copy and pasting for you. Now, this should make you question needing to do all that meatware work in the first place but…
  2. If you can’t beat the meatware process problem, join it and try to automate it. There’s probably some value in there, and even for the parts where there is no value, it might be a waste of effort to fight it (versus other ways to spend your resources of time and favors). 3. And, as I mention on my cloud strategy piece on dealing with legacy IT, perhaps by doing all this you can expose how silly it is and eliminate it.

(If you like this line of thinking, check out my webinar on Dec 1st in dealing with legacy IT in your cloud strategy.)

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.