Since agreeing to chronicle the thought process behind CROSSMARK's Knowledge Management System (KMS) and the use of NeoCore's XML Information Server, I've been involved in two incidents that convinced me that CROSSMARK needs both of these to be successful.

The first incident involved Markatec, a start-up business that provides a best-of-breed marketing approach to comarketing, brand development, and promotional services. Markatec and another company hosted an educational/sales seminar. The seminar was intended to target only C-level executives such as CEOs and CFOs; Markatec's obligation was to fill between 20-40 seats. They used a list of contacts from another company to generate the target list of C-level executives. The list was created by the sales force of the company that provided the list. The problem with the list was that none of the names were C-level executives.

When informed about the deficiency, the list owner said that the contacts on the list would help get the contact information for the top executives from the companies on the list. Markatec had to call only the listed contact for that company. Markatec complied and made the calls. Later, when the list owner was offered the collected information, it was declined. At this point, I had to know why the list owner didn't want this valuable information. The list owner stated that it wouldn't be worth the effort to keep up with the changes.

The second incident relates to a joint venture between four companies planning a virtual supply chain for international consumer product companies trying to enter the U.S. market. This story is similar to Markatec's except that each of the companies had a common interest, the joint venture. All the partners considered the proposed venture to be strategic, but none had gathered the needed information. Each company had a list of contacts that reached only to the edge of its core business. I asked each company why it didn't gather information up and down the supply chain if it viewed the supply chain as strategic. The answers came back to the same point as in the previous incident: the cost of gathering information and performing maintenance on the information exceeds the value even when the use of the information is strategic.

The underlying issues behind these two incidents demonstrate that companies have a long way to go before knowledge management is practical. I use the word practical instead of possible because two of the companies involved in the incidents just described use Customer Relationship Management (CRM) software as well as several Enterprise Resource Planning (ERP) software modules. All the companies have Web sites, e-mail, and corporate local area networks (LANs) with Internet access. The point is that capturing peripheral information about your customers and their interests is possible, but few firms have figured out how to make it practical for the employees who capture the information.

The individual salespeople who generated the list of contacts used by Markatec knew the names of many of those C-level executives. In fact, many of them had actually met with or worked with those executives at previous employers. It was surprising to find out how much of the knowledge Markatec needed to achieve the goal was trapped in the heads and disk drives of the salespeople.

CROSSMARK's approach to knowledge management is centered on two simple ideas: understanding the connectivity of each employee, and being able to capture and categorize peripheral information around the everyday interactions of the company's employees, clients, prospects, and competitors. The best example of connectivity is found in the popular parlor game "Six Degrees of Kevin Bacon." The objective of this game is to link any actor or actress, through the movies they've been in, to the actor Kevin Bacon in less than six steps. For example, Mary Pickford was in Screen Snapshots with Clark Gable, who was in Combat America with Tony Romano, who, three decades later, was in Starting Over with Kevin Bacon. That would be three steps or three degrees.

A computer scientist at the University of Virginia by the name of Brett Tjaden figured out the average number of degrees of connectedness for the quarter million or so actors and actresses that have acted in major motion pictures. Kevin Bacon's connectivity factor is 2.8312, which means that in under three moves you can connect each of those quarter million actors and actresses to Bacon. Bacon ranked 669th on the list. Imagine keeping the contacts of who you've met like credits in a movie and having access to the credits of your fellow employees.

Now think about how much easier it would be for you to meet the movers and shakers in your industry. If you're thinking that most of the people who work with you won't take advantage of a personal contact and good friend for personal advancement, you should think again.

Mark Granovetter, in his 1974 study "Getting a Job," looked at several hundred professional and technical workers from the Boston suburb of Newton. He interviewed them on their employment history and found that 56% found jobs through a personal connection. Using personal contacts to accomplish a goal is not surprising by itself. Granovetter found that most of the personal contacts that led to jobs were "weak ties." People weren't getting their jobs through their friends. They were getting them through their acquaintances.

Capturing the data around the interaction of employees, clients, prospects, and competitors is a tough challenge. This information comes in many forms such as phone calls, face-to-face meetings, memos, news releases, brochures, Web sites, and e-mail. We needed a data repository that would allow the storage and cross categorizations of heterogeneous data. Capturing and making order out of this chaos is only the beginning of our challenge. We need to be able to use the data repository to generate new perspectives to facilitate problem solving. In other words, knowledge management should lead to insight. NeoCore's XML Server is helping to make our knowledge management approach practical.

Project Description
CROSSMARK has envisioned a solution that will allow this information to become invaluable to the organization. In the proposed solution, users can freely add information that comprises many formats into a central repository. This information can become the global knowledge of the organization as it's available to all employees. But aggregating a mountain of knowledge into a single place provides little benefit if the relationships between the pieces of information can't be seen. This ability is where the power of the proposed system lies (see Figure 1).

The architecture of the Knowledge Management System is a framework for the storage, retrieval, manipulation, and viewing of entities and relationships. An entity (see Listing 1) is considered any unit containing data or information. A relationship connects one entity to another; theoretically, an infinite number of relationships can exist between two or more entities. Knowledge nodes encapsulate the information contained in two or more entities that are related, including the nature of the relationship itself. An entire collection of entities and relationships form a data repository that holds an organization's taxonomy (see Figure 2).

