What Makes an Application Enterprise?

Pulling back the curtain and showing the insides of applications

Introduction

In this week’s article we are going to do something a little different. We have talked about Architecture, but today we are going to talk about the things that make an application Enterprise. At first glance this is going to look technical, but we won’t be doing the deep dive, just a few sentences about what goes where in an enterprise application. At Sentia, we have designed and developed tools that automate the production of new software. We generate 50 to 60% of the code for a new application and all of the architecture.

What Exactly do we Mean by Enterprise?

An enterprise application is one that is built for larger organizations and governments to manage complex tasks. The objective of these applications is to automate various company operations and reduce project complexity. They must be scalable, robust, easy to use and fault tolerant.

What are the Benefits of Enterprise Applications?

Clearly automating processes drives down cost and drives up profits. In fact, it makes some things possible where they were not before. Clearly if we can get more done with fewer people, we can drive business growth. With improved communications, either literally, through a chat application, or through workflow-based messaging informing a worker what to do next. We can also automate communications with customers by either putting them in a future contact list, so they don’t drop through the cracks or sending scheduled emails or text messages.

Finally, we can automate entire industries. For example, you don’t need people to run a bank. You as the consumer put money in, you take money out, you tell the bank whom to pay. That is it. No people required. Insurance is a bank that only pays certain people. You go to the doctor and the insurance company pays for your healthcare. At Sentia we have written an Electronic Medical Records System (EMR) that picks up procedures performed and pays for them in real time. That automates the whole messy, expensive health insurance system and should save about half from the cost.

That is what enterprise software can do.

There is More to it than Just Functionality

Sure, the enterprise application has to be functional, but that can’t be all, right?

Architecture

Architecture is the study of what code goes where, so that the application is robust and maintainable.

General Architecture

We at Sentia usually use a Master Data Management (MDM) and a Single Sign On (SSO) approach. That means that anything that might be repeated in a database, like First Name or Address should be kept in the common MDM database. The SSO is the source of truth for Authentication and Authorization. That means that it ensures that you are who you say you are and that you can only access what you are supposed to be able to access. Other databases are added to create specific functionality.

The Database Layer

The database is the repository of all the data and a way to create, read, update, delete and search for it. There is no logic here beyond specifying a condition to return a subset of the data like “Where FirstName = ‘Monte’”

The API (Application Programming Interface) Layer

The API layer actually consists of four separate projects

Data Access Project

This is where we put the code that retrieves data from the database.

Core Project

This is where the interface contracts and templates, or objects go that house the data from the database

Business Logic Project

This is where we do things like decouple the database representing objects from the objects we pass around to the various higher layers. That way if we swap databases and the new database has a “Sex” column instead of a “Gender” column like we are used to, we can map that change here. We can also enforce rules like, “only approve a colonoscopy if the patient is over 45 years old.”

API Project

The API project is where the actual interface that is called by the client application, is built. It keeps the signatures of the various methods and their parameters to pass back to the database layer.

BFF (Backend For Frontend)

The BFF is an aggregation layer that brings together all the data that an application might need from the API layer. For example, every application will need access to the MDM and the SSO at a minimum, most make calls to other APIs as well so that we don’t have copied functionality between applications.

UI (User Interface)

This is the pretty part that the end user sees. This contains all the code to display and validate the data, but no business logic.

A Picture is Worth a Thousand (or more) Words

Here is a diagram of the architecture for Sentia Health’s suite of enterprise medical applications and their dependencies, for reference. Notice that the MDM does not have a BFF because it also doesn't have a UI.

Performance and Redundancy

Hardware and networking are major considerations of an enterprise application. Generally, we want to have at least two nodes in a cluster so if one machine goes down it automatically switches to the other. For application servers (where the UI lives) we need to build a “web server farm.” The web farm consists of at least two servers with many web server instances on them. This also makes scaling easy since we can just add servers to the cluster.

Web Server Farm

Web servers can’t utilize all the memory and processing power a server generally possesses. To combat that, we install several web servers on a machine to handle requests in parallel.

Database Cluster

We generally want at least two servers in a database cluster, one as a primary and the other as a backup in a high availability cluster. This also makes scaling easy, since we can offload databases to new servers as more power is needed.

SAN (Storage Area Network)

The SAN is a cluster of at least two big data storage units. One as a primary, and the other as a backup.

Networking and Switching

This is all that goes into connecting all this together. We generally run three switches:

Application communication
IPMI or console access
SAN communication

That means that each server must have at least three network cards, and we generally use a bridged 10gB card (with two ports) for increased speed to the data.

There are also a pair of clustered firewalls adequate to the task of providing VPN and security for the network.

Enterprise Logging and File Sharing

A truly enterprise suite of applications will have a centralized logging repository. This repository is searchable by application, time and type of error/event. Our choice is also set up as a document database and can store any number of documents in their native format and make them searchable.

Cloud Computing

The descriptions above are for on-premises style hardware management. The big consulting companies recommend this because it is easy. While they don’t have to worry about all the redundancies and clustering, and even switching, it is eye-wateringly expensive. For the price of a year of cloud hosting you can buy a cage full of new equipment and be done with it. These servers have a stated 5-7 year lifespan, but as they age, we can just add new servers to the cluster and either repurpose the old or just augment them. We can certainly, and will, use cloud hardware solutions, but experience tells us that you will be buying the equivalent of the server cage described above every year, instead of once in 5-7 years.

Conclusions

While this all seems relatively simple, I encourage you to go back and look at the diagram above. Each of these applications consist of tens or hundreds of thousands of lines of code. While it may be simple, there is a lot of it and there aren’t many, or any, who have an understanding of all of it.

Sentia is committed to returning value for dollar instead of simply billing astronomical fees that are basically on going. I would encourage anyone who is interested in purchasing or subscribing to enterprise software to request design documents from your preferred vendor. If they can’t or won’t provide documentation like the above, you should probably steer clear.

Not all enterprise applications are created equal. Ask Cerner or Epic for design documents. Install ServiceNow or Salesforce and then have to hire an architect and many developers to modify them to fit your particular purpose. Remember value for dollar, not billable hours.

Also remember that with the automated code generation tools, we have about half the application written on the first day. This gives us a huge advantage of a tried-and-true

methodology for producing new code and enforcing our developer’s adherence to that standard by literally doing all the architecture and most of the coding, for them.

If you liked what you read, please like and subscribe, click on the notification icon, subscribe to our newsletter, and follow us on all our social media and blog sites. You can watch the video version of this presentation at https://www.youtube.com/@sentiahealth or read on our site at https://sentiahealth.com.