ZapThink <http://www.zapthink.com/styles/Internet_Market/images/zapthinkheader.jpg>
Thinking Outside the SOA Box Document ID: ZAPFLASH-20061115 | Document Type: ZapFlash By Jason <mailto:[EMAIL PROTECTED]> Bloomberg Today, Service-Oriented Architecture (SOA) is finally off the ground. Most organizations are past the basic planning stage, and are now actively constructing their SOA implementations. Much work remains, to be sure; standards are incomplete, tools are immature, and companies continue to struggle with the political, cultural, and technical challenges that architectural change presents. Be that as it may, SOA has turned the corner in many ways: we're now focusing more on consuming Services than building them, issues of governance have risen to the fore, and organizations are finally working through the complexities of SOA quality. But perhaps the most interesting sign that SOA has reached a new level of maturity are the early indications that the focus on SOA as something separate from the rest of IT is waning as Service-Oriented best practices gradually become accepted more broadly as general IT best practices. The fact that the spotlight of hype has shifted from SOA to greener pastures like Enterprise Web 2.0 is actually an indication that SOA best practices are becoming ubiquitous. Ironically, the more ubiquitous SOA becomes, the more it fades from view. We're in the very early stages of this trend, however. Today, most SOA thinking remains "inside the box," in that we're still thinking of SOA as a set of activities and best practices separate from the rest of IT. Such inside the box thinking helps us understand what is still a new approach to organizing IT capabilities and leveraging them as flexible business resources. But there is a problem with this limited thinking: the business just doesn't care about the SOA box. After all, business managers care about solving the various problems the business faces on a day-to-day basis; when they require IT to help solve those problems, they generally don't care if the particular solution IT brings to the table is Service-oriented or not. In a fundamental way, therefore, inside the box SOA thinking places limitations on SOA's relevance to the business. Recognizing the SOA Box Retiring the SOA box, therefore, is an important step in providing value to the business, and the first step in getting rid of the SOA box is in recognizing its existence. By "SOA box" we mean the assumption that SOA is something distinct from other approaches that would therefore be non-SOA in some way. Inside the box SOA thinking affects all corners of the greater IT community, including IT end-users, consultants, and vendors. It behooves all these parties, therefore, to recognize the aspects of the SOA box that limit their thinking, in order to think outside the SOA box. We see the SOA box pattern of thought in many different areas of discourse. Some examples of SOA thinking that currently fall within the box: * SOA Quality is as yet quite distinct from traditional software quality assurance (SQA). SQA is code-focused, and generally takes place during one phase of the software development lifecycle. SOA Quality, on the other hand, is a continual process that deals with metadata, relationships among Services, as well as the quality and performance of the underlying code. * Many architects are still posing the wrong question. They're asking, "this SOA is cool; how do I sell it to the business?" instead of asking, "these are the business's most pressing problems; what are the best approaches to solving them?" When architects identify SOA as a distinct capability and bring that to the business, they typically meet with resistance. Instead, if they consider Service-oriented best practices as tools in their toolbelt, where their jobs as architects is to know which tool is the right tool for solving the business problem at hand, then they will likely find that the business will support their efforts to effect architectural change. * The worlds of Business Process Management (BPM) and SOA are still alarmingly distinct. ZapThink has spoken at combined BPM/SOA conferences, but generally people attend either the BPM track or the SOA track exclusively, in spite of the fact that BPM and SOA share many best practices, and in fact, we would say that BPM should be Service-oriented (and correspondingly, that SOA should be business process-focused). * The "lipstick on the pig" phenomenon is still dismayingly alive and well in the vendor community, as some vendors slap Service capabilities onto their older technologies in order to call them SOA products. Not only do such products still retain all the inflexibility and brittleness that plagued them beforehand, such vendors are also fooling their customers into believing that their products really do help them implement SOA. Furthermore, such SOA pretenders shift attention away from other vendors who have truly rearchitected (or newly architected) their products to follow Service-oriented principles in such a way as to truly enable their customers to succeed with their SOA initiatives. Thinking Outside the SOA Box Such inside the box thinking both restricts the value the business can get from SOA, and also introduces skepticism about SOA across the organization. Clearly, grasping the full impact of SOA long-term requires out of the box thinking. Fortunately, thinking outside the box is only difficult when no one is doing it; once people realize that existing patterns of thought are too limiting and begin to expand the context of their understanding, then the box breaks down. Here are some notable examples of indications that people are finally starting to think outside of the SOA box: * ZapThink's recent SOA Consulting <http://www.zapthink.com/report.html?id=ZTR-WS113> report concluded that while there is more SOA-related consulting taking place than ever before, companies are generally not asking for SOA by name. Instead, businesses are asking for solutions to their business problems, and consulting firms are increasingly leveraging SOA best practices to address those needs, even though those projects aren't "SOA projects." * The SOA Management market has largely consolidated, as the vendors who first built out Web Services Management products that they later renamed SOA Management have found that the core challenges of SOA management are traditional IT management problems: network, systems, and applications management. As a result, the practices of IT Service Management, SOA Management, as well as Business Service Management are beginning to converge. * Organizations increasingly realize that the movement to Service Orientation changes the way in which they manage IT projects as a whole, and not just the Service-oriented ones. As companies move to more iterative means of IT delivery, and as those capabilities utilize Service-oriented approaches to dealing with change and heterogeneity, IT development as a whole will encompass and embody the best practices of Service-oriented development, leveraging the Service Lifecycle for overall IT project development. * The more narrow definition of SOA Governance consists of applying governance practices to SOA implementations, for example, making sure that developers are following reuse policies, and ensuring running Services conform to policies around security and service levels. Increasingly, however, people are defining SOA governance more broadly, thinking about how to tackle broader governance challenges in the context of SOA, once they have SOA in place. * Many organizations are setting up SOA centers of excellence in their organizations, which are essentially teams of architects who create a set of guidelines for the adoption and implementation of SOA across the enterprise. Many of these Centers of Excellence, however, are extensions of existing Integration Competency Centers, and in many cases, they are acting as Enterprise Architecture Centers of Excellence, centralizing best practices for architecture more broadly than just for SOA. The ZapThink Take The common thread that ties these illustrations together is that the older thinking presumes that SOA represents something distinct: a distinct set of best practices or a separate market, for example. But in reality, as SOA matures, people find that SOA best practices are simply best practices, and SOA markets, practices, and projects are becoming indistinguishable from the larger software, hardware, and professional services markets, best practices, and IT projects of which they are a part. It's possible to misinterpret this trend and incorrectly conclude that SOA is fading in importance. In fact, there's even a "SOA is passé" thread through the industry that supposes that SOA is losing importance because SOA best practices are gradually losing their SOA label. However, nothing could be further from the truth: there's more SOA than ever going on today, only now people are actually doing it more so than talking about it. In fact, ZapThink predicts that by the end of the decade, SOA best practices will become so widely accepted and commonplace that there will remain very little discussion of SOA in any corner of IT: vendors won't use SOA in their product messaging, consultants won't offer SOA practice areas, and IT end-users won't be running SOA projects. Instead, all aspects of IT activity will simply be Service-oriented. Successfully thinking outside the SOA box will cause the box itself to fade from view, indicating not that SOA has diminished in importance, but on the contrary, that SOA practices will have become ubiquitous.
