SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere Nutzervereinbarung und die Datenschutzrichtlinie.
SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere unsere Datenschutzrichtlinie und die Nutzervereinbarung.
Taking Service-Orientation to the Next Level in Tough ...
Taking Service-Orientation to the
Next Level in Tough Economic Times
Deliver the promise of agility, reuse, and business alignment
BY BRAD WRIGHT
s more and more IT organizations ﬁnd 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 beneﬁt? 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 ﬁnally, the larger trend toward off-
While there is much debate in the blogosphere about ﬁnding 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 ﬁnd a SOA success story something like trying to ﬁnd 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 identiﬁcation 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 beneﬁts have This article explores the last two of these reﬁnements 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 signiﬁcantly 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 signiﬁcant 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 ﬁrst
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, ﬁner-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 sufﬁcient 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-ﬁrst 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-ﬁrst 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