Technical staff frequently talk about the need for service-oriented architecture (SOA), but rarely in terms that business managers understand. We can sum up the benefits of SOA in three words: control, agility and cost.


If your technical staff can’t tell you how SOA has an impact on those three business needs, you need to tell them to keep trying until they do – otherwise, they’re in serious danger of implementing technology for technology’s sake.


Running IT Like You Run Your Business


To set the groundwork, consider the following question paraphrased from officer aptitude tests at the military academies.


A newly commissioned officer is given a flagpole, some bags of cement and two shovels. She has a corporal and a private working for her [the corporal is senior to the private], and she has been ordered to erect a flagpole. How does she do it?


One of the more common responses from civilians is “tell the private to erect the flagpole,” but our junior military officers wouldn’t do that – they don’t want to micromanage by breaking the chain of command.


A more common response from our junior officers is several pages of equations. The thought process appears to be something like this: “The regulation height of a flagpole is h meters, and the wind shear can be estimated as s, so I need a mass of m kilograms, which means I need f cubic meters of cement, which means I need a hole d deep and w wide.”


But that and the accompanying equations are wrong. The only acceptable answer to the question is, “tell the corporal to erect the flagpole.”


There’s good reason for that response, which boils down to two common maxims of good business: delegate responsibility to the part of the organization that’s best equipped to handle it, and tell people what to do, not how to do it.


Now, returning our attention to IT, we see that we’ve rarely achieved those maxims. With massive enterprise application integration (EAI) implementations, we centralized key business processes instead of allowing subordinate managers to handle them. With large-scale enterprise resource planning (ERP) implementations, we have let systems dictate how our businesses would run, instead of enabling them to run the business the way they saw fit. The result was frequently dissatisfied business management, extreme hassle, low flexibility and high cost.


And that leads us to the way business managers should think of SOA: as a set of best practices that enables IT to be managed in the same way any other part of the business is best managed. That’s what gives control, agility and cost savings. With that in mind, let’s look at how SOA achieves those goals.




Businesses manage themselves through hierarchical controls: line workers report to managers, managers report to vice presidents, vice presidents report to the CEO.


Each level of worker provides services to the levels above and below it. For example:


  • A quality assurance worker in a manufacturing plant provides testing services to the line.
  • The line manager provides manufacturing services (the creation of the goods) and reporting services (number of widgets created, number of defects, mean time between failure of the machines, etc.) to the plant manager, as well as providing maintenance, HR, administrative and other services to the line workers.
  • The plant manager provides manufacturing and reporting services to regional managers, as well as maintenance, HR, administrative and other services to the line managers.

A service, then, is something that one part of the business does for another part of the business. If other parts of the business change, then the business manager responsible for a service might have to change the service; or the service might stay the same, but the business manager might need to provide the same service to different people.


It’s similar in IT. A service is a reusable bit of functionality, like the ability to update an order or to pay an invoice.


What we often miss, though, is the need for this service to be understandable to a businessperson, and how important it is for the requester to not care about how the service gets done. Imagine how inefficient we would be if we had to tell an administrator, “Get Ted’s address from the company address book, put this paper into a #10 envelope, put a first-class stamp on it and put it into the mailbox.” It’s much better to say, “Please mail this to Ted.” Tell people what to do, not how to do it.


So why should IT force businesspeople to understand SAP, Oracle Financials, Siebel, mainframes, and other technologies when their real goal is just “issue the invoice”?


SOA should eliminate application-specific information from any discussion of the services you need. Invoices haven’t changed much in thirty years. They have line items, quantities, prices, responsible parties, mailing addresses – all of which changes much less rapidly than the information systems that process them. So by eliminating all of the application-specific information from any discussion of the services a business manager needs, SOA makes it easier to understand what IT is doing for him. That, in turn, makes it easier for him to direct what he wants done. Knowing less about the details can actually increase the control that he has.


Buzzword alert: when IT people talk about application-specific services they’ll often call them “fine-grained services.” Business-level services are often called “coarse-grained services” or “business services.”




Everyone knows that business conditions can change rapidly; agility is the ability of a business to respond to those conditions quickly and optimally.


From an IT perspective, this often means changing the way IT handles processes, whether it’s through implementing new applications, creating new channels (B2B or Web storefronts, for example), delivering information in new ways (through Web browsers, graphical analytics, wireless devices, etc.), or other significant changes.


Consider the benefit of coarse-grained business-level services. The business manager doesn’t have to care how it’s implemented, so IT has complete control over what happens to the invoice that they’re supposed to issue.


That enables IT to completely change how they implement the service. If they want to rip out a legacy system and replace it with a more modern application, they can. If they want to outsource their invoice processing to a specialist, there’s nothing stopping them from doing so. By letting the business manager focus only on the business, it also lets IT focus on the best possible way to support the business.


But there’s even more to it than that.


An organization that’s structured along business lines will change according to business demands. Companies will be acquired; product lines will be retired or merged; noncore business processes will be outsourced.


If IT organizes itself the same way, then it will be able to roll with these changes very quickly. During an acquisition, changing a call from the old accounting department to the new one doesn’t change much (because invoices don’t change much). During a reorg, changing a call from one manufacturing division to another doesn’t change much (because inventory requirements don’t change much).


EAI projects failed so often in the past because everything was heavily centralized. Every piece of the organization (and, usually, each application) was “tightly coupled” to every other – at least from an IT perspective. SOA is decentralized, and each part of the organization is responsible for the services it provides. And remember, each division provides its services in terms of business data only. That allows different parts of the organization to be “loosely coupled” – in other words, to call one division’s service first and, if the organization changes, call a different one later.




Finally, recognize the cost benefits of the control and agility achieved through SOA.


If you use services and need to change your business processes, you can do so rapidly, with only business-level knowledge of the services involved – which enables much faster changes, cutting both hard and opportunity costs of business change, and helping you achieve the benefits of the new process (the new process does provide a benefit, right?) more quickly.


If you provide services, then nobody in the business except you is talking directly to your applications, so they won’t notice when you decide to retire that expensive legacy system and replace it with something more cost-effective. Also, nobody in the business except you knows how you audit your processes, so you can add compliance procedures without disturbing anyone else’s processes.


Either way, what used to require the collaboration of programmers with deep technical knowledge and businesspeople with a strong process orientation now requires a straightforward knowledge of available services and required business processes.


The Bottom Line


If SOA didn’t affect the control, agility and cost of IT implementations, it wouldn’t be worth doing. Unfortunately, many technical organizations haven’t communicated these benefits to their business leadership.


Many companies today still find themselves struggling to achieve these benefits, but with the right tools in place, the goals set forth by businesses can be achieved.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access