Customer Choices for Achieving Growth

Savvy Customer Has a Choice

Turning towards existing customer bases as a mainstream of revenue can be a gamble. While the odds may be better for the "Big Few," (vendors with over 20,000 customers and revenue of at least $1 billion USD), as some will argue, there is still notable risk involved. After all, these market leaders want to introduce a new product or concept that will directly challenge the model that has made them successful so far. There is certainly no guarantee (or even a strong indication) that a configurable set of process components or Web services will appeal to buyers used to buying broad, pre-packaged enterprise application suites, nor is there any indication of what they will pay for license fees for new add-ons and integrated solutions. Even if the paradigm shift takes place, competition will still exist among the Big Few and smaller vendors, that will also adopt the new model.

Nonetheless, there is another way to look at this shift: compliancy and standing still is a greater for any leading vendor when even moving too slowly is risky.. Despite some sporadic regional revenue increases, the overall trend in recent years has been for bigger enterprises to spend less on large, packaged enterprise applications. As a result, new, overall license sales growth for high-end business applications software has been slow, flat, or falling. Further, if application license growth remains subdued, a potentially greater danger is that it will translate into slower services revenues.

As traditional markets have dried out, vendors have had to pursue new avenues for revenue growth, which has logically led to increased maintenance fees for existing customers. Although discounting new accounts or up-selling older ones has intensified among competing vendors, maintenance fees have not been affected. This will likely change as customers rebel from paying for upgrades they may never need and for licenses they hardly use. Packaged enterprise systems are also still perceived as expensive, and difficult to integrate, modify, and extend. For example, the vast majority of all enterprise resource planning (ERP) customers are using software versions that are several years old. In SAP's case, more than half of all customers are still running on SAP R/3, which was nominally replaced by mySAP ERP in the late 1990s.

Moreover, some enterprises whose products are expressed in IT, like telecom and financial services, have already left the packaged and "best practices"-based software model. They are now investing in building an independent integration layer. Whether the layer is homemade, from a vendor, or is Web services-based, or if it is some combination of the above, it will give enterprises independence from any vendor. They can afford to buy software from a relatively unknown, unsafe vendor because they can isolate any component in their architecture and communicate with it relatively cheaply and flexibly. If the vendor goes out of business or is acquired, the enterprise can still make a rational decision about whether to plug-in something new or to support it themselves, if need be.

For these reasons, some, like the Sweden-based, mid-market, ERP vendor IFS, are trying to differentiate themselves from the many other (mighty or not) vendors that try to confine companies to a particular proprietary technology, such as Oracle or Microsoft. These two giants are ubiquitous and own the entire technology stack (layers) ranging from database, via middleware and development tools, to applications, which even includes business intelligence (BI) tools. IFS's approach may be somewhat in tune with the erstwhile, pre-acquisition PeopleSoft, Intentia's, and SSA Global's approach which leverages IBM's more open technology. IFS' strategy also resembles SAP's NetWeaver technology approach; however, it should be noted that certain elements of SAP's platform, such as SAP Web Application Server (SAP Web AS) and ABAP/4 language, are still proprietary to SAP. Yet, even this may change as there is an ever-increasing influence of Java openness for new, overlaying SAP components.

Unlike SAP's partial openNess, IFS, uses completely openly available tools and technologies. It plans to offer a choice of several Java 2 Enterprise Edition-based (J2EE) application servers such as IBM WebSphere, Oracle Application Server 10g, BEA WebLogic, Sun ONE. It will even offer Jboss, an open source application server. Certifications for some of these are still in progress. IFS still recognizes that its approach makes it easy for clients to implement other systems besides IFS. Yet, the vendor believes that if it makes it easy for users to replace its solution, clients will be more inclined to keep their IFS solution. This is, by all means, a progressive view that seems to be slowly pervading both users' and vendors' minds.

Thus, following this approach, some vendors have been doing well in some sectors. For example, despite its poor performance of late, a J2EE-based applications platform provider, BEA Systems still does well in the financial services sector, which is one of the few verticals that is not largely dependent on the backbone of any enterprise applications vendor to run business. With BEA's products and growing developer community, it hopes to become more strategic in the next generation of Web services-based, heterogeneous computing. This should allow customers to reconsider best-of-breed as an alternative to daunting, never-ending upgrade cycles and costly, complex packaged solutions.

