Overview: CRM vendors have been painstakingly redeveloping most of their application suites over the last two years, attempting to make them more modular and Web friendly. For almost all CRM vendors, that has meant ditching the client/server model and embracing browser-based designs implemented in Java, C++, and other object-oriented technologies. A by-product of this rearchitecting has been to make integrating CRM “point” solutions easier. The same attributes that make application deployment easier also make change easier and more straightforward. Could the trend toward modular architectures spell the end of the prepackaged CRM suite and the beginning of Best-of-Breed CRM?
New Life for Best-of-Breed
In the early days of Customer Relationship Management (CRM), most of the suppliers provided single-function “point” solutions for applications such as Sales Force Automation (SFA), Customer Service (CS), or the call center. As the industry matured – and as some vendors grew through acquisition – the vendors evolved toward providing already integrated, out-of-the-box “suite” CRM solutions.
Much of the impetus for this evolution came from customers trying to shorten implementation cycles and reduce integration costs. In turn, the vendors hoped customers would restrict their purchases and buy from only a single CRM vendor. The vendors continued to build out their functionality to provide as complete a product as possible – and to capitalize on new and emerging sub-segments of CRM such as marketing automation.
Though the idea of integrated suites has merit, it does not automatically invalidate the integration approach. The introduction of modular architectures based on Java, .NET, and C++ makes integration easier than before and supports the notion that – Mick Jagger’s lyrics notwithstanding – you can get what you want and what you need. Moreover, the buying community has chafed at vendors dictating blanket product adoption. Many prospective customers want a say in which modules they buy and implement, believing that while one vendor might offer an SFA package that meets their needs, for example, a different vendor may be their favorite for call center applications. Then, too, constrained budgets also are driving buyers to seek increasing granularity. They simply do not want to pay now for application functionality they may not use for years – if ever.
In CRM, the strategy of implementing a single vendor’s vertical application suite was a late-1990s response to the need to reduce the amount of services – and associated costs – required to get a system up and running. Involving multiple vendors in an implementation often required extra time and costs to analyze and integrate different applications and, in an era that reported 50% failure rates, significant cost overruns, many vendors took prudent actions to rein in costs, such as deploying tightly integrated suites. But as noble as the intent of lowering costs was, rather than solving the problem, single vendor implementation merely transformed the institutional heartburn.
The Case for Modularity
Client/server CRM applications reached a level of complexity that made them difficult to integrate and implement. Core processing was, to one degree or another, interspersed with code for presentation, business rules, and more. Imposing modularity cuts through much of the current complexity and makes applications easier to change. In a modular architecture, business rules, workflow or business processes, analytics, and other functions are separated from core processing in the same way that data was separated from programs with the introduction of the database.
When data and programs were separated, application programs became easier to develop and maintain. Accomplishing that separation required development of a data-oriented language – SQL. Today, applications are more complex than ever before, and modular approaches help simplify application development and modification to an even greater extent. In a modular CRM system, the workflow, business rules, and analytics engines all serve to separate their constituent functions into practical areas that consolidate the function for the application suite. Moreover, procedural languages originally developed for these engines have been replaced by graphical user interfaces (GUIs) that further reduce the amount of technical expertise required to modify system behavior. Business users – rather than traditional programmers – can then modify system behavior, which also makes modular applications inherently more flexible and able to change with business conditions.
At the same time that vendors were looking to lower implementation costs, many of them were rearchitecting their suites to be more Web-friendly. Client/server architectures were replaced with Web servers and zero-footprint clients to provide the performance and scalability needed to host many more users than the client/server paradigm could support. Vendors have chosen Java and the J2EE (Java 2 Enterprise Edition), C++, or Microsoft’s .NET vehicles to implement their Web strategies; many such as Chordiant with Chordiant 5.0 (J2EE-based) and Siebel with Siebel 7 (C++-based) have now come to market with completely rearchitected suites. Others like Oracle (Java) and Microsoft (.NET) have announced plans to do so.
All of the above-mentioned platforms are suitable for supporting a vendor’s modular plans, and each has specific advantages. The Java paradigm, for example, is an open standard supported by numerous hardware and software suppliers around the world. The programming language C++ offers many of the same benefits but is a lower level environment, and the architecture that can be delivered with it is necessarily proprietary. Finally, Microsoft’s .NET initiative offers great promise but it has only recently been announced and will require a maturation phase. And Microsoft’s recent litigation difficulties may make some people reluctant to engage in a technology that could lock out future options.
Advantages of Modularity
The big advantage of modularity is that it simplifies software deployment and maintenance, which have reached a level of complexity in which systems are becoming so expensive and risky to implement that their benefits become obscured. The high failure rate of CRM implementations in the last few years and the marketplace’s demand for proven return on investment (ROI) are the two most obvious manifestations of the problem. By rearchitecting applications as interrelated modules, and thus enabling the reuse of components, vendors can isolate points of failure, reduce the impact of bugs, and better define how changes are implemented and propagated throughout the application suite.
The rearchitecting exercise has also set the stage for vendors to approach their applications from a more granular perspective than ever before – with some interesting results. Vendors are now “disaggregating” their CRM applications in ways that go well beyond more traditional separation into broad components such as SFA or CS.
Setting up such systems will be made easier because of standards like XML (eXtensible Markup Language) for data sharing and XSL (eXtensible Stylesheet Language) to enable integrated applications to share a common style sheet, and thus look and act as one.
Best-of-Breed and Modularity
The trend that brought modularity to the forefront has also breathed new life into the argument for best-of-breed approaches to rounding out the CRM suite. Furthermore, the slowdown in the U.S. economy and relative maturity of the CRM market make it improbable that CRM-related startups will be as prominent as they were just a year ago.
The market, then, is divided into two camps – full suite vendors and niche players – each of which has certain advantages and “soft spots.” For example, large, full suite vendors can argue that their vertically integrated offerings are sufficient for most customer needs, whereas smaller point solution vendors might argue that they are the true innovators and can offer better approaches to solving new business problems. Both camps must appreciate that, in this economic environment, competition may need to make way for “co-opetition” – acknowledging that sometimes competitors need to cooperate for the good of the customer. For example, if a customer requests it, a full suite vendor might need to integrate with a point solution application to solve a unique business problem.
This suggests new roles for both large and small CRM vendors going forward. The big companies need to see themselves as platforms for solutions – many of which come from their own development efforts.
But when solutions come from outside the big vendor organization, the vendor needs to have a graceful approach for incorporating an application from an upstart. A modular architecture can provide that graceful approach. At the same time, the upstart will benefit from having an architecture that plays well with the larger suites if only because in the next few years the favorite exit strategy for new companies will likely change from the IPO to the buyout.
Aberdeen research suggests that, regardless of size, vendors that have developed their applications based on modular architectures will have an advantage when attempting to “play nice” in the new sandbox.
Aberdeen Conclusions
It is rare that changing one element of a complex system does not have a cascade effect on the remainder of it. Responding to the twin needs to improve the ease of CRM implementation and enabling applications to be more Web-centric has started a snowball rolling down a big hill.
Because human engineering issues will always need to be considered, CRM implementation will not likely become effortless any time soon. However, changes such as the adoption of modular architectures, XML, and XSL – as well as the explicit separation of business rules, processes, and the incorporation of analytics into many vendors’ solution suites – increase the potential that CRM customers not only will be able to get the applications they want, but that they will also be able to change the behavior of their systems to continuously adapt to changing market conditions.
In the near term, the traditional question of prospective customers – “What does it do?” – will likely be replaced by a more important one: “How easily can it be changed?”
Denis Pombriant is Research Director in the Customer Relationship Management practice of Aberdeen Group in Boston. For more information go to www.Aberdeen.com.