optimizing the benefits of edm and soa strategies through coordination

1

Contents Intended Audience ............................................................................................ 1

Overview ............................................................................................................ 3

Introduction ....................................................................................................... 2

The Case for Coordinated EDM and SOA Strategies ..................................... 4

The CIO Perspective on Data and SOA Dependencies .................................. 4

The “Perfect Storm” for EDM and SOA ........................................................... 5

EDM Framework and Component Considerations ......................................... 6

SOA Framework and Component Considerations ......................................... 8

SOA Best Practices Considerations ................................................................ 9

1. When thinking about Services, don’t forget to consider the

Data .................................................................................................................... 9

2. Focus on avoiding the proliferation of unshareable Services .................. 11

3. Reward both Reusability and Reuse ........................................................... 11

4. When establishing Governance, stay away from dictatorships ................ 12

5. Establish a Center of Excellence (COE) to provide guidance,

governance, and centralized coordination ..................................................... 13

6. Start with the right program size and in the right area of

emphasis ........................................................................................................... 14

7. Invest in systematically designed sets of fundamental core

services initially, allowing for rapid opportunistic extensions

later .................................................................................................................... 15

Conclusions / Next Steps ................................................................................. 16

Appendix A: Summary of Nuggets & Best Practices .................................... Error! Bookmark not defined.

Appendix B: Glossary ...................................................................................... 17

Appendix C: About the Author ........................................................................ 18

Headline Arial 18 Bold

Subhead Arial Narrow 16 Bold

A Knowledge-Driven Consulting® White Paper © 2008 Hitachi Consulting Corporation

Optimizing the Benefits of EDM & SOA by Coordinating Strategies (Part 1):

The Case for Coordinated EDM & SOA Strategies

2

Contents

Contents ............................................................................................ 2

Overview ............................................................................................ 3

Introduction ....................................................................................... 3

The Case for Coordinated EDM and SOA Strategies .................... 4

The CIO Perspective on Data and SOA Dependencies ...................... 4 The “Perfect Storm” for EDM and SOA ............................................... 5 EDM Framework and Component Considerations .............................. 6 SOA Framework and Component Considerations .............................. 8

SOA Best Practice Considerations ................................................. 9

1. When thinking Services, don’t forget to consider the Data ............. 9 2. Focus on avoiding the proliferation of unshareable Services ....... 11 3. Reward both Reusability and Reuse ............................................ 11 4. When establishing Governance, stay away from dictatorships .... 12 5. Establish a Center of Excellence (COE) to provide guidance, governance, and centralized coordination ........................................ 13 6. Start with the right program size, in the right area of emphasis ... 14 7. Invest in systematically designed sets of fundamental core services initially, allowing for rapid opportunistic extensions later ..... 15 Conclusion and Next Steps ............................................................ 16

Glossary........................................................................................... 18

3

Overview

This paper uncovers and discusses the little-known and often misunderstood relationships between the strategies, components, and deliverables of Enterprise Data Management (EDM) and Service-Oriented Architecture (SOA) solutions. It shows how an organization’s strategies for either EDM or SOA will ultimately fail if key aspects of both strategies are not appropriately taken into account in a coordinated fashion. Moreover, by coordinating their EDM and SOA strategies, organizations will realize additional opportunities to optimize their:

Business value of both enterprise data and services (e.g. increased efficiencies and profitability)

Economies of scale and synergies in key EDM and SOA processes, infrastructure, tools, and roles and responsibilities (e.g. increased organizational effectiveness and lowered costs)

Some of the primary coordination points of EDM and SOA strategies include:

Data and SOA Governance

Master Data Management (MDM) and SOA Services’ Initiatives

Enterprise Information Architecture (EIA), Enterprise Data Model, and the SOA Services Portfolio

