Getting Past the Jargon

Networking professionals concerned with network topologies, LAN/WAN connectivity options, bandwidth capacities, routing/switching protocols, security, or IP Telephony are painfully aware of a computing frontier that they do not want to explore due to its excruciating diversity and seemingly infinite amount of detail and variation. This vast frontier is the end-user applications and their enabling operating systems, databases, and services.

However, a complete lack of understanding by networking professionals of the applications environment (or by the applications experts of the networking technologies) generally leads to substandard information technology (IT) operations in SMB environments. Integration, by its nature—whether of applications or elements of the network infrastructure, such as routing, switching, and security functions—requires the elimination of boundaries.

Disappearing boundaries force networking professionals to communicate effectively with the applications experts to enable some of the more complex integration deployments to work. Similarly, elimination of boundaries between front and back office requires the understudying of the business processes that go on in both areas. In addition, SMBs should undertake the project of the integration of the front and back office applications with a high degree of commitment, which must span the initial architectural design (business process flow, database structure), the implementation stage, and, finally, the system utilization with any subsequent enhancements or refinements.

Front Office: Concepts and Applications

The concept of front office in computing refers to the applications that are facing the customer or that the customer interacts with directly. Setting business strategy and philosophy aside, the front office applications are frequently equated with CRM. The names of front office applications (apps) depend on which software and/or integration vendor is promoting them and are often based on what promoters consider the current age to be. In the e-age, it's eSales, eMarketing, eService, or, generically, eApps. In the age of automation, it's Marketing automation, Customer Service automation, Sales Force automation, or Field Service automation. In the next age, new expressions are bound to emerge.

Front office applications are usually available either as standalone modules for each unique customer contact channel or as integrated suites. The trend toward suites emerged in the 1990s. Although suites are still prevalent, ironically enough, they are giving way to what might be viewed as just the opposite: a trend toward smaller and more specific point applications that are more specialized for different categories of SMBs, even in such generic areas as sales, marketing, or field service. This is an example of the computing environment being subject to cyclic trends!

Collectively, the primary purpose of the front office apps is to enable SMBs to sell their products and services effectively. Marketing might precede the sale, and service will follow it. But without sales, any SMB's days are numbered. At the most fundamental level, the concept of sales equates to taking an order for a product or service. Thus, the classic example of a front office application is order entry.

An order can be submitted to an SMB for processing via self-service on an e-commerce website, in real time through an interaction with a call center agent, or perhaps even in what might be considered an old-fashioned or a totally novel way, where it arrives via a postal service, courier, fax, e-mail, voice mail, Instant Messenger or a Short Message Service (SMS). Consider these multiple means through which orders can be placed. Websites, call centers, and mailrooms become the interface points between the applications and the customers, whether the customer interacts with the application directly or through an intermediate agent that transfers the customer order information into the application.

At these interface points, the applications solutions facing the customer and the networking solutions providing the necessary and secure infrastructure over which the apps operate must meet and interoperate. These same interface points are where the integration between the front office (effectively a CRM solution, as long as the CRM strategy and philosophy have been adapted) and the back office (elements or all of an ERP solution) also takes place. The ideal model then becomes a fully integrated computing platform (networking, front office, back office) that equips the front office employees with the most effective tools to service the customer base. Better yet, if customers can be satisfied and loyal using self-service, it's another plus for applications integration.

Back Office: Concepts and Applications

Back office refers to the applications that are facing away from the customer, which the customer does not interact with directly. These applications tend to be more numerous than the front office ones and span a spectrum of categories that are related to SMB business types.

Classic back office applications include product design and production, accounting, inventory control (or its more sophisticated successor, the supply chain management [SCM]), human resources, and credit checking. Each SMB sector is bound to have its own unique vertical back office applications pertaining to its line of business.

When all of the back office (and possibly even the front office) applications are integrated to manage the company's resources, the system might end up being referred to as an ERP. However, as alluded to earlier in this chapter, integration seems to be a never-ending process, no matter how integrated the application environment appears at any given point in time. For example, assume that an SMB acquires an integrated mid-range market ERP system that meets 95 percent of the SMB's requirements. This means that some specific and unique applications that are required for the business to function are not included in that particular ERP, thus forcing that SMB into further integration.

Enterprise Applications Integration Tools

Enterprise Applications Integration (EAI) refers to the planning, methodology, and tools that are used in the process of creating a cohesive applications environment within an enterprise. Think of it as a means toward achieving a unified applications solution, not unlike trends toward unified communications and messaging, as discussed in Chapter 9, “Unified Communications Solutions.”

Cohesion or integration could be desirable between new and legacy applications, between applications from different vendors, or between disparate, noncommunicating applications from the same vendor. Generically, the elements of EAI methodology involve the following:

