Why is having a single point of entry for each unique piece of data such a difficult task?
For many years—after the heyday of the centralized mammoth mainframe computers—the need for multiple points of entry was easier to understand. There were almost unlimited choices in application software, vendors and development tools. Each vendor had its own set of software, style and tools, and data repositories; having to enter a client or customer record to create relationship data more than once was comprehensible and acceptable.
Today, as much as we curse the continually changing technology climate, there are benefits. True affordable data integration is somewhat available, although we may not take advantage of advances in this area. Welcome to the still-evolving world of data integration!
What happened? The first key differentiating factor is a move to more standardization for back office database structures and software development tools. Just as desktops became standardized around the office suite (word processing, spreadsheet and presentation software), the toolsets also became standardized for software development teams.
Standardization does not have to mean the exact same database, but simply the ability for applications and data repositories to communicate using a standard language. Communication "protocols" within the world of technology are once again becoming transparent—and businesses are taking advantage of the power offered.
There is also a shift within the software vendor industry toward more acquisitions and mergers between different software companies. By combining different production environments, vendors must invest in tools that support quick integration between diverse applications. The "suite" approach to software vendor offerings can be seen at almost every large software vendor. Yet, if you look behind these suites, they are often nothing more than what we already have in our office: a number of different applications designed by different teams that need to be bridged. This brings our discussion around to the software teams who design the bridges and the tools available to them.
The tools exist! These tools are software applications designed to integrate different products. Some of the bridge development software tools are pre-designed to hook two specific applications together, while others are designed with flexibility to allow customization for more diverse needs. The key concept here is that this technology is not new; it is simply more refined because of the current climate of demand.
For a real-world bridge example, consider XML Junction, a tool tapping into more standardized data formats (XML or eXtensible Markup Language) to bridge diverse stores of data. The company, Data Junction, was purchased by database vendor Pervasive, a popular database used by some accounting software vendors. More interesting within the accounting firm space is that Pervasive was purchased by LexisNexis, the same vendor who writes Billing Matters and Time Matters, popular time tracking software.
Both products are considered leading business and practice management software. Do you recognize a pattern?
A similar pattern can be seen at companies such as Wolters Kluwer, the parent company of CCH. Many of the CCH suites of bridged software are now sub-branded. For example, CCH ClientRelate streamlines professionals' practice by integrating the research authority of CCH's Internet Tax Research NetWork with the power of CCH's tax compliance software. This integration is depending on the layers of software developed to bridge diverse applications.
How does a smaller firm integrate the numerous software applications it is already using? The first step is to recognize that the Microsoft office suite of software is integrated. Microsoft Word, Excel, and Outlook currently have integration configured within the applications. Tap into this existing integration to increase efficiency and work flow. Many of the integration features, such as creating an instant SharePoint Collaboration area from Word, are unknown and under-utilized.
Your next step is to document the applications currently being used within your environment. Good questions to ask include: How old are they? When will you need to update them? In addition, you will want to find out what your current software vendors are doing about integrating and/or partnering with other software vendors. Do a bit of research, have a few conversations and think tactically about moving from your current redundant environment to a more seamless operation. Once you understand where you are, you will find that there is a wealth of information available to get from point A to point B.