The Information Perspective of SOA Design

Posted by Boris Lublinsky on Dec 13, 2008

Sections

Enterprise Architecture

Topics

SOA ,

Architecture

Tags

Design Patterns ,

developerWorks

A majority of SOA design techniques are centered on functional decomposition of enterprise’ IT assets and often deals with the information aspects of the SOA as an afterthought. In reality, the SOA solution needs to include a broader set of design concerns, reflecting information architecture best practices in order to fully support scalable, consistent and reusable access to information. In their new article, Brian Byrne, David McCarty, Guenter Sauter, Peter Worcester and John Kling introduce a set of patterns and capabilities representing the information perspective in the design of an SOA. Their approach ensures that information is leveraged in ways that best support the technical and business objectives of the SOA solution:

 

• That services are reusable across the entire enterprise.
• That the business data exposed to consumers is accurate, complete and timely.
• That data shared across business domains and technology layers has a commonly understood structure and meaning for all parties.
• That the core data entities linking together the business domains of an enterprise are consistent and trusted across all lines of business.
• That an enterprise gains maximum business value from its data and data systems.

The article defines 3 main SOA related patterns:

 

• Define the data semantics through a business glossary

  A foundation for any successful SOA is the establishment of a common, easily accessible business glossary that defines the terms related to processes, services, and data. Often, practitioners discover inconsistencies in terminology while trying to learn the accepted business language and abbreviations within an organization. Without an agreement on the definition of key terms such as customer, channel, revenue and so on, it becomes impossible to implement services related to those terms. If stakeholders differ in their interpretation of the meaning of the parameters of a service, or indeed the data set it retrieves, it is unlikely that a service implementation can be successful. It is critical that business analysts and the technical community have a common understanding of the terminology used across all aspects of the SOA domain, including processes, services and data. The business glossary eliminates ambiguity of language around core business concepts that could otherwise lead to misunderstandings of data requirements. A business glossary eliminates misinterpretations by establishing a common vocabulary which controls the definition of terms. Each term is defined with a description and other metadata and is positioned in a taxonomy. Stewards are responsible for their assigned terms: they help to define and to support the governance of those terms.

• Define the data structure through canonical modeling

  Consistent terminology is a good starting point when designing services, but this in itself is not sufficient. You must also have a clear understanding of the way business information is structured. The input and output parameters of services, that is, the messages, are often far more complex than single data types. They represent complex definitions of entities and the relationships between them. The development time and quality of SOA projects can be greatly improved if SOA architects leverage a canonical model when designing the exposed data formats of service models. The resulting alignment of process, service/message, and data models accelerates the design, leverages normative guidance for data modeling and avoids unnecessary transformations... resulting in service definitions that meet the needs of a wide range of service consumers, thus reducing service duplication... The canonical data model establishes this common format on the data layer while the canonical message model defines this uniform format on the services layer. Industry Models provide an integrated set of process, service and data models that can be used to drive analysis and design of service architectures, ensuring a tight alignment of data definitions across modeling domains. They define best practices for modeling a particular industry domain and provide and an extensible framework so that you don't have to constantly redesign your SOA as you add more and more services.

• Analyze the data quality

  Practitioners who have considered the concepts described above can deliver service designs with a high degree of consistency across models and metadata artifacts. However, this is no guarantee that the quality of the data that is being returned by services is acceptable. Data which meets the rules and constraints of its original repository and application may not satisfy requirements on an enterprise level... Quality issues which are insignificant within the original single application may cause significant problems when exposed more broadly through an SOA on an enterprise level... The problems therefore are whether the quality of the data to be exposed meets the requirements of the SOA project and how to effectively make that determination. The proposed solution is to conduct a data quality assessment during service analysis and design. After you catalog the source systems that support a service, you can start to investigate them for data quality issues... You should verify if data duplication exists and how this can be resolved during data matching and aggregation. On the basis of these types of analysis, you can take appropriate actions to ensure that service implementation choices meet the demanded levels of data accuracy and meaning within the context of the potential service consumers.

As SOA matures, issues of the SOA information design become more important. SOA practitioners are starting to realize that usage of canonical data (compare to canonical data in EAI) is the necessary requirement for building reusable, composable services without building a spaghetti of mapping intermediaries.

1. Back to top

   Have anyone considered all the requirements buried in data

   by Practical Architect

   Aside from generic data quality, should work with the analysis team to uncover all the scenarios (read: requirements!) that buried in the transaction data. This should complement the functional de-composition work and in my opinion will ensure information perspective are not overlooked.

   Reply

• Older >