• Development of proprietary resource adapters to establish communication between the applications

• Mapping of data structures, either directly between the applications or to a common model

• Subsequent presentation and/or updating of data and messages throughout the business process or multiple processes that are part of the integration effort

The volume of applications developed over the past several decades is vast and inestimable. They utilize numerous operating systems and varied computing platforms that span mainframes, minicomputers, PCs, and handheld gadgets. These factors have contributed to the development of mostly proprietary solutions in the EAI market.

A proprietary integration solution might be perfectly acceptable in the absence of standards-based approaches. However, the use of a proprietary solution should be a design decision that is accompanied by an understanding of the typical consequences: higher costs and fewer choices in integration vendors. To the benefit of the enterprises and SMBs alike, two standards-based approaches to applications integration have emerged:

• Java 2 Enterprise Edition (J2EE) Connection Architecture (JCA)

• Web Services

J2EE Connection Architecture

J2EE Connection Architecture (JCA) defines a standard architecture that allows J2EE platforms housing Java applications to connect with Enterprise Information Systems (EISes) and, consequently, integrate disparate EISes. In the context of JCA, an EIS represents the information infrastructure for an enterprise, whether it is an ERP system, a legacy database system, or a mainframe transaction processing system. The main architectural components of JCA include resource adapters, system contracts, and the Common Client Interface (CCI).

The resource adapters are software drivers that allow Java applications to connect with an EIS. They are unique to each EIS and plug into the application server. If the Java application server vendors (or in-house developers) support JCA, their products will be able to connect with EISes, provided that the EIS vendors offer an adapter for each of their systems. Effectively, there are one-to-many mappings for EIS and Java application server vendors, which implies lower development costs due to reusability. Naturally, language support for JCA is limited to Java, and a J2EE-compatible application server is required for JCA to operate, which could be viewed as a limitation of the architecture.

Version 1.5 of the JCA specification that was published in late 2003 defines additional system contracts above the connection management, transaction management, and security that were part of original version 1. They include life cycle management, work management, transaction inflow, and message inflow. System contracts are the mechanisms through which the resource adapters interact with a J2EE server. For example, a security contract allows for a secure access to an EIS, whereas a transaction inflow contract allows an imported transaction to be propagated by the resource adapter to the application server.

Conceptually, the purpose of the system contracts is similar to that of CCI. The difference is the vendor target audience. Whereas CCI, which defines a common client application programming interface (API) for accessing EISes, is aimed at larger EIA tools vendors, the resource adapters and system contracts combination is aimed at a wider spectrum of developers.

Web Services

Web Services represents another set of tools for applications integration. The intent behind Web Services is to provide open standards for communication between applications that present context-driven information to their users. Major software vendors are involved in the development of Web Services standards.

A partial definition from the Web Services Architecture Working Group defines a web service as “a software system identified by URI whose public interfaces and bindings are described using XML.” XML stands for Extensible Markup Language, and Uniform Resource Identifier (URI) is defined in RFC 2396 as “a compact string of characters for identifying an abstract or physical resource.” Any Web Services–compliant software system or applications should be able to discover a Web Service interface in another application and subsequently interact with it by exchanging XML messages via the Internet protocols. Sounds simple and promising.

The benefit of Web Services is their platform and programming language independence. The emerging challenge for Web Services, which is causing concern among some developers and industry observers, is the increasing amount of expertise required to use them due to the ever-growing number of standards that fall under the Web Services (WS) umbrella. The standards include WS-Transaction, WS-Security, WS-Trust, WS-Context, WS-Coordination, WS-Federation, and much more. In addition, numerous protocols are included in the XML standard, creating an acronym soup of their own. As the Web Services and XML standards continue to evolve and proliferate, the market will ultimately determine their acceptance and their role in the applications integration arena.

One example of an XML and Web Services–based integration tool is the Universal Applications Network (UAN), developed by Siebel Systems in collaboration with partners and technology vendors. Siebel positions UAN as a standards-based architecture that is used for the development of Business Integration Applications (BIAs) aimed at industry-specific and cross-industry business processes. Cross-industry business processes include Order Management, Customer Lifecycle Management, Sales Management, Partner Relationship Management, and more. Specific industries for which Siebel has developed BIAs include communications, energy, financials, and automotive.

Consider an applications environment in need of integration, either in terms of business processes or a specific industry. Apply to that environment a tool on the order of Siebel's BIAs. The separation between the front and back office aspects of the applications environment tends to disappear because many business processes span both front and back office functions. Thus, clearly understanding the nature of the business operations and being able to define business processes become the first steps in any applications integration effort.