A layered approach to product design

Some time ago I wrote this post.

The Problem With Oracle : If a developer/user can’t do it, it doesn’t exist.

As a result of that post I was invited to speak to a bunch of product managers at Oracle. In that session I spoke about the contents of that post and also about my thoughts regarding a layered approach to product design. I thought I would briefly outline the latter here.

I used to be an Oracle specialist, back in the days when it was possible to have a normal job as an Oracle specialist. Nowadays I find myself doing a really wide range of things. That inevitably means I am Googling my way to solutions a lot of the time. If I had stayed completely in the Oracle world I think my attitude to technology would be very different. There’s something about going outside your comfort zone that helps you gain perspective. In my previous post I said,

“I’m just a generalist that uses a whole bunch of products from a whole bunch of companies, and most of them are too damn hard to use, even with the assistance of Uncle Google.”

In my head, the solution to this issue is for companies to take a layered approach to every aspect of their products. They should be asking themselves.

  1. Who is the audience for this product today?
  2. Who do we expect the audience for this product to be in the future?
  3. Does the product we’ve created meet the needs of these audiences?

Let’s use the Oracle database as an example of this. We could use many other database and non-database products.

  1. There are aspects of the Oracle database that are focused on the developer audience, but there are also aspects of the database that are focused heavily on the administrator audience. So the audience for this product is split.
  2. Over time I expect the DBA role to completely disappear. We have already seen the beginning of this with cloud-based databases. I expect this trend to continue. As a result, I would suggest the future audience of the Oracle database will be solely developers.
  3. Since the product currently has a split audience, and we expect one of those roles to go, I don’t think the database is targeting the correct audience. Anything that is currently a DBA task needs to be automated out of existence. Anything where the DBA is a gatekeeper needs some redesign.

So how do we achieve this? My suggestion would be to take a layered approach. I’ve discussed a similar idea of a layered approach to documentation.

  • Layer 1: Simple how-to.
  • Layer 2: Give me some details, but don’t make my head hurt.
  • Layer 3: I’ve taken some paracetamol. Do your worst!

This time I’m thinking about how the product itself works.

  • Layer 1: The product works out of the box. A developer with no experience of administering this engine can start doing something useful with it immediately. There are no commonly used features that are out of their realm of control. A company or person may choose to stay within this layer for the lifetime of a project and see no ill effects.
  • Layer 2: If the company have some skills in the product, or a specific aspect of the product, they may choose to dip down into this layer. Here they can perform some actions that are not directly covered in layer 1, but this doesn’t mean they lose all the benefits of layer 1. They are not switching off all automations just because they want to deviate from one bit of default functionality.
  • Layer 3: The company have some people with God-mode skills and want to do almost everything by hand. They want to take full control of the system.

The important point is, people want work in the layer(s) they are comfortable in, and still do an effective job. This makes the product accessible to everyone, but doesn’t discriminate against those that want to no-life the product, if they can see a benefit in doing so.

I know there will be objections to this approach, and believe me I can make counter-arguments to it myself, but I don’t see a way forward without taking this sort of approach. I’ll go back to a quote by Jacob Duval where he was comparing MySQL and PostgreSQL.

simply put: mysql has a superior developer experience. postgres has a superior DBA experience. DBA is not really a job anymore, so I pick the developer experience every time.

Jacob Duval

The developer experience has to be the #1 focus from now on!

I’m not underestimating the impact of that statement. It is a massive job for a huge and mature product such as the Oracle database, but not doing so is a death sentence IMHO.

I know some people will see this as a cloud sales pitch, but actually it’s not. I think the on-prem products need to live up to these ideals too. Why? Because I see the future as multi-cloud. If Oracle focus entirely on their cloud offerings, people who decide not to pick Oracle Cloud will be left with a sub-par experience when running Oracle products on other clouds. The result of that is they will pick non-Oracle solutions. I don’t think this is a road Oracle should go down.



PS. I’ve kept this post purposely vague, because I think focussing on individual features will make the post huge, and detract from the overall message…

Update. Akiva Lichtner raised an interesting point. I thought I would add it here, in case someone else is using their own interpretation of what I am suggesting.

“You can see from Tesla’s speed of change that vertical integration which is the opposite of a layered approach is a superior approach. Also reminds me of Bryan Cantrill’s old DTrace talk where he says that the layers conspire to make the whole system impossible to troubleshoot”

Akiva Lichtner

My response.

“It depends what your interpretation of the layers are. Sounds like you are interpreting it as something different to me. The Tesla interface has layers. It can self-drive, or you can drive for yourself. Just like what I’m talking about…”


I’m not suggested we should just keep stacking layer-upon-layer on the existing products. My focus is very much on the potential for a layered audience. As I mentioned above, a Tesla can use autopilot or be driven by a human. Same car. Two modes of operation. We could consider them two audiences.