Every enterprise engages in projects to connect people, processes, information, and systems. These projects happen hundreds if not thousands of times a year. Considering the more connected and collaborative world in which we live today, these connections are essential for partnerships, decision making, collaboration, and improved efficiency. They enable business transformation, new opportunities, and cost reductions. In this Advisor, we discuss the conceptual reference model, which provides the foundation needed for any “connection” architecture, capability, or project. A conceptual reference model defines the terms and concepts used by the enterprise and the communities in which the enterprise operates. It is referenced by other strategic, operational, and architectural assets as a way to federate and pivot between different processes, communities, schemas, and systems without coupling them together.
The terms and concepts in conceptual reference models make sense to business stakeholders. They represent the “stuff of the business,” not the stuff of IT. The conceptual reference model approach takes enterprise vocabularies and enterprise data models to a new level that enables federation and integration capabilities to be partially automated and validated. These models help define the terms used in enterprise architectures, value chains, and other elements of business architecture. Conceptual reference models can also be used to help facilitate solutions by leveraging technologies such as ontologies, model-driven development, data transformation, analytics, and information sharing.
A conceptual reference model is not an overly simplified or abstracted data model. It is not a data warehouse. It is not a model of data at all; it is a model of the actual stuff of the business. For example, a conceptual model about loans refers to actual loans — the obligations between real businesses and people, not a “schema” describing loans. Does this mean we don’t care about data? Of course not! It means we understand that data about loans can be represented and encoded in many different ways for many different purposes. Understanding the business concept provides a reference point for these many different terms, data structures, applications, and technologies. Concepts define what our data structures mean; that is, their semantics.
Making It Relevant
Well-defined concepts are essential for people and machines to extract the correct information from data to understand a message or record. We are well aware that the same terms can mean different things in differing contexts or that the same concept can be communicated using different terms from different communities using various human languages. Our goal is to capture the concepts behind the terms. Ask a group of business stakeholders what they mean by “product” or “customer.” It is not uncommon to find that they are not talking about the same thing or even the same concept. Data based on these terms alone may not be correctly interpreted and translated into accurate and useful information. Models help put terms into context to provide for effective communications and analytics.
Consider an analogy: the role of interpreters at the United Nations. They must first understand the concepts being communicated and then translate them for individuals speaking different languages without coloring the information with their own perspectives. These experts utilize an internal resource that maps terms and concepts. When we want to formalize or automate such a resource, we create a conceptual reference model.
The anti-pattern of expecting a data model to integrate other data models ignores the fact that data models are tuned and optimized for a particular problem and technology. Data models must, by necessity, commit to a particular context, structure, and set of labels that may not work well for other purposes. Similarly, ontologies intended for a particular inferencing technology (e.g., OWL-DL) and application must make compromises and commitments specific to that technology and purpose. Well-defined business-centric concepts captured in a model provide the basis for mapping between, integrating, federating, and sharing information (e.g., about loans or customers) among different systems and communities, even when their vocabulary or “schema” seem unrelated.
Validation and Automation
Besides relevance to business stakeholders and strategy, the other feature we look for in a conceptual reference model is that it can be validated and emergent capabilities partially automated. This requires expressing the conceptual reference model in a structured language so that automation can leverage the model. Conceptual models don’t directly provide operational capabilities, but they can be mapped to technologies that do, such as ETL, analytics engines, data schema, inference engines, integration platforms, or publish/subscribe infrastructures. These mappings take into account the rules and best practices that apply to the target technologies for a specific enterprise and the degree to which automation makes sense for the enterprise.
Part of the art of conceptual modeling is navigating the balance between what is intuitive for business stakeholders and what is sufficiently precise to enable automation and automated validation. Languages such as UML or OWL are frequently used for conceptual modeling but must be applied in a way that enables this balance. While these languages can help formalize a model, it is the intent that the model directly captures business concepts that differentiates it from other uses of these languages.
One example of a conceptual reference model initiative is the Financial Industry Business Ontology (FIBO) managed by the EDM Council and standardized by the OMG. FIBO utilizes both UML and OWL to define terms and concepts relevant to finance. A similar effort is underway to define threat and risk-related concepts. FIBO and similar community models can be used as a basis for enterprise efforts, saving vast amounts of time and money while enabling interoperability with other organizations. The availability of carefully considered and well-defined concepts provides a lot of leverage to enterprise initiatives.
By leveraging standard and community models and defining enterprise models, projects that seemed unrelated can start to leverage common architectural assets to accelerate design and development while reducing risk. Without a reference model, developers must figure out what some element in a system means and how it relates to something else that may seem similar. This can take time, cost money, and introduce errors. When developers do this for hundreds or thousands of connections, the resulting web of systems and connections becomes complex, fragile, and anti-agile. Some organizations are paying dearly to build this fragile web, connection by connection, and in doing so are building one that is very difficult to escape. Conceptual reference models help provide a business-focused architecture to enable the interconnected network of people, organizations, and systems by mapping information, services, and processes based on reference concepts.
Taking the Long View
One challenge for architectural assets like a conceptual reference model is that individual projects may determine that it is outside their responsibility to define or follow that model. Project managers may think that they can get their job done faster or cheaper without worrying about anything outside the system they are building. This may or may not be true for an individual project, but it is certainly not the case for the suite of projects facing the enterprise. Enterprise goals are served by an enterprise perspective as part of every project, leveraging and contributing to the conceptual reference models that help people and systems work together. These models are best managed by business-focused, cross-organizational teams that can promote the enterprise perspective while enabling each project to proceed effectively. A conceptual reference model is not a “one-shot deal,” but rather an evolving agile asset that can return value quickly while enabling strategic goals.
As a brief example, consider concepts relative to a prospect (see Figure 1). A prospect may be defined as the role of a person or organization that has been qualified by sales as having a likelihood of becoming a current customer by way of the recent purchase of a product or service. Consider how many of these concepts are interrelated and become part of the definitions of other concepts. These interrelationships, combined with relevant textual definitions of each, serve to fully define terms and concepts. By identifying the things of interest in the enterprise, including the relationships between them, we create a model of these concepts that is usable across the enterprise. These terms and concepts can be referenced as part of an enterprise architecture for improving sales processes, including value chains for identifying prospects and turning prospects into current customers. These same concepts can be referenced by applications that analyze big data streams, perhaps finding prospects in social networking feeds. These feeds can be related to the schema of customer relationship management (CRM) systems that help turn prospects into customers and further used to unify information from invoicing systems to track actual purchases.
Systems defined based on reference concepts may also utilize semantic technologies and implement information-sharing gateways. These fielded capabilities may use cloud computing, analytics, ETL-based data integration, semantic mediation, and other technologies. Integration and interoperability infrastructures such as enterprise service buses or messaging systems can leverage reference concepts to integrate data and systems.
An enterprise approach can only succeed where there are common enterprise concepts. The notion of “reference” is important in that it emphasizes the separation of concerns between a reference model and a technology-focused schema or application. The technology artifacts reference business concepts but may represent these concepts in different ways using technology and application-specific structures and terminology. Note that the above example is just a simplified summary of a conceptual model and its mappings.
[For more from the author on this topic, see “Connecting Inside and Outside the Enterprise.”]
