WHITE PAPER DATA GOVERNANCE ENTERPRISE MODEL MANAGEMENT

WHITE PAPER DATA GOVERNANCE ENTERPRISE MODEL MANAGEMENT

CONTENTS 1. THE NEED FOR DATA GOVERNANCE... 2 2. DATA GOVERNANCE... 2 2.1. Definition... 2 2.2. Responsibilities... 3 3. ACTIVITIES... 6 4. THE IMPORTANCE OF ADEQUATE TOOLING... 8 4.1. Tailored Tools... 8 4.2. Data Lifecycle Management... 9 4.3. Model Mapping... 10 4.4. Model Driven Approach... 11 5. REFERENCE MODEL VS. IN-HOUSE DEVELOPMENT... 13 6. CONCLUSION... 14 7. ABOUT PRIMA SOLUTIONS... 15

WHITE PAPER DATA GOVERNANCE 1. THE NEED FOR DATA GOVERNANCE The increasing size of enterprise information systems and system actors via external growth of organizations through mergers or acquisitions make the communication between the different actors of the information systems increasingly complex. Each "silo" application of the enterprise architecture defines its own semantic which drastically increases maintenance costs with the need to exchange information. This is especially true when the applications are highly specialized such as a policy administration system or a claims system. Therefore, when these applications need to share and exchange information, the semantic differences become a nightmare to manage and administrate. Some of the many consequences include: A difficult challenge to integrate disparate applications or systems A duplication of functionalities with different semantics An obvious lack of agility in the enhancements/upgrades to the information system and constraints on how the systems can be enhanced This lack of semantic consistency can result in integrity issues when information is fetched from different data stores. In order to reduce these issues, it is highly recommended that organizations set up a data governance team. 2. DATA GOVERNANCE 2.1. DEFINITION The data governance gathers the activities that allow the different actors of the system to maintain constant synchronization around the enterprise data. It defines the business dictionary as well as the reference data across the enterprise. This activity publishes, manages and administrates them. Data governance can only be successful if the team in charge of this activity is composed of subject matter experts and technical experts. The subject matter experts are in charge of the semantic synchronization with business requirements whereas technical experts check the semantic used in any specification document and functional architecture. This structure should be chosen in order to avoid any differences in the data semantic across the enterprise. 2

DATA GOVERNANCE Data governance should be included in any enhancements to existing systems, new applications or projects. 2.2. RESPONSIBILITIES The data governance activity should manage: The business dictionary definition for each actor of the enterprise The definition of a conceptual business model which will serve as the foundation for any data referential, services or flows within the enterprise The strategy definition for propagating the common conceptual model to the rest of the information system layers in order to increase the functional integration agility of the IT system The definition and the configuration of tools which will help maintain the enhancements of the common semantic and conceptual models. The definition of a strategy to administrate the data including the administration of reference data The business dictionary should highlight the entities used across the organization and bring a common definition. The dictionary should be complete and fully documented so it prevents any discrepancies on what the data should represent and encapsulate. This dictionary should be communicated to every actor of the system so it preserves the integrity and the consistency of the data used. The challenges of building such a semantic dictionary in its first version are multiple and include: COPYRIGHT PRIMA SOLUTIONS JANUARY 2009 3

WHITE PAPER DATA GOVERNANCE Gathering all the requirements and use cases Creating a team of business and technical experts that can understand every business activity and have an understanding of the enterprise data architecture Recognizing the effort might spread across multiple iterations which can delay any subsequent activities by a significant time. While this process occurs, the evolution of the system will bring new requirements and therefore make this effort difficult to keep in synchronization with the current state of the information systems. Success is not guaranteed for such initiative and any failure would have disastrous effects on every IT project of the organization. The organization can avoid this hazardous phase by leveraging an existing standard of the market that has been proven amongst multiple organizations. When such a product that matches the business activity of the organization is found, this phase is reduced considerably and the productivity gains occur when applications are defined. 4

DATA GOVERNANCE A business dictionary is never static by nature. It needs constant enhancements to follow business changes. Therefore, versioning of the semantic is a critical feature so the organization can keep track of the dictionary used by specific versions of the IT infrastructure. While the business dictionary and model are very similar, the conceptual business model offers a structure around the dictionary items. Instead of maintaining two semantic sources separately, you have the ability to extract the business dictionary from the conceptual business model. What format should the Conceptual Business Model take? The requirements needed for such a model are: Defining and structuring any type of business data Technology independence Reliability on a proven modeling language The standard that could support these requirements is the UML language. COPYRIGHT PRIMA SOLUTIONS JANUARY 2009 5

WHITE PAPER DATA GOVERNANCE 3. ACTIVITIES In order to guarantee the conceptual business model is correctly used, it should be used as a reference data model for the definition of application interfaces. A modeling tool should then receive the business semantic model that would have been described in UML. The tooling should manage model versions and allow: Extraction of the business dictionary Exporting of the model to the different information layers The generation of the business dictionary will bring several benefits to the enterprise; It will enable the definition of a shared glossary which will facilitate the communication between the different actors of a project It will become the referential for the enterprise "data" dictionary by offering more flexibility to maintain it over time The next activity will consist of propagating the common terminology to the IT applications and systems. This propagation should start from the entities (or classes) manipulated at the source code level to the physical model of relational databases. This is essential to guarantee full traceability between the business & technical assets and the full integrity & consistency of the data manipulated by the infrastructure. 6

