• 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.

  • 21 Oct 2016

    There Is No Data Center

    One of the less stated charters of my team is to push the bounds on system design and innovation within our company’s larger technology group. In doing so, it is expected that we will push people out of their comfort zones and while this will undoubtedly create friction, the idea is that the final outcome will be better for the larger group. While I think the final outcome is still to be determined, there are many ‘right conversations’ that are happening. One of them that I’ve been reflecting over recently is the disagreements with different central teams - especially around issues related to infrastructure and operations. Two areas where these disagreements appear to surface the most right now are related to how cloud resources should be provisioned and used, and on how our API gateway should be designed in relation to the infrastructure that hosts the services it proxies.