Introduction

The media is publishing research results saying organizations are postponing their SOA projects due to fear that costs will be higher than the benefits. This article explores an alternative approach where organizations can get the most important benefits of SOA with a little less investment, and in a shorter time.

There has been a lot of debate about whether agile and SOA go well together or not. Some say that SOA demands a wider, documentation-oriented approach. Others say that with the agile approach, a team could deliver the key functions with less money and less time. There’s no reason why the agile approach couldn’t be used to deliver the benefits that organizations are looking for with SOA.

Since real business needs and benefits are always the highest priority, this article first reviews the benefits that organizations are seeking from SOA. Then we'll discuss how an agile approach could be used.

Back to top

Overview: Benefits of SOA

SOA is typically described as an architecture in which functions are grouped around business processes, and the functions can be accessed through interfaces. There are several benefits that businesses are typically seeking with SOA, as follows.

Applications are not isolated

The interfaces make it both easy and affordable to integrate the organization’s existing applications. This reduces manual work phases, thus saving time and money.

Easier integration of the applications

The functions are offered by, and easily accessible with, the interfaces.

Hidden implementation-related details

The interfaces hide implementation details, technologies, and platforms, making integration a lot easier.

The location of applications is also more transparent. One application can be a C++ application run on Linux, while another might be a custom built REP running on LAMP.

Continued life span of existing applications

By continuing the life span of existing applications, businesses can save money. Typically, the most important reasons for replacing existing applications are: rising maintenance costs, difficulties with integration, or limited functionality. By creating interfaces, you can ease the integration problems and open new avenues for the limited functions.

Reuse existing interfaces

This benefit will only materialize after the organization has built a few interfaces and applications. If the interfaces have been properly designed, their functions can be reused while building new interfaces, integrations, or applications.

Respond quickly to business needs

With the help of the interfaces, and the reuse of existing functions, you can respond faster to business needs. Some of the more interesting business needs are to:

• Bring existing data or functions together to use them in other applications. The data could be aggregated from two or more applications, or it could simply be atomic data (customer’s address) that is shown to the customer in the self-care Web application.
• Use other applications to update data in existing applications. For example, the self-care application would also likely let the user update the current address.
• Let partners update data.

Obviously some of the benefits are only possible after making a large investment. However, you can achieve some benefits with smaller investments, and in a shorter time frame.

The common theme in the business needs described above is that the company wants to offer functions to new or existing users by way of a new interface, such as a Web or mobile portal. Typically, the users are new, or they've been doing a process in a different way. One of the key drivers in such cases is the need to bring down costs (which are the costs of running the current process).

In the current economic situation, some companies are thinking about postponing their SOA projects due to high costs. If they continue to use the old processes, they won't realize the savings and business benefits that new solutions would bring.

The next section explores how the agile approach would make it possible for a business to start enjoying the benefits of SOA.

Back to top

Agile approach to SOA benefits

Some folks say that agile teams are overly concerned with short-term deliverables, and they don't pay enough attention to the architecture. If a team uses an agile approach, it does’t necessarily mean that they'd forget the architecture (and build functions for the most important requirements only). The agile team can focus on the overall architecture first, and roughly sketch the picture of the future architecture. Since the requirements are likely to change before most of the architecture or the interfaces are built, the big picture can be maintained at a high level. This is exactly where we can see one of most visible benefits of the agile approach.

With more traditional or documentation-driven approaches, the development team might spend more time going into the details of the big picture (which in later phases would change). If you have a detailed overall architecture, you're more likely to estimate the total cost for implementing the entire architecture. These figures can often scare decision makers. This is a dangerous way to think for two reasons:

• You don’t have to implement the whole architecture.
• You should start enjoying the benefits after the first implementation is released.

Consider all of the applications in a typical organization. Some of them are used daily by loads of users, while others are not used very often and have only a few users. Making the distinction between these two is not difficult. It would be obvious to focus the SOA activity on the applications with more users and higher usage. The more difficult category of applications are those that are used daily, but only have a few users. Are these processes critical (such as reporting, or business intelligence), or will they work just fine the way they are?

It would be prudent to quickly go through all the applications and choose the ones that would really matter. Take just a few hours to quickly sketch the overall architecture for interfaces and their main functions. Then you’ll know what the elements (or the building blocks) are while you start to build your first solutions. Don’t worry if the drafted interfaces will change in the future.

