by Mike Kavis

SOA Still Isn’t Just For Integrating Legacy Systems

Sep 19, 20085 mins

Service-oriented architecture is not just for legacy systems but can be strategic for Startups as well., a SaaS provider of IT Service Management solutions, has used SOA as a competitive advantage.

A few weeks ago I wrote how SOA is not just for integrating legacy systems but could also be a strategic approach for launching a brand new startup. I argued that startups can build their products and services from scratch in a true service oriented fashion without the burden of culture change issues, business process reengineering efforts, and changing the way the firm develops. Starting from scratch creates a tremendous opportunity to build it right from the start.

Fred Luddy, CEO of agrees with me. This is exactly the approach his company took to gain competitive advantages on its competition. is an on-demand IT Service Management solution provider. Their SaaS solution combines ITIL v3 with Web 2.0 technology and SOA to provide a rich user experience to address a firm’s problem management needs.

Luddy, former CTO of Remedy and Peregrine founded his company knowing there had to be a better way of delivering software solutions then the way traditional shrink wrapped solutions of his past were being delivered. Previous systems were too inflexible, took too long to change, and were not customizable enough for the users. After spending several years with companies who are now his competition, Luddy came to the realization that it was time for “significant simplification.” In 2004, he formed with the intent of leveraging the Internet as the platform to build his product on. His vision of the underlying architecture was that software must be “simple, approachable, configurable, and easy to integrate” and had to be as “restless and stateless as possible.” Luddy also wanted to eliminate the data formatting issues and figuring out how to communicate with various other applications. In his own words he states that “there were no alternatives, no decisions to be made. There was no other way then with a SOA mindset.”

Luddy and team had the luxury of starting with a blank sheet of paper and applying the lessons learned from his years of working on packaged software products. Like I mentioned in my previous article, startups do not have to deal with some of the big challenges that established companies have to deal with while implementing SOA: namely culture change and business process reengineering. The whole team clearly understood the SOA vision and the benefits that came with it. There was no resistance to change here. Also, the business processes were being created from the ground up so there were no existing business processes to change. This was the perfect scenario for implementing SOA. The team established standards upfront and created an architecture that provided them the simplicity, flexibility, agility, and ease of integration that would separate them from their competition. In 2005 their Java-based product was commercially available. Today their product has over 30 built-in integrations such as Tivoli, OpenView, LDAP, SMS, SiteMinder, and Oracle Financials.

Reaping the benefits is now reaping the benefits of their strategic use of SOA. Their product is extremely configurable which allows them to easily adapt to change. One of their biggest challenges is integrating with partners who do not have a flexible architecture. They have had to write several adapters for partners to provide a seamless integration. Recently they integrated with who also has an excellent standards based SOA product offering. The integration took only one week! Try that with your existing problem management and CRM system! Another benefit is that a single code base can be deployed on premise or hosted

Also with SOA, claims there are fewer moving parts to complicate integrations. A pure SOA implementation should be largely platform and technology neutral, meaning that .NET to Perl or Perl to Java for example is very easy to achieve. When properly designed, SOA makes versioning of software on both sides of the integration less challenging.

Lessons Learned

As with all implementations, there are lessons learned. Luddy warned that he drank some of the cool aid from the SOA hype machine that said that with SOA based products, everything will be easy. What he came to realize is, once SOA is implemented, integration to other SOA services is only easier than non-SOA, or legacy, software. While it took less than one week to implement bi-directional ITIL incident management with cases, integrating with HP Openview or Tivoli Enterprise Console required that first create a SOA layer on top of the legacy code before being able to move forward with the integration.

Luddy used a combination of young and experienced staffers claiming that a young mindset is required. More experienced developers can tend to be set in their ways which may have been good ideas in the past, but are not good ideas today. For example, Luddy asks “why would anyone write APIs” anymore? APIs made sense back in the client server days but is not the most efficient approach in an SOA. Luddy challenged his more experienced developers to go with what is relevant to the problems you are trying to solve today and “shed your baggage at the door.” Luddy’s best advice is “choose the simplest, most flexible technologies.” His team did just that and selected a variety of open source and web 2.0 technologies to make the user presentation layer as user friendly and customizable as possible.


As has proven, SOA is not just for legacy system integration. In reality, SOA is actually easier to implement for startups then for companies that have been around a while. Starting with a clean slate and building SOA properly from the ground up can give a company huge competitive advantages over competition that is bogged down with legacy applications and outdated business processes. It is also much easier to start with SOA then to build it in later.