Purpose
Occasionally, companies purchase what is generally referred to as an industry-standard or conceptual model of data and process for their industry from a vendor. For example, IBM and Teradata have developed models of industries such as insurance, financial services, and discrete manufacturing These can serve as the foundation for constructing an enterprise model for the organization, and can assist in refining those models that have already been constructed, if appropriate, by adding the integration of requirements across applications or subject areas. This integration is essential if an organization is to realize the benefits of increased productivity and reduced systems development and maintenance costs.
Technology independent, enterprise models provide a stable, cohesive view of the corporate information resource for both data and process. An interdisciplinary team that understands the enterprise’s requirements for data and the processes that act upon that data should develop the model. Building an enterprise model can be done concurrently with application development, as long as the application efforts are tailored to reflect the decisions made by the enterprise modeling team as they evolve. Of course, the enterprise modeling team should be in control of all data modeling activities, so that the enterprise model reflects the organization’s data accurately and completely.
In many cases, the development of enterprise models solidifies the business’ views of its essential functions, and the data needed to perform those functions. This effort should result in a single, enterprise agreement of the information and functions that a company needs to be a cohesive, competitive force in their market.
Scope
Conceptual overview for appropriate business and IS associates (data and process)
Decision on the logical divisions of enterprise subject areas (for a property and casualty insurance company: Account/Customer, Policy, Claims, Financial and Reinsurance, Legal, HR, Actuarial, IS, Operations) These subject areas would be the focus for a set of activities that are commonly called Business Area Analysis. Many companies find that there are 8-10 logical subject areas, which can be prioritized into 4 or 5 core areas (e.g., Account/Customer, Policy, Claims, Financial and Reinsurance, Operations) and 3 corporate areas (Legal, HR, and IS). One of the first decisions for the project team would be the order of priority for completing the Business Area Analysis for each subject area.
Business Area Analysis (BAA) for a chosen area (repeated for all subject areas) which includes the creation of data and process model for the chosen subject area, using the conceptual model as a foundation and reference guide. Areas that have been modeled should be revisited to determine if any new requirements have been discovered, or if decisions made by the enterprise modeling team affect the representation of the data and processes outlined in the BAA.
Integration of current application models into an enterprise view (e.g., combining the different treatments of Customer into a single accepted view)
Coordination of simultaneously proceeding application development modeling with enterprise efforts (strategic view versus tactical view)
The level of detail in an enterprise data model usually includes: Subject Areas, Entities, Relationships, and key Attributes. It does not include all attributes, subtype entities, and domain values for coded attributes. Development of an Enterprise Model of data and processes usually does not require the same amount of time to develop as a set of fully attributed application models.
Crafting an enterprise model requires the dedication of empowered representatives from all business units, along with a modeling specialist and a meeting facilitator to accurately capture and represent the data and relationships for all subject areas. Starting with the subject area deemed to be the most critical or the central area, each subject area is analyzed and modeled. Such an effort should require approximately 6 weeks elapsed time for the first subject area, with resources dedicated for the entire time. This time is required for the initial subject area to create a cohesive team and to teach and practice the modeling and analytical techniques the team will use for the entire project.
To coordinate the efforts of the various application or maintenance teams, effective communication methods and a solid understanding of the synergy of enterprise and application modeling is essential. Active managerial support, at all levels, of the modeling activities will help ensure that this communication will flourish. It is also imperative that the core team members remain constant for the life of the enterprise model project, to achieve continuity and consistency in business requirement knowledge and modeling techniques.
The enterprise model provides the framework for the development and maintenance efforts of the IS/business partnership. A key principle of an Information Strategic Plan is that IS adheres to an overall set of strategies in building business applications. An Enterprise Model enables an organization to manage its data and processes efficiently and effectively, thereby fulfilling this key principle.
Process
Enterprise modeling does not require the detailed development necessary in the application models. Requiring the same level of detail was a flaw in the approach prevalent in the 1980’s that gave modeling a poor reputation it currently holds in some management and development circles. The enterprise model works best when it serves as a framework for the IS development and maintenance process (methodology), and prevents the construction of stovepipe applications and islands of redundant data. Data and process modeling is a fundamental function for projects of all types, accelerating the project’s ultimate delivery. The Data Management group should be a catalyst and reference point, informing a team about other efforts and how those groups solved a problem. They should serve as the source of reusable objects (entities, attributes, definitions, abbreviations, etc.) and should enable development and maintenance to proceed faster, secure in the knowledge that their efforts will be integrated into the rest of the enterprise. Data Management, in its role as the administrator of the corporate metadata repository, can provide corporately defined objects for reuse and the guidance to ensure their effective use.
During the data and process modeling activity, any available models that pertain to the subject area should be reviewed and revised to reflect the enterprise view. Since many existing applications were developed in isolation, each application model may treat a given area differently. Integration will eliminate the conflicting views and create a single, uniform view of the entities, attributes, relationships and definitions for the subject area. This consolidation will enable reuse of these entities, attributes, relationships and definitions across applications and within the business community.
One of the strongest recommendations is that any changes identified during this integration process be implemented into existing applications to preserve the consistency of the enterprise view of information (data and process). If these modeling integration activities are not incorporated into the existing applications, the modeling efforts will have been solely an intellectual exercise.
Questions arise during every enterprise modeling effort concerning the balance of strategic (enterprise) modeling versus tactical (application) modeling. These efforts can occur simultaneously as long as the tactical modeling team communicates regularly with the strategic modeling team. The tactical team must be expected to incorporate objects developed by the enterprise team so that reusability is achieved and maintained. The strategic team must recognize the needs of the application modeling team for robust, flexible objects that can accommodate multiple applications. This amalgamation is common in model-driven development and is successful in organizations that recognize the need for both types of models.
The level of discovery needed for a task will determine the activities and durations associated with each task and the composition of the team assigned to fulfill it. In general, a BAA and basic model development for a particular subject area should be completed in 4 to 6 weeks, with dedicated staff. However, the first BAA will require the longest duration, since it will include the formation of a team, the education into any industry standard model that is used as foundation, enterprise data modeling concepts and techniques, and the initial efforts at information discovery for the team and its subject area experts. It should be noted that most of the activities will require the services of an experienced facilitator and an experienced modeler, and reserving their availability must be accounted for in the development of the activity schedule.
In conclusion, the development of enterprise models is an activity that requires commitment from Senior Management (to approve the project and to require adherence to the modeling purpose and results), from business management and staff (to provide knowledgeable, dedicated and empowered resources for the duration of the project), and from IS management and staff (to provide knowledgeable, dedicated and empowered staff for the duration of the project, and to adhere to the modeling principles and results in systems development and maintenance). If all parties agree that enterprise models would provide sufficient benefit to an organization, this project will be successful and produce a cohesive enterprise model.