When USinternetworking, an application service provider (ASP) to more than 150 companies, was still very small, software architects and programmers were able to keep track of the available application codes and figure out how to make them work together. But as the Annapolis, Md. based company grew, the task rapidly became unmanageable.
USi "had a lot of legacy code and a lot of different systems that we connected together in a variety of ways," explains Michael Rulf, vice president of advanced engineering at USi (acquired by AT&T in October 2006). "We were using SSH and various types of network calls. The lines between applications had started to blur."
Different parts of the organization had begun using different vendors for similar operations, such as those involving Customer Relationship Management (CRM), but these applications still needed to be able to work together. "I had to figure out how to get the data from one system to the other, and each one of them made very different transformations to the data. It rapidly became very messy. I found that SOA helps you a lot with that integration process," says Rulf.
Service-Oriented Architecture, aka SOA, is a system that enables companies to isolate and define sections of program code -- the services, which are usually part of large applications -- and then implement a standard form of communication, allowing data to pass between the different services. A service can exist anywhere -- inside or outside an enterprise or made accessible via the Web -- and can be used for a variety of purposes by those who have permission to access it. (article continues)
Grow Up Fast
"We went from a traditional way of doing integration with data feeds and message brokers and made a hard right so that things could be more scalable and streamlined," says Rulf. "That's an advantage of SOA."
USi decided to use a middleware SOA software product for transitioning, rolling out and managing its SOA environment. The software includes components for discovering what services you already have available in your enterprise, then describing and defining those services using a Universal Description, Discovery and Integration (UDDI) registry, which has become a global standard.
"What happens in large organizations when you change to an SOA environment," says Jim Connolly, director of development for Kettley, a financial technology company based in Newport Beach, Calif., "is that you start losing lots of [code] duplication," thereby getting rid of the unnecessary data that gums up applications and, in Connolly's words, "kills an organization."
While Connolly agrees that cataloging and describing all of the functions in an organization is an enormous task, it's well worth the effort. After SOA is implemented, no time is wasted writing code that already exists -- a simple "call" to a service suffices. When a mistake is discovered, it only needs to be changed once, and all applications that use that service immediately and automatically switch to the corrected code. Services can be written, rewritten and tested without any change to the user interface before being described, cataloged and deployed. SOA provides greater efficiency and a large, well-organized software knowledge base. (article continues)
Stabilizing the Application Environment
Perhaps most important, says Sateesh Narahari, the senior product marketing manager for APM (Applications Performance Management) at Symantec in Cupertino, Calif., is that software performance improves and systems become more stable.
"We check the availabilities of services 24/7," Narahari says. "Our APM products enable you to do a system 'health check' on a regular basis, and alert the proper person if something goes wrong."
Narahari strongly encourages his clients to focus on business requirements first, closely followed by performance. Through a constantly monitored system, the SOA environment enables even sprawling enterprises to build, define, manage and reuse code embedded in even the largest applications and systems in a methodical and economical fashion, without regard to what language the code is written in.
Implementing a SOA environment has surprisingly few technical issues. Cataloging the services and creating a central repository can both be done using either open source or commercial solutions, both of which are fairly well established. "It's about not reinventing the wheel," says Connolly.
Instead, the biggest challenges involve changing engrained habits and businesses processes, according to Connolly. "It's a change from the traditional mindset of programmers wanting to have the autonomy to write their own code in their own style to thinking in terms of specific problems and checking to see if someone else in the company has already solved them."
While it's a large task to transition to an SOA environment, experts agree that for most medium and large-size enterprises, it's a worthwhile long-term investment.