Why Business Managers Should Care about SOA

Running IT Like You Run Your Business

To set the ground work, 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 what SOA achieves those goals.

Control

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.

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 (reports on 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 just 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 reponsible 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.

Real-life projects support this claim. One iWay Software customer saved an extremely rapid Warehouse Management System implementation from failure by identifying exactly which part of the business was responsible for a particular set of services, and then ensuring that their priorities were met. The project manager reports that if she had allowed people to wire together individual system transactions without identifying the services in business terms first, her project would have slipped because no one would have been directly responsible for the integration being done. (Except her, of course – so SOA was important for business success and her career.) Interestingly, the team didn’t use the term “SOA” to describe what they did, because they’re a conservative company that’s distrustful of buzzwords. What matters is the practice, not the acronym.

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”.

Agility

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, say, 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 just 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; non-core 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).

Enterprise application integration (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.

Cost

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. Our experience at iWay Software in implementing SOA projects has shown us that although the benefits are difficult to achieve, they’re well worth the effort.

Jake Freivald is VP of Corporate Marketing for Information Builders and its integration-oriented subsidiary company, iWay Software.