Very recently, and coinciding with IBM's SOMA approach, BEA offered a free Web-based tool to quantitatively measure a prospective company's "baseline" for pursuing an SOA strategy. The tool, called the Service-Oriented Architecture Readiness Self-Assessment is built around BEA's SOA Domain Methodology. It focuses on six areas of an SOA: architecture; building blocks; business strategy and process; costs and benefits; organizations and governance; and projects and applications. The vendor hopes this will take SOA from hype to something users can actually realize.

This is Part Three of a three-part note.

Part One detailed recent events that may change the business model of major vendors.

Part Two discussed how the Big Few vendors will cope.

Focusing on Delivering the Best Solution

As a result of these new developments, technology user lock-in will inevitably have to be replaced by delivering the best solution for the customer, even if it includes some components from competitors. If one looks at a combination of Oracle and PeopleSoft applications to Oracle's infrastructure platform; SAP applications and SAP NetWeaver; and IBM's technology and its consulting capabilities, one can see that these vendors are all fairly comparable when it comes to providing large corporations with business process-oriented solutions.

In the IBM grand schema of things, business processes, which are the building blocks of business innovation, will be created from an individual, consulting project that leverages underlying applications, as required. The vendor providing the enterprise application can be almost anyone with a worthwhile solution. In SAP's view, however, business processes are part of the core functionality of mySAP Business Suite and some selected third-party applications. This, along with new processes and Web services, will form the building blocks of the next-generation of applications.

Oracle has a similar vision, although some will note that its technology roots are typically much deeper than its applications. Oracle's understanding of how software is developed and deployed stems from nearly three decades of delivering market-leading database and tools technology. It is also stimulated by a million or so experienced Oracle developers and database administrators (DBA). Compare this with SAP, which is still a relative newcomer to the technology arena.

But, SAP and IBM will gladly point out their industry savvy and their respective application leadership, that go far beyond mere, unified data control and cost-cutting by reducing the number of database servers. The problem is that in the real world, most user enterprises have to live with many data repositories, and here flexibility is often more important. Large applications need to be broken into many smaller parts that can be rearranged or put around various events. Like SAP, Oracle has been busy wrapping its traditional application programming interfaces (API) with Web services interfaces and is actively building more, but it remains to be seen how far in granularity it will go. IBM may also be an unavoidable choice even for once hesitant Oracle, as no one would want to forsake IBM's mindshare, consulting and infrastructure expertise, and customer base. Support from the likes of Hewlett-Packard (HP), Sun Microsystems, Fujitsu or BEA will be important too, but IBM should remain the first choice.

The ultimate winner in the market will have to provide industry-specific solutions that solve essential problems that others cannot. The vendor will have to have deep domain experience coupled with industry-specific product functionality that will insure successful implementations. It also needs to offer an integrated suite of industry-specific products that satisfy current customer requirements. Finally, it must provide an enhanced roadmap for customers potential long-term needs (for more information, see If Software Is A Commodity—Can You Still Win Some Competitive Advantage?).

Yet, no one can yet (and will ever) be all things to all people. To be successful and reach as many customers as possible, the Big Few vendors will have to recruit consulting and development partners or make more focused acquisitions in their respective corners of the world. And this is what SAP did with its recent acquisition of DCS Quantum, a vehicle dealer system from DCS Automotive, a subsidiary of UK-based DCS Group PLC. This solution will be integrated into SAP's existing automotive industry suite and will be known as SAP Dealer Business Management.

Large vendors have also been seeking to recruit smaller, specialized vendors in the under-exploited retail segment. Because retail's precise requirements, such as getting the right mix of merchandize onto dispersed stores' shelves, retailers have long run their businesses with heavily customized in-house systems, instead of opting for more standardized off-the-shelf packaged applications. Consequently, Oracle and SAP began a tug-of-war to recruit Retek, an obscure, small vendor that nonetheless carved a notable niche providing complex solutions tailored to the exacting needs of retail chain stores and other merchants. Oracle was, the ultimate, overpaying winner (see Retail Market Dynamics for Software Vendors).