ACTIVITIES This activity will allow the management of the data flows across applications since it will keep track of the specificities for each interface. It will also manage the persistency layer for each referential by keeping the traceability between the application models and the relational models. Finally this activity can manage the definitions of the objects that will be exchanged between each application which will guarantee the consistency and uniqueness of service signatures as well as preserving the signatures used for the execution of business rules. The schema above summarizes the different phases to build an application from the Business Conceptual Model. 1) The Conceptual Business Model is enhanced using documentation of existing applications and processes. This phase is handled by Data Architects whose responsibility is to enrich and maintain the Conceptual Business Model (or Reference Model) 2) When starting the new project, the new Project Model leverages the Conceptual Business Model by extracting the concepts needed for the given project. The traceability between the two models is carefully maintained. Business Analysts and designers use Project Specifications, Screen Definitions and process descriptions to select the appropriate elements and enrich the project model when needed. The enrichments can be retrofitted in the Conceptual Business Model later on. 3) The Implementation Model, reflecting the different layers of the final application, is built by Application Architects maintaining once again the traceability with the Project Model. 4) Assets such as Java Code or XML structures are Created by technical experts leveraging the Technical Architecture and Coding Conventions. COPYRIGHT PRIMA SOLUTIONS JANUARY 2009 7

WHITE PAPER DATA GOVERNANCE 4. THE IMPORTANCE OF ADEQUATE TOOLING 4.1. TAILORED TOOLS The Business Conceptual Model covers most of the enterprise concepts. We saw that this is not a static model: it is enriched when its functional scope is enhanced and its maintenance requires corrections and additions. It becomes necessary to manage its lifecycle as explained in section. The conceptual business model, having the purpose to cover all lines of business of the organization, is far richer than the scope of each application, flow or service. Therefore, the conceptual business model needs to be tailored for each application and this has to be achieved through adequate tooling. That tool should allow designers to define their own model elements by picking those elements from the conceptual model. The names, definitions & any meta-data information belonging to an entity of the conceptual model could be copied to the project model. It is important that the tool captures the traceability with each element of the project model with the elements from the conceptual model in order to manage evolutions in a bidirectional way. The tool should also allow the propagation of the semantic to the implementation models. This is a critical aspect because the conceptual business model is not only a documentation repository but also the physical glue between layers, applications and systems. This can be achieved in several ways and not all possible solutions are effective. Incorrect Solution: Each developer creates from the application model an implementation model in the chosen technology or language. This option provides a lack of control and readability. Each developer can interpret the project model differently which can bring some consistency issues. The maintenance or any enhancements of the application might alter the semantic used and then break the compatibility with the conceptual business model and bring difficulties to bridge information over disparate systems. Correct Solution: A code generation facility is used to generate assets from the application model in the chosen target. The MDA alternative is used to deduce the application source code from the project model. In order to be efficient and bring productivity gains, this approach could be automated by a code generator. This reduces greatly the cost of ownership and insures the quality and controls of the generated assets. 8

THE IMPORTANCE OF ADEQUATE TOOLING 4.2. DATA LIFECYCLE MANAGEMENT From a software development lifecycle, the conceptual business model, the project models and the implementation models will have to be integrated in the project requisites as well as the project governance and life cycle. It is important to know that the conceptual business model has its own lifecycle and will evolve at a different speed than the applications. Even some slices of the conceptual business model could be reviewed and modified. Then the organization will have to update the flow, services and applications that are using the modified elements. That's the reason why the evolution to the common business semantic should respect the backward compatibility. The tooling that should be used to administrate the different models will have to offer a robust versioning system but also a mechanism to support distributed collaboration between the different teams that will make changes to the conceptual business model as well as the derived project and implementation models. Since every model will have its own life cycle and have multiple versions based on the state of the underlying applications, it is critical to tag every model version at a specific time. The collaboration effort between multiple actors enhancing these assets needs to be considered in order to prevent any duplication and preserve the integrity of the models; therefore, a locking mechanism should be in place so the changes are under control and well managed. The life cycle of a model could also mean the addition of new entities or attributes but also highlight some obsolete elements; the benefit of having a UML Conceptual business model as a reference point will allow the setting of "Deprecated" to any attributes or entities that are not needed anymore. This prevents the deletion of the elements so the backward compatibility and the traceability to previous versions of the model are preserved. COPYRIGHT PRIMA SOLUTIONS JANUARY 2009 9

