This sounds like a story
Let’s start by defining it so we’re on a level playing field. Software bit rot is best viewed by a word picture of a software lifecycle. A piece of software that is started for a single purpose (a ‘Solution Architecture’) gets some traction and has had many additions added to it based on customer requests. This software gets to the point where something added or fixed over <here> break things seemingly unrelated over <there>. The complexity of the software has exploded far beyond what the original architecture intended, and it is now brittle and hugely expensive to add functionality.
Bit rot is growth in complexity of software beyond what the initial architects designed for, or the architecture was beyond their capability.
So, how do you combat bit rot based on a vision of future complexity that isn’t a requirement right now?
You start with an architecture that is complex enough to handle some imaginary set of requirements that is huge.
That’s the way we’ve done that here at Spieker Point with our DECK DecisionWare software platform. We’ve used our experience to start with a planetary-scale complex architecture. Over time, we’ve rested bigger and bigger customer problems on top of DECK to prove it out. Over time, we’ve demonstrated that DECK is a framework that is nimble for medium companies with small-ish problems, but also beefy for large companies with large problems. Generally the same problems, just a very different scale.
We started building DECK without a specific customer. We envisioned a future customer who wanted to use DECK for a country-level financial backbone. Think: trillions of transactions moving between massive sub-systems, huge analytics, business processes triggering users to be aware of emerging situations, big policies requiring compliance tracking, hundreds of thousands of users, etc. All the while, it needs to be cool, easy to use and understand without manuals, by the most basic user on a web browser.
This way of architecting software without a specific customer in mind is often called a ‘Reference Architecture or Framework’.
DECK is a completely decouple architecture. In simple terms, a piece of data enters DECK (a monthly revenue result, a piece of IoT sensor data, a request from a user to self-register, a user making a credit card purchase, etc) and is put in an input queue. A module in DECK pulls the next piece of data off the input queue, inspects it, and makes a decision on what needs to be done with it. Perhaps it’s an IoT measurement that first needs to be normalized (eg. scaled from a binary value to degrees Celsius, and it sends it off to the normalization queue. The module at the end of the normalization queue then picks the data off the queue, does the required calculations, and perhaps sends it over to the routing queue, which takes care of sending a copy of the data to the analytics queue so that it can be included in a visualization AND sends it over to the database queue to be saved.
A decoupled architecture is completely modular and it ‘Scales’.
‘Scaling’ is an industry buzzword these days. It can be used as a question and as a response. Example:
Customer: “Does it scale?”
Vendor: "It scales!"
Translated, the question means: as my business grows and 10, 50, or 1000 times more data is thrown at the software compared to what we have now, will the software still perform?
The quality of the answer depends on several factors. Not to pick on
DECK scales very well. As the pressure from the input data grows, the queues grow. The size of the server DECK sits on grows to a point where it spills over to multiple servers. Each queue and resulting module picking data off of it can be on a completely separate server inside of a cluster of servers all working together. In other words, DECK is completely ‘cluster aware’ and it adds computing resources as the data pressure grows.
Here’s another way to think about the importance of scalability in light of this queuing technology and subsequent cluster infrastructure. Let’s say a piece of data comes in that needs to be part of a big,
The big advantage of this architecture is that new modules can
This type of architecture is expensive to build. It takes software architects and developers who are at the top of their game and have had experience. It takes a vision of future clients with complex problems that are worthy of spending the time to do it right from the very first line of code 6 years ago.
That, dear readers, is how Spieker Point ensures that DECK DecisionWare is going to be with you well off into the future.
Do you need software that meets you where you are now as a medium size business and grows with you as your business takes off? If so, we know you’ll appreciate DECK DecisionWare! Oh – and you’ll simply LOVE the price!