To secure its place in this new market order, Oracle, which has recently made a flurry of acquisitions will have to prove to the market that its high profile acquisition of PeopleSoft is part of an "assembler" strategy rather than a "consolidator" strategy. Consolidators provide solutions to disparate customer bases with minimal or no integration between acquired assets. The acquisition strategy is driven by a larger scale or specific, financial model and metrics. However, the assembler strategy is driven by specific vertical requirements and a solution model. Oracle needs to show that its acquisitions are intended to provide enterprise solutions with "best-of-both-world" functionality and domain experience.

Recommendations For Vendors

Vendors need to make a painstaking strategic decision, and then pick where they want to be and execute their strategy to get there. To be part of the Big Few, they must either grow their client base at a rate faster than the market and their competitors, or find the capital to grow through acquisitions. The latter may be harder to do given these still difficult economic times. Also, vendors should target the anxious customers of their competitors that are financially struggling or are undergoing troubled acquisition migrations. Also, as many vendors will take their flagship products through a profound architectural change, they have to explain to their customers why it is necessary to spend the time to really grasp what this will mean for them.

To be a boutique, niche vendor, vendors must focus on one or a very limited number of verticals or regions, and excel at serving those customers. If a vendor does not pick between these two strategies, it will either end up as a collected company, owned by one of the Big Few, if lucky or by having a solid value proposition like a large customer base or a non-emulated vertical solution. Otherwise it will face oblivion. If a publicly traded vendor that does not want to be acquired, then the vendor needs to think of some defensive moves prevent acquisition. Going private, which is possible through an infusion of private funding, repurchasing outstanding shares to ensure majority voting power. Maintaining only a necessary level of cash, resorting to the "poison pill" shareholders provision, merging with a peer as to make any future acquisitions too awkward for the predator, and so on are other strategies. Conversely, if a vendor wishes to be acquired, the house needs to be in order by keeping expenses in line, if not by growing the top line.

Recommendations For Users

The recent events of merger-mania will have a deep impact on how customers evaluate vendors in the future and what kind of relationships they will create. We suspect that most end users organizations will weather this storm, despite some overcast skies, that possibly hover over some PeopleSoft and J.D. Edwards' users.

On a more general note, the larger the install base for the products you are using, the safer you should be. If not the new owner, then at least some implementation partners will have heavily invested in the software, and they will likely gladly oblige you with ongoing support, possibly with an outsourcing arrangement. An installed base of even modest size should generate enough recurring revenue to support a development group that will enhance the product at least enough to keep it viable in the current technological environment.

Although end user companies should continue to track the financial health of their vendors to possibly discern if the vendor will be a collector or one of the collected. The latest affair involving Oracle, PeopleSoft, and J.D. Edwards may prove that even a stable vendor can involuntarily end up being acquired. Thus, even a fairly solid balance sheet cannot guarantee that the vendor will remain intact a few years down the track. Neither should vendors be perfunctorily crossed out just because it is not as big, or is not seemingly financially viable as the usual suspects on your list. There are many recent success stories of nimble, highly focused vendors in certain markets, whose return on investment (ROI) have been much more tangible and faster than those of large, generalist providers. Ignoring these would only defeat the purpose of a due diligence, and would only nurture creation of a few complacent, large vendors' oligopolies.

Yet, even if you are comfortable with your vendor's merger, you may want to take an aggressive negotiating stance, given the vendor will likely be more amenable to steeper discounts during any transitional period. Pay more attention to clauses and fine print in your contract that guarantee your future rights, maintenance terms and conditions, and rights to additional capacity so that you can avoid future negotiation challenges.

If your vendor is acquired, be sure to meet the new owners. Talk with management and make certain they know your expectations and plans. Measure their commitment to support your technology for a specified time. Keep a close eye on their actions, given that product enhancement and service and support strategy can sometimes change as early as three to six months after the acquisition. Also try to understand their product strategy and look for opportunities in their product portfolio. Customers that reach out to the new owner, build a relationship, and agree to act as references will likely get significant attention, and they may receive some concessions concerning contract terms or pricing. Users should leverage user groups to get vocal about functionality improvements in the near term and push for database and application server options for next-generation products.

