White Papers      Webinars  Search

Register for our newsletter:

Customer Relationship Management (CRM) applications can benefit greatly from Service-Oriented Architecture. For many organizations, CRM applications typically require extensive customization and integration, and Service-Oriented Architecture promises to make this easier and reduce associated costs. The future of CRM applications will likely be divided into two camps: large monolithic applications with built-in processes that are difficult to customize; and applications built using Service-Oriented Architecture that are more nimble and enable customized processes.

THE EVOLUTION OF APPLICATION PLATFORMS

As the enterprise software industry has matured, there has been an evolution of the platforms on which applications are built. This evolution is a result of the following cycle:

1. Vendors use the current preferred platform to build enterprise applications.
2. Customers and platform providers note duplicated functionality in the various enterprise and homegrown applications, and push to standardize the functionality in the platform itself. Standardization results in greater reliability, simpler administration and improved integration.
3. As new platform functionality is standardized and accepted, vendors build enterprise applications on the new platform.Vendors do this because customers prefer it, and because it lowers their own development costs since they no longer have to build the platform functionality themselves.

This evolution of application platforms sometimes creates opportunity for new platform vendors—for instance, the rise of the relational database as a standard platform element created an opportunity for companies such as Oracle. However, older platform vendors such as IBM remain in a good position to add to their existing platforms, either through development or through acquisition. This will enable them to continue to be key platform vendors going forward.

The challenge for the application vendors is greater. An evolution of application platforms means that the applications themselves require a significant change or a complete revision. This is because, as we said, the newly evolved application platform has absorbed many of the proprietary application features into a common standard. So application vendors who are successful within one platform generation are at great risk of being outdated and overtaken in a new platform generation.

The following sections discuss the three most significant stages of application platforms, and the effect of those stages on customers and vendors.

First Stage: Single-Tier
In the first stage of application platforms, the only standardization was around operating systems and networking protocols.We can refer to this generation as “single-tier.” The platform vendors widely recognized in this stage were IBM and DEC.

Enterprise applications built on the single-tier platform had:

• A variety of data storage mechanisms
• A variety of user interfaces, each developed for the operating system they were built on
• Their own built-in mechanisms for multi-threading, clustering, connection-pooling, transaction-management, error-handling and recovery

Application vendors that were popular in this stage included McCormack & Dodge and MSA. These vendors were wiped out when they were unable to transition to the next evolutionary stage.

Second Stage: Client-Server
In the second stage of application platforms, there was standardization of the data storage mechanism— relational databases—and the client interface— primarily Microsoft Windows. This generation of platforms challenge they face in rebuilding their products. is known as “client-server.” The platform vendors recognized in this stage were IBM, Oracle, Sybase, and Microsoft.

Enterprise applications built on the client-server platform have:

• Standardized data storage mechanisms
• Standardized user interfaces
• Their own built-in mechanisms for multi-threading, clustering, connection-pooling, transaction-management, error-handling and recovery

Well-known vendors who built applications using a client-server architecture include SAP, Siebel and Peoplesoft. Although these vendors have evolved their applications to incorporate new features such as webbased interfaces, their applications are still based on the characteristics described above.

Third Stage: Application Server
We have now entered the third stage of application platforms, with standardization of component-based application servers. In this stage, there is standardization of component architectures (J2EE or .NET) and standardization of functionality generic to enterprise applications, such as:

• Built-in multi-threading for efficient resource usage
• Built-in clustering support for scalable solutions
• Built-in connection-pooling for efficient network usage
• Built-in transaction-management for reliable applications
• Built-in error-handling and recovery along with common administration tools for simpler and better administration

Platform vendors who are widely recognized in this stage of evolution are IBM (with the WebSphere family of products), BEA (with the WebLogic family of products), and Microsoft (with the .NET and BizTalk family of products).

E.piphany is among the first and leading vendors delivering enterprise applications built directly on the application server platform. Many vendors with previous-generation client-server applications have developed integration and co-existence strategies. In some cases, they have announced intentions to rebuild their applications on the new platform, but have not as yet committed to clear timelines due to the difficult

What is clear is that the application server platform has reached maturity, and that customers are choosing specific application servers as their preferred platform for both purchased and home-grown applications.

BEST PRACTICE: SERVICE-ORIENTED ARCHITECTURE (SOA)

