Constructing an enterprise model

There is a two-track approach to constructing an enterprise data model. First, reverse engineer existing applications to understand their content and seed the enterprise model. Then, review the draft enterprise model with business staff.

Begin an enterprise data model by infusing application content, which may include multiple applications of various sizes. Application databases are much too complex to reconcile in their entirety; therefore, it is not feasible to include all of their content. Rather, it is adequate to find the major concepts of each application, reconcile those major concepts and put that content in the enterprise model.

For enterprise modeling, reverse engineer by rifling through the application databases and noting major tables. The ideas embodied by the major tables are the initial concepts. Table names can be cryptic, so use judgment in interpreting them. Also, exercise judgment in deciding how names correspond for the various applications. The net results are seed concepts for the enterprise data model.

The second step is to review the reverse-engineered model with business staff – to refine the concepts, improve names and definitions and add relationships. Business review also ensures that the model can satisfy future needs that current software does not address. The intent of the model is to avoid bias towards any individual application, and instead serve as a guide for enterprise-wide integration. It is important to choose reviewers with deep business knowledge and involve different business constituencies.

Avelo’s top-level enterprise data model

Figure 1 shows the top level of Avelo’s enterprise data model, using the UML class model notation. The model shows core entity types and relationships. The enterprise model provides basic capabilities for new applications to include and existing applications to evolve towards. By intent, the enterprise model omits capabilities that are unique to single applications.

The boxes denote entity types. The lines in the diagram denote relationships. The annotation on the end of the lines denotes multiplicity (how many items of one entity type relate to an item of the associated entity type). Thus a Party has many Ledgers and a Ledger pertains to exactly one Party. There are recursive self-relationships on Party, Activity and Holding. Here are definitions for the entity types.

Figure 1 – Avelo’s top-level enterprise data model

• Activity. Behavior that can be performed. This includes historical activity as well as scheduled activity yet to occur.

• Document. A physical or electronic representation of a body of information.

• Financial Scenario. A strategy for managing a Party’s financial objectives. Refers both to past actual occurrences and future hypothetical occurrences.

• Holding. Something of value. An asset has a positive value and a liability has a negative value.

• Ledger. A label for recording, reporting and managing a quantity of something.

• Party. Someone or something that is notable in terms of data or relationships.

• Product. The packaging of an item for the marketplace. This includes Avelo products, as well as other products.

Integration architecture

An enterprise data model is a substantial step forward for integration, but it is not sufficient in isolation. An organization must also address architectural issues.

• Fluid application boundaries. Product managers are like entrepreneurs. They seek to best position their individual product to meet future opportunities, and to boost revenues and profits. The problem with this situation is that these individual product-by-product decisions do not lead to an optimal situation for the entire organization. The actions of individual product managers must be coordinated so they fit within the broad product portfolio strategy. Also, it is difficult to integrate applications when their scope and boundaries are continually changing.

• Customer variation. It is also difficult to deal with disparity in customer size and sophistication. At one end are individuals who are tentative with computing. At the other extreme are large organizations with sophisticated IT staff and technology infrastructures. The products developed must be scalable for a range of customers.

• Conforming to customer IT systems. The integration challenge for a vendor is greater than the integration of its own applications. There is also a need to mesh with customer IT systems and to provide basic services, including customer, account, application, security and identification services.

• Customer centric vs. account centric. Customer-centric applications look at the totality of customer business, such as the various ways that a customer can do business with a bank. The entire breadth of customer activity is used in assessing a customer. Other applications are account centric. A customer can have multiple accounts; an account pertains to one customer. Accounts are the top-level entity for collecting information, and there is little effort to look across accounts for the same customer. The enterprise model is neither customer centric nor account centric. Rather, it describes the essential data content.

• Software engineering. A software development organization should have solid software engineering practices. For example, it is important to perform modeling and think deeply before writing code. Agile development as also important.

Many vendors have offshore development that must be coordinated with onshore efforts. Application data models should be provided as specifications to which offshore developers must conform. Furthermore, onshore staff should carefully inspect and test offshore code during acceptance.

Avelos’s integration platform

Figure 2 shows the integration platform that supports Avelo’s business goals and overall strategy. It consists of the following elements, looking from the inside out.

• Avelo .NET. The Microsoft .NET framework and associated toolkits lie at the core of the integration platform. Avelo has adopted .NET for all its applications for consistency in infrastructure, software, development skills and training. Avelo has elaborated .NET with a series of detailed patterns and practices that cover the mechanics of usage. The combination of .NET and Avelo’s enhancements form Avelo.NET.

• Enterprise and integration framework. The E&I framework holds core platform components – the enterprise data model and libraries of standard integrations to third-party systems and services.