E-business and Data
We’re past Y2K, and nearly all systems survived with nary a problem. Now we can turn our attention back to how to use IT to solve pressing business problems.
One major issue is how to address the challenges posed by competitors that are leveraging the Internet to gain business advantage. A lot of people are talking about e-commerce and e-business in this context and, in fact, I believe most people would say the two terms are synonymous. There is a crucial difference between them, however. E-commerce is a subset of e-business. E-commerce is the set of processes and activities that enable a consumer to purchase services or products from a provider using software and networks to complete the transaction.
E-business, on the other hand, can include a host of activities other than buying and selling. For example, e-business can include engineering, product specification, and design. It can include customer self-service for support after a sale. It can include query and analysis to allow a purchase agent to examine, analyze, and modify the procurement behavior of an organization.
If you’re thinking about deploying an e-business application for your company, there are two major areas you have to consider: applications and data.
The applications component will be driven by your goals and objectives, which may have a profound impact on its business model.
The data component will determine what kind of infrastructure is required to effectively implement an e-business business model. For instance, if you want to deploy a customer relationship management (CRM) system, you need to develop a way to deliver data to all customer touch points, such as Web sites, call centers, e-mail and snail mail correspondence, faxes, inside and outside sales people, customer service representatives, or physical offices. The problem is this data is often stored in a variety of applications, including order processing, accounting, and shipping.
Another example is electronic engineering. Product specifications, design documents, engineering change orders, diagrams, bill of materials, and other engineering documents all need to be shared with engineers and designers within your company, as well as with organizations that are either upstream suppliers or part of the downstream distribution channel. Often these documents are stored in a heterogeneous variety of home-grown or packaged applications.
The problem you have to consider is how to deliver the information these applications require. The first thing to do is define what data is required, then create an inventory of where the data is located. This inventory should include information about the data location, database structure, database format, and its relationship to other data elements.
Once you have identified the data location, you then need to consider how to make the data available to the new e-business application. Again, this will be driven by the application’s requirements. Some applications will be oriented to deliver information to people. People, unlike machines, typically have some flexibility and can deal with data ambiguity. Some applications, on the other hand, require machine-to-machine interaction. Machines are still rigid and inflexible, so data ambiguity must be eliminated.
In some instances the best thing to do is to run batch extraction routines and load the data into a data warehouse or data mart. In other instances, it is best to leave the data where it is and build or buy an integration tool to retrieve, modify, or update the data in place. This can be complex, especially if the data is stored in older databases where access may be problematic. It can also be a problem if the data is stored in a proprietary format or if an update would require simultaneous updates to multiple databases. A third alternative is to build a data transport mechanism that takes data in its native format, converts it to a vendor or platform-neutral format, such as XML or a message queue. Once the data is in a standard format, multiple applications will be able to act on it, assuming you can build or buy adapters for each data source.
The most important thing to do is to make sure that you keep abreast of how standards, like XML, are evolving so you can leverage them as much as possible. --Robert Craig is vice president of marketing at Viador Inc. (Burlington, Mass.), and a former director at the Hurwitz Group Inc. Contact him at robert.craig@viador.com.