“During 2003, the architecture of mainstream business applications will evolve from monolithic, client/server and thin client to a service-oriented architecture.” Gartner, Predicts 2003: SOA Comes of Age via Web Services, M. Pezzini and Y. Natis, December 5, 2003

As application servers have become the preferred platform for enterprise applications and industry standards such as XML and SOAP have become increasingly pervasive, a new consensus has emerged in support of Service Oriented Architecture (SOA). This best practice architecture is based on applications built from either platform services (such as J2EE Enterprise Java Beans or .NET components) or SOAP-enabled web services. The services are then woven together using Business Process Management (BPM) capabilities.

Application servers from vendors such as IBM, BEA and Microsoft are the platforms for SOA. SOA takes advantage of the application server capabilities for components, and also the additional integrated functionality that vendors such as IBM and BEA are including in the application server suites. For instance, IBM, BEA and Microsoft are all delivering built-in support for web services and integrated business processes. The business process support is particularly significant for the future of enterprise applications. The development of standards for business processes using the Business Process Execution Language (BPEL) will allow application vendors to deliver processes that are portable across multiple application servers. It also promises to make it easier to integrate business processes.

SOA defines the following design principles to be applied in developing applications:

1. Modularity—splitting functionality into smaller, reusable building blocks.
2. Encapsulation—enclosing the modular functionality inside components with well-defined “client” interfaces
3. Loose coupling—each service makes no assumptions that clients will include any specific functionality to allow the service to function properly.

Leading industry analysts have clearly identified the importance of SOA and the likely dominance of SOA as the common application architecture in years to come:

• “Giga recommends architects consider service-orientation as the top priority for their architecture planning efforts.” Giga, IT Trends 2003: Application Architecture and Design, R.Heffner, October 11, 2002
• “Advances in software technology and potent business drivers are making service-oriented architecture a must.” Gartner, Predicts 2003: SOA Comes of Age via Web Services,M. Pezzini and Y. Natis, December 5, 2003

The reason that analysts and customers are rallying behind Service-Oriented Architecture is that there are a number of distinct benefits related directly to two key issues: flexibility and agility. Previous-generation architectures have made it difficult for IT organizations to integrate functionality and systems, and made it difficult for them to respond quickly to changing business needs or competitive demands. In a world where no single vendor delivers all the competitive functionality required, it is highly desirable to have applications that are not rigid and restrictive.

SOA offers the following specific benefits:

• Simpler configuration of composite applications using Business Process Management tools
• Easier integration of functionality into multichannel solutions
• Faster integration of multiple pieces of in-house and third-party functionality
• Safer upgrades using platform service upgrade capabilities and versioning support
• Better support for large or geographically distributed development teams by dividing development using services

Certain standards, particularly those related to security, are still being defined by industry consortia and organizations such as the Organization for the Advancement of Structured Information Standards (OASIS). Until these standards are resolved, it is likely that SOA applications built on different application server platforms such as IBM or BEA or Microsoft, will rely on certain features specific to the platform. While this will necessitate extra integration work when combining applications across multiple application servers, it is not likely to slow the progress of SOA because of the many benefits that still remain.

CRM BENEFITS OF SERVICE-ORIENTED ARCHITECTURE

The general benefits of SOA described above can be applied directly to CRM applications. In order to understand why these benefits are so critical, it is important to understand a few key principles of CRM applications:

• CRM applications usually require integration with other systems, such as order management or shipping
• CRM solutions are almost never entirely from one vendor; they are typically a combination of multiple vendor systems and some home-grown functionality
• CRM functionality is multi-channel—addressing customers on the web, over the phone or in-person

There is one more principle that most customers have traditionally faced: CRM solutions are time-consuming and costly to configure and deploy. The main benefit of SOA, discussed in more detail in the sections below, is that it invalidates this third “principle” by enabling quicker, easier customization, integration, and maintenance.

Faster Customization
Most organizations, particularly large enterprises, are not interested in installing a CRM application without first customizing it to fit their own processes. The cost of this customization is a key factor in the overall cost of a CRM solution, sometimes amounting to ten times or more the price of the purchased “out-of-box” application. This cost becomes even greater when you consider adaptation over time as the business or competitive needs change.

Another factor in customization is the need to extend vendor applications with home-grown or custom functionality. This functionality needs to be inserted, or blended, directly into the application.

SOA helps ease the customization burden and lower the time and costs by enabling process-driven applications. Process-driven applications are identified by the following characteristics:

• Critical business logic in the application is captured in processes or business rules
• Processes and business rules are understandable and reconfigurable by a business analyst