Such coordination along each of these EDM and SOA organizational levels and components can further be facilitated through and should be incorporated into an organization’s overall IT Strategy, including its Initiatives Portfolio and Roadmap Management (i.e. perhaps under the guidance of an overarching Program Management Office – PMO). This paper lays out the strategic EDM and SOA coordination and integration points, as well as the synergies between most organization’s EDM and SOA strategies and their related infrastructure and processes. Then it further prescribes a facilitative framework to evaluate and mature the benefits of coordinating their EDM and SOA strategies. A follow-on white paper, “Introducing the Coordinated Service-Oriented Data Architecture (C-SODA) Framework and Capability Maturity Model” demonstrates an effective, efficient, and flexible tool for assessing and driving the coordination between an organization’s EDM and SOA strategies and initiatives. We further show how to use and adapt the C-SODA Framework and CMM for your organization’s needs, and how this can be applied in both an evaluative assessment as well as an improvement roadmap to drive organizational maturity.

Introduction

Strategies for Enterprise Data Management (EDM) and Service-Oriented Architecture (SOA) are often pursued as separate and disparate programs and initiatives within organizations, both from a business requirements as well as an IT implementation perspective. However, there are important overlapping and interdependent components, processes, and quality checkpoints of each of these strategies for which coordination becomes necessary in order to ensure the success of either strategy.

Organizations

4

Furthermore, by coordinating their EDM and SOA strategies, organizations should realize additional opportunities to optimize the:

Business value of both enterprise data and services (e.g. as increased operational efficiencies and quality, increased business services utilization and resulting profitability, as well as decreased development and maintenance costs)

Economies of scale and synergies in key EDM and SOA processes, infrastructure, tools, and roles and responsibilities (e.g. as increased organizational effectiveness and efficiency, as well as decreased infrastructure costs)

Hence, there are asset value and quality, as well as organizational efficiency, profitability, and cost optimization reasons for organizations to pursue coordination of their EDM and SOA strategies. In either case, data management and governance should be applied at a minimum for the Master Data and Metadata that is supportive of the organization’s SOA strategy or utilized by its services.

The Case for Coordinated EDM and SOA Strategies

The CIO Perspective on Data and SOA Dependencies The fact that there is a need for coordinated data and services under the guidance of coordinated EDM and SOA programs, respectively, has recently been raised to the executive office. As shown in Figure 1, it is now clearly a focus area for most Chief Information Officers (CIOs) that data-centric initiatives such as Customer Data Integration (CDI) and Master Data Management (MDM), generally under the guise of a broader EDM program, are primary drivers for their SOA projects. In fact, even traditionally non-SOA yet data-centric areas such as Business Analytics and Knowledge Management are now also significant drivers for SOA projects, according to surveyed CIOs.

Figure 1 – the CIO perspective is that data issues are key drivers of SOA Initiatives

5

Also revealed in this survey was the realization by most CIOs that SOA creates interdependencies between systems requiring high quality and consistent data, which further suggests that the full benefit of a SOA program cannot be reached without an accompanying EDM strategy and program.

The “Perfect Storm” for EDM and SOA

Many interrelated factors across industries are creating an environment ripe for organizations to develop their EDM and SOA strategies and programs in parallel timeframes and in a coordinated fashion. Figure 2 lists a few major contributing industry events that together are resulting in strategic corporate initiatives driving increasing requirements for coordinated EDM and SOA strategies and capabilities, including coordinated Data and SOA Governance.

Figure 2 – The “Perfect Storm” for EDM and SOA

From left to right in Figure 2, we can see that:

High quality data is required to enable corporate- and enterprise-level decisions

Real-time and near real-time decisions are required as competition increases and market cycle times accelerate, which includes the need for both data and real-time services

Common services are required, and need to be optimized, to decrease time-to-market pressures in many industries

“Certifiable” transactional information in (near) real-time, both data and metadata, is increasingly a compliance requirement

Businesses require efficient and effective data acquisition and integration, while reducing the time, cost, and complexity of these solutions. Meanwhile, enterprise technologies have recently matured enough to be able to deliver these capabilities, mostly as configuration and plug n’ play, quickly and inexpensively

Organizations require that their applications and end users utilize an abstraction layer rather than sources of data directly, which is enabled by a SOA approach and a Data Services layer

Increasing tendencies for packaged applications to come equipped with standard web services out-of-the-box are further placing requirements for combined data (EDM) and services (SOA) strategies, including coordinated governance

6