Status of the Project
In attempting to prove that rapid development against a relatively free-form XML data repository is simple when compared to a structured relational database, we lost time focusing on database design. In fact, we discovered that doing so with the NeoCore XML Information Server isn't necessary. As of this writing, our timeline for this project is two weeks behind. The good news is that none of the lost time is due to problems with NeoCore's XML Information Server.

CROSSMARK relies on standard Rapid Application Development (RAD) methodologies in its software projects. Another technique used by CROSSMARK is designing to accommodate changes. Most short-term change is predictable given a thorough knowledge of an organization, its culture, and environment. Adopting this practice, however, requires significant time during the design phase to ensure the design is correct and can be modified to meet anticipated changes. The time required is amplified when designing the data-storage tier. While changes to the logic or presentation tier can usually be implemented quickly by code changes, changes in the data tier inevitably have a ripple effect throughout the entire application and often require changes in the logic and presentation tiers.

Another problem with designing to anticipate change is that the application designer must have a thorough knowledge of the problem, and the project requester must completely define the requirements. This condition is rarely met, meaning a typical application contains flaws because of incorrect assumptions or incomplete knowledge of requirements.

NeoCore's XML Information Server solves the data tier. For years the best developers have been those who allow time to understand the requirements and build a data tier that can handle changes. Telling a developer not to worry about the data tier is like telling a fox not to eat the chickens. We lost time on this project by worrying about the data tier. The biggest hurdle to maintaining applications is unanticipated change. Part 1 of this article (XML-J, Vol. 2, issue 3) discussed some of the challenges CROSSMARK faces providing custom sales and marketing services to product suppliers and retailers. The very nature of providing a customized service means that CROSSMARK is constantly looking for new opportunities and adapting to meet new requirements. We're not alone in facing this challenge; rapid change is occurring in virtually every industry.

One practice that can insulate systems from unanticipated change is to implement a flexible structure. The goal is a flexible process and architecture that can react favorably to virtually any new requirement the future throws at it. As CROSSMARK has seen time and time again, a flexible design is necessary because the perfect design is impossible.

A prime technique to achieving a flexible architecture is to make the data tier easily adaptable. To achieve this, the system must be divided into separate state and logic layers. This is a common design practice, and the data layer usually exists as a relational database. This approach doesn't go far enough. Applications implementing relational databases, by their nature, don't provide a flexible architecture. Though building and modifying the database during initial development is a simple task, once the logic and presentation tiers have been coded and the database populated, changes to the data structure often require significant effort. Granted, this inflexibility is also the great strength of relational databases. They ensure well-formed, consistent data at the database engine level through table structures and referential integrity. Many types of applications require this kind of rigidity, but for those that can accommodate the tradeoffs of a flexible architecture, a relational database can be more a hindrance than a help.

It's in this space that NeoCore's XML Information Server will become a mainstay. By its very definition, XML is flexible. The extensibility of XML allows it to describe a wide variety of heterogeneous entities. And since XML-based data is self-describing, data can be processed and stored without having a predefined description. If the state information is persisted as XML, changes to the data structure might necessitate changes in the logic layer, but it wouldn't necessarily break existing applications by requiring restructuring of the data design.

The traditional niche for XML has been as a transport mechanism. A commonly cited role for XML in a complex application is in a data exchange port in which the application receives and transmits data as XML. However, once the XML is received, it's typically translated to another format and usually stored in a relational database. Until now, documents have rarely been stored as XML because of the inability to get at the underlying data in an efficient manner. Previous efforts at CROSSMARK involving storing data as XML have taken a conventional approach. Documents are stored as XML files, and metadata containing the contents of each document is stored either in a relational database or in separate XML documents. But NeoCore's XML Information Server removes this limitation. The product allows you to query an entire repository of XML documents in their native format and find, for instance, all transactions related to one company or all that occurred on a given date.

Advantages include:

• No need to pre- or posttranslate the data; XML is received, it's stored as XML, and XML is the output.
• XML exchange apps that store data in a database require assumptions about the way the data will be formatted. Queries can be optimized based on that format, but what happens when the format changes? Changes in tag structure, location, or name require changing the translation maps, and additions of new tags require modifications to the database structure. By translating the data into a proprietary format, you effectively remove the "eXtensibile" from XML. NeoCore puts the "X" back in XML and frees you from these limitations. Since documents are stored in XML, they can be queried based on their tag structure, data contents, or both, with no mapping or structural changes to the database required.

• Storing the data in its original format, as a single document, allows it to be treated as a single entity. Because of its hierarchical nature, when XML is stored in a database, each level of the hierarchy is typically stored in a child table. For example, an XML document with a root node and three child nodes, each having another three child nodes, would require 13 tables. Querying, decomposing, re-creating, and processing such a document would be a task best left to experienced programmers. Now multiply that by the number of documents that would exist for an average XML-based exchange and the task of maintaining the proprietary format, and it becomes overwhelming.
• Excellent speed with large amounts of information.
• Easy to use.

CROSSMARK is excited by the potential of NeoCore's XML Information Server. To investigate its viability, we needed a pilot project. Fortunately, we had a ready-made problem crying out for the flexibility offered by NeoCore's product. Part 3 will let you know how it all turns out. We're more than halfway through this project and our expectations have increased.