NETTING IT OUT

Service-Oriented Architecture can be applied to create software modules that integrate, synchronize, and share data in business-meaningful chunks.

Because services are independent of data sources as well as of data consumers, your company’s data can be freed from the confines of applications and the technologies in which those applications were implemented. Services can integrate data from redundant sources, repair data problems created by multiple updates, and restructure data to more closely align with your customers’, trading partners’, and company’s requirements. Service-Oriented Architecture, especially when implemented using Web Services, provides the delivery mechanism to bypass many technology-based barriers to flexible data access and management. But don’t expect services to solve the business and people issues that created many of today’s data issues.

This report examines nine common data and application problems and identifies ways in which services can be used to resolve the root causes of these problems. We also identify problems that cannot be solved with IT services alone and recommend as solutions a number of techniques that your organization probably already employs.

CONTEXT

Service-oriented architecture (SOA) can be an effective tool to use in helping to solve corporate data and application problems. The tasks at hand may involve breaking apart data that shouldn’t be lumped together, assembling fragmented data into correctly-shaped chunks that reflect the business, applying business rules, eliminating redundant application-owned data stores and eliminating situations where different code processes the same data, or simply making data accessible with minimal effort to the right people when they need it.

We’ll highlight nine specific issues in this report, but the overarching goals we’re addressing are 1) to break down application “stovepipes” that confine data and 2) to deliver business-meaningful, current, accurate, and complete view(s) of data to employees, suppliers, customers, and software that need such data and are authorized to use it.

This report examines problems that most organizations face as they try to leverage their data for previously unanticipated uses and share it with trading partners. We will describe the architectural approach that, in our experience, best leverages IT services for solving these problems.

The next report in this series will examine service architecture solutions to these data and application problems. Some solutions will involve changing existing applications, but others primarily will focus on providing complete and correct views of corporate data to new data consumers (such as portals that you may be building for your customers or integration with your suppliers). We will demonstrate that the recommended architectural approach enables you to solve a range of data and application problems with variations on a common solution approach.

The third report in the series will take a closer look at changing existing applications so that the benefits of data integration can be driven back into the applications that source your organization’s data. Such solutions involve more change to older applications than, say, integrating a view of customer or product for use on a Web portal. Such solutions, however, can upgrade older applications for the balance of the software’s service life and correct serious architectural defects that exist due to the age of operational applications or fundamental design problems.

BACKGROUND

The Data Tar Pit

Data can be difficult to define, access, manage, share and secure. Every project seems to need its own subset of the corporate whole, and the copies rarely stay in sync once applications are deployed. Packages from different vendors usually don’t share data--they may share the same logical data model, but the physical implementations are different so that data can’t be shared among them. Business rules that should govern data are spread around various applications--or, worse, are left for people to manually “enforce” when they enter or change data. Departments and business partners name and define seemingly common data concepts in different, conflicting ways. And mission-critical data often are ill-defined and undocumented.

Untangling the mess is daunting. Data modeling and enterprise data models offered hope until the extent of effort required ran afoul of budgets and human attention span. Even if all stakeholders could wait out enterprise data modeling efforts, however, business changes so quickly today that such data models are a bit like painting the Golden Gate Bridge: when the painters reach one end, they start over immediately at the other end. The process is never ending. It’s daily maintenance, not a project with a crisp start and a distinct end. That reality is discordant with one of the most persistent illusions about IT: projects are “done” on an artificially defined date. It’s an illusion because ...