Howard Dierking

I Don't Work for a Technology Company

And it’s likely that neither do you

One of the projects that my team works on is a GraphQL server. The service provides a consistent, data-focused interface between multiple types and versions of front end applications and multiple types and versions of back end APIs. Now, let me be clear up front: this post is not about GraphQL vs. REST. As I’m sure will be unsurprising to the vast majority of you, our back end services differ wildly in terms of design (from RPC to “Pragmatic REST” (aka RPC) to full-blown hypermedia), content types and granularity of resources. So our decision to use GraphQL is based on what I think are 3 realities that are specific to a company and a culture.

  1. The management culture is not top down - so mandating a common API design spec is not going to happen
  2. In absence of that, API design will continue to diverge across all of the back end teams
  3. The UI teams don’t care about the aesthetic preferences of the back end teams

So - agree or disagree - there’s your context for why GraphQL made sense for us.

Our GraphQL Service

The first (and current) incarnation of our GraphQL server had noble motives, but was overly optimistic in its ambition. We decided to design, build, and operate a single GraphQL server that would define and contain the schema for the entire company. By putting ourselves in this position of technical middle-man, we would then also be able to be the gatekeepers for defining a new “clean” data model for the company - and thereby save the company from itself.

If you’ve been down this road, you know exactly how it played out. A team of 12 - no matter how talented - could not develop the level of domain expertise to cover the entire business domains of travel and accounting fast enough to define, articulate (e.g. argue for), and implement a clean-room data model. In the meantime, UI teams had started down the path of using the service and the velocity of their requests for new parts of the business to be exposed via GraphQL grew exponentially. To quote my Product VP, the team had lost control over its own backlog.

So, took the lessons learned from running the current service and pivoted towards building out a platform whereby other teams could create and deploy GraphQL fragements and we would stitch them together into a unifying schema and provide all of the runtime capabilities. The phrase I’ve been using inside the company is that we want to create the AWS Lambda of GraphQL. So imagine my surprise this morning when I discovered that AWS is already thinking in this direction.

This Seems Familiar

In all honesty, this morning’s discovery shouldn’t have been all that surprising. We followed a similar path with our API Gateway project, and while at the end of the day the company is still running its own API Gateway, I suspect that the technology has already been surpassed by what’s available either commercially or in the open-source community and we will soon find ourselves in that all-too-familiar place of deciding whether to accept pain in moving forward with a better technology or staying with what we’ve built because we’ve custom-tailored it to the ways that we do [have always done] things.

The Problem

I’ve had the opportunity to see this type of problem present itself several times now, and while each instance looks a little different, I think there’s a common root cause that looks something like this clip from the movie, “The Founder.”

In this clip, Ray, the main character in this story of the McDonald’s fast food chain, is lamenting some of the challenges he’s facing with the restaurants when his counterpart lays out a very poignant assertion: that Ray doesn’t realize what business he is actually in. I’ll encourage you to watch the movie for the rest of the story, but I’ll bring up this quote because I think that it applies to most of us in the software development world. Most of us don’t realize what business we’re actually in - and as a result, we make decisions that are either unhelpful to, or in some cases downright harmful to our actual business.

My company, like many of yours, is a business software company. It is not a technology company. “What’s the difference?” you might ask. After all, with slogans like “every company is a technology company“ and “software is eating the world“ having taken root as a part of our every day world view, it’s difficult to see or care about the difference. However, it’s important because - as I said - it affects how we make choices.

I’ll toss out a couple quick definitions so that even if you disagree, we can disagree having the same understanding of terms.

Both of these are necessary and good functions. However, when you try to apply them in the wrong context, you’re asking for all sorts of problems - problems ranging from wasted time and money to architectural decisions that set your company back years.

So why do we keep chasing after trying to reinvent the wheel and build technology rather than simply add value to our respective businesses by building software? I’m sure that there are as many answers as there are people, but I’ll take a stab at a few common ones that I’ve both felt and observed.

As a result, we reinvent the wheel, but in a way that only works for our car, and then we build the rest of our car in a way that only works for our wheel - and our customers are the ones who suffer for it.


Clearly, there are examples out there where an organization started as a software company and morphed into a technology company. However, in most of the examples I can think of, that transformation happened as a function of scale at a level that you and I will likely never have to concern ourselves with. To restate something that’s been said many times, you are not Netflix.

The Path Forward

The message in this post should not be taken negatively. In fact, what I’m suggesting here is that we should all take a great deal of pride in what we’re doing rather than wishing or pretending that it is something else. So here are a few reflective questions and actions that I’m talking about with folks in my organization.

Again, at the end of the day, neither type of business is better - just different - with different customers - who expect different deliverables.