[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).