Is Your Enterprise Application on a Road to Nowhere?

Your business changes continuously. You add and drop service or product lines. Your customers demand new and challenging levels of flexibility or integration with their operations. New laws and regulations require that you track more and more data on your operations in highly specific formats. And there is the relentless demand to increase operational efficiency and product quality year after year while reducing costs. How do you keep up with these demands?

If your enterprise application cannot change as fast as, or faster than, your business, it actually hinders you from achieving your goals. This means that your application vendor must, like you, continue to make changes and improvements. Yet because of recent developments in the enterprise applications market, your application vendor may no longer be investing in the product it sold you, or it may be making changes and improvements too slowly to help you remain competitive.

Two market forces are affecting the enterprise applications market: consolidation and inertia. Consolidation among application vendors has left some vendors with a large number of products that cannot all survive. That means most or all of these products may not receive further investment in research and development. Other application vendors have invested heavily in their existing technology, and inertia may be keeping them from updating and evolving their applications.

Consolidation is a well-documented trend and is to be expected in a maturing market such as the market for enterprise applications. In its wake, many products may be widowed or orphaned, having been purchased by conglomerates that may not intend to continue investing in research and development. Other enterprise application products have been purchased by vendors that plan to replace them entirely with a new platform, but may not have a reliable timeline for doing so.

The ownership of other enterprise applications may still be in the hands of the companies that developed them, but how do you know whether the owner intends to invest the necessary dollars to move the product forward, adding new functionality and adapting to changing technology? If a vendor has made extensive investments in its old technology and has a substantial user base, it may be especially reluctant to make the changes necessary to truly evolve the product. This article traces the evolution of the enterprise software market, focusing particularly on the much-publicized and truly revolutionary technology known as service-oriented architecture (SOA). It concludes by outlining the key questions you should ask application vendors about their future plans for the products they are marketing.

The SOA Revolution

Wholesale change in the enterprise applications market has taken place in fits and starts, driven by leaps forward in technology. In the 1980s, there was a technological leap from enterprise applications built on character- and terminal-based systems to those built on a client-server models with graphical user interfaces (GUIs). Today, there is a similar revolution taking place, as these client-server applications are, or are about to be, replaced by applications built on SOA.

SOA implies an application architecture made up of loosely coupled "services" (for example, the various software features used in creating and processing a customer order), and service "consumers" (for example, the users and applications that need to create customer orders). Most business software applications can create customer orders. But a business application made up of services enables you to easily connect the processes needed to create customer orders, and then configure the steps that must be taken to create them. The loosely coupled nature of SOA services also means it is relatively easy to substitute the components that implement each step in the process. This process tends to be rigid in non-SOA applications, which is a major factor behind SOA's popularity.

An SOA-based architecture works in much the same way as your Web browser when you access functionality through the Internet. Regardless of whether you are using Internet Explorer, Netscape, Firefox, or Opera, and no matter which version of the browser you are using, you can access information and interact with systems on the Web. The relationship between your browser and web sites, databases, applets, and other executable files on the Internet is loosely defined. Web site functionality may change without affecting the rest of the Web or your browser.

Similarly, the various features in an SOA-based application environment are relatively self-contained and are not overly reliant on the entire system. This functional autonomy allows individual portions of an application to be changed or updated more easily and less expensively than would be the case with an application built on monolithic blocks of code.

The modular design of an SOA-based application means it can be implemented or upgraded in phases, with minimal disruption to the end user. In contrast, a traditional monolithic application must be implemented in its entirety, and if portions of the system are not used right away, they are "switched off." This increases the complexity of the implementation. From a development standpoint, an SOA-based application is well suited for rapid, continuous change.

This new system architecture philosophy enables application users to open up their applications by exposing the individual pieces of functionality as services, and to configure and reconfigure these services through a standard interface using technologies such as business process execution language (BPEL).

This is the way that the industry is going. But moving in this direction requires a reengineering of the application that is much more complex than the transformation from a character-based to a GUI-based system.

Most applications on the market have not been through the transition to components, which is necessary for users to take full advantage of SOA. In some cases, application vendors have opened "plug points" into their applications where services can be exposed. These services tend to cover the types of processes handled for the past twenty years by electronic data interchange (EDI). Data for processes such as order taking, order response, invoicing, and currency exchange is available as services through these plug points.

SAP, Oracle, IBM, and other vendors are offering a variety of SOA middleware products, and they're getting better and better. Nevertheless, these applications do not offer the exposed services necessary to take advantage of these tools outside EDI-type processes. A company may have the budget to pay an application vendor or a system integrator to build new services that expose the functionality to its needs, but as its needs change and new services need to be exposed, the company may end up going far over budget. What the company really needs is an application that already has all its functionality exposed as services so it can freely and easily reconfigure the application to meet its changing needs—without incurring major, unanticipated expenses at every turn.

Other Drivers to Change

Although SOA is the primary trend in enterprise applications, other technology and functionality will be important in the years ahead. Some of these features, which users are already demanding, will require extensive investment.

