"We need the ability to handle late-arriving changes at a reasonable cost and time. Because the competition is always in flux!"
We can change the DSI records at any time by adding fields. We can change the logic at any time by revising the Logic Boxes. Only a few LBs are affected by any change you can imagine. No doors are ever closed. We welcome and celebrate change.
"The last 7 projects that I have been assigned to have been canceled before completion. I don't feel that I am contributing to the corporation."
Every project is launched to meet a perceived need. Sometimes the need evaporates, but more often projects get canceled because of cost and time overruns. These are rare events in our DSI world. Generally, a DSI project will proceed as planned.
"Bjarne Stroustrup says it takes 10 years to get good at Object Oriented programming. That's too long!"
Our LBs are “Objects” that we can live with. It takes at most 10 weeks to become adept in this work. It's not Rocket Science.
"The amount of damage that a poor programmer can do is huge!"
In the DSI world a weak LB can be detected and repaired or replaced. Poor performance will be flagged in the acceptance tests.
"Disaster Recovery is hugely important to us, but we don't have a good way to do it. Nobody is confident that our plan will work when needed."
DR is a design requirement of every LB. It is simple to requisition the necessary history from the Librarian and re-build each Data Base (DB) in every LB. So DR is easy to test and verify. It's not a big deal for us.
"Security is hugely important, but we don't have good ways to ensure it."
In the DSI space we can lock down every TCP/IP stack so it responds only to DSI records that arrive at a socket pair. This prevents unwanted access. Supervisors can watch every DSI message, looking for unusual traffic. The most secure systems are immune from insider exploits.
"Personality conflicts are devastating to our progress."
Yes, Developers as a class are often lone wolves. They need to do it their way. In the DSI world the Developers are assigned LBs and they can work alone. They do not control the large system design. Further, the Developers will seldom meet each other. They generally do not have a need to know the big picture. So the conflicts are eliminated.
"Software bugs are inevitable. Nothing can be done."
Bugs are not inevitable in the DSI world. The LBs are kept small so a Developer can understand the whole of it. LBs are tested before use, with a focus on boundary conditions. The only API is DSI messages. Disaster Recovery is a requirement of every LB and this is tested before acceptance. LBs are "Objects" that we can live with.
"We have Legacy systems that are hard to maintain and impossible to re-engineer."
You can re-engineer a Legacy System by tracking its inputs and outputs with a DSI system. When the outputs always concur, then you can retire the Legacy.
"I like Development work but I can't stand the hours. I have kids at home."
In the DSI world the LBs can be built in the wee hours while the kids are snoozing. LBs are not allowed to get large and complex. So the development work can be scheduled.
"The stream of late-arriving changes are devastating to our project plan. We are constantly re-doing the work that was completed. There is no obvious way to make the changes."
DSI welcomes change. Bring it on! Change is not disruptive for 2 reasons: 1. DSI records can grow new fields. 2. One or more LBs will have to change. The remaining LBs and the remaining DSI records are not impacted.
"We're supposed to be Agile, but there's not much support. The Developers are all lone wolves."
DSI is inherently Agile, meeting all 12 requirements. Conflicts are rare. Developers are free to work alone creating LBs.
"The Object-Relational "Impedance Mismatch" is a huge problem for us."
In the DSI world the Data is publicly owned and is always available from the Archive via the Librarian. We have a perfect impedance match.
"Why do you call your system a 'paradigm'?"
It's a method. It separates Strategy from Tactics. There is always a Strategy, which can be broadly understood, by both Civilians and Geeks.
"What broker software does the system use?"
RabbitMQ. It's open source, easy to use and runs on all major platforms.
"What container technology does the system use?"
Docker. It's easy to fine-tune and works on any system.
"You claim that the Developers on the job do not need to meet, ever. How can that be?"
In the DSI world, it's not the Developers who do the Analysis. It is the stakeholders. Developers only build the LBs that are required.
"You claim that the Developers on the project have no need to know the whole picture. How is that possible?"
In the DSI world, it's not the Developers who do the Analysis. It is the stakeholders. Developers only build the LBs that are required.
"Are your Logic Boxes really just Objects as in OO?"
Yes. But with a perfect impedance match.
"What is new about your paradigm?"
Nothing. It's all old, from the early days of computing. Except that today we have copious and very affordable resources available to use.
"How long does it take to learn your paradigm?"
Not long at all. A few weeks. It's just common sense.
"How much experience does a Developer need?"
The LBs should be of the order of complexity that is common in college course assignments. So recent graduates can do the work.
"What computer language do you use?"
The DSI infrastructure is built using Java running in Linux. The LBs are agnostic, so the Developer can freely choose his OS and language. The only API is socket pair XML messaging.
"What OS do you use?"
The DSI infrastructure is built using Java in Linux.
"Is DSI a Cloud system?"
Yes, if you want it to be.
Each LB has a socket pair connection to the Broker. LBs can Publish XML messages. LBs can also Subscribe to message types. The Archive Subscribes to every message type and saves it forever, as if chiseled in stone.
"How will I share my database with other Logic Boxes?"
You cannot. Your DB is yours alone - it is “green”. If other LBs need the DB they must create their own version of it. Since the DBs are created from the same DSI records, they will be identical.
"How will I coordinate with other Logic Boxes?"
You can only Publish DSI records to which they Subscribe.
"How do I send a message to another Logic Box?"
You must Publish a DSI record to which the other LB Subscribes. Your message will be Archived forever. It is not private.
"How do I send a message to an external service like Syslog?"
A few LBs will be designed with external ports for things like Kiwi Syslog, Credit Card authorization, etc.
"Do the Logic Boxes use State Engines?"
Yes.
"How much assistance do you supply to Developers for their Logic Boxes?"
We make it easy to get started with DSI. Our infrastructure provides the Router, Archivist and Librarian. Our Logic Box support includes Publisher, Subscriber and state engine.
"Can a Logic Box be tested independently?"
Yes indeed! Since the only API is DSI messages over a socket pair, it is easy to set up a test bed to assure operation as intended. This is part of each LB Specification. Also each LB is tested for disaster recovery.
"Can a faulty Logic Box be replaced by an improved Logic Box?"
Yes. The circumstances of the failure are in DSI messages. So one can play these messages through the repaired LB to prove that the problem is fixed.
"Can I test a new Logic Box by feeding it historical data?"
Yes, this is very common. It is due diligence.
"What is the Librarian?"
The Librarian is installed with the Archivist. Its job is to collect old DSI records that match the request of a LB and deliver them via FTP.
"What is the Archive? Where and how many?"
The Archive is a column database that stores every DSI message, forever. The store is indelible meaning that DSI records can never be altered, only read. Write once, read many. There are multiple Archivists, as many as you like. One might be under your roof and another might be on a different continent.
"Can your system be run locally, with no Cloud connections?"
Yes. The connections are socket pairs over TCP/IP so distance is immaterial.
"Do you have a fall-back plan for use when I lose Internet connectivity?"
If the Internet is down you can fall back to telephone modem or a tethered cellphone. The DSI messages are often fairly infrequent and short, so dial-up is practical.
"Can I run a local Librarian on my LAN, for high speed lookups?"
Yes, you will choose to do this for some applications.
"What Database does the Archive use?
Cassandra, which is a very fast Column database. It is not a Relational Database.
"What Database(s) can the Logic Boxes use?
Any DB you like. Graph, column, relational, whatever. Since the DB used inside each LB is green (there will be no other users), you are free to chose the best DB for the mission of this LB. How liberating!
"Can I use Triggers in my Legacy Database to generate DSI records?"
Yes, this is commonly done. It's an easy way to tap into a Legacy system without disturbing anyone.
"What is a DataStreamInfrastructure (DSI) Record?"
It's an XML message composed of data fields that are "of interest". Meaning "relevant".
"We frequently need to customize our main application. Can DSI help with this challenge?"
Yes! Customization means custom LBs. The required changes are easy to define and easy to implement.
"When we fix one bug we often create 2 more. This sucks."
Bugs will reside in the LBs. Since the LBs are small and contain a modest amount of logic, faults are rare.
"Our programs are too large and complex, so nobody understands them. This seems to be inevitable. How do you avoid this trap?"
We do not permit any LB to become large, obscure and unwieldy. We slice and dice the logic so it is easily manageable. The LBs are "Objects" that we can live with.
"Stakeholders are so indecisive! It's always, 'I'll know it when I see it.'"
We accept: "I'll know it when I see it."! Our job is to be there when the light dawns. There is always a better way. Nobody is clever enough to see the best way at the outset of the project.