Semantics in Business Systems: The Savvy Managers Guide (The Savvy Managers Guides)

Everyone has some projects in progress. These are your best and most immediate opportunities to take these ideas for a spin. Following are some ideas organized by the type of initiatives you might have going.

Application Development

• Rethink the boundary and the scope from the standpoint of how they fit in with the rest of the enterprise.

• Perform a set of semantic modeling sessions to determine if there are any constructive changes you could make to your data model.

• Ask yourself whether there are any unstructured data interpretation needs that could be met by a package or a tool.

• Have you looked at the areas of your application most likely to change, and considered applying metadata design techniques to those areas?

Selecting Packaged Applications

• Add to the requirements items such as the need for an XML or Web Services interface.

• Go one step further and examine whether the interfaces are really what you need to fit the rest of your architecture.

• Select a package that can be partitioned and decommissioned in pieces if need be.

Implementing an Application Package

• If you're in the middle of implementing a package, ask yourself whether you really understand the semantics of the package you're implementing.

• If you understand the semantics, are they well documented? Can you express the semantics of the interfaces?

• If you don't understand the semantics of the system you're implementing, now would be a good time to learn them. Try a semantic modeling session with the vendor.

Systems Integration

• Build a message model as the basis for your integration efforts.

• Make sure you can express any of your interfaces in XML and potentially RDF, even if for performance or other reasons you aren't doing that now.

• Do data profiling on the data you will be integrating; make sure it means what you think it means.

Middleware Upgrade

• If you are in the middle of upgrading your middleware, check that it will support a message-oriented style of interaction.

• Make sure you are building to a message broker style of architecture to overcome the exponential explosion of interfaces.

• If appropriate, determine whether a semantic broker would fit in with the new middleware.

• Make sure that the way you are implementing the middleware doesn't cause you to become too closely tied to a particular vendor or a point-to-point style of interfacing.

Knowledge-or Content-Related Initiatives

• If you have any initiatives that deal with knowledge or content, have you looked at a knowledge base or a rules repository?

• If so, do you have a good semantically based ontology on which to express the knowledge or the rules?

• Have you looked at the use of codes and categories throughout your application systems and considered centralizing them under the purview of an ontology-based repository?

• Do you have a consistent way to identify real-world items (partners, products, locations, etc.) and intellectual property (official versions of documents, code sets, etc.)?

Business-to-Business and eCommerce Initiatives

• Do you have a common vocabulary or taxonomy that you can use to avoid having to reimplement your mappings for all your trading partners?

• Do you have an enterprise solution for business-to-business (B2B) or are you allowing this to be done on a project-by-project basis?

• Are your eCommerce initiatives integrated with your transaction systems, or are they stand-alone systems?

Web Site Upgrades

• If you are in the midst of a Web site upgrade, have you considered converting the content to a format that would allow more reuse, such as XML instead of HTML or pdf?

• Have you made arrangements to repurpose your content to alternative devices, such as handheld devices, cell phones, voice interfaces, or tablets?

• Are Web site transactions integrated with your broader work flow initiatives?

Platform Rationalization

• If you are in the midst of rationalizing your platforms (consolidating some old hardware, databases, operating systems, etc.), it is a good time to ask yourself what the motivation for the consolidation is.

• If some of the platforms have become obsolete, that's a good reason to rationalize.

• If the rationale is to get all the platforms to talk to each other, or to make interoperability easier, you may want to rethink this. It may be more effective to wrap the platform with an adaptor and replace it later at your leisure or when it truly becomes obsolete (whichever occurs first).

Software Maintenance

• Almost everyone is involved in software maintenance. In the midst of this, though, you might ask whether your current systems are unwieldy to maintain (most are).

• If your current systems are unwieldy to maintain, can you use your maintenance requests as an opportunity to begin refactoring your application into partitions that are more cohesive, easier to maintain, and possible to replace?

• Instill a step for all maintenance work to explicitly capture the semantics of the portion of the database that the maintenance request touched. (This will require a repository of some sort to maintain this information as you gather it.)

Application Architecture

• If you do not have a project underway to define or redefine your application architecture, you need one before you do any more implementation projects ("first do no [more] harm").

• Determine your need for shared services, and conduct a requirements study.

• Begin to think how you will make data accessible in a transparent and unambiguous manner.

• Identify message-based interfaces for your shared services that are specific enough to be useful and generic enough to be shared.

This should give you some food for thought, as well as areas where you can start applying semantics to the work you're already doing. I hope that, after looking at this list and reflecting on the content of the book, you will realize that semantics, far from an arcane specialty, is at the heart of everything we do as information system professionals.