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
2
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
O disparate programs and initiatives within organizations, both from a
r business requirements as well as an IT implementation perspective.
However, there are important overlapping and interdependent
g components, processes, and quality checkpoints of each of these
a strategies for which coordination becomes necessary in order to
n ensure the success of either strategy.
i
z
a
t
i 3
o
n
s
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
4
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
5
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
6
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
7
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).
8
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
9
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.
10
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.
11
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:
Data Governance with SOA Governance organizations, roles,
and processes
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
F These different approaches should not be confused with a maturity
o model. The goal is not to progress to a dictatorship. Instead, while
r 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-
h
i
g
h 12
l
y
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:
Data Governance with SOA Governance organizations, roles,
and processes
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
13
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
I COE or ICC for stakeholders and interdependent projects,
f coordination is required for:
Data Governance with SOA Governance organizations, roles,
a and processes
n EIA and its Enterprise Data Model, with the SOA Services
Portfolio and release management
EIA, MDM, and Metadata Management processes and tools with
o SOA services’ initiatives architecture and design processes
r and tools
g Enterprise-level EDM assets (EIA, MDM, and Metadata
a Management) with enterprise-level SOA assets (Enterprise
n Architecture, SOA Services Model, and SOA Services Portfolio)
Enterprise-level EDM and SOA architecture and design
i processes and tools
z
a 6. Start with the right program size, in the right area of emphasis
t Recognize early on that starting too big with either EDM or SOA can
i lead to big mistakes. Think strategically, but act tactically and locally
with an emphasis on launching a realistic program that can be
o successful and grow. Develop a coordinated long-term vision for your
n EDM and SOA programs, but implement these incrementally and in
support of each other. Coordinated Data and SOA Governance
d programs, as well as an ICC that addresses both data and services
concerns (see Best Practice # 5 above), can support the initial
o definition, scoping, and launch of such a “right-sized” program.
e
s In some cases, you can design a set of services around selected
business models and data models. The data model could be used to
n encapsulate the business data, and the business model can further
be used to link business processes of applications with its software
o implementation (i.e. services). For example, business-based services
t typically consume data-facing services, and these are often
implemented as internal components that are never directly exposed
h outside of the enterprise.
a In other cases, the data model may be the sole defining model for an
v application, or the data may be encapsulated within the business
e services. Hence, data and business models would be the best
choices on which to base systematic services, user interfaces, and
a 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
C depth of middleware can be determined properly.
O
E
14
t
o
15. In order to define and launch an appropriately sized program in the
right area of emphasis, coordination is required at a minimum for:
Data Governance with SOA Governance organizations, roles,
and processes
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.
15
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:
Data Governance with SOA Governance organizations, roles,
and processes
EIA and its Enterprise Data Model, with the SOA Services
Portfolio and release management
EIA, MDM, and Metadata Management processes and tools
A with SOA services’ initiatives architecture and design processes
n and tools
EDM and SOA COEs (or an ICC) with the EIA and its Enterprise
o Data Model, and the SOA data services layer and infrastructure
services release management
r
g
Conclusion and Next Steps
a
n This paper demonstrated a strong case for the need of coordinated
EDM and SOA strategies and capabilities in organizations. It further
i
showed what strategic EDM and SOA components require our
z attention in order to facilitate appropriate coordination.
a
t In a follow-on paper, Introducing the C-SODS Framework and
i Capability Maturity Model, we will describe the C-SODA Framework
and CMM as tools to assist us in the evaluation of organizational
o maturity as well as in developing a prioritized, sequenced roadmap of
n initiatives to achieve the future vision of an organization’s desired
C-SODA strategy level of maturity.
c
In this paper, we showed that organizations need to develop/adopt an
a
appropriate Data – SOA Governance program for their organization,
n because these need to be coordinated at the highest level of
leadership initially to enable potential to achieve optimal value to the
e organization of their services and data. This is job one, as possibly
v the highest priority building block towards coordinated EDM – SOA
capability maturity and an agile services and data enterprise. In
a addition to the guidance provided in this paper, there are industry
l standards and best practices that can further assist the definition and
u transition to an appropriate governance model for an organization.
a
As an organization’s Data or SOA Governance Model is being
t
developed/adopted, it should be closely coordinated for processes,
e checkpoints, and ownership with the other (SOA or Data) evolving
Governance model. The reality is that we rarely develop these
t strategies and governance models as coordinated entities from
h scratch. Instead, these are probably already underway, or at least
one or the other is. Hence, it is important to adopt and adapt
e appropriate processes and checkpoints between these initially
separate governance structures, as well as to (re-)define roles and
m responsibilities to support of more enlightened coordinated Data –
a SOA Governance.
t
u
r
i
t 16
y
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.
17
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
18
