Designing Your Enterprise System the Right Way

There are three things you need to get right in your technology stack when implementing an enterprise system for a large organization. These are

1. Data Model

2. Interface

3. API (Application Programming Interface)

Note I am not listing the business rules. Not because those are not important but because that is the wrong way to design the stack.

By focusing on business rules you tie the requirements too deeply into the system so that when things change, as they must, your system becomes obsolete.

Instead what you should be creating is the technical framework within which your requirements should be implemented, both the immediate ones at hand and those resulting from inevitable changes in the future.

Data Model

The data model is the set of entities (ie tables) and attributes (ie fields in those tables) that govern how data is stored.

Actually, not quite.

That is a reasonable definition of a data model but it gets its importance backwards. The data model is not important because of how you store data in it. It’s important in the context of how you get data back from it.

No matter what kind of storage paradigm you are using, the reason you are storing the data is because you want to find it later. And in particular you want to find it in a way that gives it context, ie a way that shows how it’s related to other data.

Whether that be other attributes of the same entity (first name is pretty useless without last name) or other entities (it’s pretty useful to know what grade and school a particular student is at) the data is not meaningful by itself.

So the real definition of data model that we should use is the that it tells us how each data field is cataloged so it can be referenced later in the context of other data fields

Interface

This is a little more obvious. Getting the interface right means that it is unobtrusive but useful. If you’ve read any PG Wodehouse (the most gloriously written tripe ever), the gentleman’s personal gentleman par excellence, Jeeves, is the human manifestation of the perfect interface.

When you don’t want it, it gets out of the way, but suggests the best way to do things. You are free to ignore those suggestions but the more useful they are the more the interface helps you follow that path. The less effective an approach is the more difficult that pathway is made.

People often dumb this philosophy down by simply creating wizards. Ie, standard workflow templates that guide the user through a series of data entry steps. The trouble with these is that they do a really great job of leading you down the exact path that the developer has predicted.

But god help you if you want to deviate even a little away from this standard path. Microsoft used to be particularly bad at this but has gotten a lot better. Apple hasn’t yet really learned the difference between opinionated and dictatorial software.

The large tech company doing this the best is AWS. Just compare how easy their interface allows you to create an Alexa skill vs Google’s assistant. Or try creating a serverless function with AWS lambda vs an Azure cloud functions.

The key is to think of the interface more as the communication mechanism between the various users of your system rather than the communication mechanism between the user and the system..

The data is stored in the data model and is made available to other people through the interface. Using the right framework in your interface will allow users to efficiently ensure accurate and relevant data is entered and provide the right data to them at the right time to do their jobs.

API

The API is the glue between the two. The way it’s normally described is the way that an external entity communicates with the core system.

But a well designed API is much more than this. The API embodies the basic design philosophy of your whole system. It even more important then the data model in terms of how scalable and flexible your system is as your business processes evolve. And it allows maximum flexibility in your interface by hiding the details from the data model.

This is clearly a good thing from a development management standpoint because it allows for some parallel development from two different teams, one working on the data model, the other on the interface. Changes can be made to the interface don’t necessitate changes in the data model.

But even more than helping to efficiently develop the system, the API will make it or break it in terms of how system becomes a living part of your organization vs a static pain in the ass that people are forced to use.

By carefully designing your API calls so that its not only used by external systems but also by different workflows and interfaces within your system you ensure that the interfaces are not tied to the data model so that both can be more easily replaced by newer technologies.

The well-designed API will group calls in a way that clearly delineates one work function or module from another while at the same time providing access to core business objects and business rules in a succinct way. Just the right design of objects, methods, and parameters.

Clean Thinking

In fact the API is so important that it actually should be one of the first things that is developed. Even before a single line of code is written or a single database table is created, the API should define the way data flows throughout the system. It should be the skeleton that everything else is built upon.

Do that right and everything will fall into place.