EDM Framework and Component Considerations Let us first take a look at an EDM framework to see which of its components have potential overlaps, dependencies, and synergies with SOA strategies and components. This will help us identify, along with a similar look at SOA components, where we should focus our strategic efforts for coordinating EDM and SOA strategies. A typical framework of the key EDM components to consider is shown in Figure 3. Hence, the major EDM components are:

Data Governance

Master Data Management (MDM)

Metadata Management

Enterprise Information Architecture (EIA)

Data Security/Privacy

Data / Process Monitoring and Controls

Data Quality/Profiling/Measurement/Metrics

Typical EDM initiatives will consist of activities that address several of these components simultaneously or at least in coordination. When considering which of these EDM components have significant impacts to a SOA strategy, as well as which are significantly impacted by a SOA strategy, some will have direct major considerations and should be emphasized as primary coordination points within a joint EDM-SOA strategy, while others will have smaller considerations and should be emphasized secondarily and selectively. Data Security/Privacy, Data/Process Monitoring and Controls, and Data Quality/Profiling/Measurement/Metrics will generally have secondary smaller linkages and impact considerations for a SOA strategy. Thus, an organization should start with their identified primary coordination points of these EDM components and their SOA strategy impacts, dependencies, and synergies in greater emphasis, then determine which selected aspects of secondary components are also pertinent for coordination within their particular EDM and SOA environment and strategic initiatives.

Figure 3 – Typical EDM Framework

7

From a high-level perspective, organizations that fail to appropriately coordinate their EDM and SOA strategies will inherently cause their enterprise data and services to evolve disparately rather than synergistically in support of each other as part of a well-managed overall enterprise architecture. Without this coordination, an organization will need to answer:

How will the Master Data and Metadata utilized within services and their resulting transactions be managed effectively?

How will SOA services be launched and maintained to utilize only the standardized Master Data, Metadata, and other data under the jurisdiction of an EDM program (rather than unmanaged copies of siloed data)?

How will an organization ensure that the process and data integration, as well as the overlapping roles/responsibilities and ownership/stewardship concerns for the data utilized or made available by services are jointly managed by and communicated between parallel Data and SOA Governance programs?

These are just some of the important issues from the EDM perspective that will go unmanaged unnecessarily when an organization’s data and services strategies, governance, architecture, and development go uncoordinated. The Enterprise Information Architecture (EIA) component of EDM is a new or refined part of the EDM organization that:

Is made up of Information and Business Process Architecture

Consists of “bridge” staff, who understand the business, but also communicate with the technical staff

Is responsible for determining the type, content, and quality of the enterprise information delivered by SOA (by working with both the Data and SOA Governance organizations and processes)

Includes enterprise information knowledge workers

Creates policies and standards for use of enterprise information

Figure 4 – The Enterprise Information Architecture component and subcomponents within the EDM Framework

8

While Figure 4 demonstrates how the EIA works with and between the organizational business processes and the SOA under the guidance of both Data and SOA Governance; it also shows how the EIA is directly leveraged by the SOA. It will, amongst other things, include the enterprise data model that SOA services will utilize in their designs. As such, the EIA will work closely with, and contain the enterprise-level aspects of, the MDM and Metadata Management EDM components. The EIA also coordinates the pertinent data integration and quality issues, best practices, and tools between the EDM and SOA strategies. Hence, from the EDM perspective, the EIA is a strong primary component, as is Data Governance, for coordination with SOA strategies.

SOA Framework and Component Considerations Looking similarly at a typical SOA Framework and its components as shown in Figure 5, it becomes clearer where there are overlaps, dependencies, and synergies between the EDM and SOA strategies and the SOA-specific components. Hence, the major EDM components are:

SOA Governance (and IT Services Management)

Workflow Management Services and Business Rules

Access and Security Services

Enterprise Business Services

Enterprise Services Bus (ESB) (and Messaging Middleware)

Enterprise Data Platform Services (and Infrastructure)

Common Infrastructure Services

Typical SOA initiatives will be comprised of activities that address several of these component areas simultaneously or at least in coordination. Also, as it turns out, when jointly considering how EDM components are impacted in a SOA environment, most of these SOA components play at least some part in a coordinated EDM-SOA strategy and program. The primary cross-impacts of the strategic SOA components and sub-components on an EDM strategy and its components are as follows:

