"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.
"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.
"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.
"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 say you can begin the Specification before you meet with the stakeholders. That's crazy talk!"
We begin by defining DSI records to capture the events that are of interest in the space. Most of this is obvious, and we can easily correct our errors and omissions when we meet with the stakeholders. The DSI records make no assumptions as to their use.
"You say that you approach every new system with the same analysis approach. How can that work??"
Every space has data that is of interest. We always start with that. Then the LBs can be defined later. This method always works.
"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.
"You claim that the non-computer staff can design the system with no input from geeks. How?"
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.
"What do you mean by "Transparency"?"
In a transparent paradigm, the stakeholders do the Analysis. A team of Engineers knows how their refinery must operate- what must happen, and what must be prevented.
"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.
"Is DSI a Cloud system?"
Yes, if you want it to be.
"How does Publish and Subscribe work?"
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.
"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.
"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 LB has a socket pair connection to the Broker. LBs can Publish 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.
"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.
"Your System Analysis method is amazingly fast! How is that possible without errors?"
In every space, the things that are “of interest” or “relevant” is quite obvious. And it's easy to add any fields that we missed.
"I am a Systems Analyst and your methods are very attractive to me. I could finally do my job!"
Yes, the SAs will guide the stakeholders in harnessing the DSI paradigm.