4: Risks in SOA Adoption
The author proposes to be "frank and open" about the things that could go wrong with an SOA implementation. (EN: Given the rose-colored case studies, I have my doubts about whether this will be objective or comprehensive - and doubly so, as the rest of the chapter introduction speaks of "human error" as being the root of all evil.)
CRITERIA FOR SUCCESS
For any technology to be successful for a company, the costs of the technology (obtaining, installing, and maintaining) must be covered by the increased revenue or decreased costs that result from its implementation.
(EN: be careful of a pure accounting approach to this. A technology that results in a product that is competitive may merely retain customers that might have been list to competitors who adopted it, so the considerations go beyond the immediately fungible. That's not to say that one should swing to the opposite extreme and pronounce a deployment successful because of imaginary consequences that might have occurred, just to say that one must consider more than the immediately measurable phenomena).
For technology to be successful in a society, the social benefit of the technology (increased standard of living for some) must outweigh the social costs (lost jobs, decreased quality of life, environmental impact, etc.)
(EN: the second seems to be more of a societal concern, but it's worth mentioning - as social woes often lead politicions to single out some companies for a public flogging.)
TECHNOLOGY AS A TOOL
Historically, technology has been in the nature of tool-making. Except in rare cases where it takes a predictive role, technology provides the means to do existing tasks more efficiently, or provides a solution to an existing need: the computer replaced the calculator, while replaced the adding machine, which replaced the abacus, etc. - but the need for numbers to be added predated (and precipitated) the tools for doing that task.
Computer technology, however, is different than traditional tools in that IT "tools" are often used by multiple users, each of whom has different needs, and the way in which one tool works may interfere with the operation of another tool. This creates a complex web of ownership and responsibility for the systems and the data they contains, and thus far, IT has not been successful in managing these interrelations. The author refers to paper written by Cynthia Rettig, who portrayed the current state of information technology as a "crisis" on the verge of widespread disaster.
Insofar as SOA is concerned, it must consider some of the existing problems with IT. While it may be intended to address these problems, it will continue to exist in an environment where it is just as likely to be impacted by legacy IT as to cure it. In particular:
- Making any change to a system is slow, due to the complexity of systems and the unforeseen impact even a simple change can have.
- Making any change is also risky, as "computer problems" can bring operations to a halt, and losses amount every second a system is offline or malfunctioning
- Software tends to be riddled with defects that have been patched up, compensated for, worked around, or merely accepted.
- Data is poor quality, which includes both "bad" data in existing systems and the inconsistency of data across systems (a single customer may have different IDs in each of five systems)
- Software is excellent at working with standardized data, but is not very good at dealing with variability, which is become increasingly common.
BARRIERS TO SOA'S PROMISES
There are also a number of factors, external to a SOA project, that can prevent the SOA solution fro delivering its promised value.
The promise to bring business and IT together has been the aim of many technologies, even going back to COBOL (which was supposed to be a programming language business could understand) - and to date, nothing has worked very well. Neither side has been very willing to act cooperatively. So while SOA can help get them on the same page, both parties must be willing to collaborate, which is a cultural and political change for many organizations.
The promise to automate business practices has long been the focus of IT, but only the simplest and most menial of tasks has actually been automated. Task automation depends on a formal approach to tasks (documented procedures and contingency plans) and systems that have sufficient complexity to handle the kinds of decisions that human workers make. There is a tendency for business not to document, just to leave people to figure out what to do, and for IT to oversimplify tasks in order to reduce system complexity, and a happy medium has proven elusive.
The promise to create reusable services is difficult to achieve. As with automation, it depends on a collaborative approach to requirements, such that the business units do not impose requirements that add unneeded complexity to serve their "unique" needs, whereas IT does not develop services that are not sophisticated enough to handle the necessary differences in requirements. This also depends on the ability of legacy systems and new purchases to play nicely with a middleware layer to support SOA (and naturally, the services will inherit their defects).
The promise to make services that will be usable as building blocks depends on the abstraction of business processes - such that a function can be defined by inputs, operations, and outputs - but the abstraction in most businesses is new, and the documentation may not exist, or it may overlook critical components, making it difficult to provide a "rip-and-replace" service that can easily replace, or be replaced by, other services., and a great deal of customization is still needed to build applications that are based on services - or the services may be customized to fit a system, making them difficult to replace or reuse.
The promise of systems integration is dependent on systems to support interoperability, and the dream of open standards has largely been unrealized. Many vendors lock down their systems to prevent customers from integrating with other vendor's products (thus forcing customers to buy their own solutions)., which frustrates attempts to integrate internal systems.
The promise top make business more agile is thwarted by the current state of SOA. The promise to rapidly develop snap-together solutions depends on the services to already exist - but until the library of services matures to include most business functions, it is likely that any change will require the creation of a new service, which is a more time-intensive task.
OTHER RISKS
Presently, there is a lack of standardization across industries - each company has its own ways of doing business and storing data - and while XML is an attempt to enable industries to standardize the data they commonly communicate to other in their environment, the standards are immature and there may be conflicting standards (which is not an improvement over having none at all). As a result, any "connection" from one firm to another (such as allowing a customer to automate ordering by integrating it with their own inventory system) requires a lot of custom code.
(EN: I'd be very wary of this. A lot of voices seem to be demanding companies comply with a set of industry standards - but from the perspective of a single firm, standardization means loss of competitive advantage and reduces a product to a commodity. Admittedly, it be highly efficient to create a generic product that is no different than anyone else in the industry, there are valid reasons for product differentiation.)
There is also a problem with SOA platforms themselves. As with any new technology, it's surrounded by hype and vendors are quick to roll out solutions that capitalize on the spike in interest, regardless of whether those solutions are any good. The author claims to have worked with several such solutions, some from major vendors, and found their lack of quality to be "alarming" and advises a very careful evaluation before buying any of the existing products.
Testing service-based solutions is allegedly complex. Not only do the testers need to examine any new system developed based on services, but if any modification has to be made to a service, it is wise to test every other application that relies upon that service. The author claims that this is not unique to SAO - any solution that leverages existing capabilities has the same testing requirements, regardless of the development technique.
Finally, SOA is said to be ineffective in improving software quality. The author concedes this, but indicates that this isn't a problem that SOA creates, just a benefit it does not deliver - and cannot deliver. He suggests SOA is the "glue" that ties together existing software, and if that software is buggy, so will any solution that leverages it.