"I need certainty in IT project costs. We cannot have these constant overruns in cost and time."
We capture all the data that is "of interest", in DSI records. Then we support the analysis of this data in ways that are useful - now or in the future. We never close doors, we leave all options open.
"We need effective Business Intelligence from our systems. Our past investments in MRP systems have failed to deliver the benefits promised."
DSI records capture every event that is of interest. These records can be analyzed in every way imaginable, at any time. So your BI goals can always be met. When the data is captured, nothing about its analysis is presumed. No doors are ever closed.
"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.
"We are under constant pressure to reduce costs by outsourcing the work."
The DSI analysis and the LB definitions are done by the Stakeholders. The building of the LBs can be contracted to outsiders - possibly working from a home office. Like the old Putting Out system of production.
"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.
"Our systems cannot cope with the Internet of Everything."
DSI is IoE. DSI records are "of interest" without regard to the eventual uses that may be made of them.
"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.
"My project is late and I have been ordered to speed it up with more developers. But that never works."
In the DSI world the LBs can be created in parallel. If there are 5 Developers creating one LB per week then 25 LBs will take 5 weeks.
"My best Developers are bailing to become System Analysts. They are burned out."
This is because the work has been too difficult. Not so in the DSI world.
"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 two 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.
"I can find lots of recent graduates but very few experienced Developers."
Recent grads will create loads of quality LBs. We can prosper just fine using them.
"I can't find the Cloud Developers I need for my projects."
DSI is cloud. The only API for LBs is messaging on socket pairs.
"As soon as a Developer gets experienced, he leaves!"
We can prosper with LBs created by recent graduates.
"I can't find Business Analysts who understand our business."
Your best BAs are your stakeholders. DSI is transparent to them, so they can create the Analysis just as they need it to be. Now, and next week too.
"Your system uses Linux but we do not have that skillset in our shop."
The LBs run in the OS and language of the Developer's choice. The Sysadmin only deals with socket pairs and DSI messages.
"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.
"Can you use the Raspberry Pi?"
Sure. The pi runs Linux and has a fine ethernet port.
"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 to avoid conflicts by permitting multiple versions of the same Logic Box. How can that be affordable?"
LBs are only large and complex and expensive if you let them become so. So don't let that happen. Small and simple LBs are inexpensive to build and test.
"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.
"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.
"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.
"Can you use Elance talent to build the Logic Boxes?"
Surely! The best Developer for a given LB might be in Romania or NZ.
"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.
"Tell me about Disaster Recovery."
Each LB has DR as a requirement. It is tested and assured before the Developer gets paid. Just call back the historical DSI records from the Librarian and your LB DB's are all refreshed to the pre-disaster state. Carry on from there. No big drama.
"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 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 XML message composed of data fields that are "of interest". Meaning "relevant".
"IT systems are a major competitive driver for our business. But they are too costly."
Development of a DSI system can be very economical, and fast. And flexible.
"IT projects sometimes fail to deliver, or are canceled. How does your system differ in this risk?"
The DSI project will proceed methodically. DSI records are defined to capture all that is of interest. Then the LBs are defined and specified, and built to order. Then tested and installed. There is steady progress, and constant Deliverables. What's to fail?
"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.
"We need a method to document production processes for liability protection. Can DSI help?"
Yes. Since the DSI records are stored indelibly in the Archives, they can be of evidence quality.
"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.
"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.
"Your system stores data that nobody needs. This is a wasteful extravagance, and foolish."
Hardware resources are nearly infinite and nearly free. This redefines “waste”. What is not useful today may be critical tomorrow.
"We use mainframe computers because we are I/O intensive. We can have 1,000 users doing 100 transactions per second."
Each user creates a DSI record every few seconds. These are easily processed via TCP/IP. Processing capacity can grow as required to handle the load. Users type slowly and there are 1,000,000 uS in every second that passes. We can do lots of processing during the user response gaps.
"We can't afford to hire recent graduates and train them, only to lose them to another shop. So we only hire experienced Developers. But there are too few of them."
LBs can be built by recent grads. They are small and contain a modest number of function points. The Analysis is done by your stakeholders, not by Geeks.
"My company sends invoices for electric energy and sometimes the amount charged is outlandish. I need a "sanity check" that is independent from all other systems, to check and approve each invoice before it is printed and mailed."
In DSI there would be a DSI record published for each invoice. Today the subscriber would be the printing department. But you could easily place a sanity check LB into this sequence. This new LB would have access to all the DSI records in the Archive, so it could certainly check that this invoice is reasonable. If not, then it would not be published to the printing dept, but instead a new DSI record would be published for the CIO's attention. Then a team would swing into action to track down the cause of the insanity.
"We need to be compliant with the new CASL law. Can DSI help us with our marketing communication challenges?"
DSI would be a good way to manage your marketing emails. Each subscriber would be described by a DSI record. Each Unsubscribe would be a DSI record. So it would be easy to check each address before sending. Each email would be described by a DSI record, showing the intent, category, stage of interest, etc. This could be built into a super contact management tool.