For what seems eons, technologists have been trying to get complex apps built in time to impact the business. Microservices, object-oriented programming, new DevOps processes have at most reduced time and effort 10% – 25%.
The next evolution of both microservices and object-oriented programming is Fractal. Fractal delivers a micro app rather than a microservice.
That distinction at first seems slight until outcomes are measured. Those outcomes are revolutionary and partly attributed to a new programming concept – fractal programming.
Fractal means a single developer builds a small system on her laptop with all the features for the eventual production system. Her app may process 25,000 customers out of the app’s domain of 100 million. Yet, those 25,000 customers exemplify most of the use cases for the eventual production system.
This “fractal system” is hosted on a small server, think an Intel NUC costing $5,000. Then the rest of the customers are added; no changes are made to her fractal app. Just add customer records.
Fractal app development is the future because it has shown that about any production app can be built or rebuilt as a fractal. Ninety percent of corporate apps can be built with a small, but representative number of customers, vehicles, endpoints, bills, then scaled to full production in a day or two, not a year.
Fractal is revolutionary because it moves decimal points. Here is an example:
A corporate billing system, with about a million customers, lots of complex rate tables, and billing dependencies is estimated to cost $5 – $12 million. It will take 18 – 24 months to build.
It will take 18 -20 highly skilled programmers, project managers to run. It needs endless system design meetings. It will not be in the hands of the user for 2 years, maybe longer.
Using Fractal, the same system was designed in a month with 25,000 representative customers. In 45 days, it ran with 500,000 customers. In 90 days, a full production billing system was delivered with 1 million customers.
The cost savings was 90%. The time savings was, well, this app was finished before the contract was completed. This is not in the future – Fractal is delivering this today with large, complex legacy apps.
Fractal did not just happen.
Like many disruptions, it is derivative and dependent on architectural and system design concepts.
Fractal is not new. It harnesses well known concepts – map reduce, pipelining and other known, tested computing concepts originating in the 1970s.
Fractal recognizes the complexity of current app development is mostly from current system design constraints.
Programmers do not just write instructions. They interface with scores of tech layers purpose-built to be anything for anyone. Oracle, VMware, middleware, security systems, report writers are the complex building blocks the app developer must use. The app developer needs to array an army of experts in each domain.
A fractal mindset sees the world differently.
Each customer has attributes. Customers perform transactions, like using a cell phone or flicking a light switch. There is something a company wants to do about that customer’s action: produce a bill.
Instead of looking at the world as hundreds of tables, crammed into a relational database, the fractal programmer gathers 100% of the customer data for 25,000 customers in one shard. It’s all there. Then she writes the simple code to process what the customers did – make a cell call or turn on a light. They add up the transactions, do the simple math, and produce 25,000 bills.
25,000 customer bills are in the end user’s hands in a few weeks so they can test the system, add features. Days later, more customers are added and this new “production level” system is run in parallel with the current legacy system. Every line item is reconciled. Every transaction, going back 10 years is cross tested for accuracy.
You won’t find Fractal from the technology companies whose mission is to convert bodies into billable hours.
You will, however, find Fractal in some early adopters who need to move decimal points.