Of course, it is not necessary for an application to use SOA for it to be process-driven. But the fact of the matter is that demand for process-driven applications has developed recently in large part due to the factors enabling SOA. Indeed, component-based application servers with integrated business process management capabilities, along with all the associated standards, are what make SOA applications realizable. As a result companies have the opportunity to implement applications that are driven by business processes they are beginning to embrace this approach. Traditional, client-server applications were built before these platform capabilities existed and before this customer demand was clear, and are therefore typically data-driven.

SOA applications have the following advantages for CRM applications:

• Services can be configured into processes using common business process management tools
• Home-grown and custom functionality that follows SOA design principles can be included as part of the process-driven application

CRM applications that are designed using SOA allow quicker and easier assembly of processes. This makes it easier to build multi-channel and competitively advantageous solutions.

Reduced Integration Costs
Integration has been the number one problem and cost for most CRM projects using traditional applications. This is because the first generation CRM applications were designed with the expectation that they would be the only or primary CRM application, and that they would “own” the customer data. They also assumed that they would “own” the desktop and that they would “drive” the processes through to the back-end.

In this sort of an application-centric model, it is possible to believe that integration will be limited and controlled, and therefore that it will not be costly or difficult. For customers who are willing to standardize on one vendor from front-end to back-end, this model may work.

But the reality for most customers is that they have multiple vendors and multiple systems, and no single application can be said to “own” the customer data or to “drive” the processes from end-to-end. Trying to integrate an application under these circumstances is a costly, difficult effort that has left many customers dissatisfied with their CRM applications.

SOA defines a completely different integration principle right from the start. SOA automatically assumes that every piece of functionality is available for integration and reuse, and that every piece of functionality requires- a well-defined interface for that integration and reuse. The application is not the “owner” or “driver”, but the application is a composite of multiple services, and thiscomposite is ready to be re-combined or integrated with other services. The expectation, therefore, for a CRM application built using SOA, is that it will not own the customer data, that it will not drive the processes from end-to-end, and that it will not be the only or primary CRM solution. Instead, the assumption is that it should be a good and pliable citizen among the various other pieces of home-grown or third party functionality that need to be combined for the final solution. The benefit to the customer is that an SOA application is easier to integrate into a world where multiple applications coexist and no single application drives the processes.

Rather than an application-centric model, the new model for a CRM solution is customer-centric. Under this model, a company’s CRM solution will react to the customer through multiple channels, and then enable a process optimized for that customer based on the company’s business objectives. A monolithic application cannot meet this objective, since no single application can handle all the functions necessary or possible. Instead, it is necessary to define enterprise processes, and to connect the application functionality into these processes as required. This is what SOA is all about. Using SOA applications and an application server suite with built-in business process management capabilities, companies will be able to deliver increasingly powerful CRM solutions.

Ease of Maintenance and Upgrade
One difficult cost to measure and predict is the cost of maintenance and upgrade. Given that CRM solutions represent a considerable investment, it is desirable that the solution have a considerable lifespan. Whether the lifespan is seven years or twenty, there will be maintenance and you will most likely want to upgrade.

SOA applications offer a number of key benefits related to maintenance and upgrade:

• Deployment, monitoring and administration can be done using common application server tools.
• Using common logging facilities of the application server platform, problems can quickly be isolated down to individual services and thereby more quickly discovered and addressed.
• If a service requires a maintenance fix, that service can be replaced without replacing other services and introducing other quality risks; furthermore, that service can typically be hot-swapped into a running production system without bringing the entire system down.
• As with maintenance, upgrade only involves replacing chosen services; if new services are added, they do not have to be enabled or used immediately, and SOA on an application server platform ensures that these unused services will have no quality or performance impact on the upgraded system.

Traditional CRM applications, like all enterprise applications, have been notoriously difficult to maintain and upgrade. SOA enables a vastly simplified model for problem isolation and maintenance, and a simpler and safer path to application upgrade. This approach, combined with reuse of administration skills across multiple SOA applications on an application server platform, translates to vastly reduced costs for maintenance and upgrade.

E.PIPHANY E.6™ SERVICE-ORIENTED ARCHITECTURE

With the launch of E.6 in 2002, E.piphany became one of the first enterprise CRM vendors to offer a true J2EEbased solution built using Service-Oriented
Architecture. With subsequent releases and the release of E.6.5 in 2003, E.piphany continues to provide the most comprehensive SOA CRM solution available.