SOA Governance Data Governance processes and checkpoints should jointly ensure that services are using the right data and metadata when available, and that any proliferation of data for or by services is controlled and managed for quality, integrity, and consistency appropriately. To some extent for service-related data and metadata aspects, Data Governance, in coordination with SOA Governance, will be involved in the management of all the other SOA components.

Workflow Management and Business Rules Metadata Management should include commonly managed automation and workflow routing rules, service-level agreements (SLAs), and business (decision) rules.

Access and Security Services MDM should include appropriate security classifications for Master Data and user entity categories, while Metadata Management should include descriptions and rules around handling and interaction of each classification for services and data access and update rules.

Enterprise Business Services MDM should ensure the availability and the controlled evolution and releases of Master Data in support of all enterprise business services, whether fine-grained data access services or composite business services. Metadata Management, similarly, should ensure that all enterprise business services are utilizing the appropriate Metadata (e.g. workflow rules, business rules, or SLAs).

9

Meanwhile, EIA, as the manifestation of the Master Data and Metadata architecture, should be directly referenced and influenced by the planned releases of enterprise business services.

ESB Metadata Management should drive the rules and configuration of the ESB for transaction/message processing.

Enterprise Data Platform Services MDM and EIA should have similar impacts as presented earlier for Enterprise Business Services, though these services will have less influence over the evolution of these (more so for reference).

Figure 5 – Typical SOA Conceptual Framework

SOA Best Practice Considerations

Another perspective from which to consider the SOA strategy impacts to and synergies with EDM is to explore how organizations would achieve a state of SOA best practices. If there are strong dependencies on and synergies between an organization’s EDM and SOA strategies, these surely will reveal themselves and must be taken into account when attempting to achieve a mature state of SOA (or EDM) best practices. The following are amongst the key best practices when pursuing a SOA strategy. Notable here is that most, if not all, of these SOA Best Practices can and should be also applied as EDM Best Practices.

1. When thinking Services, don’t forget to consider the Data The process of systematically designing a service model resembles that of designing a data model. For either, its impact should be

10

considered long-term, and the level of normalization of the designed components, whether services or data elements, is generally considered a sign of strategic quality and maturity.

Figure 6 – Service-Data Normalization Levels

As shown in Figure 6, there are four degrees of Service – Data Normalization, from immature to very mature organizations:

1) “Wild West” Where there are virtually non-existent or ad-hoc and uncoordinated (just pockets of) normalization

2) Ownership/Stewardship Where service designs build upon data designs; hence, data designs are precursors and inputs to the service designs

3) Encapsulation Where service and data designs are jointly coordinated; hence, these co-exist in initial development as well as maintenance initiatives; either may drive the other as long as they are jointly updated and coordinated

4) Object In this case, service and data designs are managed as one and the same. These normalized Service-Data designs become part of the enterprise-level EIA designs. Furthermore, the service implementations will take data ownership to another level, where master data value is known and visible only within the appropriate service implementation and its interface designs for both application developers as well as end-users.

As we will see, these Service – Data Normalization maturity levels are part of the overall capability maturity model for coordinated EDM and SOA strategies and programs. Most organizations attempting coordinated Services – Data Normalization have only progressed to the Ownership/Stewardship maturity level. However, almost every organization pursuing an EDM and/or SOA strategy needs to at least reach the Encapsulation level before major benefits in development efficiency, maintenance costs, and asset business value can be realized. On the other hand, the highest level of Service – Data Normalization, Object, may not yet make sense for many organizations, especially those for which Master Data or Business Services, for example, are still evolving and change relatively “frequently.” Depending on how stable these components are, the better the possibility for an Object level of Service – Data normalization. However, the cost-benefit balance may still make Encapsulation the preferred target level of normalization maturity for most organizations. First achieve Encapsulation, and then see if the efforts to further gaining an Object level are desirable for business value reasons.

11

Making the transition from a lack of normalization (“Wild West”) to the advanced normalization of Service – Data relationships (Encapsulation or Object) is a process of increasing the organizational maturity of both its EDM and SOA strategies, processes, best practices, and tools, in coordination. The evolution towards greater Service – Data Normalization maturity will primarily be facilitated by the coordination of:

