• 26 Nov 2016

    The "Must Haves" for a Service-based Architecture

    Over the past several years, I’ve seen lots of architecture-related efforts come and go when it comes to services. These efforts have typically involved introducing one more more technologies that, if everyone would just get onboard, would move the organization to a next-generation, 100% available, reliable, compliant, secure stack. A few examples include REST, Kubernetes (then Swarm, then back to Kubernetes, then…), Consul.io, and Kafka.

  • 14 Nov 2016

    Linked Data and Mutations

    I’ve spent much of the last couple years thinking about linked data and what that can mean for Web APIs. Whenever I’ve given a talk on the subject, there are generally 2 questions that get asked. The first is: what are the practical benefits of applying linked data principles such as globally scoped names, RDF, and linking to published vocabularies? For these questions, some answers are more clear (e.g. globally scoped names and a directed graph data model) while others are not (e.g. ability to infer relationships and ability to equivocate terms across vocabularies).

  • 04 Nov 2016

    Service Ownership and Linked Data

    As large technology companies transition to services and APIs, there will inevitably be quite a bit of debate around what data a service “owns” (and related: how to stop another service from owning that data), what document schemas should be supported, how to create and expose Swagger documents, and so on. As I’ve observed and participated in many of these kinds of discussions, I am convinced that while none of these discussions are fundamentally bad, they are all secondary to a well thought-out data model based on a directed graph. Put another way, with a cohesive data model, otherwise contentious (and therefore political) debates around the number, purpose, and ownership of services, become data-driven conversations about naturally-emerging clusters of terms in a graph that describes the company’s data.

  • 28 Oct 2016

    The Misappropriation of Terms: Andon Cord

    Software developers tend to be a bit hipsterish in that we seem to have an inherent attraction to novel things - especially when those novel things are lifted from the old things of other disciplines. The Andon Cord is one of those nuggets lifted from the same corpus that brought us much of what is now termed “agile”: Automobile manufacturing - specifically, the manufacturing practices of Toyota.