Comment lines: Kyle Brown and Rachel Reinitz: SOA lessons learned for Web 2.0

Five ways to keep you on track for success

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. This content is part of the IBM WebSphere Developer Technical Journal.

Kyle Brown, Distinguished Engineer, EMC

Kyle Brown's photoKyle Brown is a Distinguished Engineer with IBM Software Services for WebSphere specializing in SOA and Emerging Technologies. Kyle provides consulting services, education, and mentoring on SOA, object-oriented topics and J2EE technologies to Fortune 500 clients. He is a co-author of Java Programming with IBM WebSphere and Persistence in the Enterprise. He is also a frequent conference speaker on the topics of SOA, Enterprise Java, OO design, and design patterns.



Rachel Reinitz (rreinitz@us.ibm.com), Distinguished Engineer, EMC

Rachel ReinitzRachel Reinitz is an IBM Distinguished Engineer with IBM Software Services for WebSphere and a member of the IBM Academy of Technology. She has built much of IBM’s internal and external intellectual capital and education on SOA, Enterprise Service Bus, and Web services. Rachel focuses on how to get started with SOA and ESB best practices. She consults with clients and ISVs on how SOA and ESB can be used to achieve their business and technical objectives. She is a frequent conference presenter and written many developerWorks articles on ESB and Web services. Rachel lives in the Bay Area in California, and enjoys hiking, socializing, and international travel.



28 January 2009

Also available in Chinese Japanese

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
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.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and web services, Web development
ArticleID=366854
ArticleTitle=Comment lines: Kyle Brown and Rachel Reinitz: SOA lessons learned for Web 2.0
publish-date=01282009