• How will the master data and metadata used in services/transactions be managed?
• How will SOA services be developed/maintained to use only standardized master data, metadata, and "gold standard" data?
• How will processes and data integration, as well as overlapping roles/responsibilities and ownership/stewardship concerns for data utilized or made available by services, be managed between parallel data and SOA governance programs?

These are important issues from the EDM perspective that may go unmanaged when organizational data and service strategies, governance, architecture, and development go uncoordinated.

The Enterprise Information Architecture (EIA) component, a primary coordination point, is relatively recent to EDM organizations. It:

• Comprises information, business processes, and architectures
• Includes information knowledge worker "bridge" staff who understand the business, and communicates with technical staff
• Determines type, content, and quality of enterprise information delivered by SOA (via data/SOA governance)
• Creates policies/standards for enterprise information usage

Figure 4 shows how EIA works with organizational business processes and the SOA, under the guidance of data/SOA governance. It is directly leveraged by the SOA and includes the enterprise data model that service designs will leverage. Hence, the EIA works with and contains the enterprise-level aspects of MDM and metadata management. It coordinates pertinent data integration and quality issues, best practices, and tools between EDM and SOA strategies as a primary EDM component for coordination with SOA strategies.

SOA Framework and Component Considerations
Looking similarly at a SOA framework, it becomes clearer where dependencies and synergies between EDM and SOA strategies exist.

SOA initiatives generally address several of the components shown in Figure 5, simultaneously or at least in coordination. Considering how EDM components are impacted in a SOA environment, most SOA components play some role in coordinated EDM-SOA strategies/programs.

Key cross-impacts of EDM and SOA components in a SOA environment are:

• SOA Governance: Data governance ensures that services use the right data/metadata, and any proliferation of data for or by services is managed for quality/consistency. For service-related data/metadata, coordinated data-SOA governance is needed.
• Workflow Management and Business Rules: Metadata management includes common automation and workflow routing rules, business rules, and SLAs.
• Access and Security Services: MDM includes security classifications for master data and user entities, while metadata management includes descriptions and rules for handling service/data classifications.
• Enterprise Business Services: MDM ensures the availability and evolution of master data supporting fine-grained data and composite business services. Metadata management ensures services use appropriate workflows, business rules, SLAs, etc. Meanwhile, EIA (e.g., data architecture) is referenced by service releases.
• ESB: Metadata management drives configuration rules of the ESB for transaction/message processing.
• Enterprise Data Platform Services: MDM and EIA are referenced.

SOA Best Practice Considerations
Another way to consider SOA strategy impacts on and synergies with EDM is in addressing how organizations achieve SOA best practices. Significant dependencies between an organization's EDM and SOA strategies will surely reveal themselves and must be taken into account when pursuing SOA best practices.

The following are among the key best practices for SOA strategies, and most/all can also be applied as EDM best practices.

1. When thinking about services, don't forget to consider the data
Systematically designing a service model is like designing a data model. For either, its impact should be considered long term, and the level of normalization of designed components, services, or data is considered a sign of quality and maturity.

Figure 6 shows service-data normalization from immature to mature organizations:

• "Wild West": Non-existent or ad hoc and uncoordinated normalization
• Ownership/Stewardship: Service designs built on data designs
• Encapsulation: Service and data designs coordinated in development/maintenance initiatives; either may drive the other as long as they are coordinated
• Object: One and the same service/data designs. Normalized designs are within EIA designs; service implementations take data ownership to another level where master data value is known only in service designs/implementations.

Most organizations pursuing services-data normalization have progressed to ownership/stewardship levels, yet need to reach encapsulation before realizing major benefits in efficiencies, maintenance costs, and asset business value.

The highest level of service-data normalization, object, may not make sense for some organizations, especially where master data or business services change frequently. Depending on their stability, the more possible an object level may be. However, cost/benefit analysis may make encapsulation preferred for some organizations.

Transitioning to advanced service-data normalization is a process of increasing organizational maturity toward coordinated EDM-SOA strategies.

This is facilitated through coordinated:

• Data and SOA governance organizations and programs
• MDM, metadata management, and EIA with SOA initiatives' enterprise services architecture/development

2. Focus on avoiding the proliferation of services that can't be shared
SOA strategies have little business value if their enterprise services aren't shared (i.e., reused) among multiple user groups and business domains in the enterprise and sometimes outside the immediate enterprise.

Not coordinating data with SOA initiatives (e.g., via governance), services may inadvertently propagate non-"gold standard" data to service consumers when developed by the initiatives. Such services become, or should be, unable to be shared.

Worse, the absence of coordinated data and services may tempt developers to create their own data stores/marts to support their services' domain, causing unnecessary propagation of potentially unmanaged databases. This will damage both your EDM and SOA strategies.

Avoiding services that can't be shared is facilitated by coordinated:

• Data and SOA governance organizations and processes
• EIA and enterprise data model, with SOA services portfolio and releases
• MDM and metadata management with SOA services' initiatives architecture/design

3. Reward both reusability and reuse
Reusability and reuse applies to services and data in development, deployment, and consumption cycles. Services and data should be normalized for reuse (see SOA Best Practice #2), and developers and consumers of either should be rewarded.

This is a delicate balance that should be managed by data-SOA governance and processes to ensure appropriate reuse when it makes business sense (i.e., unless service/data requirements are new or existing designs/implementations are obsolete).

SOA governance will sometimes advocate development of new or improved services when it makes sense. Similarly, data governance will almost always advocate reuse of existing master data or managed metadata, but decreasingly over time as managed data stabilizes, there may be reasons to extend or change "gold standard" data.

Reuse and reusability should also be enforced, and best practices established, by coordinated data and SOA governance programs. Governance should include the identification of which data and services can potentially be reused for a given initiative, and the criteria for when new data/services should be created or modified.

Rewarding reusability/reuse is facilitated by coordinated:

• Data and SOA governance organizations and processes
• EIA, MDM, and metadata management processes/tools with SOA services' initiatives architecture and design processes/tools