 |
Level: Intermediate
Kyle
Brown ([email protected]),
Distinguished Engineer, IBM
Rachel
Reinitz ([email protected]),
Distinguished Engineer, IBM
28 Jan 2009
 In this article, two experienced SOA architects
look at the new world of Web 2.0 technologies with a critical eye and
present five best practices that can help you be more successful in
adopting Ajax, REST, and other Web 2.0 technologies as part of your SOA.
>From IBM
WebSphere Developer Technical Journal.
Here
we go again
We've heard it all before: A new
technology comes along and then suddenly everything we've ever done
with any older technologies is obsolete and will go away. At first
glance, the new Web 2.0 technologies appear to follow this pattern.
Hardcore proponents of these technologies will tell you that you need
to throw out all of your SOAP services; not only will building with
SOAP and WSDL make your project take longer, they won’t convey any
benefits. The truth, of course, is not so simple.
While REST makes it easier to build some
types of services -- particularly those that face outwards to the
Internet or to Ajax clients -- there are still lots of services that
will benefit from applying SOAP, WSDL, and the WS-* specifications.
And, depending on the type of SOAP services you have, you might be able
to embrace Web 2.0 by transforming your services into REST services;
this is particularly true for data-oriented services. This argument
aside, however, even if you do decide to adopt REST for your services,
you would be wise to look at some of the lessons we have learned from
building enterprise SOA systems and examine how they apply when
building RESTful services. Lucky for you, there are several major areas
in which we've learned some very painful lessons. We share these with
you here to spare you similar distress, and to help you get a jump on
Web 2.0 success.
1.
Enable new business models
A
top priority of CEOs (and, therefore, CIOs) is to innovate and reach
new markets. A key selling point of SOA has been increasing the
flexibility of business processes, through services as building blocks,
thereby enabling new business models and innovation. SOA delivers the
most value to a business when combined with business process management
(BPM). A frequent objective of BPM is to enable reaching new markets or
regions, and to accelerate the introduction of new products or
offerings. Likewise, Web 2.0 enables you to reach out to, communicate
with, and collaborate with your customers and business partners in ways
not previously possible.
Web
2.0 concepts can be used to drive new business models in several ways.
Businesses can build communities, empower users as producers of key
data, build ecosystems around users, find new ways of communicating to
users, and enable the “mashing up” of information into new forms or
views. Companies like eBay, Amazon.com, Flickr, and Twitter are
examples of businesses whose core values and business models comes from
user-generated data. This is, of course, a simplification, but if you
view Web 2.0 only as cool technology focused on rich UIs, Atom feeds,
and RESTful services, you can miss how Web 2.0 can be used to enable
fundamental business change.
2.
Reach out to the business
A
major success factor for SOA has been that it is a message that has
succeeded simultaneously on two levels; it reaches the business, and it
also resonates with IT. To reach the higher level value of Web 2.0
discussed above, the business must understand both the transformational
role that Web 2.0 can play and the investments that are required to
make it happen. Typically, IT needs to get the business to support
adoption of new technologies through tying technology to business
value. The connection between BPM and SOA has accentuated the alignment
of business and IT. It is often easiest to first explain the benefits
of BPM, and then explain how BPM is best implemented on an SOA base.
This then enables you to demonstrate how one complements the other.
Part
of the reason for this success has been IBM's ability to line up the
way in which we convey the benefits of SOA, couched in terms that are
understandable by both the business and IT. Here, we've been aided by
some common scenarios (such as the IBM SOA Foundation scenarios
described in a series of Redbooks on the Patterns for e-business) with
which we can demonstrate value that business people understand.
The key lesson to take away from this is
that you need to be as concrete as possible on business value, and --
even better -- provide projected return on investment (ROI) for
adoption of Web 2.0. Let's face it: the business community doesn't
necessarily get jazzed by new technology the same way that developers
do. Therefore, you need to be able to reach out to the business
community on their terms (as you probably do already for developers) in
order for Web 2.0 to take off. One example starting scenario is to use
Web 2.0 to build a community for your business or products, and drive
value, such as improved customer service and brand loyalty. We all need
to become more mature in articulating these values (more and more books
are being written, which help; see Resources),
and we all need to be able to explain Web 2.0 without ever mentioning
the detailed technologies that are used. This is something we have done
successfully with SOA, and it's just as important for us to be able to
convey the business benefits of Web 2.0 without getting into the nitty
gritty.
3.
Drive adoption from a firm methodological basis
Another
key success factor for SOA has been the practices, procedures, and
rules that form the basis of IBM SOA methodologies, Service Oriented
Modeling and Architecture (SOMA and RUP-SOMA), and its tight link to
business modeling techniques. IBM Business Consulting has developed
Component Business Modeling (CBM) and uses it as the key input to SOMA.
CBM and other business modeling methods engage business users and help
them understand the alignment of business and IT. SOMA emphasizes the
alignment to the business all the way through detailed service
specification and realization. SOMA and RUP-SOMA didn't spring
fully-formed from the brow of the IBM Rational® Unified Process (RUP)
when Web services first came into use; it took several years to develop
and refine, and continues to be evaluated and revised.
In order for it to succeed, Web 2.0 will
also need a firm
methodological basis that will be an evolution of existing SOA and
object-oriented design methods. For example, there need to be ways to
identify the communities that are the targets of Web 2.0 applications,
and also ways to identify their communication styles. As mentioned
earlier, there also need to be ways of defining the business value that
result from leveraging these communities to help you evaluate services.
Likewise, there should be modifications or extensions to the SOMA
services identification mechanisms and services litmus tests to
identify the difference between services that are appropriate for
application integration and those appropriate for supporting rich
Internet applications.
To give you an example of how you must
think differently about RESTful services, consider the different
perspectives that a RESTful service can have when compared to an
enterprise SOA service. First of all, exposing an internal service
might not be the best way to reach the masses; an external service
might need to represent a unique viewpoint of your enterprise. Imagine
that you're extending your enterprise SOA onto the Web for a worldwide
shipping company. In this situation, there are two different foci for
how you build your services. Let's say you start from business process
modeling as a part of applying the SOMA method in identifying your
services. If you model the processes of an enterprise like this, then
it's likely that the focus of your modeling (the internal focus) is
about optimizing your resources to maximize profitability. In other
words, when you model like this, you might ask:
- How full are your planes and trucks?
- How do you minimize fuel costs?
- What's the cheapest way to get X
packages from point A to point B?
But when you look at the enterprise from
the viewpoint of someone using your Web site (or someone wanting to use
a RESTful service published from your Web site in a mashup), the
modeling exercise must have a different focus. In other words, with an
external customer focus, the questions you would ask instead might be:
- Where is my package and when will it
arrive?
- How much will it cost for me to ship
my package from here to Toledo?
Presuming that you initially did your
modeling from the first perspective, and then came along and wanted to
add RESTful services from the second perspective, you need to realize
that you have more modeling and design to do. But that's one of the
beauties of methods like SOMA and RUP-SOMA: they are iterative, and can
accommodate changes like this if you recognize the need, rather than
making the exercise more like trying to fit a round peg into a square
hole.
4.
Have vision, establish a roadmap, and execute projects
Figure
1 shows one of the most useful diagrams we have used for communicating
what is needed to adopt SOA. It’s a graphical representation of the
need for an SOA vision across business and IT. You assess where you are
today, establish a roadmap to get you from where you are to the vision,
and implement projects that incrementally execute the roadmap. This
approach applies equally well to Web 2.0 adoption as it does to SOA
adoption.
Figure 1. SOA vision
It is critical to 1) have a vision and to
2) execute projects. If
you focus only on the vision and roadmap for Web 2.0 (which includes
implementing infrastructure and framework projects) in the absence of
”real” projects (which go into production and deliver business value),
then you run a high risk of achieving an infrastructure and procedure
that do not meet project needs, making it even harder to get project
teams to adhere to the roadmap/architecture/frameworks. If you start
running individual Web 2.0 projects without a vision and roadmap, and
without a common infrastructure, you risk delivering less value,
re-learning lessons already learned, not reusing code across projects,
and not building common infrastructure and procedures (such as
security). Early projects do not need to be large to deliver value, but
they always offer the opportunity to gain experience with the new
technology and business models.
5.
Do not overlook governance
Something
we discovered relatively late in the process of helping customers adopt
SOA is the strong need for SOA governance. IT governance is sometimes a
touchy issue; it's something that is more often preached than
practiced. SOA governance is the process of extending IT governance to
deal with the specific semantic and business elements provided by an
SOA, and it's key to building an SOA in such a way that it can be
grown, maintained, and extended. Also, SOA governance should extend
beyond IT governance to include business leaders.
What we have seen is that the management
and control of both the SOA infrastructure and the services development
and deployment process has become extremely important as architectures
built using SOA principles grow and mature. Tools like IBM Rational
Asset Manager, IBM WebSphere® Service Registry and Repository, and IBM
Tivoli® Policy Manager for SOA Security exist to help put a robust
governance process in place.
What
we have seen from early applications built using Web 2.0 principles is
that governance for Web 2.0 will be even more challenging, given that
key aspects of Web 2.0 adoption is free communication and collaboration
in a community and the sharing of information. As we expose RESTful and
Atom services, the question becomes: how do we control but not limit
the use of those services and the development of assets by users? If
the sociological aspects of building a community are limited by a
too-restrictive governance process, then the community will not thrive.
However, too often we've seen online communities poisoned by
insufficient or improper governance; it's too easy to get buried in
"junk" and not be able to highlight the valuable content that exists.
An
analogy you can use is that governance for Web 2.0 might be like
managing a park. Like a good park ranger, you want to encourage
diversity within the limits of what you have control of, but not let
things go beyond the set bounds. In any case, planning for governance
and making sure that your RESTful services are controlled through some
governance process is important to ensuring that your RESTful services
have a long and profitable life.
Bring
it all together
These
aren’t all of the lessons to be learned from enterprise SOA
development, but they do show the importance of planning ahead,
focusing on business value, and having a wide view of your overall SOA
as you build RESTful services. Stepping back and thinking through these
issues should help you make your Web 2.0 projects more successful and
more easily connected with the other aspects of your enterprise.
|
