Architectural manifesto: Adopting agile development, Part 9

An agile approach to faster, cheaper SOA

In this final installment of the series, learn how an agile approach can help companies enjoy the benefits of SOA. In our current economy, organizations are carefully analyzing which projects they will implement, and which they will not. SOA's reputation of being costly, in both time and money, doesn’t help in getting new projects started. In this article, explore how companies can quickly start enjoying the benefits of SOA using an agile approach.

Mikko Kontio, Partner, Dazid

Mikko Kontio has a background in software development and consulting. Formerly a director with Softera, a software development company focusing on business portals and telecom-billing solutions, Mikko is currently a partner at Dazid.

20 January 2009


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.

This article is not intended as an introduction to SOA. Resources has more on 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.

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.

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.


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.



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



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. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. 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 Rational software on developerWorks

ArticleTitle=Architectural manifesto: Adopting agile development, Part 9