WHITE PAPER DATA GOVERNANCE 4.3. MODEL MAPPING A mapping editor is critical to the data governance and the deployment of a common business semantic across the organization. It brings traceability between your conceptual business model with your analysis requirements, your project models and your generated assets. The traceability happens at multiple levels: entities, attributes, relationships. The mapping facility could be used through two different strategies: Transformation mode: views will be defined as flat views of the conceptual business model used in the interface layers of the middleware (with screens, rules, communication services, etc.). The views will be mapped to the classes of the conceptual model and the code generator will generate the views in the chosen language with the mappers (allowing the transformation between views and entities of the conceptual model) Pivotal model mode: organizations derive project models from the conceptual business model. The conceptual business model then serves as the referential node between the different project models, which guarantees full traceability between each project model and with each generated asset. 10

THE IMPORTANCE OF ADEQUATE TOOLING 4.4. MODEL DRIVEN APPROACH The Model driven approach brings multiple benefits: More productive development: by defining templates of generation with your code generation facility, you can generate more than 60% of the code needed by your application. Higher quality of code: the generated code will follow coding guidelines set by the generation templates which maintain code consistency; it will also enforce best practices Business and technical agility: on the one hand, the conceptual business model can be extended incrementally which provides greater flexibility to capture new business requirements ; on the other hand, the generation rules can be changed at any time so it fits any technology change COPYRIGHT PRIMA SOLUTIONS JANUARY 2009 11

WHITE PAPER DATA GOVERNANCE 12

REFERENCE MODEL VS. IN-HOUSE DEVELOPMENT 5. REFERENCE MODEL VS. IN-HOUSE DEVELOPMENT The in-house development of a conceptual business model could be successful on a very limited scope where the organization could easily grasp every detail. However, the deployment of a full scale enterprise semantic seems a gigantic task because of the disparate systems already in place in the organization. Furthermore, the investment and the time to conceive such an artifact are considerable. On top of building this model, the data governance should be studied in detail. Indeed, a newly created conceptual business model with no data governance in place and no adequate modeling tooling makes the model unusable and therefore reduces its benefits to documentation. Tools will not be tailored to the conceptual business model that has been developed which means some additional time will be required to customize the tool so the model can be leveraged from an IT perspective. By purchasing a conceptual business model off the market that comes with the associated tooling, the IT organization will save a great deal of time from the start by using the reference model to jumpstart their enterprise conceptual business model. The tooling will be tailored in such a way that it will provide productivity gains out of the box. COPYRIGHT PRIMA SOLUTIONS JANUARY 2009 13

WHITE PAPER DATA GOVERNANCE 6. CONCLUSION Every company, whatever their size, infrastructure and lines of business they are handling is facing challenges (and even more issues) in maintaining and extending their data infrastructure. This is logically related to business growth which effectively leads to the exponential growth of data without any control or governance. With the deployment of online applications and the needs for executive and business users to get fast and reliable information, it becomes impossible for the IT organization to perform without a proper strategy. In order to reduce costs and increase agility to the data infrastructure, companies need to adopt a data governance strategy with the adequate tools. The purchase of an existing conceptual business model from the market decreases significantly the risks of this strategy. The companies that follow this strategy are able to realize a savings of 60/70% in cost and time for enhancements and maintenance to their data infrastructure within their organization. The initial investment into such a model is leveraged easily to produce real returns, which decreases their TCO (Total-Cost-of-Ownership) throughout the lifetime of their data stores and applications. 14

ABOUT PRIMA SOLUTIONS 7. ABOUT PRIMA SOLUTIONS Prima Solutions provides a standard-based software framework to support incremental transformation of existing Insurance IT systems into component-based Service Oriented Applications. Built around an extensive Insurance Reference Model (Prima IBCSTM), a template-based code generation toolset and an innovative business service repository, Prima RepositoryTM, the Prima software framework complements existing infrastructure to enable a pragmatic and efficient approach to SOA transformation. Dedicated to the insurance industry, Prima Solutions' technology promotes Reusability and renewed Business and Technical Agility. Founded in 2000 Prima Solutions operates globally from offices in Paris, Chicago and Tokyo. Customers include Safeco, Generali, CNP Assurances, KILN, Burns and Wilcox, Max Capital, Beazley, La Réunion Aérienne, Eurolife, RLI Insurance Corp, Farm Bureau, Swiss Life, Groupama, HCL, Wipro, Patni. Projects implemented by these customers involve General, Health, Life and Pension Insurance products for core distribution, underwriting, policy administration and claims processing. IBM owns 33% of Prima Solutions. Prima Solutions is a member of ACORD and OMG. About the Authors The authors of this white paper are Data or Technical Architects at Prima Solutions : Philippe Boutet, Alexandre Solomides. Thanks to Ibelise Paiva for the visual quality of the finish product. For more information about Prima Solutions, visit www.prima-solutions.com http://www.prima-solutions.com or contact contact@prima-solutions.com contact@primasolutions.com. 2008 Prima Solutions. All rights reserved. The information contained in this document represents the current point of view of Prima Solutions on the exposed subjects at the date of the publication. Any extract or partial broadcasting is forbidden without the authorization of Prima Solutions. The names of products or companies in this document can be the registered trademarks of their respective owners. COPYRIGHT PRIMA SOLUTIONS JANUARY 2009 15