Five Phases to Support the Data-Centric SOA

Data-Centric SOA

Information Management Magazine, August 1, 2008

Adel Harris, Ramesh Ramakrishnan

We’ve all heard that the successes of enterprise initiatives are only as good as their data foundation - and the transition to a service-oriented architecture (SOA) is no exception. As organizations look for strategies to manage data as an enterprise asset, an evolutionary, data-centric SOA transition allows them to move one step closer to that goal.

Delivering on the promise of true, enterprise-wide SOA - an environment in which discoverable, accessible, interoperable and trusted services are business applications aligned with business goals - is a huge undertaking that can last for years. But with a proven SOA transition plan that focuses first on data, organizations can achieve sustainable results with quick wins, while at the same time, proceeding down the path of an architected approach that will deliver fully on the SOA promise.

The formula for SOA success is not a one-size-fits-all approach, and it’s not merely a technical system-centric solution for application consolidation. An SOA transition needs practical strategies that begin with creating the core of minimal architecture requirements with data as the foundation.

A data-centric SOA transition allows organizations to better leverage new and existing IT investments to support business requirements, transition legacy systems incrementally and deliver reusable, interoperable, secure and trusted business services. This article outlines the five iterative phases of a data-centric SOA transition that have become a best practice for several organizations.

SOA enables new and existing enterprise systems to share services and information across technical platforms, departments and ultimately across organizational boundaries. To achieve the benefits of SOA, organizations must transition from a siloed system-centric view to an enterprise data-centric view of IT. This transition requires that enterprises break down the barriers between business and technical organizations that have prevented sharing information and IT solutions in the past.

SOA Formula: Focusing on Data

A data-centric SOA transition builds an SOA strategy around authoritative data sources. By focusing on the data that is at the core of legacy infrastructure, a data-centric strategy preserves your IT investment and provides better access to legacy systems by integrating existing systems and tapping into authoritative data sources. Extending the existing application by adding new functionality allows for an agile implementation that is responsive to your business objectives. Migrating your business functions/processes to the new platform preserves business functionality and reduces support costs by moving to an enterprise technology solution.

Designed to mitigate challenges enterprises face when implementing SOA, a data-centric methodology combines legacy modernization efforts, metadata management and data quality best practices to help organizations infuse an authoritative data sources approach into their programs. This approach is based on the premise that services must align with business and information requirements, and they must be discoverable, accessible, interoperable and trusted in order to deliver on the promise of SOA.

A data-centric approach consists of five iterative phases to support the evolutionary transition to an SOA environment that are held together by a robust, governance process. This five-phased approach mitigates the risks of implementing an SOA and provides a roadmap to design, acquire, orchestrate and govern services that fit the needs of your business modernization and integration efforts.

These phases include: architect and plan, decouple data, model, assemble, and deploy and manage.

Phase 1: Architect and Plan.

Services, new or acquired, need to be aligned to an organization’s target business architecture so that enterprises can facilitate information sharing by breaking down the barriers between business and technical organizations. Establishing an architecture that provides the framework for business and information requirements as well as integrates processes and data from literally hundreds of systems must be done to effectively implement SOA.

The architect and plan phase focuses on architectural alignment, gap analysis and transition planning. Architectural alignment identifies how the scope of the SOA efforts fit into the target architecture and categorizes current systems and data stores into that framework to identify opportunities for reuse and consolidation. The architectural alignment is also used for gap analysis, identifying high-level requirements to build or acquire services and planning the transition from the current to the target SOA environment.

During this phase, the organization creates a transition roadmap that will provide an enterprise view of business objectives and insight into where data is being entered and used again and again.

Phase 2: Decouple Data.

The next phase focuses on decoupling data from systems to provide the basis for an information warehouse and support an incremental transition. This step depends on the requirements of your transition and your enterprise environment. In environments where multiple disparate systems are not interdependent, it makes sense to skip the decouple phase and move on to the model step.

However, decoupling data is important in cases where many enterprise systems rely on the same set of data. Decoupling the data breaks this point-to-point contact and makes your enterprise systems more data dependent. Data becomes a shared enterprise resource that is stored at a centralized place and is not dependent on any on system. This provides the basis for creating authoritative data sources and gradually evolving to SOA. This involves:

• Classifying data into existing high-level information classes,
• Identifying systems/functions affected based on business drivers,
• Publishing decoupled data with information services of affected systems/functions and
• Implementing business rules to decouple the systems.

By focusing first on the data definitions and relationships, you can ensure that subsequently designed services originate from authoritative sources and that data exchanged is present in a centralized and integrated data store, which makes subsequent data modeling easier.

Phase 3: Model.

The model phase focuses on adding more depth to the target architecture and creating the core requirements for the service. This entails evaluating current legacy assets in terms of how they are supporting business utility, then categorizing investments, defining duplication, formulating criteria for selecting best of breed and, ultimately, laying the foundation for a true enterprise-wide framework.