The new owners' motivation in buying your product and vendor was the install base and that's you. Showing interest (and keeping both eyes and ears open) is your part in keeping the relationship the way you want it. However, should your vendor be acquired in a hostile manner, and the new owner is trying to force you to migrate to its platform, do evaluate all the alternatives and do not accept the new vendor' seemingly sweet deal at face value, since it might not necessarily be much different to migrate to another more congenial provider than to your new heavy-handed provider. J.D. Edwards EnterpriseOne and World customers considering an upgrade should not commit to significant projects until Oracle reveals its long-term detailed strategy for both product lines, black on white. They will either have to vehemently state their preference for non-Oracle platform support (at least as a negotiating ammunition) or start anticipating conversion choices for the 2008 Project Fusion timeframe.

For those that cannot wait for long, as they might lose competitive edge, evaluating all alternatives should start now. For those considering the upgrade, possibly by switching the provider, please bear in mind that free' or heavily discounted upgrade of enterprise applications is not free at all, given that license fees can amount to even less than 10 percent of the entire upgrade price tag (i.e., beside users' training, change management, data migration, customization/modification migration (preservation), fit/gap analysis of new software, implementation, etc.). If an end-user company is overly concerned about the future offered by the incumbent vendor, they could get "peace of mind" by switching vendors. The real catch for them is to discern the continuing cost of upgrades. In other words, hybrid SAP-PeopleSoft-J.D. Edwards environments must not let sentiments make your decision, but rather the mathematical exercise that would factor in all the above software lifecycle costs.

Although in most cases, it is not sensible for companies to run critical systems without maintenance contracts, users still have more options (see The Old ERP Dilemma: How Long Should You Pay Maintenance?). Companies with older versions of PeopleSoft products that are not expecting to upgrade in the next three to five years may choose to investigate the available third-party maintenance vendors with the promise of quite lower maintenance costs. If staying with Oracle, users should avoid committing to multi-year maintenance agreements without the ability to cancel. Also, customers should ensure that maintenance costs do not escalate by more than a reasonable rate (e.g., inflation), while also avoiding the maintenance and technology lock-in from any supplier.

Again on a more general note, although the widespread acceptance of Web services inter-enterprise implementations will not happen any time soon, the major players' involvement in leveraging these should prompt large global enterprises to start learning the new protocols, standards and technologies in order to grasp the potential underlying business advantage. They should try to grasp how developers will leverage Web Services, SOA and business process management (BPM), what their ongoing needs are, and what intricacies may arise from their utilization, such as cultural and standards issues. To casual and power users of business applications on a desktop, conversion to SOA should be fairly transparent, which is not the case with the army of IT staffers though, for which the move will represent a significant reworking of the IT infrastructure that is typically a complex mishmash of disparate technologies.

While SOA/Web services may make integration easier through some imposed interoperability, they will not eliminate the need for application integration via adapters, connectors or so, since they are not any kind of panacea, and a replacement for event-driven architectures (EDAs). Also, although they may provide new business opportunities and create some dynamism and efficiency , they are not going to transform businesses on their own, given that they are only a piece of new technology. It is a more flexible and open architecture, but it depends on the availability (a critical mass of exposed applications) of services, and the fact whether they can be exposed as services. On the other hand, traditional EDA is more tightly coupled, and in many circumstances will offer higher scalability and performance, making users ideally needing both approaches.

Even if large organizations are the first to dabble with deploying Web services, their impact will ultimately be also felt by companies that supply products and services to consumers, regardless of their size. Businesses can already create and utilize Web services that can be reused by other applications, such as services to authorize credit card or to authenticate a person's identity while logging onto several systems.

Yet, to fully benefit from Web services and SOA, companies should carefully and painstakingly reexamine their business processes and best' practices and look for the efficiencies a revamped infrastructure could bring. The starting point for building an SOA blueprint would be to identify and create Web services around common business reference objects for the entire organization, which will be largely dependent on the organizational strategic alignment and the industry in case.

While many companies are going to attempt building their own SOA blueprint, the other might be driven by more complex cross-company driven SOA blueprint efforts, such as the one already initiated by IBM, SAP, BEA or the Middleware Company. For example, the IBM's SOMA approach uses techniques like domain analysis, process modeling, component-based development, object-oriented application development, but also goal service modeling, which customers may use to determine the optimal granularity of a Web service. Still, the strictness and effectiveness of the innovative but yet unproven process will have to be closely watched down the track.