Inside the mind of an enterprise software development organization

My intention with this blog is always to find new ways of delivering insightful content related to enterprise software, cloud, leadership, and new business models in the enterprise.

Recently, I came upon the writing of analyst, Holger Mueller, and was impressed by his depth of knowledge and experience in enterprise software. For that reason, I invited him to write a guest post for this blog. Well, Holger took this to heart and wrote enough material for two pieces, of which this is the first.

Holger's topic is important because software companies, by nature, are technology creatures. By understanding the dynamics underlying a vendor's software development efforts, you will be more successful negotiating, buying, and implementing their products.

Holger Mueller is Vice President and Principal Analyst at Constellation Research, covering topics such as cloud, IaaS, PaaS, Analytics, and SaaS. Mueller provides strategy and counsel to key Constellation Research clients, including Chief Information Officers, Chief Technology Officers, Chief Product Officers, investment analysts, venture capitalists, sell side firms and technology buyers.

==========

Inside the mind of an enterprise software development organization

For some time, I have wanted to explain the inner workings of an enterprise software vendor’s development organization. In my experience, customers usually respect their vendor’s development group, but may not fully understand how a development organization really works. In this guest post, I will explain important aspects of software development inside an enterprise vendor and, far more importantly, offer tips on turning that understanding to your advantage.

Importance of business “fit”

From a technical perspective, enterprise software is often easier to build than consumer products. In contrast, success for an enterprise vendor depends on understanding their customers’ business processes and practices sufficiently well to make the software simple and user friendly. As a practical matter, however, enterprise vendors cannot support every possible business process, forcing software providers to decide which processes are most critical and relevant to their market. Choosing which processes to support, or not, is a crucial decision for every enterprise vendor (and their customers).

Every enterprise software customer should understand this key point, to understand how their needs map to the vendor’s core product focus and design plans. Although configuration or custom development can address some process shortcomings, these solutions are not optimal. Configuration is only possible when the vendor pre-built the choices beforehand, while modifying the vendor’s code with custom programming virtually always drives significantly higher cost of ownership.

To avoid these problems, try to purchase software that closely matches your business processes; if in doubt, verify that your specific business processes are in the product and will continue to receive ongoing development. Ensuring a good fit between your business needs and the product’s features is an essential step when evaluating enterprise software.

Architecture and platform

It is easy to trivialize the complexity of building enterprise products because the software itself tends to be relatively straightforward to write. However, this apparent simplicity masks the complex underlying architecture on which most enterprise software runs; developing and maintaining an enterprise platform is difficult to get right, especially when the technology starts to age and the vendor must reinvent its platform to avoid becoming obsolete.

As a buyer, don’t worry too much about architecture, except to be aware of the important role it plays in enterprise software development. However, be sure to select a vendor that can demonstrate sufficient clients and references to prove their architecture is robust and works as needed.

If your vendor has a limited client base, pay particular attention to ensure their architecture will be scalable and reliable in your environment. In addition, if your vendor makes a significant platform change, reevaluate their products before buying into the new architecture. Right now, three of the top enterprise software companies are undergoing platform transitions: SAP (HANA), Oracle (Fusion), and Infor (Ion).

The enterprise architecture life cycle is ironic because just when your vendor sees greatest adoption, their architecture is probably getting old and may need to be refreshed. It can take years for internal product teams to build applications on a new architecture and for customers to buy and use these products. Therefore, vendors are understandably reluctant to rewrite their architectural foundation unless necessary for technical or business reasons (such as competitive pressures). Nonetheless, most enterprise vendors do undertake periodic architectural refreshes; according to this measure, architectural warning bells may be ringing for popular vendors such as Salesforce and Workday.

The maintenance question

Enterprise software support and maintenance has a bad reputation, because vendors frequently fail to make the value proposition tangible; in addition, vendors sometimes do a poor job maintaining their own software, which makes matters worse. Combined with high cost, which can be 22 percent of the license list price, these factors can create unhappy customers for software maintenance. As a result, third-party suppliers of maintenance, such as Rimini Street, are growing increasingly popular. Despite poor public relations, maintenance is a key success factor in enterprise software because every vendor must address and fix defects.

All software suppliers must find and fix issues in their latest code, but on-premise vendors must repeat this process in all iterations of maintained releases. For each product release, the vendor must locate the issue, create and test a fix, and finally ship it to customers. Companies such as SAP and Oracle may support up to seven earlier releases, making maintenance a daunting challenge; you can imagine it’s no fun to repeat this find, fix, and test drill seven times! Despite the challenge, maintenance is essential to the vendor’s success; moreover, you deserve to receive high quality fixes in a timely manner since you pay for them.

Changes in statutory requirements over time make maintenance more difficult, because they can force software companies to update their applications continually. In addition, these regulatory changes may require on-premise vendors to update old releases dating back many years.

Although vendors may actively fix known defects in current software versions, be aware they may be less diligent finding and fixing problems in older software. For this reason, try to avoid remaining on “orphan” software that the vendor does not actively maintain. As a simple rule of thumb, as long as more than a 1000 customers are on the same version, you are probably safe.

Does SaaS make it easier?

True software as a service (SaaS) vendors promise that all their customers are on the most recent software version. Given the challenges of maintenance described above, it is clear that SaaS is highly beneficial to the vendors. With SaaS, vendors only need to maintain one set of production code, which reduces complexity and lowers their costs by avoiding the messy on-premise problems described earlier. By continually upgrading their entire client base to the latest version, SaaS vendors eliminate the need to maintain multiple configurations and older releases.

Today, SaaS is just growing out of its infancy. As these vendors mature, they are likely to face co-existence challenges between new platforms they develop and old ones that customers continue to use. Other growing pains include significant discussion among SaaS customers about the pros and cons of user interface changes that occur when the SaaS vendor releases a new version. Although many SaaS vendors “turn off” new features by default, customer training is an issue shared by both on-premise and SaaS vendors. Because the SaaS industry is relatively new, vendors have avoided many configuration and release complexities faced by on-premise developers, but the future may not be this easy.

SaaS customers should request their vendors for long transition timeframes when significant changes occur in either functionality or architecture. In some cases, vendors will offer customers an upgrade window extending up to nine months after releasing the change. However, be aware that demanding this flexibility may negatively affect your vendor’s ability to develop functionality and maintain software quality.

Final thoughts

Understanding the mind of enterprise software development can help you gain most value from your investment while minimizing cost, time, and hassle. Therefore, be sure to consider these four points of advice:

• Be sure there is good fit between the software and your business process requirements
• Understand the dynamics behind software maintenance
• Stay on current releases with other customers to ensure the vendor actively maintains your software version
• SaaS customers should ask their vendors for plenty of time to transition users following significant product releases

==========

Thank you to Holger Mueller for writing this guest post.