One Software, One Vendor, Less Complexity
History - How and Why
Crystal Computer Consulting opened it's doors in 1990 featuring custom programming services. It's founder, Brian Lippincott, already had several years of experience designing business applications for several area small businesses. As the customer list grew, Brian became more and more frustrated with the traditional program development models that he had learned and were widely accepted in the industry. Crystal found itself wasting a lot of time rewriting code to take advantage of newer technology, or to implement similar features over and over again in multiple applications used by different customers.
As the company grew Brian began to realize why large software companies needed so many programmers and support staff. The relationship wasn't linear, but exponential; if you hired a second programmer, he was only 75% as efficient as the first, and the third was only 50% efficient. You could only imagine how little real work was being accomplished by the 132nd programmer hired by a large firm. A search began for the cause of this phenomenon, in hopes that a solution could be found.
A couple causes were identified. The first was a tremendous lack of scalability. Database and program design techniques simply tend to collapse under their own weight. Initial program designs tend to be very specific in focus, and as the programs expand to support more features they become difficult to manage. Most companies combat this by specializing their designers into specific functional areas. This just causes more problems. When different subsystems are written by different groups of people, more resources need to be dedicated to both interfacing these subsystems and to managing these groups so that the users see a consistent interface across the entire system. Soon more manpower is being used to manage the system than to develop the software.
The second cause found was software obsolescence. Computer technology changes quickly and constantly. As new technologies emerged, software needs to be rewritten to take advantage of it.
Some companies choose to never update their technology. For years after Microsoft Windows became the standard in the PC world, DOS applications still existed and needed to be supported. Abandoning the investment in the old program was unthinkable to the developers. Eventually these programs stagnate, and the users will be forced to abandon what used to be a beloved system because it was too old.
The other alternative is to rewrite the code, but this is a daunting task for a mature computer program. All new development needs to be put on hold for months or years to accomplish the task, at a tremendous cost of time and money. In addition to the real cost, the cost of lost revenue and customer confidence can be large when new features are so long in coming.
If solutions could be found to these two problems, lack of scalability and obsolescence, a great leap would be made in the way software was developed and managed. Where would one look for such a solution? The solution was not to be found inside the IT world, so Crystal looked outside, to biology and the human mind.
Why do we develop software in the first place? To assist our brains. The computer, its data, and its software, are all meant to supplement our minds. The human mind is already the ultimate in scalability and non-obsolescence. We can teach it to perform any number of tasks, and we know it will be able to learn tasks in the future that we can’t even imagine today (who would have thought 200 years ago that a human would need to learn how to fly an airplane, or send a text message from a cell phone). How does the brain do this? More importantly, can we make software that can do the same thing - learn on its own. Our quest has now moved into the realm of Artificial Intelligence.
A computer is better than the human brain at storing and retrieving information, so we at Crystal decided to focus on combining the computers innate ability to store and retrieve information with the brains ability to understand that information. To accomplish this, we thought that the computer needed to do more than understand the data it was given, it needed to be able to understand the very nature of information in general. If a computer was capable of this, it would be able to store and retrieve, while also taking on the mundane (and time consuming) task of managing the scalability and obsolescence problems for us.
A "eureka" moment (our first epiphany) occurred when we realized that early humans had already developed a technology that allows for the storing and retrieving of unlimited amounts of information, that was completely scalable, and has proven over thousands of years to never go obsolete: Language. Everything human kind has learned about the world—all knowledge that exists in our minds—has been described with spoken language, and has been recorded permanently in written language.
We went to work creating a data storage system that simulates language. By doing so, we created a process to not just store information, but to understand it. A simple sentence like "The dog is large" could not only be remembered by the computer, but the computer could understand that "large" was a characteristic of the dog. The computer could easily be asked to tell us the rest of the dog's characteristics. Our second epiphany occurred when we realized that our program also could tell us what else was "large" in its knowledgebase. We hadn't intended this, it was just a natural consequence of the simple but powerful algorithms that had been created so the software could understand the data.
With such a powerful knowledgebase in place, we focused our attention on how best to use it. We started by reproducing common business applications (accounting, inventory, billing) within the new system. We learned we could create programs that looked like familiar, old-school applications, but had additional capabilities that just needed to be harnessed. We learned that unlike the systems that became unwieldy (less scalable) as they became larger, our software became easier to develop as it grew. We named the system Epiphany, because it forever changed the way we thought about computer software.
We spent the next few years refining Epiphany. We were expecting problems. We were worried about what would happen when the knowledgebase got too large. Could modern computer technology handle all of that data? Would it be slower and less efficient than traditional software? Would it really be able to handle anything we threw at it? Surely there would be some unforeseen data element or process that would burst our bubble, collapsing the ideal that Epiphany represented. We ran into a few issues that needed to be worked out, but the biggest surprise was the lack of surprises. Whether we used the software for accounting or document imaging, whether is was used in manufacturing, restaurant POS, or the home service industry, the software proved its power and versatility.
Today, most Epiphany customers see the software as a feature rich package that gives them far more for their dollar. Some see it as an alternative to standard industry software that poorly fits their specific needs. Some see it as an alternative to custom software that is expensive and takes a long time to develop. A lucky few have their own epiphany and see the software as we do - a positive and revolutionary change in the way business software works.