J2EE and SOA
As discussed previously, the rise of application servers is enabling and, in some ways, driving the rise of SOA. As the leading enterprise application platform, J2EE will also become the leading SOA platform. J2EE application servers already include all the features critical to SOA, including support for components, web services and business processes.

The features and common design patterns of J2EE are directly in line with SOA. In J2EE, services are defined using Enterprise Java Beans (EJBs). These EJBs are typically designed as independent and reusable components. They are integrated into user interfaces through Java Server Pages (JSP) and typically a modelview-controller (MVC) interface such as Apache Struts. They are integrated into other applications through their EJB interface or through a SOAP web service interface wrapped around the EJB.

E.piphany E.6 applications are built from a set of stateless session EJBs. The user interface is realized through JSPs using an MVC interface. And web services are wrapped around the EJBs for SOAP-client access.

Key E.6 Services
Analytics Services. E.piphany is a recognized leader in the area of marketing and analytic services. In E.6, the marketing and analytics are available through services. This allows the functionality to be integrated easily into other applications, or to be included as part of custom business processes. For instance, you can include analytic data or reports in a portal or a custom servlet, or you can include a real-time marketing recommendation into a customer dialog or request routing process.

Key services in this category are:

• Analytic Service. This is the main interface to the sophisticated analytic query engine. This service accepts query requests and runs them against the marketing data mart, returning the results in a graphical or data table format. This information can be used for reporting, or as a way to identify customer segments for analysis or a new sales campaign.
• Real-Time Decision Service. This sophisticated engine provides real-time recommendations for inbound marketing, customer support or self-service. For instance, this service can be used to identify the optimal marketing offer when a customer hits your web site or phones your call center. The service accepts a customer identifier and an indication of the recommendation desired, and it returns a ranked list of recommendations along with information about those recommendations (such as the URL of the web page where the recommendation details can be found).

Business Information Services. Another key set of services in E.6 are the business information services. These services provide the interface to business information stored throughout the enterprise. Data locations are identified through metadata mapping, and these services allow other services to add, update, delete and query information. The business information services can be mapped to relational databases, web services, JMS messages, EAI middleware, LDAP servers or file systems.

Key services in this category are:

• Business Information Objects (BIO) Service. This is the primary object-to-data mapping service used by E.6 applications. Using pre-defined metadata, this service understands application objects and how they map to physical storage objects. Individual objects may be mapped to multiple data stores. This service also understands relationship rules between objects and can enforce integrity. Additionally, it performs caching on request. It accepts insert, update, delete and query statements, and returns result conditions or result datasets as appropriate.
• Content Management Service. This service provides access to files in the file system, in the database or in a third-party content management system. It handles the storage and key-creation for new files, and retrieval of existing files. It accepts file uploads or requests for files using file keys. It can return file definition information or entire files when requested.
• Service Lookup. E.piphany’s solution enables rapid access to directories in order to find necessary services. The process involves creating a query, sending it to a discovery service, and parsing the results.

Business Process Services. The business process services in E.6 allow CRM processes to be defined and run. However, the generic business process capabilities inherent in these services make them ideal candidates for reuse by other applications. Through their service implementations, they can easily be accessed remotely to launch processes or run business rules.

Key services in this category are:

• Dialogs Service. This is the agent scripting and interactive screen flow service within E.6. Dialogs, specified in XML using the Dialogs Designer, define a branching screen flow that can incorporate questions and answers and branching decisions. The service is used to launch and run Dialogs, and at each step it produces XML output for the next screen to be shown.

• Workflow Service. This is the task flow and team coordination service within E.6. Workflows are defined in XML using the Workflow Designer. Workflows are collections of tasks and can contain multiple types of branching, looping or sub-workflows. The service contains special features to enable flexible task flows for working teams, or it can enforce rigid task flows when desired. The service is used to launch, run, monitor or stop workflows, and the service interface was built to comply with industry workflow standards.

• Intelligent Business Rules (IBR) Service. This is a complete business rules engine within E.6, and is used to define business rules that can run automatically when certain events occur (such as a data element changes) or on demand. The rules are defined in XML through the Business Rules Designer and, as of 6.5,will include rule tree hierarchies and the ability to call rule sub-trees. Rules can access run-time data (such as the name or identifier of the current customer) or transaction data (such as the request currently being handled). Rules can result in a variety of actions, including launching a Dialog or Workflow, or sending an alert. The service interface allows the caller to pass a data object and run a rule tree, or to run a specific rule, or to simply check a rule condition for true or false.

