User (backend) applications are built using many approaches…and for many purposes. From database to flat-file to XML, and from third-party-acquired to in-house-developed, the solutions vary greatly. In-house-developed applications are typically the result of several hasty decisions made by organizations that generally include either or both of the following reasons:
- The requirement (for now) is small – it will be quicker and less-costly to build an in-house solution while a long-term resolution is examined. Unfortunately, more often than not, the short-term solution becomes the long-term resolution, and ongoing challenges will bring about more long-term bandages.
- It is believed that a third-party solution certainly could not provide the customization needed for the company’s business and therefore it would be most beneficial to build an in-house-designed application rather than buying and re-customizing portions of an available third-party system.
When coupled with the varying Business-to-Business (B2B) data formats and production requirements that frequently change from customer to customer, a company can quickly find itself trapped in situations where it becomes more costly to implement and maintain a new customer than the gained revenue by adding that new customer.
In many situations, multiple interfaces will be put in place and the costs for ongoing maintenance will continue to compound over time. Obtaining and sharing data between these disparate systems is critical for a company but might not be achievable without further costly development. And, let’s not underestimate the perceived “unthinkable” – certainly not a product of technology but rather due to a lack of progress – that manual entry of phoned or emailed customer data could make up a reasonable portion of the company’s business.
Strategic decisions do not always involve the overhauling of backend applications but instead may take advantage of integration technologies that might otherwise be viewed as tactical solutions. B2B integration through a consolidation of interface tools will combine a common interface with an expanse of supported connections and format types. While support of common standards is generally expected, the hidden value may exist in the ability to refocus the “assembly line” of users tasked with manually entering data to tasks that will instead increase the volume of customers.
The “B2B Traffic Cop” is an approach that employs an integration broker to direct and process electronic data into and out of the customer’s system by offering many communication connections and integration options. This provides the means by which a single solution can handle any data format required and thus eliminating the need for multiple interfaces, programs, products, and/or tools, and to reduce or eliminate manual intervention. (Diagram 1 shares a simple depiction of such an environment.)
With this said, consider the scenario where a company sells fine jewelry to a dozen retail outlets. These outlets could vary in size from large retailers to small family-owned businesses. Where the large retail company may be more advanced using XML formats and secured by AS2 communications, another might be EDI-enabled using FTP through a third-party service such as a value added network (VAN), while yet another might only be capable of sending spreadsheets by way of email. Already we see the need to support three different connection types (AS2, FTP/VAN, and Email) and three different data types (XML, EDI, and Spreadsheet)…all to be integrated into the customer’s backend application. The possible solutions are many and could vary from outsourced managed services, to acquiring and implementing multiple products to support both connectivity and data requirements, to developing in-house solutions that are part or wholly unique to the requirements of each individual customer. Regardless of the chosen solution(s), time and money will ultimately affect whether the company can continue to do business while maintaining profitability.
In this example, a single integration broker will provide “Connectors” (links between the company and its customers) and “Adapters” (links between the company’s applications and its customers’ data formats). Acting as the integration “traffic cop”, the integration broker will see that all data is funneled through a single collection point and will be distributed to the appropriate applications through configurable interfaces designed to eliminate extraneous custom-coded functions. Technicians will have one product to learn and one place to look.
What lies in store for the users responsible for receiving and manually entering data into the backend application? They can move away from those daily mundane tasks and contribute in areas more directly related to business expansion…not to mention the company is certain to have cleaner data!