What’s with all the doom and gloom? In the past few months, we’ve seen a rash of ZapFlashes, articles, blog posts, and podcasts talking about the downsides of Service-Oriented Architecture (SOA), and for good reason. Any trend that demands such a significant portion of executives’ and practitioners’ time and budget demands to be critically examined so that the good of all parties are being met. After all, very few people benefit from trends that are all hype and no substance. A proper debate shows that there are not only substantive reasons in favor of some approach, but also show the causes and reasons in opposition.
In the last ZapFlash, we talked about a host of reasons and the different players that are stifling SOA’s potential for success. On the flip side, over the past seven years of ZapThink’s existence, we provided numerous reasons that support the use and expansion of the role of SOA. First and foremost, the role of SOA is to provide an architectural approach that supports an organization’s ability to continuously change in the face of a heterogeneous environment. Certainly this concept has legs, as companies continue to struggle with the most fundamental of integration and change management issues. But if so many parties are working to thwart this basic value of SOA, what forces are working to make sure it succeeds?
Proper Scoping of SOA Projects
Most often, the single cause of failure for SOA is inappropriate scoping of the SOA project. Companies too often seek to make SOA an enterprisewide effort, even though the business case for that is typically not justified. The rationale goes that SOA is an aspect of Enterprise Architecture and therefore its scope is enterprisewide, or because it is so important and strategic, it must be implemented at an enterprisewide level. Other IT practitioners are simply used to implementing all of their major initiatives enterprisewide, so why should SOA be different? Because SOA is not a project or a technology — it is an approach, that’s why.
SOA is simply not appropriate for all problems, and even for problems that need to be solved enterprisewide, not all parts of the solution should be Service-oriented. A good enterprise architect knows how and when to apply SOA. Knowing when and how to apply SOA is 80% of the battle. Managing the Service lifecycle, including continuous quality, Service modeling, governance, and management is the rest. When companies seek to implement hundreds of unproven Services against a business case that is not justified using millions of dollars of untested technologies, they risk significant failure. And when those SOA projects fail to deliver as promised, do they blame their own efforts, the products they used, or their methods? Of course not. They rest the blame on SOA itself.
On the flip side, well-scoped SOA projects are often remarkably successful. Most case studies of SOA success relate to organizations fixating on a particular business problem, perhaps at even the departmental level, and solving that in a Service-oriented way. The champions of SOA know full well that success comes from focusing the solution on a particular problem and solving it well. “Think big, start small, succeed often” is the refrain of successful architects.
Enterprise Architecture Teams
Our previous ZapFlash lambasted individuals that simply had no credibility, training, or experience to call themselves enterprise architects. Where individuals fail, sometimes teams succeed. Indeed, the problem is that very few individuals have the skills to understand the business combined with the technical acumen necessary to understand how SOA best practices can drive business solutions. But, properly constructed enterprise architecture teams can have the best of all worlds. In most successful SOA projects, there exists a strong, multi-role, cross-organizational team that helps to provide all the perspectives needed to understand the full scope of enterprise architecture.
As we related in the parable about four blind men and the elephant, IT departments have necessarily grown into siloed organizations that have neither the skills nor resources to appropriately manage and view all aspects of the organization. While one way to get that visibility is to hire enterprise architect experts that have the necessary skills to see all parts of the business and technology, getting those resources will become an increasing challenge. Most firms can achieve the same effect simply by building cross-functional teams that include line of business representatives, application development, data modeling, process modeling, security, and network operations roles, just to name a few. While it is certainly preferable to have a knowledgeable EA individual on staff, sometimes the team is necessary. However, significant care must be taken to insure that political issues and design-by-committee effect doesn’t happen. Even EA Teams need to be guided by best practices and have validation and auditing, especially when there’s no single individual with EA expertise. A number of ZapFlashes talk about building the right EA team to make SOA a success.
Lines of Business Champions vs. Tech Insiders
ZapThink can trace many instances of SOA success to the fact that someone from the business has identified a specific need that can only be solved by one of SOA’s four points of ROI. Where business can see a solution, sometimes IT is blind. Too many times IT departments try to use the SOA hammer to approach every problem as a nail. Indeed, the symptom of ill-scoped SOA projects is partially caused by this inability (or inexperience) to utilize SOA properly. But more than simply letting the business determine the scope of a SOA solution, the business part of the organization is also less resistant to the concept of SOA and its speedy and successful implementation than IT.
As we detailed in our Finding the Real Barrier to SOA Adoption ZapFlash, the IT organization, more often than not, resists implementation of SOA even in the face of compelling business propositions. Technologists often get stuck in defensive positions regarding particular technological approaches (REST vs. Web Services anyone?). These arguments relate little, if at all, to the business problem at hand and tend to devolve into pedantic arguments of semantics. The truth of the matter is that any technology approach that can solve a business problem is valid, and probably will be displaced in favor of a better one in a few years anyways.
While technologists pride themselves in technological understanding, they are often the ones that get suckered into buying the Vendor-driven Architecture (VDA) story. While technologists understand little about the business, they can easily understand a technology story, which vendors tend to pitch. Business users already abstract technology in their thinking. In their mind, all technologies are alike as long as they meet the business needs, policies, costs, and timeframe. This makes line of business champions the most successful starting point for SOA. Where an LOB champions SOA, we see rapid success. Where the success of SOA depends on an IT-only champion, we see SOA projects stuck in the IT-political and technology-religious quagmire.
Technology Best-of-Breeds
The SOA vendor landscape is steadily creeping towards single-vendor suites and platforms. Oracle’s potentially pending acquisition of BEA will only further cement in some customers minds that SOA infrastructure, many currently branded as ESBs, are best offered by large vendors as part of platform suites that address a wide range of SOA runtime issues. However, SOA does not necessarily favor this suite approach. Indeed, SOA thrives in an environment of heterogeneity and continuous change, and as such, proper architectures abstract technology implementations, which would mean that the value of a suite in a SOA is no greater or less than the value of best-of-breed components. One can also reason that unless an organization reigns in or prevents change, it is quite unlikely that any organization can ever solidify its implementation on a single vendor’s suite. Technology change, like business change, is continuous, and as such it makes little sense to solidify the architecture to a particular technology implementation. Yet, too many organizations let the vendors drive their architectural decisions.
Not all technology providers are pushing the VDA story that is so detrimental to the long-term success of SOA. Best-of-breed SOA infrastructural technologies aim to solve point problems such as simply providing reliable Service intermediary capabilities, policy enforcement, or metadata management. Such technologies and vendors are not in the business of trying to lock you into their suite and will correctly advise their customers that the success of the architecture is entirely the responsibility of the end user. Where companies treat technology suppliers as simply enablers and not as packaged “architecture” vendors, we see success. Where companies come to rely on vendors to solve their problems without requiring the customer to create and manage their own architecture, we see problems.
The ZapThink Take
Just because someone points out the downsides of something does not mean they no longer support it. Indeed, ZapThink has long championed the appropriate use of SOA to solve lingering business problems. In fact, ZapThink has long advocated a balanced approach to considering any technological trend, starting with our very first report — the Pros and Cons of XML. In the same fashion, we offer in this last set of ZapFlashes a Pros and Cons of SOA of sorts. Smart architects and business managers who seek to apply SOA to solve their problems should have a firm grasp as to when SOA will provide success and when it is being inappropriately shoe-horned. Such a grasp includes realistic assessments of the people, technologies, processes, and methods of the existing environment and proposed solution, and the drawbacks of any potential solution. Having such a balanced approach serves to further the likelihood of success with SOA, and doesn’t by any means kill the value of SOA itself.
The post What's NOT Killing SOA? appeared first on ZapThinkTank.