Your choice for the first solution is important, because you want to show the business owners that getting results does’t take that long. As you evaluate the possible business needs, choose something that is relatively easy to implement. Using a business need previously mentioned, a typical case could involve allowing customers to check and update their address details. Depending on the number of possible users, this is relatively easy and quick to implement. Still, if updating the address details was previously done manually, and the number of changes is high, the savings could be significant. This would be an ideal business need to implement.

The team could examine existing applications that contain address details, decide which of them is the master, or simply decide to update the information to all of them. The team would then investigate the possibilities for updating the data, such as:

• Using existing open interfaces, such as HTTP, SOAP, RMI, or socket interfaces.
• Using existing inter-application interfaces, such as Java components.
• Getting and updating data directly to a database (making sure that you don’t break any validity rules).

If it's obvious there will be loads of difficult, or numerous, integrations to different types of applications, it is wise to evaluate an integration product. They might be too expensive (and complex) for small applications and small budgets, but soon the advantages will start to kick in.

Quite often, companies build Web portals to use the information from existing applications. The portal would be an excellent way to implement the address update functions. The team could build on the progress by: getting a portal product (commercial or open source); drafting and implementing the basic functions of the address updating in the portal; implementing the interfaces; and integrating it all together. The size of the application is quite small, so the team is likely to implement it in a reasonable time, depending on the existing applications and their technologies.

If you now look at the big picture, the team has started to implement the overall architecture. Instead of doing it one layer at a time, though, they're tackling one real business need at a time. Both the business people and the development team have learned a great deal about the existing applications, possible bottlenecks, and implementing the interfaces and applications. Now they are more capable of suggesting the next moves relevant to the business needs.

As the business folks and the team choose the next implementation, which could be an update to the first release or a new application targeting a different business need, the architecture would evolve. Since the architecture was just a draft, making changes to it is not a big deal.

Back to top

Conclusion

This article explored the benefits of SOA, and how organizations can get real benefits in less time and with less money. You can use the agile approach to release something concrete that the business can use. As always, this is not possible in all situations or organizations, but you can likely turn the rejected SOA project into an accepted project.

Typical SOA projects involve Web portals in one way or another, either at the organization itself (self-care, help desk) or at their partner's solutions (reseller portal, e-commerce). By implementing the first efforts vertically, from the portal through the interface to the existing applications, instead of horizontally (one layer at a time), the business can release their first SOA based applications faster and start to enjoy the benefits.

Resources

Learn

• Check out the other parts of this series on adopting agile development:
  • Part 1, "Is agile development right for your organization?" (developerWorks, Mar 2008)
  • Part 2, "Understanding the different facets" (developerWorks, Apr 2008)
  • Part 3, "The role of agile stakeholders " (developerWorks, May 2008)
  • Part 4, "Using user stories to define project requirements" (developerWorks, Jun 2008)
  • Part 5, "Applying user stories in a Web-based financial planning tool" (developerWorks, Jul 2008)
  • Part 6, "The buyer's viewpoint" (developerWorks, Sep 2008)
  • Part 7, "Different methods to estimate work efforts in agile development" (developerWorks, Nov 2008)
  • Part 8, "Improve the quality of your agile process by modeling" (developerWorks, Dec 2008)
  
  
• "Amazon’s SOA strategy: 'just do it'" (Jun 2006) describes how your best bet is to just get out there and start doing it. And keep it simple — very simple.
  
  
• Read Wikipedia's discussion of SOA.
  
  
• Agile Software Construction by John Hunt discusses agile software production as well as modeling.
  
  
• Agile Modeling explores agile modeling methodology.
  
  
• Read Wikipedia's discussion of Scrum.
  
  
• Read about the principles of SOA in Service-Oriented Architecture (SOA): Concepts, Technology, and Design and Service Oriented Architecture For Dummies.
  
  
• Read more about Scrum, and Adaptive Project Management Using Scrum.
  
  
• In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Read what everyone is talking about in developerWorks blogs and get involved in the developerWorks community.
  
  
• Check out Scott Ambler's blog - Strategies for Scaling Agile Software Development.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Overview: Benefits of SOA
• Agile approach to SOA benefits
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

Dig deeper into Rational on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers