— ANDREW CRAPO, AMY ARAGONES
There are a variety of tools and approaches available to model the enterprise and its processes. Almost all of these lack a clear, standards-based semantics and the ability to integrate different types of enterprise models. Semantic technology addresses some but not all enterprise modeling needs. Hence enterprise modeling can derive significant benefit from embracing semantics, and semantic technology might be made significantly more robust and valuable by applying the community’s skills to enterprise modeling problems at-hand.
Introduction (or Everything is Model-Driven)
There are a lot of modelers in this world—arguably every functioning person falls squarely in this category. Most do not think of themselves as such. They build mental models that allow them to play games, interact with other people, survive and even thrive in a diverse set of situations and activities. A small subset of the totality of humanity consciously builds models, which they capture in information-bearing artifacts. These self-acknowledged modelers come from many disciplines and use many different languages and tools. Are there modeling principles that span these diverse domains? Do they translate to common methodologies? Languages? Tools? If so, can this modeling landscape itself be modeled and the various approaches, languages, and tools thus be put into relationship in a way that provides a useful context for each? We think the answer to at least some of these questions is yes, and we will argue that semantic technologists can both benefit from and enhance their contributions by considering where semantic modeling fits into the larger picture, and more precisely how it can help integrate enterprise architecture (EA) and business process modeling (BPM).
The Case for Better Enterprise Modeling
During the past several years, we have had the opportunity to think about and work on modeling at the enterprise level. We think that enterprise modeling, also known as enterprise architecture, is of increasing importance. A complex enterprise without direct line-of-sight to its architecture puts itself at risk for a number of adverse effects, including
- The inability to anticipate and manage the impact of change
- System and application downtime
- New and often-unforeseen security threats
- Higher cost of doing business
- The need for – and the lack of – people with specific skills to keep systems running
- Disproportionately high spending on systems maintenance rather than new technology development.
Enterprise Architecture mitigates these effects by providing a core knowledge base about how the enterprise works and why. Enterprise architecture has been practiced for a long time and many different definitions, methods and frameworks have been used (see Lankhorst  for an excellent overview of popular methodologies and frameworks).
In practice, enterprise architecture diagrams and documents tend to be developed in formats that are ill-suited to long-term maintenance and repeated use. Diagrams about business process, strategy or composition are often captured in PowerPoint charts, which are usually short-term representations for one or at most a handful of static presentations. Sometimes a flowcharting package like Visio is used when the diagram grows large and more detailed. These formats have the advantage of being visually oriented and crafted for ease of communication (although a little probing often reveals that there is a great deal of ambiguity around the communication). Usually as much or more time is spent manually laying out and formatting the picture than is spent modeling. These formats are also “lossy” representations in the sense that important metadata are not captured, hampering extension and re-use. For example, arcs and nodes are often unlabeled and inconsistencies in how concepts are visualized limit the ability of future users or readers to interpret what they mean.
Spreadsheets can be an improvement over diagrammatic formats because formulas require some level of consistency to work and metadata are made explicit in labels heading columns and rows. Spreadsheet enthusiasts will tell you that Dan Brickley’s invention  has turned millions of people into modelers by allowing them to build computational models of just about anything. However, researchers have also found that the spreadsheet models that drive much of the world’s commerce and engineering are full of errors . Further, spreadsheets aren’t necessarily easy to make sense of after the fact or by someone other than the creator. Tabular views are also limiting in the number of perspectives one can generate from a single model and are not well-suited for visualizing process or information flows.
Snippets of enterprise architecture are scattered throughout presentations, spreadsheets, information systems and documentation. They rarely integrate well and often conflict with each other and lack consensus in terms and meanings. Even information captured through requirements engineering and software design tends to be single-purpose and lacks consistency and completeness. We see the same modeling activities done over and over again as prior models are lost to employee turn-over or a forgotten shared drive or just because a particular problem or domain is being considered from a different angle or by a different group.
The most valuable enterprise architecture is based on a shared and extensible representation (model) of the enterprise that is both easily understood by humans and computable or translatable by a computer. The model characterizes the elements that comprise the enterprise, their properties and the relationships that connect one entity to another (for example, process hierarchies, enabling systems, system dependencies, etc.). The model is a platform for analysis, insight and communication about how the enterprise works, why it works the way it does and what will happen if we change elements within it. There are a number of well-regarded tools on the market that support enterprise architecture modeling (see Forrester  and Gartner  for on-going research on the state of the art in enterprise architecture tools).
However, these enterprise architecture tools can quickly become islands of partial knowledge themselves because they lack a shared, well-founded semantic underpinning. As a concrete example, we have begun to evaluate business process modeling and business process management (BPM), which has received a lot of attention in recent months. Service Oriented Architecture (SOA) promises to restructure enterprise applications into flexible combinations of reusable atoms of computation and BPM stands ready to orchestrate those services at the beck and call of business leaders. One of the most interesting objectives of standards and tools in the BPM arena is the effort to provide a “top-down” business analyst viewpoint using Business Process Modeling Notation (BPMN) and a “bottom-up” IT specialist viewpoint using Business Process Execution Language (BPEL). The holly grail is the shared model in the middle. Some BPM enthusiasts even go so far as to suggest that the process view, using formal foundations such as π-calculus, is the computing paradigm of the 21st century.
However, when we ask BPM vendors how they integrate with existing enterprise models most have no better answer than that a low-level BPEL script can access a database or execute a set of instructions. Enterprise Architecture tool vendors fare better since many provide capabilities for integrating enterprise models with business process models – if you use their tool as a holistic, enterprise-wide modeling solution. Even then, integration solutions tend to be proprietary or require custom programming after significant investment in learning the meta-model or API. There is little appreciation of how ontologies could be used to integrate BPM with other enterprise models at a semantic rather than syntactic level. Most tool builders, in our experience, have never heard of OWL or RDF. Even if they have, how they might use them for integration is far from straight forward because BPM and enterprise architecture can have very different views of closely related things.
We first encountered the difficulty of integrating state and process in the Adaptive Work-Centered User Interface Technology (ACUITy) project , which used semantic models to drive user-interfaces. We found OWL to be well-suited for modeling the concepts behind interactive user interfaces—the types of input and information display widgets with their properties and even the connections from these display widgets to the underlying domain-specific information stores—but we found it more difficult to model behavior—the transformation of information from one format to another, or the reconfiguration of the user-interface in reaction to new information. In ACUITy we adopted John Sowa’s Script concept  and sub-classed it with various kinds of procedural code, e.g., Java, and scripts for various purposes, e.g., to learn over a set of instances. While this approach achieved our functional objectives, it was not a very “smooth” integration.
So while OWL and related semantic technologies seem to focus on the state side of things and are good at modeling the Continuants  of a domain, they seem less well-suited to modeling the process side of things—capturing the essential aspects of the Occurrants . This difficultly seems to have been encountered by the OWL-S community. OWL-S seeks to provide an enabling model for Semantic Web Services. Had it been entirely successful, there would perhaps not be a Web Services Description Language (WSDL) or a SAWDL (Semantic Annotations for WSDL) recommendation for WSDL-S. (Although WSDL-S offers an ontology language independence not available with OWL-S.)
Meanwhile, the Object Modeling Group (OMG) effort in Model Driven Architecture (MDA) tries, among other things, to solve the same fundamental problem as does BPM. “No longer tied to each other, the business and technical aspects of an application or integrated system can each evolve at its own pace…” . MDA addresses explicitly problems such as differentiating between model and meta-model. An explicit understanding of the meta-model of a particular language, e.g., OWL, facilitates understanding of the capabilities and limits of the language as well as automated translation to and from other languages, e.g, from OWL to UML and vice versa. The Meta-Object Facility (MOF), provides a formal modeling paradigm for expressing meta-models of models, meta-models of meta-models, etc.1 Using MOF, one can represent the language concepts of OWL. Meta-models of OWL 1.1 in MOF-like representation are available . OMG continues to try to increase the semantic capability of MOF and MDA. Perhaps the most advanced effort to bring the two modeling communities together is the Ontology Definition Metamodel Specification .
Familiarity with MDA efforts among semantic technologists does not seem widespread. Most in the enterprise architecture and BPM fields seem entirely oblivious to both MDA and W3C efforts to raise modeling to a higher level of abstraction and integration. Hence, while many off-the-shelf enterprise architecture tools have invested in meta-models that provide structure to their repository, these meta-models are often proprietary and are not cleanly integrated with standard representations that can render the enterprise architecture computable (e.g., consistency/completeness checking, OWL reasoning, BPEL execution, etc.). This leads to the common bifurcation between enterprise models: those which remain purely informative, and those that actually gets executed. Any enterprise knowledge repository that is divorced from the applied operations (computations) of the business becomes difficult to maintain and therefore limited in its usefulness beyond documentation.
A Plea for Semanticists to Collaborate with Researchers in Other Modeling Disciplines
In addition to solving the integration problems discussed above, there would be other advantages to using semantic models in enterprise architecture. First, since they are understandable by both humans and computers, the concepts expressed in the model can be reasoned over using computational methods to check for consistency and completeness or to provide decision support.
Second, semantic models can be nested and extended. Domain-specific models can import and extend upper-level models, promoting information reuse as well as the use of common semantics and model frameworks. Commercially available enterprise architecture tools provide this capability by copying and merging data repositories, which introduces the complexity of ensuring that diverging copies remain consistent as changes are made.
Third, ontologies neatly address Lankhorst’s  recommendation that the intrinsic model of the enterprise architecture be abstracted from its visual representation. We can visualize model concepts in a variety of different ways, depending on which properties we want to highlight, but the underlying properties of those concepts should not change. This level of abstraction is not readily apparent in most tools we have evaluated. Adaptive’s Enterprise Architecture Manager  does abstract the symbolic representation from the semantic representation of EA elements, but does not integrate with standard semantic technology (e.g. OWL language, OWL reasoners, etc.) and visualization choices are limited.
Some practitioners and researchers have explored the use of semantic technology to model the enterprise (see for example, the Federal Enterprise Architecture Reference Model Ontology , the TOVE ontology project , and the IDEAS Group ). There has even been recent reference to utilizing ontology editing environments as enterprise architecture tools  . However, semantic technology in its current state is not the answer to all of our modeling needs. There is, first of all, a lack of commercially available and well-supported semantic tools for modeling EA. State-of-the-art ontology editors are not yet appropriate for use by business specialists to model the enterprise day-to-day, where the tool of choice is probably ExcelTM. Some may be reluctant to grant model status to spreadsheets2, but to claim to be better for a particular modeling purpose, new technologies will have to be “good” enough to lure subject matter experts away from the spreadsheets that many use today. In our modeling endeavors this has become somewhat of a threshold—does an alternative approach actually produce better results than ExcelTM over the long-term and in the hands of the business’ developers and users?
Publicly available enterprise architecture ontologies are also needed for bootstrapping applications and guaranteeing interoperability. And, as noted above, current languages such as OWL have not adequately addressed the needs of process modeling nor have they cleanly addressed the separation of model, meta-model, meta-meta-model, etc. in ways that allow subject matter modelers to think clearly about these levels and how they contribute to the robustness and reusability of their models.
Semantic technology would benefit from rubbing up against these issues in a more open and engaging way. Are there fundamental differences in the modeling of Occurrants and Continuants? How does one rationalize in a formal way the enterprise models of what exists and of what happens. After all, state and process are like the proverbial chicken and the egg. A process is often defined in terms of the state before, during, and after, including agents and resources consumed and produced. On the other hand, the motivation for modeling state is often the desire to determine how to efficiently transform one state into a more desirable state, e.g., convert available resources into money. From the existing and desired state we wish to derive the process.
We have come to both appreciate the capabilities of semantic technology and rue the shallowness of its penetration into the real-world problems facing today’s enterprise. Through our efforts to model enterprises and their processes, we have reluctantly concluded that significant advances in semantic technology and tools will be required to solve these problems. Until we can build a consistent, integrated model of what is and of what happens in our enterprise—at the semantic and not just the syntactic level—our models will be disjoint at best and more likely inconsistent, incoherent, and incompatible. But before we can even imagine an enterprise with model-driven everything, we must increase both the power and the usability of our modeling tools, including their semantic capabilities. Semanticists, what are we doing to solve enterprise modeling problems? Business leaders (and tool developers), include some semanticists on your modeling teams!
1. Adaptive Enterprise Architecture Manager, http://www.adaptive.com/solutions/eam.html.
2. Adaptive Work-Centered User Interface Technology (ACUITy), http://acuity.sourceforge.net/.
3. Buggy spreadsheets: Russian roulette for the corporation, http://www.theregister.co.uk/2006/05/03/buggy_spreadsheet/
4. Federal Enterprise Architecture Reference Model Ontology (FEA-RMO) http://web-services.gov/fea-rmo.html.
5. Forrester Research, http://www.forrester.com/rb/research.
6. Gartner Research, http://www.gartner.com/.
7. IDEAs Group, http://it.toolbox.com/blogs/enterprise-design/open-source-enterprise-architecture-tools-9857.
8. Jurgens Pieterse, Enterprise Design Strategy: Aligning IT & Business Practices, http://it.toolbox.com/blogs/enterprise-design/open-source-enterprise-architecture-tools-9857.
9. Lankhorst, Marc, Enterprise Architecture at Work: Modeling, Communication and Analysis. Springer, 2005.
10. Model Driven Architecture in Adaptive Library Generation, http://www.diva-portal.org/diva/getDocument?urn_nbn_se_vxu_diva-2304-2__fulltext.pdf
11. OLAP and spreadsheets—friends or foes?, http://olapreport.com/purchase/snapshot/OLAP_spreadsheets.htm
12. Ontology Definition Metamodel Specification, http://www.omg.org/docs/ptc/06-10-11.pdf.
13. OWL 2 Web Ontology Language: Structural Specification and Functional-Style Syntax, http://www.w3.org/TR/owl2-syntax/
14. Sowa, John, Knowledge Representation: Logical, Philosophical, and Computational Foundations, Brooks Cole Publishing Co., Pacific Grove, CA, 2000, pg. 73.
15. Top-Level Categories, http://www.jfsowa.com/ontology/toplevel.htm
16. TopQuadrant, http://www.topquadrant.com/enterpriseArchitecture.html
17. TOVE Ontology Project, http://www.eil.utoronto.ca/enterprise-modelling/tove/
18. VisiCalc, http://en.wikipedia.org/wiki/Visicalc
1. We have encountered one enterprise architecture tool provider, Adaptive, that utilizes MOF as the framework for its meta-model. The Adaptive meta-model is among the most open and well-structured of those we have seen, but does not leverage the strength of semantic approaches to reasoning and integration.
2. To those who claim spreadsheets aren’t real models one might retort, “There are half a billion spreadsheet users in the world . How many models have been built using your modeling approach?” Of course this argument is flawed, because at their beginning spreadsheets also had no operational base and we may be at the beginning of something better.