Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Taking Service-Orientation to the Next Level in Tough ...

239 Aufrufe

Veröffentlicht am

  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Taking Service-Orientation to the Next Level in Tough ...

  1. 1. DATA SERVICES Taking Service-Orientation to the Next Level in Tough Economic Times Deliver the promise of agility, reuse, and business alignment BY BRAD WRIGHT A s more and more IT organizations find themselves multiple don’t wish to create confusion with the ongoing technology debate years into their journey toward service orientation, the about Web-oriented architecture or SOA 2.0. reverberations of an economic downturn are shining As organizations shine light on SOA Iteration 1, a number of chal- bright lights on SOA. The business is re-asking old questions: lenges are becoming apparent. First, as efforts expand beyond initial What is the benefit? What are the early results? And the familiar projects and teams, the need for process governance, metrics, and question: Are we better off now than four years ago? The service- incentives to overcome the “not invented here” syndrome to service oriented promise of increased agility, reuse, and improved align- reuse are apparent. Second, the shallow application of service- ment between IT and business continue to have appeal, but tough orientation to the top or business visible portion of the software questions deserve answers if we are to “make the case” in new architecture has left the problem of fragmented, redundant, and economic realities. low-quality data unresolved. And finally, the larger trend toward off- While there is much debate in the blogosphere about finding SOA premise software or Software as a Service (SaaS) has complicated success stories to make the case, this is perhaps self-defeating. Isn’t service construction. trying to find a SOA success story something like trying to find an ar- With these challenges in mind, some organizations are begin- chitecture success story? How can you declare success on something ning SOA Iteration 2 with a focus on design-time process and so pervasive without a macro perspective? Perhaps the more rel- asset governance, a new emphasis on the identification and use of evant question is what have we learned in our initial attempts and service-oriented design patterns throughout the IT architecture, how can we do better? Increasingly, organizations asking themselves and deployment of Master Data Management (MDM) technology to this question come to the conclusion that their initial SOA efforts address critical customer or product-focused data quality problems. did not extend to the critical world of data – that the benefits have This article explores the last two of these refinements and proposes been less than anticipated because data is still siloed, fragmented, that both require taking service-orientation to the data. and inconsistent. In this article, I explore this challenge further and As discussed earlier, many organizations choose to focus on craft- propose that applying service-oriented patterns, approaches, and, ing a set of business services as the primary form of adopting ser- yes, technology to the data world can significantly enhance the vice-orientation. They choose to decouple critical, coarse-grained service-oriented journey. business functionality from inside application silos and expose Before taking a look at the problem, it’s useful to understand them as services. This approach makes sense but is something akin where we are on our collective SOA journey. After significant debate to adopting green design principles (see http://www.nrdc.org/ over the years, most everyone has come to agree that SOA represents buildinggreen) for the second story of your house and not the first a strategy, process, and set of principles to guide IT choices. That is, and then wondering why your energy bill is still high. Long-term that SOA is not simply a technology problem. Further, that ser- service-oriented success depends on applying appropriate SOA vice-orientation is not something that can be “dropped into” IT or design patterns beyond just the business service layer. Long-term done in a Big Bang fashion. Service-orientation is best approached success depends on taking it to the data, so to speak, by applying by identifying key projects (and problems) to apply its guiding the data service design pattern. This pattern calls for decoupling principles to and expand from there. As a result, most organizations common, finer-grained data access and integration logic from the have embarked on their SOA journey by identifying key IT-support- underlying data sources and exposing them as reusable services that ed business processes to service-enable and craft a set of business produce logical, consumer-friendly data objects. In this way, there services from which the business processes can be constructed. This is a true separation of concerns between your business services and is a sound approach but begs the question: Is it sufficient to focus the underlying data sources. One can change independent of the only on the top of the IT software architecture? other. Further, due to a tendency to think of IT as a set of technologies, Applying the data service pattern is facilitated by a relatively many organizations have looked at SOA through a technology-first new, vendor-independent standard known as Service Data Objects prism. This has led to many organizations thinking of SOA as any (SDO). This standard provides a consistent way of representing and project that uses an Enterprise Service Bus (ESB) or Web services. handling data in disconnected architectures such as SOA and has This is perhaps harmless but limiting. In a technology-first ap- been crafted by a collection of vendors known as the Open SOA Col- proach is it not possible that success will be limited by a tendency laboration. The key role of SDO is to act as the mechanism through to apply service-oriented principles to only those portions of the which a data service supplies or hands-off data to your business ser- problem for which technology was acquired? vices and receives changes back. SDO standardize this service-ori- With this in mind, think of these initial SOA efforts as SOA Itera- ented interaction in the same way that JDBC and ODBC standard- tion 1. I use the word iteration as opposed to version to reinforce the ized how client/server applications interacted with databases. (See notion that service-orientation is a journey that involves multiple http://www.osoa.org/display/Main/Service+Data+Objects+Home attempts with (hopefully) improvement in each attempt. Also, I for details of the standard.) 1 November 2008 www.SOA.sys-con.com
  2. 2. A word of caution, though. As you study and embrace the data on all your consumers. And easy-to-use services are much more services pattern to enhance your SOA journey, be warned that the likely to be reused. term “data services” has begun to appear in vendor and analyst As we’ve now seen, taking service-orientation to the data by literature to describe something other than a design pattern. When applying the data service design pattern can yield significant making your decisions about technologies, be sure you understand benefits and enhance your SOA efforts. How do you construct how the term “data service” is being used by the vendor under these data services and what are the performance implications? evaluation. Do you have to create these data services by hand? Certainly that Another aspect of “SOA Iteration 2” is the deployment of Master is an option but doing so is costly, repetitive and error-prone. The Data Management technology to rationalize redundant customer good news is that mature technology choices are available now or product data into a “golden” master data hub containing a that significantly reduce the effort to construct scalable, high-per- cleansed, rationalized record for each customer or product. This formance data services. These technologies leave data where it technology offers real value for a critical problem, but MDM comes naturally resides and in a variety of declarative, metadata-oriented with unique challenges and a striking irony – the irony of the hub if ways construct operational data services to access and integrate you will. The irony is that in trying to improve your organization’s data from multiple sources and technologies on behalf of multiple key data, you end up creating another data silo – a copy of your key classes of consumers – Web services, Java, C++, and .NET. While data that exists outside of the originating systems of record. How is there is no commonly accepted name like enterprise service bus that copy (the hub) kept current? How is the cleansed data folded for this class of technologies, perhaps the name “enterprise infor- back into your operational systems? These are critical integration mation switch” or “data service platform” are appropriate. questions IT organizations face when adopting MDM. As mentioned earlier, use caution when searching for a data In a striking synergy between two aspects of SOA Iteration 2, the service platform or enterprise information switch to be a part solution to this irony is to apply the data service design pattern of your SOA infrastructure as many vendors are adopting the to construct a quality perimeter – a virtual wall of data services term “data services” to describe products that have nothing to that surround your master data hub and key operational systems do with the data service design pattern. Specifically, look for solu- whose sole purpose is to ensure that only good data gets out and tions that: bad data doesn’t get in. In the same way that your network firewall • Integrate data in-place and on-demand without the need to cre- separates and protects your internal network from the chaos of the ate a new data silo or mart (remember copies of data have hidden Internet, a quality perimeter protects your operational systems and costs) MDM hub. (It’s important to note that in this approach the term • Support multiple classes of data sources to access and integrate: data service refers to a collection of service implementations of relational, service-oriented, mainframe, packaged applications the data service pattern.) These quality perimeter data services • Support multiple APIs for diverse consumers: Service Data Ob- are responsible for accessing and integrating data from a combina- jects (SDO), JDBC, ODBC, ADO.NET, WSDL/SOAP, REST tion of your MDM hub and operational systems so that a consum- • Support multiple standard query languages: SQL, JPQL, LINQ ing service is presented with a logical, high-quality data payload • Provide visual tools to define logical models, mapping to sources, – the proverbial single source of truth. Just as important, the data and data service testing services in the quality perimeter are responsible for ensuring that • Include advanced optimization and mediation strategies to en- changes to critical customer or product data are only made in such sure high performance and maximum service reuse a way that data quality is not compromised. Doing so might require • Support multi-source transactional update and use of optimistic enforcement of a number of integrity checks, but also might require concurrency policies invoking some of the data quality capabilities of an underlying • Provide flexible, role-based security to restrict access to data MDM technology to cleanse or standardize the new data on the • Support memory-based caching of accessed and integrated data fly. Further, the perimeter data services would ensure that changes • Include management tools and integration with runtime gover- are applied to both the MDM hub and operational systems in a nance solutions consistent, coordinated manner. The chief benefit of constructing a quality perimeter of data services around your critical systems Even as we enter a new period of tough economic realities, is that IT has a gate or valve through which to enforce and govern service-orientation continues to hold great promise for both IT data quality and a mechanism to ensure long-term return on costly and the business. Yes, you may be asked to justify again the MDM efforts. promise and benefits. Do so armed with the lessons of your first What if your organization has exploited another significant trend iteration attempts but also with the knowledge that iteration too in IT cost containment and moved to an off-premise CRM system? must push beyond the business visible top layer of your architec- Perhaps your organization’s CRM system is in the cloud or deliv- ture and on to the data. Do so armed with the knowledge that the ered by a SaaS provider. In such a scenario, how do you integrate data service design pattern and concept of a quality perimeter are your customer data with your MDM hub and ensure that data stays the best approaches to both solving the problem of data quality consistent and clear? Again, the answer is by applying the data and integrating the trend toward off-premise software into your service design pattern to construct a quality perimeter. The el- organization’s SOA strategy. Do so knowing that the technology of egance of the quality perimeter is that whether systems are on-or- an enterprise information switch or data services platform can off premise doesn’t matter. Each can be placed within the pe- help you rapidly realize the data service design pattern. With these rimeter and accessed only through the designated data services. new strategies and technologies, confidently press on to deliver Further, the use of the data service pattern to architecturally en- the promise of agility, reuse, and business alignment! capsulate and hide your off-premise systems isolates dependencies on the external system in the (likely) future event that the system About the Author or technology changes. Finally, due to the complex and low-level Brad Wright is a senior product marketing manager for DataDirect Technologies, a compre- nature of most off-premise solutions’ APIs, the use of consumer- hensive provider of software for connecting disparate crucial business applications to data friendly data services to hide that complexity reduces the burden and services. bradley.wright@datadirect.com www.SOA.sys-con.com Reprinted from SOAWorld Magazine. Copyright ©2008 SYS-CON Publications, Inc. All Rights Reserved. November 2008 2