I hoped and prayed SOA would fade into that dark place where all overused three-letter acronyms go for rehabilitation. Unfortunately, the popular computer press and the geek intelligentsia won't let it go away. Why is that? When service-oriented architecture first reared its ugly head, I figured it was just another name for something programmers and developers had been doing for years–as in reusable code, as in not having to reinvent the wheel every six months. Let's face it, a lot of code a developer writes today would be very difficult to write from scratch. In the golden days of coding (that is, pre-Windows, pre-semi-documented APIs), coding was fun and easy. Writing a C routine to search and index an extremely large list was fun and logical–as in Boolean logic extended out to its extreme limits. Coding to an object model that was created by a large team of developers whose goal was to make the API usable for internal consumption is not always logical. Even the best and most intuitive developers literally can spend hours trying to determine the exact code needed to access and use an object model.
I find it ironic that logic is not necessarily the most important thing on a developer's mind barely a half century into the age of computing. And that is why reusable code is so essential. Once I finally have figured out the best way to call NastyWidget.getdata_structure and do something useful with it, I most certainly am going to save that little (or maybe not so little) bit of code and share it around my shop. In fact, I may even wrap it up in a utility Dynamic Link Library (DLL) along with all the other utility code for the project.
That is what I thought SOA was going to be all about: taking a computational resource and promoting its reuse. In that respect SOA seemed old hat. So what if we now were going to expose code as a Web service? What if we were going to use industry standards to publish that code? It still was about code reuse. SOA also involved a concurrent movement to wrap up code in bigger chunks. If you had to write a routine to pull customer information from your CRM system, it made sense to create a unique, stand-alone object that wrapped up all the possibilities "pulling customer information from your CRM" could encompass. That object or DLL or Web service or whatever then would be shared throughout your enterprise for a multitude of applications. At least that is what I interpreted the SOA vision to be.
Silly me. I was thinking like the diehard geek I am. If it's about IT or data processing, it must be about the code. At the end of the day, all that silicon and wire we call a computer is just a boat anchor without code. Wrong. It's about the business. And if it's about the business, it really is about the money. Which takes me back to why I quit my job at the bank many years ago. So, maybe it's time we take a look at service-oriented architecture as it really is–that rough beast slouching toward Bethlehem.
I will turn to a well-respected international outfit–the Organization for the Advancement of Structured Information Standards (OASIS)–for help. This is how that august body describes SOA: Service-oriented architecture represents a collection of best practices principles and patterns related to service-aware, enterprise-level, distributed computing. SOA standardization efforts at OASIS focus on workflows, translation coordination, orchestration, collaboration, loose coupling, business process modeling, and other concepts that support agile computing. (See http://www.oasis-open.org.) I am sure that makes everything crystal clear. Kind of makes you wonder whether you should have been an attorney. If you have to read stuff such as that, you better be able to bill yourself out at $400 an hour instead of the measly $200 IT consultants get. Nevertheless, even OASIS still is talking about best practices for computing–not best practices for business.
There was a time when CIOs were techies, maybe techies with an MBA, but their core values and interests centered around technology. They then would implement technology in a way that could best promote the goals of the business or the individual business units. Nowadays, there is a trend to place individuals in the CIO spot whose core values are business oriented. Business goals do not always coincide with technology goals–even though they should.
A business person may look at technology and see it as nothing more than a core service that needs to be funded from the business units. There is nothing wrong with that perspective–in fact, it is a perfectly valid way to look at IT and IT services. But if it becomes the only perspective, radical change is inevitable.
This is where the business types hijacked the SOA model and repurposed it to their own use. And that is the height of irony. Treating IT as nothing more than a core service such as payroll or grounds maintenance was the first step in the subversion of SOA. Business types have usurped the acronym to view IT as a collection of services that are consumed by the business units of the organization. Just as SOA software architecture provides services that are consumed by other software applications, IT can be modeled as a provider of services that are consumed by the enterprise.
And those services have to be paid for. Each business or business unit must contribute funds to support the IT organization and infrastructure. At a high level this paradigm probably is OK. It always has been true business paid for IT and infrastructure. However, once you pose the situation this way, you have opened the door for business units to shop around for services, which is fraught with pitfalls.
I have worked within organizations where business units decided they should contract their own development teams. They decided they no longer wanted to pay for X percent of the internal development staff and tried to bring in outside contractors to build out their Web applications. It never occurred to them (1) they needed access to my servers and (2) my team would need to maintain those Web apps once they were deployed. What did occur to them was IT was providing services to them and they didn't like the budget line IT was creating for those services. The thinking (if you want to call it that) was something in the range of: Hey, my son-in-law says he can build out our Web sites for a third of what we now are charged. Granted, in this case, the business units did not get to use their own vendors for IT services, but it demonstrates the type of thinking that leads to radical change and dissatisfaction.
Consider the following: The CIO of a global company decides he no longer wants to fund any internal software development. Even though the organization has hundreds of internal applications and thousands of Web applications and Web sites, a conscious decision is made to eliminate all internal developers. The developers weren't really all that expensive, but their pension and benefits packages were. Short term it appeared to make more sense to pay contractors a lot more money on a per-hour basis to perform all development work. According to the model (based on subverted SOA), the company would consume only the developer resources it needed when it needed them. Sounds reasonable. So, how did that work out?
What actually happened was this organization created a gaggle of IT managers. These managers may or may not have been technically competent because they were recruited and hired as managers–not technologists. These managers, in turn, managed the IT contractors who were doing all the "real" development work. The managers spent their time attending meetings and hiring more contractors. Of course, the contractors got paid for overtime, so the best ones were being billed out at 60 hours a week at a rate of well over $100 per hour. Not only that, but the contractors had job security. The good ones were more or less guaranteed permanent employment. Oh, yeah–and the nontechnical managers were totally at the mercy of the developers.
Another very large company was trying to cope with what it perceived as runaway IT spending. The necessary budget for IT was growing faster than revenue. So, each year at budget time, the IT budget was constrained to reflect a constant percentage of top-line revenue. That meant IT had to scale back the services it was able to provide the business units. In point of fact, IT really didn't scale back services–it scaled back service levels. And that coupled with the increase in real-dollar spending was unacceptable to the business units.
The solution in this case was to outsource the entire IT infrastructure. All network, Internet, intranet, server, desktop, and helpdesk services were outsourced. A contract was negotiated with another very large organization to provide all these services. Everything–from service calls to server support to storage–was assigned a cost and a service-level agreement. The rationale went something like this: Our core competency is manufacturing and selling XYZ, not IT management, so we should contract that to a technology company whose core competency is IT management.
Wait a second. This company had been managing an IT infrastructure for a multinational enterprise with 35,000 employees–and now claims it wasn't a core competency? That's utter nonsense. There exist only a handful of organizations in the world that match the scale of that organization. The fact it was enormously successful and profitable proved it had a core competency in managing a massive IT structure. There was no reason to expect a third party to be able to manage IT with increased efficiency. Beyond the obvious problem of finding and hiring thousands of competent individuals, there is and was a complete disconnect in motivation and goals. The internal IT folks who were deemed too expensive and too inefficient were, in fact, motivated by ensuring their employer maximized profits and thus maximized their incentive bonus plans and salary. The new firm's employees were motivated by maximizing the revenue for their employer, which meant providing as little service as possible for the most cost. On the white board, there appeared to be efficiencies gained by using an SOA model on the basis of pay for what you consume. Thankfully, white boards can be erased. Abstracting IT to a laundry list made this organization less efficient and less agile.
SOA is a sound paradigm for software architecture. And that probably is where it should stay. While there most definitely are efficiencies to be gained by examining and streamlining the services IT provides an organization, there is no demonstrable rationale to identify those services and put them out for bid. Certainly, there are situations where it makes sense to bring in a hired gun for a particular project or service, but if I am managing an IT project that is critical to my business–and thus my livelihood–I want players who have the same goal I do. And that goal is the most excellent solution for my organization–not the one that brings the best short-term changes to the bottom line. One is reminded of the quote that always has been attributed to John Glenn–"As I hurtled through space, one thought kept crossing my mind: Every part of this capsule was supplied by the lowest bidder."
© Touchpoint Markets, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.