Service Oriented Architecture
Thursday, July 31st, 2008We talk about our products being designed as a Service Oriented Architecture (SOA). They are, but why should you care? This posting attempts to explain why you might.
Historically, software applications were written with few if any open interfaces. These systems were huge, monolithic, and difficult to interface to. The challenge is that these legacy systems contain business logic that implements key decisions about business processes. Without an easy set of interfaces, these highly valuable units of business logic are locked away, difficult to reuse, and costly to maintain.

The concept of SOA was introduced so that those involved in business processes and information technology could design software and business rules as a service. The goal was to make it much easier for companies to reuse software and to interface to SOA applications.
This was helped along by development platforms, like Microsoft’s .NET or Java’s J2EE, which make it easier to both create SOA applications and to interface to an SOA software implementation. We estimate that it takes 50-75% less implementation work (measured as hours of work) to integrate our scheduling platform into a customer’s IT infrastructure then with comparable non-SOA scheduling solutions. We achieve these cost savings, even if the customer’s infrastructure is based on legacy mainframe or UNIX platforms.
By being a SOA web service, we also provide customers with leverage to solve multiple business problems. Customers typically purchase and deploy one of our scheduling solutions for a particular business problem such as automating the people and workflow in telecommunication service activations. This only involves a percentage of all of the employees in the organization. If there are scheduling challenges with another section of the business, our implementation can be used to solve those challenges with a small amount of incremental work. Traditional business applications can sometimes be applied to new business problems, but rarely can they do so with little work effort.
When SOA is well done it brings greatly reduced integration costs and higher reusability of business logic and application solutions. That’s why you could care about Service Oriented Architectures.
David Greer
Cartoon courtesy of Geek and Poke





