What You Need to Know About Service-Oriented Architecture
SOAs promise to speed development and decrease integration time and effort - but only if you implement them correctly
Reader ROI
- Definition of SOA
- Benefits and risks of the new architecture
- Steps in developing a SOA strategy
Don Buskard, senior vice president and CTO at AXA Financial, a $US7.5 billion insurance and financial services company, compares his service-oriented architecture (SOA) to a system of gears: some big and slow-turning, some small and fast. And Buskard believes SOA is the right mechanism - a transmission of sorts - for an IT environment (like so many others) in which relatively ponderous data-crunching legacy systems must mesh with agile front-facing applications.
Service-oriented architecture isn't a new approach to software design. Some of the notions behind SOA have been around for years. Jess Thompson, a research director at Gartner, says the underlying concepts date back to the early 1970s, when researchers started drawing boundaries around software and providing access to that software only through well-defined interfaces (an idea called encapsulation). But lately, SOA has been gaining traction, especially as CIOs begin to think seriously about Web services. Gartner estimates that by 2008, more than 60 per cent of enterprises will use SOA as a "guiding principle" when creating mission-critical applications and processes.
But to implement a SOA, you must first understand it - and that isn't always easy. So let's begin with some simple questions and (hopefully) simple answers.
What the Heck Is a SOA?
SOAs start with services, which are groups of software components that carry out business processes; for example, verifying a credit card transaction or processing a purchase order. At its most basic, a SOA is a collection of services on a network that communicate with one another. The services are loosely coupled (meaning that an application doesn't have to know the technical details of another application in order to talk to it), have well-defined, platform-independent interfaces, and are reusable. SOA is a higher level of application development (also referred to as coarse granularity) that, by focusing on business processes and using standard interfaces, helps mask the underlying technical complexity of the IT environment. It's like translating a high school science text for your kindergarten-age daughter; you can tell her that the heart pumps blood without getting into the mitral valve and pulmonary veins.
Isn't SOA Just Corba in New Clothes?
No. SOA is an evolution from traditional tightly coupled application connections - including common object request broker architecture, or Corba - to loosely coupled ones, such as Web services. Tight coupling makes it hard for applications to adapt to changing business requirements, as each modification to one application may force developers to make changes in other connected applications. Also, object-oriented development uses a finer level of granularity - objects might be defined at the level of employee or customer order. In a SOA, a service is defined at a more abstract level, say, a business process such as generating a phone bill.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.