Now that we’ve established what a canonical data model is, let’s talk about our objectives for what we want to achieve with our Canonical Data Model and what toolsets can be applied. In my Canonical Data Modeling environment, I want to store and manage my entities and their relationships. I want support for the Conceptual, Logical, and Physical Data Models. I want support for normalization and/or dimensional modeling. I want to store and manage my business rules. I want to be able to generate XML and WSDLs for my SOA developers. I want to perform these acts in an Enterprise Model so I can be model driven. And I want to be able to modify my models and generate my supporting SOA artifacts as quickly as the business changes.
A few additional objectives for any Canonical Data Model environment should:
Provide an enterprise-oriented dictionary of reusable common objects and definitions at the enterprise or business domain level to enhance interoperability. We want to define a common business language and encourage its adoption by the IT community.
- Generate canonical schemas based on the enterprise semantic model to help an organization avoid having Services that might use incompatible schemas in its data representations, thus hindering service interaction and composition.
- Establish an Enterprise Data Model to store in a central location my entities, relationships, and business rules that manner to the Business
- Deploy the Enterprise Canonical Model to help us avoid services where disparate models for similar data may impose transformation requirements that increase development effort, design complexity, and runtime performance overhead.
- Provide support for various model diagrams (Use Case Diagram, Class Diagrams, Activity Diagrams, Sequence Diagrams, etc.) in helping the Architect build this integrated world.
- Allow the ability to store and manage the entities and relationships required by the Business.
- Facilitate the ability to the business rules (functions \ web service) required by the Business.
- Provide the ability to associate the business rules with the entities
Finding a toolset for this effort is not easy. IBM’s Data Architect, Computer Associate’s Erwin, and Embarcadero’s ER Studio are good toolsets for modeling relational objects (rdb). As far as I know, none of them will manage the business rules, and generate the XML & WSDLs to support a SOA environment. However, these vendors are advancing their toolset towards this mean, and I think you’ll see progress in that regard in the next few years.
There is a toolset that can be used today. It’s Sparx’s Enterprise Architect (EA). EA will allow you to store business rules as a UML class where each class can have its own functions/operations. As for Web services, Sparx EA has its own tool components specific for WSDL modeling. Given the rules are typically defined within a class, they can be associated to any other classes. You can consider the classes as your entities. Sparx EA has a Class Diagram tool component that acts like Erwin where I can define Entities (classes) and its Attributes, along with relationships. There’s a few things Sparx EA does poorly, like model comparison. To compare my logical data models, I like to use Erwin’s CompareComplete function. I’ll import & export my models between the toolsets using an XML format.
One of the nice features of Sparx EA is its support for UML (Unified Modeling Language). UML comes in 2 flavors: Structural Modeling Diagrams (like Class Diagrams) and Behavioral Modeling Diagrams (like Use Case diagrams). Collectively, I call these diagrams my artifacts. We want to store and manage them using a single toolset if possible and we want to manage the artifacts using a source code manager. In this environment I’ll have reference models. The reference models are the logical data models that I will reference in building out my enterprise semantic model. The enterprise semantic model will become the enterprise logical model. It will store the entities and relationships of interest to the business.
Given our Canonical Data Modeling environment, it will allow the Architects, Developers, and Business Users to discuss the integration solution using the Business terms and processes across the enterprise.
Powerful stuff!
