HarrisData Blog

[This post is the eighth of a series defining software quality].

Software vendors spend a huge portion of development budgets on software quality, yet industry news is filled with examples of software failing during implementation. Why can’t the vendors get things right with software quality? Part of the problem is that software products are complex logical systems (especially ERP products) and share a key characteristic with all complex mathematical and logical systems:

if such a system is also capable of proving certain basic facts about the natural numbers, then one particular arithmetic truth the system cannot prove is the consistency of the system itself

To put it in plain language modern software products are complex enough that no quality program can be created which can be proven to remove all errors. This leads some vendors to give lip service to quality and produce good enough software, but most realize that in order to attract and retain customers a serious quality effort is needed.

Even though we cannot create a proven quality program, some approaches to quality are known to be more effective than others:

Quality demands requirements specifications in enough detail that the products produced can be quantitatively measured against those specifications. Many organizations are not capable or willing to expend the effort to produce specifications at the level of detail required.

This is the most important effort in any quality program – requirements document what the customers need and expect from the software product. From this foundation flow a series of quality assurance opportunities. As developers translate the requirements into a product design, quality translates requirements into a test plan, and tech writers draft documentation. These must be compared and corrected before any code is written. As programmers code the design into software, quality prepares test cases and sample data, and a second draft of documentation is written. Once these are completed, quality is able to execute the test plan through automated and manual test cases and quantitatively measure results. The end result is software, supported by documentation, which meets the requirements and performs to expectations in customer environments.

HarrisData’s Aggressive Quality program is based on the idea that documenting customer requirements is the most important thing we do. Effort spent on requirements not only ensures customer satisfaction, it saves valuable time and effort downstream as we transform requirements into software products.

[This post is the seventh in a series defining software quality].

Software vendors often try to cash in on their customer footprints by operating as a one stop shop – providing everything the customer needs. The problem with this is not that sole source can be very expensive (it is), but that no software vendor knows everything. When software vendors solve unfamiliar problems, quality suffers. Once again, a software vendor desire to gain monopoly power (and profits) should be balanced by the customers’ agenda to solve actual business problems with quality solutions at a reasonable cost. Software vendor partner programs offer one step in the direction, providing customers some choice when extending business solutions. For many software vendors, partner solutions too add monopoly control and profit as commissions or finders fees are charged behind the scenes [ed. HarrisData does not accept commissions or finders fees from our partners], or requiring partners to gain certification at a substantial fee [ed. HarrisData asks potential partners for customer references using the combined solution]. What happens when the customer prefers a product not on the vendor partner list? Will maintenance and warranty services continue?

The route to quality is to open the software product to whatever combination of add-on product or custom programming maximizes customer return on investment. This is the key to Open Architecture. In practice such openness requires standards, documentation, and source code. Applicable standards include Service-Oriented Architecture (SOAP), Web Services Architecture, HTML. Use of data transferred between the vendor product and other applications requires plain language definition of what the data elements are used for – information provided in technical and user documentation. Manuals addressing How to Interface to Product X are particularly useful here. Access to product source code allows the customer (or the customer’s agent) to identify and access any data not included in vendor supplied program access points. The vendor’s high quality execution of these elements allows the customer a low cost escape route from the vendor’s monopoly power.

Unfortunately, it is still possible for a vendor committed to an Open Architecture to exert monopoly power to constrain customer options. Software vendors extend monopoly power through the use of proprietary technology by requiring vendor approved certification programs for partners (e.g. NetWeaver, .Net). Open technologies free both customers and partners from this obstacle to success. A software vendor might choose Java, PHP, or HTML as open technologies with thousands of potential partners for customers to choose among. Customers then choose the combination of product capability, cost, and availability that meets their needs (not the vendor’s monopoly desires).