Data and SOA Governance organizations and programs

MDM, Metadata Management, and EIA with the SOA initiatives’ enterprise services architecture and development teams

2. Focus on avoiding the proliferation of unshareable Services

A SOA strategy would have very little business value if the enterprise services it developed and deployed were not shared (i.e. reused) amongst multiple user groups and business domains within the enterprise, and in some cases amongst user groups, such as external users or partners in business-to-business (B2B) scenarios, who are outside the immediate enterprise. Without managed data coordination with SOA initiatives for Access and Security Services, Enterprise Business Services, and/or Enterprise Data Platform Services (e.g. via SOA Governance and Data Governance at the highest level), services may inadvertently propagate non-“gold standard” data copies to consumers of the services when they are created or updated by the initiatives. Thus, the services would become, OR SHOULD BE, unshareable! Even worse, in the absence of coordinated data and services, service developers may be tempted to create their own data stores (or data marts) to support their domain of services, causing further unnecessary propagation of potentially unmanaged data to new databases. This damages both your EDM and SOA strategies. Hence, to avoid the proliferation of unshareable services, coordination is required, at a minimum, for:

Data Governance with SOA Governance organizations, roles, and processes

EIA and its Enterprise Data Model, with the SOA Services Portfolio and release management

MDM and Metadata Management with SOA services’ initiatives architecture and design, including a data services layer

3. Reward both Reusability and Reuse Reusability and reuse applies to both services and data, both in their development as well as their deployment and consumption cycles. Services and data should both be developed appropriately reusable (see SOA Best Practice #2 above), and furthermore both the developers and consumers of either should be rewarded for this delivered reusability. To ensure the intended reuse of services and data is realized, organizational consumers of services should be rewarded for reusing these (rather than creating new ones). However, this is a delicate balance that should be carefully managed by the SOA and Data Governance leadership and process checkpoints in order to ensure the appropriate reuse of existing services and data when it makes most business sense. This should naturally be most of the time, unless the service or data requirements are new, or existing designs or implementations require updating or have become obsolete.

12

In some cases, however, SOA Governance should advocate the development of new or improved services if it makes good business sense. Similarly, Data Governance would almost always advocate the reuse of existing Master Data or managed Metadata, but in a decreasing number of cases over time as the managed data stabilizes, there may be business reasons to extend or change the “gold standard” data (i.e. to support a new service or new user types). Reuse and reusability should also be enforced, and best practices established, by the coordinated Data and SOA Governance programs. Governance services should include the identification of which data and/or SOA services can potentially be reused for a given initiative, and the criteria for when new data or services should be created or modified (e.g. for perhaps new or changing requirements). Hence, to properly reward reusability and reuse, coordination is required for:


EIA, MDM, and Metadata Management processes and tools with SOA services’ initiatives architecture and design processes and tools

4. When establishing Governance, stay away from dictatorships There are three major Governance approaches, from non-existent to highly centralized and dictatorial governance organizations:

1) “Wild West” Where there are virtually non-existent or simply ad-hoc and uncoordinated (pockets of) governance. Hence, there is a lack of overall enterprise coordination, but there may be minimal governance processes and roles developed out of necessity within a few enterprise domains.

2) Federated Where there are coordinated independent efforts between various domains of the enterprise. Hence, there is selected enterprise coordination, but standards, best practices, and tools are inconsistent as they remain within each business or technical domain. There may also be inconsistent coordination points with the business for requirements, etc., as this is also within the control of each domain.

3) Dictatorship Where there is centralized control of all related data or service assets. Hence, all assets are considered from an enterprise perspective, but this may not be as effective or efficient for domain-specific assets. Here, everything is coordinated, but at the cost of domain-specific flexibility.

Figure 7 – Major Governance Approaches

These different approaches should not be confused with a maturity model. The goal is not to progress to a dictatorship. Instead, while the “Wild West” approach is clearly a problem in its lack of control or coordination, a dictatorship will swing the pendulum too far the other way to the centralized control of all decisions regarding enterprise-

For highly e

13

wide as well as domain-specific assets. This is true, whether we are referring to Data or SOA Governance.

Hence, to effectively establish Governance and stay away from a dictatorship, coordination is required for:


