Avoiding Bad SOA
Unfortunately, there is no way that Zapthink can make guarantees about the success of your Service-Oriented Architecture (SOA) initiative. Sure, we often write and speak of SOA best practices and implementation roadmaps and the like, but even if you read all our stuff and truly understand SOA, there are no guarantees that you’ll actually do SOA right. On the contrary, it’s actually quite easy to build a bad SOA — an architecture that may technically be Service-oriented, but will not solve the business problems that led you to make an architectural change in the first place. The best practices that make up SOA are not fully baked, and therefore, there are many wrong turns that companies make as they stumble their way through their SOA projects.
There is some good news, however. As an increasing number of companies blaze SOA trails, ZapThink is collecting the lessons of their mistakes, and can pass them along to you. Here, then, are some of the top errors we see companies make in their SOA initiatives, often leading them to dead ends, wasted efforts, and bad SOA implementations that don’t meet business needs.
Mistake #1: Arguing about what SOA is rather than how to do SOA right
Techies, being very smart people, love to argue about the definitions of technical terms and the nuances of implementation, and SOA is no exception. Blogs and online forums are full of discussions about the “true” definition of SOA, and we have to admit, ZapThink’s definition has appeared in more than one. Arguments about SOAP vs. REST, CORBA vs. Web Services, ESB vs. fabric, and the like have come to dominate the surprisingly large quantities of free time many techies appear to have, while the more difficult questions of how to best build SOA to address business problems consumes far too little bandwidth. The fact of the matter is, it doesn’t really matter what the precise definition of SOA is, as long as you implement SOA in a way that addresses the business problems you set out to solve. For some great examples of SOA discussions focused on solving business problems, attend our ZapForum Webcasts!
Mistake #2: Confusing Web Services and SOA
Web Services are standards-based interfaces to software functionality, while SOA is software architecture oriented toward Services. The definition of architecture is the fundamental organization of a system embodied by its components, their relationships to each other and to the environment and the principles guiding its design and evolution (from IEEE). Web Services alone can reduce the cost of integration, but will no more give you SOA as having a pile of lumber and nails will give you a house. In fact, it’s possible to have one without the other — although building SOA without Web Services will more than likely lead to bad SOA, because achieving loose coupling in the face of heterogeneity is far more difficult without the use of open standards. If you’re still confused about the difference between Web Services and SOA, take the SOA term and reverse it: instead of Service-oriented architecture, say architecture oriented toward Services. Remember, adding Web Services interfaces to an existing architecture does not SOA make.
Mistake #3: Putting SOA entirely in the hands of the IT department
As enterprise architecture, SOA addresses a range of business problems through the application of IT resources. As such, it is essential to a successful SOA rollout that the business drive the initiative. Ideally, a line-of-business executive should act as stakeholder and champion of SOA. Companies without such a champion often find themselves focusing on trees rather than the forest: they think of business requirements as a set of use cases that the technology must implement, rather than understanding the true business context of Service orientation. The true “meta-requirement” for SOA, after all, is to build an architecture implementation that addresses ever-changing business requirements. Line-of-business must drive such a meta-requirement.
Mistake #4: Thinking you can buy SOA from a vendor
As a previous ZapFlash discussed, products that vendors have architected internally in a Service-oriented fashion may not help you with your enterprise SOA initiative. Even so, there are many maturing products on the market that may truly contribute to the success of your SOA. However, you can buy the best SOA products on the market today, and you still won’t have SOA. Buying the best tools won’t make you a carpenter, after all. Remember, SOA consists of a set of best practices — a discipline to follow, if you will. You can buy SOA from a consulting firm, but not from a vendor who doesn’t offer SOA consulting as well.
Mistake #5: Building SOA from scratch
If you think the alternative of buy is build, then you’re missing the point. While software products won’t give you SOA, attempting to build SOA from the ground up solely with internal (or outsourced) development talent is rarely effective either. After all, successful SOA implementations require a range of capabilities, including security, management, integration, Service discovery, governance, and more. Enterprises who attempt to build all the pieces themselves without taking advantage of existing products on the market typically find themselves bogged down by the sheer scope of functionality necessary to get SOA right. Instead, companies should look for a combination of internal or external architectural expertise with an appropriate selection of software (and hardware) products that are well-suited to building SOA implementations.
Mistake #6: Waterfall SOA projects
Gather requirements-design-build-test-deploy-manage — the familiar waterfall methodology for software projects is surprisingly tenacious, considering the fact that it’s common knowledge that it usually doesn’t work very well. Waterfall works best when business requirements are well-understood, stable, and easy to communicate. With SOA, the business meta-requirement is often poorly understood, always in flux, and difficult to communicate. Therefore, the waterfall approach is particularly ill-suited for SOA implementations, because the reasons that limit waterfall’s effectiveness are exaggerated in SOA projects. As a result, iterative, agile methodologies work much better with SOA projects for all the same reasons they work better with any other software project that struggles with clear, stable requirements.
Mistake #7: Making SOA too difficult
Sure, SOA is challenging. After all, architecture in general is a challenge on its best day, and SOA is still in its formative stages. But that being said, companies often make the mistake of thinking SOA is even more difficult than it has to be. It’s not necessary to decompose all the business processes in the entire enterprise, or plan to reuse hundreds of Services, or tie together dozens of business partners in the first phase of your SOA rollout. Tackling too much too soon is a recipe for disaster. Instead of biting off more than you can chew, try tackling SOA in bite-size chunks. Plan an SOA pilot project with high ROI and relatively low risk. Pick a project that you’re team can handle technically, with a line-of-business champion that can muster the budget and support necessary. Maybe the initial pilot offers only a few Services — but by tackling the architectural planning as part of the pilot, SOA really isn’t that difficult to implement, and can provide significant return for the business.
The ZapThink Take
Best practices are rarely if ever derived from first principles. Instead, people hammer out such practices after making many mistakes, and learning the hard lessons that result. Therefore, while we see many people making the mistakes above, and those mistakes often lead to bad SOA implementations, you should not necessarily see such mistakes as failures. Instead, there are only successes and “learning opportunities.”
Of course, the best kind of mistake is the one someone else makes. Fortunately, SOA has mostly moved beyond the early adopter stage where companies are willing to take risks in order to leverage their early adoption for competitive advantage. We’re now in the early majority stage of SOA, where many more companies can learn from the mistakes of the pioneers. While the complexity of SOA necessitates that additional mistakes will be made in due course, there’s no reason for you to make any of the mistakes discussed in this ZapFlash. Instead, let business drive and architects plan your SOA, while taking an iterative approach that leverages the best SOA products on the market, and your SOA initiative promises to be successful.