One such feature is the type of text-based, deep search functionality made popular by search engines such as Google. Deep search enables application users to search all the data within their enterprise applications using specific keywords or phrases. Developing a deep search tool for an application is a daunting task. But it is even more challenging for a vendor that markets more than one product. Each product has its own architecture, and a vendor with ten products must engineer a deep search tool ten times, taking into account the way information is stored and managed in each application. This is why many software vendors cannot afford to add deep search functionality—or for that matter, make any investments in their diverse product portfolios.

Another investment that many application vendors plan to make is integration between their enterprise applications and office suites such as Microsoft Office. Most people spend a great deal of time working in both the enterprise suite and their word processors, spreadsheet applications, and other productivity tools. Bringing word processing, spreadsheets, and other documents together adds value. When you are e-mailing and chatting in a program outside your enterprise application, you likely are discussing a product or project and would like to be able to tie those communications into the appropriate activities within your enterprise application. The Excel spreadsheet you are working on may contain the quarterly budget forecast, or it might relate to the marketing plan. It would be nice to be able to import that information seamlessly back into the enterprise application. In fact, wouldn't it be better if the enterprise application also kept track of the spreadsheet so you wouldn't need to worry about where the latest revision is or who may have access to it? To get the most value from the loosely coupled communications outside the enterprise application, you need to keep more information within the broader business context that the enterprise application provides.

Enterprise applications are also becoming more vertical in their orientations. Although most enterprise applications offer functionality suitable for a variety of industries, some software providers are adding more and more industry-specific functionality. Over time, these industry extensions, as they are called, make the application a better fit for companies in certain industries. A vendor with several disparate products has a hard time investing in each product and may not be willing to deepen its relationship with customers in specific industries.

Because there are different types of application vendors in the market, there are different questions you should ask of each. For convenience, we will divide the enterprise software market into two types of vendors: collectors and unified technology companies.

Questions for Collectors

Collectors are enterprise software companies that are growing rapidly through acquisition. Oracle and Infor Global Solutions are good examples. Oracle became the number-two enterprise applications vendor behind SAP with the 2003 purchase of JD Edwards and PeopleSoft. The company's plans to replace both products with the SOA-based Fusion platform have been well-publicized, but some analysts have questioned whether Oracle has made significant progress in this regard. In the meantime, Oracle has aggressively launched various Fusion middleware products.

Infor Global Solutions became the number-three enterprise application vendor behind SAP and Oracle in 2006 with the purchase of SSA Global and Systems Union Group. Infor, a Virgin Islands (US)-based company owned by a San Francisco, California (US)-based private equity group, now owns a broad spectrum of disparate products, including Marcam, EXE Technologies, Infinium, Baan, Elevon, Ironside Technologies, Computer Associates' interBiz, MAX International, MANMAN, MAPICS, Frontstep, Mercia Software, Clarus, D&B Software, Anael, and Extensity. The company has not announced specific plans to upgrade or replace these platforms with an SOA-based product.

Here are key questions to ask collectors:

How do you plan to evolve this product to accommodate major market trends, including SOA?

If an entirely new product is being promised, when will it be available? What will the process be to migrate from the old to the new platform, and how much will this cost?

When will you have a standards-based search engine within the product, and how will this be accomplished?

How are you adapting this application to my specific industry?

How have you invested in this application? Discount the upgrade history of previous owners of the product. The current owner likely will have a much different posture toward the product than did the visionaries who first created and marketed it.

To what extent is this application built with industry-standard technologies, including Java and .NET? Proprietary programming languages, middleware, and development tools will be harder to support as the market evolves away from them.

Questions for Unified Technology Companies

Unified technology companies provide enterprise applications based on a single integrated platform. Examples include SAP and IFS.

Here are key questions to ask unified technology companies:

How can this application be evolved to meet my needs as they change?

If you have not already done so, what are your plans to break down this product into many independent, granular components to create a fully functional SOA?

To what extent are the features and functionality you are promoting represent products that have not yet been launched or demonstrated effective in the market?

How are you adapting this application to my specific industry?

Can you provide examples of companies using your enterprise application that have dramatically changed their businesses, and then explain how the product has accommodated these changes? How much of a reimplementation process is necessary to allow for business process change?

Conclusion

Selecting an enterprise application is not a lifetime commitment, but it is a commitment that will last ten years or longer. Given the degree of product complexity and pressure vendors feel to sell new licenses, caveat emptor—or buyer beware—has never been better advice for software purchasers.

You can count on vendors to tell you what you want to hear about whatever products they are trying to sell you. They will claim either that their products meet your needs today or that the software will do so somewhere down the road, in a subsequent release.

It is important to keep in mind that the best predictor of future behavior is past behavior. Vendors tend to announce their plans to release new products well in advance. Perhaps the best way to tell whether an application vendor will make good on its promises is to look at the promises it has made in the past, either in public or to individual customers. Did the company keep these promises? Did development timelines slide? Or did product roadmaps disappear entirely?

Don't be afraid to ask tough questions, because the answers are critical to your selection of an enterprise application.

SOURCE:http://www.technologyevaluation.com/research/articles/is-your-enterprise-application-on-a-road-to-nowhere-19400/