Enterprise-level EDM assets (EIA, MDM, and Metadata Management) with enterprise-level SOA assets (Enterprise Architecture, SOA Services Model, and SOA Services Portfolio)

Enterprise-level EDM and SOA architecture and design processes and tools

5. Establish a Center of Excellence (COE) to provide guidance, governance, and centralized coordination A well-organized and managed EDM or SOA environment will generally have a Center of Excellence (COE) established in order to:

1) Involve all appropriate stakeholders (business and IT) early and as often as needed, AND

2) Facilitate all necessary coordination between interdependent projects, programs, and divisions of the organization

Hence, a mature EDM or SOA strategy will include the development and management of such a supporting COE. However, there is the possibility of an organization developing disparate EDM and SOA COEs for organizations that are pursuing both strategies, despite the overlapping roles, responsibilities, dependencies, and potential synergies of these COEs.

Figure 8 – Relationship of a COE / ICC to Data – SOA Governance

14

As shown in Figure 8, consider instead establishing an Integration Competency Center (ICC) rather than a traditional COE (or separate ones for EDM and SOA). An ICC will do more than a traditional EDM or SOA COE can do individually, in terms of providing a design, development, prototyping, and testing sandbox for the integration of both data and services. An ICC should provide all the processes, best practices, and tools for both the EDM and SOA environments, and it should facilitate all strategic services and data architecture, design, development, and testing coordination to achieve, amongst other things, the Service – Data Normalization maturity. Figure 8 demonstrates that such an ICC closely coordinates with both Data and SOA Governance, as well as the EIA, and all of these will be coordinated for overall enterprise architecture and IT Governance concerns. It further identifies some of the key components managed within each of these Governance programs for which instances will reside within the ICC as well as within production-level implementations. Hence, to properly establish a joint Service – Data COE or ICC for stakeholders and interdependent projects, coordination is required for:




Enterprise-level EDM assets (EIA, MDM, and Metadata Management) with enterprise-level SOA assets (Enterprise Architecture, SOA Services Model, and SOA Services Portfolio)

Enterprise-level EDM and SOA architecture and design processes and tools

6. Start with the right program size, in the right area of emphasis

