Why You Should Ask Your Vendor How Your Enterprise Software Is Developed and Not Just How It Works - Mitratech

Why You Should Ask Your Vendor How Your Enterprise Software Is Developed and Not Just How It Works

Selecting any enterprise software can have a long lasting impact on your company and even your career. The right ELM software can impact an entire corporate legal department in a positive and cost effective way. However, the downside of making a wrong decision in the purchase of any enterprise software is huge. Make a mistake and you could be fighting fires and wishing you had a second chance at your choice.

Of course during the vendor selection process the obvious questions need to be asked regarding how the software works, what feature sets you will purchase, limitations, and how it will integrate with existing systems. You will also most likely ask about warranties, support, and company stability both financial and experiential.

However, chances are it may not occur to you to ask what many experts consider the most important question of all– how was your software developed?

Why is software development as important as its warranty, features, and functions? Let’s look at how experts approach developing the world’s most important pieces of software. Take for example a sophisticated device like the pacemaker. This little gadget literally cannot fail. If it does, the owner may just keel over dead. The pacemaker has been around in at least prototype form since the early 1930s. Of course, those early versions had no software. A modern pacemaker utilizing a microprocessor and associated software is reliable and adaptable, dynamically adjusting its function on a heartbeat by heartbeat basis saving many lives every year.

Over the past 70 years manufacturers of pacemakers and the FDA which regulates their construction and design learned important lessons about how to make something so critical to the life of the owner work absolutely without interruption. A pacemaker is rigorously tested both during development and during manufacture, but the FDA learned that this is not enough.

Through the years the electronics, materials, processors, and software used in a pacemaker have become more and more sophisticated. The FDA learned that makers of these devices needed to have rigorous manufacturing and testing controls, but somewhat surprisingly they learned that software was unique and that software quality did not improve when it was looked at as just another electronic or mechanical part. In fact, software presented new challenges to the FDA and manufacturers of pacemakers.

So how does this impact your choice of a matter management provider? Consider the following remarkable statement directly from the FDA:

“Software quality assurance needs to focus on preventing the introduction of defects into the software development process and not on trying to “test quality into” the software code after it is written.”

Or this one: “……. software engineering needs an even greater level of managerial scrutiny and control than does hardware engineering.”

General Principles of Software Validation; Final Guidance for Industry and FDA Staff (Jan 11 2002):

Software that is put together without proper controls and with haphazard “code-from-the-hip” philosophies may appear on your desktop quickly, but that instant gratification will be short lived as bugs and hastily constructed custom applications could break under even rudimentary stress. Any enterprise level software for ELM will likely be complex, perhaps containing millions of lines of code. Bugs are inevitable, but if the product was developed with a robust process in place they will be fewer in number and quicker to resolve than otherwise.

To sum up, a good set of questions for any software vendor might be as follows:

  • What process do you use for development? Your vendor should be able to tell you about their process in detail, e.g. Agile, Waterfall etc. Software development without a well-defined process is like driving a car at night without headlamps.
  • What kind of automated code analysis does your vendor do? A first class vendor will do what is called static and dynamic code analysis, utilizing sophisticated tools to help prevent human error when code created long before it reaches an end user.
  • What kind of process does your vendor use to prevent security flaws? Do they utilize tools to automatically detect defects as the code is being modified, or do they entirely depend on finding security flaws once all code is complete? Black box testing after the code is complete is not effective in finding many critical flaws.
  • Does your vendor do peer code reviews? Every new line of code should be looked at by another qualified human before it becomes part of the product. Checks and balances like this reduce the chance of human error.
  • Do they incorporated extensive automation for testing, or do they simply rely on human black box testing? Short-cuts are often taken in the development of custom enterprise software which can work through the most common use cases but fail miserable when anything slightly unusual is encountered. So buyer beware.
  • I was once asked by an executive how software could “break”; after all, the computer always executed the same instructions time after time. He could understand how a mechanical thing could break or wear out, but how does software break? It’s all bits and bytes right? I explained by saying that software did not really break, but that since the type and variety of data entering the application was essentially infinite there is always a chance that the software can encounter a completely untested set of circumstances and then fail. This is why the FDA focuses so much on the process of coding for a critical thing like a pacemaker. Since testing quality into the software is futile, design, code craftsmanship, and real time quality and security monitoringduring development are essential. If your ELM vendor does not understand this, raise some flags!

    Comments are closed.