ZapThink <http://www.zapthink.com/styles/Internet_Market/images/zapthinkheader.jpg>
Pragmatic SOA Document ID: ZAPFLASH-2007118 | Document Type: ZapFlash By Jason <mailto:[EMAIL PROTECTED]> Bloomberg Posted: Jan. 19, 2007 ZapThink met with the global CIO of a multinational financial services firm recently to discuss the success he'd had with his Service-Oriented Architecture (SOA) implementation efforts. He made an interesting and provocative point: even though he had achieved substantial success with SOA in terms of the business value such initiatives yielded, he had constrained the scope of his SOA efforts to a set of specific problem areas. In fact, he had no plans to Service-orient most of his IT operations -- and yet, his firm is one of the most successful SOA implementers in the world. This CIO's experience underscores a fundamental principle of SOA adoption that many organizations on the roadmap to SOA overlook: SOA solves some problems, but not all, and is best implemented when the characteristic benefits of SOA outweigh the overhead and cost of architectural change that moving to SOA requires. As a result, success with SOA rarely necessitates comprehensive change; instead, architects who choose their SOA battles carefully can deliver on SOA's promises to the business via projects of limited scope. Architects who miss this point often set the bar for SOA success too high -- but by taking a more pragmatic approach to SOA, success really doesn't have to be that difficult. No Silver Bullet ZapThink has long discussed the fact that SOA is no silver bullet for solving all of IT's ills, as we introduced in <http://www.zapthink.com/report.html?id=ZAPFLASH-02162004> a 2004 ZapFlash. After all, silver bullets are only good for killing werewolves; if a vampire is after you, you'd better have a wooden stake instead -- and the same is true for the various problems organizations have with IT. Starting with the business problem you're trying to solve and identifying the appropriate solution based on that problem is an obvious best practice for all of IT, and is clearly a best practice for SOA as well. Taking such a solution-oriented approach to SOA, however, is only one aspect of pragmatic SOA. On the one hand, it's important for the architecture team to prioritize potential SOA projects, while on the other hand, it's also an established best practice to take an iterative approach to SOA implementation, where each project iteration delivers business value. Combine this two-dimensional evaluation process with an additional risk/benefit analysis, and you have a pragmatic approach to SOA that will likely enable you to eliminate many potential SOA projects from your roadmap entirely, and focus on the ones that will provide the most value for the smallest risk. Project-by-Project Pragmatic SOA The best way to get a clear picture of how to approach SOA in a pragmatic way is to discuss a few examples of how organizations might approach specific initiatives. Here are some common situations: * Pragmatic SOA Governance. Most governance challenges facing organizations today don't directly involve IT -- if they involve IT at all. Many policies are simply not automatable, and as such, IT takes a secondary role of simply enabling the communication of written policies. When planning a SOA governance initiative, therefore, it's important to differentiate between automatable policies and other policies that are best left for manual enforcement. As a result, Early iterations of SOA governance initiatives might focus, say, on security policies for Services, followed by reuse and quality of service policies, and eventually, Service consumption policies. From the business perspective, therefore, of the full range of policies the organization must create, communicate, enforce, and update, IT is able to leverage SOA to automate a specific subset, and will do so by prioritizing specific policies based upon a risk/benefit analysis. * Pragmatic Reuse. Many people like to tout reuse as the primary benefit of SOA, but in fact, reuse is quite difficult to achieve in practice. After all, reuse really means sharing of resources -- and while we all supposedly learned how to share in kindergarten, we didn't like it then, and we don't like it now. Effective reuse also requires governance, and even so, presents challenges to organizations seeking to obtain business benefits from increased reuse. It's important, therefore, for the architect to understand that reuse builds over time. After all, the word "reuse" itself indicates that "use" must happen first. Only after an organization builds a comfort level with the use of the Services at its disposal will it begin reusing those Services. Pragmatic reuse, therefore, typically means delaying the expectation of reuse to later iterations. Seek to achieve different short-term business benefits from a SOA initiative, and let reuse grow at its own pace. * Pragmatic Legacy Enablement. One specific area where the reuse benefit of SOA becomes particularly important is legacy enablement. The surprisingly durable 80/20 rule of thumb works quite well here when it comes to Service-enabling legacy capabilities. Analyze what legacy functionality you use most for any particular system or application, and chances are, you use about 20% of the functionality 80% of the time. Service-enabling that 20% is likely to provide the best value for your legacy rejuvenation investment, both for increased use as <http://www.zapthink.com/report.html?id=ZAPFLASH-2006531> well as better reuse of the legacy assets. In fact, you may find that rarely are you justified in Service-enabling much of the remaining 80% of the functionality. * Pragmatic SOBAs. When ZapThink discusses the creation and management of Service-Oriented Business Applications (SOBAs), which are applications composed of Services that implement business processes, all the effort required to build and maintain such SOBAs can appear to be far too much trouble. As a matter of fact, SOBAs really are too much trouble for many business processes an organization conducts. After all, static, stable, well-understood business processes gain little by adding the overhead and complexity required to support SOBAs. It's important, therefore, for the architect to identify those business process in the organization that require the special flexibility, agility, and user empowerment benefits that SOBAs provide. Chances are, just like the global financial services firm discussed above, only a small portion of all the business processes the organization executes every day can justify the extra expense and overhead that SOBAs require. * Pragmatic User Empowerment. Enabling certain business users to manage and evolve business processes without direct IT involvement is one of the most ambitious of SOA goals, and for good reason -- such a vision requires bulletproof governance as well as mature tooling that's only now beginning to reach the market. A more pragmatic approach to user empowerment leverages end-user tools that are available today, including browsers, spreadsheets, and mobile devices, combined with the power of SOA-enabled Services to offer a richer, more functional interface for users, and leaves the more challenging composition tasks to IT. Such pragmatic user empowerment can come in many forms, including Ajax-enabled portals, handheld interfaces to business Services, spreadsheets that place Service queries into cells, and more. In other words, the Web 2.0 movement presents a smorgasbord of options for the enterprise, but architects watching their "waste" will pick and choose those tidbits that provide high business value with low risk. Pragmatic user empowerment, therefore, builds upon the capabilities and desires of users with an eye toward increasing business value, instead of bombarding users with new tools and capabilities that they are unable or unwilling to take advantage of in their day-to-day work. The ZapThink Take It's quite rare to find anyone using the words "pragmatic" and "architecture" in the same sentence, let alone use the phrase "pragmatic SOA." In fact, if you Google that phrase, much of the discussion centers on nuts-and-bolts Web Services, and not on the SOA-as-Enterprise-Architecture perspective that ZapThink espouses. And yet, we feel that it is crucial that organizations take a pragmatic approach to Enterprise Architecture (EA), especially if they're implementing SOA. Any architect who's ever struggled with the Zachman Framework understands that taking an overly formal, all-or-nothing approach to EA is bound to fail. Instead, architects must balance the more technical, formal aspects of their job with the more ad hoc, human parts, and focus much of their time on pragmatic efforts that build rapid, visible value for their organizations. When architects are implementing SOA, this need to focus on pragmatic efforts is particularly important, because of the immaturity of the architectural approach on the one hand, and the need to build and maintain business support for SOA initiatives on the other. The good news is that the number of organizations who have achieved real success with pragmatic SOA is growing dramatically. Regardless of the problems that the SOA initiative is meant to solve, taking a pragmatic approach to SOA lowers risk and increases your chance of success -- both in the short term with individual projects, as well as with long-term architectural change in the enterprise.