Recognize early on that starting too big with either EDM or SOA can lead to big mistakes. Think strategically, but act tactically and locally with an emphasis on launching a realistic program that can be successful and grow. Develop a coordinated long-term vision for your EDM and SOA programs, but implement these incrementally and in support of each other. Coordinated Data and SOA Governance programs, as well as an ICC that addresses both data and services concerns (see Best Practice # 5 above), can support the initial definition, scoping, and launch of such a “right-sized” program. In some cases, you can design a set of services around selected business models and data models. The data model could be used to encapsulate the business data, and the business model can further be used to link business processes of applications with its software implementation (i.e. services). For example, business-based services typically consume data-facing services, and these are often implemented as internal components that are never directly exposed outside of the enterprise. In other cases, the data model may be the sole defining model for an application, or the data may be encapsulated within the business services. Hence, data and business models would be the best choices on which to base systematic services, user interfaces, and business process designs. In this case, the organization should defer the choice of a dedicated SOA middleware until their service topologies are established and the requirements for the type and depth of middleware can be determined properly.

If an organization does not have a COE to s

15

In order to define and launch an appropriately sized program in the right area of emphasis, coordination is required at a minimum for:


EDM and SOA COEs (or an ICC) with the EIA and its Enterprise Data Model, and the SOA Services Portfolio and release management

7. Invest in systematically designed sets of fundamental core services initially, allowing for rapid opportunistic extensions later This best practice conceptually pairs Best Practices # 5 and 6 above, and further ensures that not only is our joint Data – Services program starting with the right program size and emphasis, but that it will evolve systematically to become more strategic over time. Hence, while such a program may be launched with mostly a tactical but flexible and scalable starting point, it should systematically incorporate program scope strategically, perhaps with the guidance from and assistance of Governance organizations and an ICC. For example, key intermediary services that intercept and handle operations common across services and should be reused include: authentication, auditing, logging, monitoring, and message routing. All such services should access information from a common data services layer. In Figure 2, this will be a combination of the Enterprise Data Platform Services and the Enterprise Data and Metadata Services. A common data services layer will:

Provide an abstraction layer between the producers and consumers of data; service and data consumers are insulated from complexity, location, and changes in source data systems

Present services and data consumers, whether human, application, external parties, or business services, with a virtual aggregated view of data from multiple data sources in a consistent and centralized fashion

Centrally manage, monitor, and report on the enterprise view of the data and metadata

A SOA strategy will also cause an organization to implement an EIA and infrastructure in support of its services, which will include a common data services layer capable of supporting all producers and consumers with timely, actionable, and consistent information for near real-time, event-driven processing. Main service categories within the data services layer include:

Enterprise Data Services – Encompasses all services directly around the data (retrieve, update, etc.). Also, service enablement of traditional MDM functionality such as data quality and data harmonization across participant systems is exposed as Enterprise Data Services.

Enterprise Metadata Services – Encompasses services around the metadata (e.g. retrieve master data schema of customer, etc.). SOA designers and developers creating business services, as well as those consuming services, have to reference the organization’s master data schemas, which are exposed as Enterprise Metadata Services.

16

Enterprise Data Platform Services – Supports all services around the services and data platforms, including management, monitoring, and reporting.

Within all services and across all three data service layer areas, common infrastructure service methods for search, access, creation, update, deletion, management, monitoring, and reporting functionality should be made available. Hence, to systematically and progressively design core services within the combined SOA and EMD strategies, coordination is required for:




EDM and SOA COEs (or an ICC) with the EIA and its Enterprise Data Model, and the SOA data services layer and infrastructure services release management

Conclusion and Next Steps

This paper demonstrated a strong case for the need of coordinated EDM and SOA strategies and capabilities in organizations. It further showed what strategic EDM and SOA components require our attention in order to facilitate appropriate coordination. In a follow-on paper, Introducing the C-SODS Framework and Capability Maturity Model, we will describe the C-SODA Framework and CMM as tools to assist us in the evaluation of organizational maturity as well as in developing a prioritized, sequenced roadmap of initiatives to achieve the future vision of an organization’s desired C-SODA strategy level of maturity. In this paper, we showed that organizations need to develop/adopt an appropriate Data – SOA Governance program for their organization, because these need to be coordinated at the highest level of leadership initially to enable potential to achieve optimal value to the organization of their services and data. This is job one, as possibly the highest priority building block towards coordinated EDM – SOA capability maturity and an agile services and data enterprise. In addition to the guidance provided in this paper, there are industry standards and best practices that can further assist the definition and transition to an appropriate governance model for an organization. As an organization’s Data or SOA Governance Model is being developed/adopted, it should be closely coordinated for processes, checkpoints, and ownership with the other (SOA or Data) evolving Governance model. The reality is that we rarely develop these strategies and governance models as coordinated entities from scratch. Instead, these are probably already underway, or at least one or the other is. Hence, it is important to adopt and adapt appropriate processes and checkpoints between these initially separate governance structures, as well as to (re-)define roles and responsibilities to support of more enlightened coordinated Data – SOA Governance.

An organization can evaluate the maturity o

17

Also, if the organization has an overarching program or project management organization (PMO) that plans and funds initiatives, especially enterprise architecture (EA) initiatives that span services as well as data, this coordination should be taken into account in the form of prioritized initiatives to lay the foundational building blocks for achieving advanced strategy capabilities. Moreover, as the Governance model and processes are expanded and stabilized for additional enterprise data scope and functional areas of the organization, the related but more granular processes and checkpoints (e.g. MDM, Metadata Management, and Services – Data Stewardship) should also expand to encompass this scope with increasing maturity. Hence, the organization should develop and scale progressive joint EDM – SOA initiatives, with shared Data and SOA Governance responsibilities with coordinated processes and communications. This should be complemented with internal education to inform EDM and SOA resources and stakeholders of how to effectively leverage each other during joint data and services development. Keep in mind that many business processes and transactions may use and reuse services and data, and may demand security, accountability, integrity, and performance across heterogeneous (and often multi-enterprise) transactions span. Hence, both data and services reuse increases the dependence of one application on another, further complicating management efforts, which is another reason to evolve toward greater levels of simultaneous EDM and SOA maturity, progressively and in a coordinated fashion. Above all, ensure both business- and data-modeling analysts are involved in the design of services, in addition to the services analysts. This will help ensure services reflect business functionalities rather than the technical partitioning of software or data stores. A properly chartered COE or ICC can help facilitate bringing the diverse stakeholders together early and often to establish and drive the necessary coordination during all stages of requirements, design, development, and testing of coordinated EDM – SOA initiatives. Lastly, promote a culture of sharing and collaboration throughout the organization, as this is the underpinning of successful EDM, SOA, and more progressive C-SODA programs. The organization should make this part of their culture for many reasons, but to especially be a catalyst for the skills and communications that will enable C-SODA optimization for the organization.

18

Author Bio Keith R. Worfolk Senior Architect, Hitachi Consulting Keith Worfolk has more than 21 years of senior IT management and executive level success in strategic enterprise architecture, software development, and large-scale systems integration. Worfolk is an expert in directing business and technology organizations for the strategic planning and implementation of business-aligned IT solutions, and directing managers and staff to produce high-quality software and integrated solutions for the successful completion of strategic IT programs. He is skilled in shaping and communicating the technology vision across organizations, while ensuring alignment with executive team goals, and directing planned releases and the strategic incorporation of capabilities, emerging technologies, and best practices for competitive advantage. Worfolk is an empowerment leader with strong international and Big 5 management experience, and complementary Masters level credentials in Computer Information Systems as well as an MBA with honors from Duke University. He has managed large-scale programs and projects in lead management as well as chief architect capacities, and has led medium-sized technical architecture, development, and deployment teams. His experience includes the employment of complementary business and IT leadership skills, including the management of organizations with as many as 250 managerial and technical staff, as well as providing strong technology leadership for strategic vision, selected emerging technologies, and the technical development and deployment of complex technical solutions. His breadth of experience in industry solutions includes Public Services, Government, Public Health, Telecommunications, Software Products, High Technology, Insurance, and Financial Services.

Glossary

CMM: Capability Maturity Model

COE: Center of Excellence

C-SODA: Coordinated Service-Oriented Data Architecture

EDM: Enterprise Data Management

ICC: Integration Competency Center

MDM: Master Data Management

PMO: Program / Project Management Office

SOA: Service-Oriented Architecture

SODA: Service-Oriented Data Architecture

19

About Hitachi Consulting Corporation

As Hitachi, Ltd.'s (NYSE: HIT) global consulting company, with operations in the United States, Europe and Asia, Hitachi Consulting is a recognized leader in delivering proven business and IT strategies and solutions to Global 2000 companies across many industries. With a balanced view of strategy, people, process and technology, we work with companies to understand their unique business needs, and to develop and implement practical business strategies and technology solutions. From business strategy development through application deployment, our consultants are committed to helping clients quickly realize measurable business value and achieve sustainable ROI. Hitachi Consulting's client base includes 25 percent of the Global 100 as well as many leading mid-market companies. We offer a client-focused, collaborative approach and transfer knowledge throughout each engagement. For more information, call 1.877.664.0010 or visit www.hitachiconsulting.com.

About Hitachi

Hitachi, Ltd., (NYSE: HIT / TSE: 6501), headquartered in Tokyo, Japan, is a leading global electronics company with approximately 384,000 employees worldwide. Fiscal 2006 (ended March 31, 2007) consolidated revenues totaled 10,247 billion yen ($86.8 billion). The company offers a wide range of systems, products and services in market sectors including information systems, electronic devices, power and industrial systems, consumer products, materials and financial services. For more information on Hitachi, please visit the company's Web site at http://www.hitachi.com/.

© 2008 Hitachi Consulting Corporation. All rights reserved. "Inspiring your next success!", "Knowledge-Driven Consulting", "Dove Consulting" are all registered service marks of Hitachi Consulting Corporation. “Building the Market Responsive Company,” “Business Intelligence at the Edge of the Enterprise” and “Performance Management at the Edge of the Enterprise” are all service marks of Hitachi Consulting Corporation.

http://www.hitachiconsulting.com/

http://www.hitachi.com/