Global canonical database enterprise architecture offers the ability to layer a common component to the enterprise design that allows these heterogeneous systems to coexist and interface with a common language. (Canonicality depends on context, but is defined as the usual or standard state or manner of something.) Such an architecture supports a strong management desire to combine all related aspects of enterprise data-centric operations.
Service-Oriented Architecture (SOA) is supposed to address the disconnection that forms between new applications and legacy applications. The disconnection occurs when, over the years, as technology advances, new systems are built using new techniques, and interfaces are built, but are typically custom interfaces, slow or delayed processes, or are crudely constructed in such a way they’re dependent on manual activities. Having custom interfaces that may or may not use differing technologies means more human resources and less flexibility. Keeping the organization flexible means being able to quickly adapt to change while keeping costs low. SOA can alleviate these problems, but it can be difficult to keep operational costs reasonable. Moreover, SOA often underutilizes and improperly manages DB2. However, a proper balance in mapping, caching, and efficient SQL design can help overcome most performance issues.
Enterprise Database Design
From a physical implementation perspective, implementing a global canonical database enterprise architecture means using a set of common interfaces and a common set of tools to let disparate systems quickly communicate. Typically, a common enterprise architecture group is responsible for creating and maintaining these common objects. The result is a core set of people working with a common set of programming tools to bring it all together. The tools typically consist of:
• A common service architecture layer connecting all services that supply data and processes
• Messaging services, usually event-based, that handle the communication across services
• A common message format that’s used across the enterprise to carry information across services
• A set of maps that let the disparate systems and data stores convert data from the local format to the common format carried in the messages.
There’s never an absolute right or wrong way to do things—only tradeoffs in the costs and benefits of a specific implementation or strategy. There’s always a price to pay. In the case of canonical database architecture, you must be aware of the implementation challenges. It’s often more difficult and costly than it initially seems. Poor implementation of any architecture also can result in performance problems that are near to impossible to resolve.