s seen at the recent 2008 Semantic Technology conference in San Jose, serious interest in corporate use of semantic technology continues to grow rapidly. Semantically-enabled applications are increasingly seen as fertile ground for Web 2.0 applications such as mash ups as well as the basis for innovative business intelligence strategies, internal collaboration wikis, and rich canonical models for service-oriented architectures (SOA).
What’s lacking, however, is a clear understanding of where semantic technology fits in enterprise architectures. Should it be thought of primarily as purely a web technology to integrate information on the presentation layer? Should it be seen as closer to the data layer of the application because of its potential to bring disparate sets of data together? Alternatively, should semantic technology be focused on the increasingly important middle layer of enterprise architectures where messaging and service implementations live?
Where Does Semantic Technology Fit in an Enterprise Architecture?
Semantic technology's perennial problem is to gain enough traction to be taken seriously in the corporate world—lest it suffer the fate of object databases—exciting ideas with only niche adoption. Currently, semantic technology is all about “critical mass,” for example, having broad enough adoption that it becomes ubiquitous. Its place in enterprise architecture needs to be clarified; if we don’t know ourselves where it fits, we’re going to have a hard time explaining it to anyone else and an even harder time getting anyone to finance the dollars to make it happen!
First, let’s look at a typical current corporate architecture. With rare exceptions, nearly every real corporate architecture has grown organically. Most mature companies have multiple databases and multiple programming paradigms. People who are new to the field would be shocked at how many major systems continue to run on mainframes accessed via a “green screen” (a dumb terminal that connects to the mainfraime and nothing else). Most of us who’ve been around a while thought these would be long gone, but the reality is that a huge proportion of corporate computing continue to run on mainframes. These systems are simply too complex to rebuild. Newer systems tend to be built on more open platforms—but real architectures are nearly always hybrids—they mix the most modern Web 2.0 features with systems that are at least a decade old.
Figure 1. Sample Hybrid Architecture:
Most enterprise architectures combine services, sometimes including those requiring human
intervention, with tightly coupled interactions.|
As shown in Figure 1, many applications in a real corporate environment remain as two-tiered applications, connecting directly from the data layer to the presentation layer. Applications built since 1990 are commonly comprised of three tiers with either a J2EE, .Web server, or a .NET application intervening between the data and the UI. As service-oriented architectures have proliferated and enterprise service buses become common, the intervening layers have become “thicker,” decoupling the entire presentation layer and application layer from the underlying data stores.
Presentation and Data Layers are Obvious Opportunities
Semantic technology is a collection of technologies, rather than a single model, so it can fit into more than one place. For simple data aggregation “on the glass” or in a thin application close on the UI—in the mode of Web 2.0 applications—the presentation layer is an appropriate target. Using XSLT or other presentation tools, information can be mashed directly on this layer. A corporate collaboration wiki could use this layer to interconnect data from a wide range of sources.
On the other end of the spectrum, semantic technology can be appropriately used on the data layer of the enterprise architecture. “Tall skinny” tables containing RDF triplets or quartets have the potential to provide a more dynamic means of storing data than relational tables. This is particularly crucial when the relations between data elements are themselves subject to frequent change. An example of this use is found in storing policies, such as web service policies, that drive services contracts. The exact interrelationship of these policies can be difficult to predict in advance, therefore, changes in relational tables require modifying columns and foreign key relationships. A table in which the columns are RDF subject, verb, and predicate (and, potentially, provenance), changes in structure only require CRUD (create, read, update, delete) operations on rows, and so are far more flexible.