Other E.6Services. There are over 100 services in E.6, and they fall into a variety of categories. In addition to the above categories, there are some that provide messaging or data access infrastructure, some that provide authentication or authorization functionality, and some that provide features necessary for particular applications. These and all E.6 services are fully documented and reusable.

Key services are:

• Single Sign-On Service. A service that provides single sign-on authentication across all client applications, integrated with the E.6 single sign-on server and able to integrate with other SSO systems or LDAP or Active Directory servers.

• Message Processing Service. A service that can send or receive JMS and XML messages, and integrate those messages directly into other services.

• Connectivity Service. A service that maps remote calls from one protocol to another. For instance, a Java/EJB client can make a SOAP call through this service and the client will not need to know that it is talking to anything but another EJB.

• Computer Telephony Integration (CTI) Service. A service that provides integration with popular CTI middleware such as systems provided by Genesys or Avaya. Provides capabilities for call pickup, call disconnect, and routing integration.

• E-mail Service. A service that allows you to read inbound e-mails from specific inboxes on specified email servers. It can access all e-mail information, including attachments, and also has the the ability to send outbound e-mails.

• Search Service. A service that integrates the Lucene search engine from the Apache group with the E.6 business information services. The service provides a common search service interface—a caller submits a search string along with a category of items to search and receives back a ranked result set. This service is implemented so that it could also be integrated with search engines other than Lucene.

THE FUTURE OF SOA

“By 2008, SOA will be a prevailing software-engineering practice, ending the 40-year domination of monolithic software architecture (0.7 probability).” Gartner, Service-Oriented Architecture Scenario, Y. Natis, April 16 2003

The long-term acceptance of Service-Oriented Architecture will be contingent on customer success and the success of Independent Software Vendors such as E.piphany. Given the many obvious benefits of Service-Oriented Architecture, it is very likely that it will achieve long-term success and become the widely accepted best practice for a significant set of enterprise business applications.

The key issue regarding the success of SOA therefore is not if but when.When will be a result of three key issues:

• How successfully the standards bodies such as OASIS can drive the standards to an acceptable state of completion for wide-range customer adoption
• How quickly the platform vendors can incorporate the new standards and the full range of SOA functionality required for wide-range adoption into their application server suites
• How accessible the tools vendors can make the integrated tools for the design,configuration and testing of SOA applications

The last issue is probably the most critical. The move to SOA as a generally accepted best practice for application architecture is driving the delivery of tools for Service-Oriented Development of Applications (SODA). The rate of success of SOA will be limited by the rate of success of SODA and SODA tools. SOA and SODA offer the promise of entire applications defined as reconfigurable business processes, but this presents a significant challenge to tools vendors. It is very likely that the success of individual SOA platforms will be based on how easy the tools for that platform are to learn and use.

Over the next few years, we will likely see further consolidation in the SODA tools market, and clear winners will begin to emerge. As this happens, application vendors such as E.piphany will further integrate their own configuration capabilities directly into the most popular SODA development environments. Ultimately, the configuration of third-party applications, the development of home-grown applications, and the integration of both will all appear as one seamless configuration project within an integrated SODA tool.

CONCLUSION

“The state of the art in software will evolve markedly in 2003…New software technology will be brought to market, products will be repackaged and repositioned, and new standards—particularly web services—will begin to mature. All these factors will help foster a new, more agile and efficient generation of application systems. As enterprises shift their buying habits, a new set of winners and losers is emerging among software vendors.” Gartner, Predicts 2003: SOA Comes of Age via Web Services, M. Pezzini and Y. Natis, December 5, 2003

The times are changing, and both customers and application vendors must change. As usual, customers are leading the charge because they have realized the unreasonable costs of integration and the unrelenting demand for agility. Service-Oriented Architecture is a key part of the answer that can let customers meet the agility demands at a reasonable cost.

CRM applications have long suffered from difficult integration challenges and rigid, inflexible application architectures. Although there may be a place in the future for such applications, it will only be with customers who are to a large extent willing to accept the vendors’ model of their business. For customers who want to implement CRM solutions that fit their business and provide competitive advantage, the application architecture of choice will be Service-Oriented Architecture, built on standard application server suites.
For these companies, agile and nimble CRM applications built using SOA, such as E.piphany E.6, will be their applications of choice.