Evaluating Architecture - Customer Relationship Management

Honestly, I’d have my IT department doing this if I were you. But I’m not you, so I’m going to give you just enough information on evaluating a customer-driven architecture to make you want the IT department to do it.

Web Services
CRM initiatives can be technically complex. Architecturally, they are based on web services and standards that are interoperable—and frameworks that incorporate those web services in some way. When it comes to architecture, there are competing platforms, such as .NET and J2EE. There are also various ways to address the services through different architectures, such as the service-oriented architectures and RESTful architectures mentioned above. But before we get to the architectures and the differences, let’s talk about web services.

The World Wide Web Consortium (W3C), the official standards body for web services, defines a web service as:

…a software system designed to support interoperable machine-tomachine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

What in the name of nomenclature does that even mean? In English, that means that web services provide a common way of “speaking” between computers via a network so that the action of one can be understood by the other and a response to the action can be sent that is understood by all concerned. Most important, it uses standards that are interchangeable between competing systems. For example, I send a request to the system to generate a form that will be used to enter a pricing quote for a client. To do that quote, I need to draw on the product catalog to get the most current pricing and to check inventory. My order management system is Oracle, my product catalog is in salesforce.com, and my inventory is SAP. Theoretically, because all of these use web services that are based on the same standards, it should be no problem to do that quote. Theoretically.

In order for that theoretically seamless communication to occur between competing systems, the web services need to meet certain criteria. There are certain components that are important for them to work effectively. Five of them to be specific.

Those five pillars:

  • Extensible Markup Language (XML) XML is a “meta language”—a generalized markup language with which you can write other more customized markup languages. It provides a set of specifications and basic syntax that is stored in plaintext format, which is hardware, software, and platform independent, making it interoperable, easy to use, and future-proof. It also supports Unicode, which means that any human spoken language is usable with XML. While it allows machines and processes to talk to each other, it doesn’t provide a way to actually display the information, so it has to be tied to more traditional approaches to display, such as cascading style sheets (CSS). Its flexibility—also known as extensibility—in creating custom languages is also a disadvantage because there are so many custom languages it gets hard to “hear” the appropriate one. There are XMLs for chemistry, cooking, and real estate descriptions, and ten separate custom XMLs for biology alone. There are even two XML standards, 1.0 and 1.1. But it does work.

  • Simple Object Access Protocol (SOAP) SOAP (most current version 1.1) is a series of procedures written in XML to allow objects and procedures to pass through from one operating system to another using HTTP as the transport mechanism. That way, system administrators don’t have to take down firewalls so other ports can be accessed beyond the standard port 80 that is commonly used. Even though reusable objects are ordinarily platform specific, SOAP allows them to call and respond to each other regardless of platform, port, or firewall. This is not used in RESTful architectures.

  • Web Services Definition Language (WSDL) This XML language is used to describe the interfaces between web services (the endpoints between the services). The most current W3C recommended version is 2.0, formerly 1.2. (I love numbering and naming conventions.) One thing germane to this book is that 2.0 offers better support for RESTful web services.

  • Universal Description, Discovery, and Integration (UDDI) The UDDI is a registry that an enterprise uses to publish its web services descriptions so that other parts of the enterprise can discover and use those web services due to the common descriptors. This allows different enterprises to communicate via those web services. It provides information such as contact info, industrial categories, and the exposed technical specifications for web services from the specific enterprise. It sits between (in a manner of speaking) SOAP and WSDL, allowing SOAP to interrogate it and access the descriptors provided by WDSL. The current version is UDDI v.2.0.

  • Business Process Execution Language for Web Services (BPEL4WS) BPEL4WS, also known as BPEL, defines both business processes that use web services and business processes that externalize their functionality as web services. It is usually a tagged XML message that is sent between partners or links partner to activity. This standard was created by a lot of the CRM-related vendors—Microsoft, IBM, Siebel Systems, BEA, and SAP. The current version is 1.1. It superseded the WSDL extension called XLANG, which used business processes to orchestrate applications and web services. But web services alone do not an architecture make. They are just the brokers for moving messages and actions within the overall framework.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Customer Relationship Management Topics