Worldwide Locations
Abstract
SOA is all about architecture-after all, it's right there in the acronym-yet most organizations think it is about turning existing software components into web services. When you adopt SOA, remember that it is all about design and governing that design. It's about how you design your service interfaces, your services, your data model, and your business processes. It's about how you keep track of your services, how you control the design, definition, deployment, and distribution of your services and their artifacts, how you define a service contract and service level agreement for your service consumers, how to secure your services, and how to react when things go wrong with them.
Sample
Introduction
Around 1996, Gartner analysts Roy W. Schulte and Yefim V. Natis published the first series of reports around the newly introduced concept and terminology of Service-Oriented Architecture (SOA). It was not really clear back then what SOA really meant in practice for organizations, and after more than a decade, it seems it is still not clear to many of them what SOA is all about, its value proposition, and, more importantly, why they should care about it and adopt it in their organizations.
Even worse, while the rest of us were trying to find answers to these questions, in the meantime, vendors were doing their best (and still do so) to coopt the term and repackage it as a product that they could sell to unsuspecting organizations. The pitch was simple: purchase this product, and you will have an SOA! Quite a few organizations bought into this sales pitch from leading vendors and subsequently proceeded to fail miserably to adopt SOA, inevitably wasting millions of dollars and countless man-hours and creating severe disruptions within their enterprises, with little to no tangible results. In some extreme cases, the whole endeavor was abandoned to the point where even the mention of SOA to anyone in upper management could be a career decision-and not a good one.
What a shame.
SOA has a lot to offer when it is understood and its principles applied consistently and incrementally. In fact, it forms the foundation for cloud computing, which is rapidly growing in popularity (see the Forrester research article at ZDNet: http://www.zdnet.com/blog/btl/cloud-computing-market-241-billion-in-2020/47702).
As an SOA consultant and trainer for many years, I have seen many organizations struggle with SOA adoption and, in this article, I wish to share with readers what I believe to be the most important factors that impact whether you will succeed or fail at SOA. Let me begin by dispelling a few entrenched myths around SOA.
SOA is not and never will be a magic bullet. It will NOT solve all your corporate IT problems in one fell swoop.
SOA is not easy. Adopting SOA is a long-term commitment to better IT practices and system design and is not a quick fix.
SOA is not a product. Vendors do not sell SOA; they sell products that support SOA development and speed up its adoption.
SOA is not about web services. It is primarily about architecture and design. Web services are a practical result of this and an enabling technology, nothing more.
SOA is not "an IT thing." It is NOT about technology, and even though the standards it promotes do simplify integration, that is not its main goal.
SOA helps to address issues of years of IT system neglect or the accumulation of decades of technical debt. It can provide a new path and approach that can dramatically reduce IT system degradation in the future and salvage existing legacy systems to the maximum possible extent. However, this will not happen overnight.
SOA requires a commitment from the whole organization. It can NOT be driven solely by the IT department. SOA should involve the business from the very beginning, because it is not purely an IT concern.
I do not want to discuss here the many reasons why organizations attempt SOA; this will be a topic for future articles. I will assume that the decision has been made for one or more good reasons (say, for example, reusability, flexibility, and/or agility) and that the organization is embarking on SOA either holistically throughout the organization or within some pocket of it (typically the IT department drives initial adoption but not always). So, what happens next?
Buy-In from Senior Management
A major goal of SOA is the evolution of the business and its processes, with potential widespread impact across the organization, so it is vital that members of the senior management team actively sponsor and promote SOA within the organization.
By the way, this is a show-stopper. Let me put this very simply: if you do not have support from upper management for your SOA efforts, and they do not share your long-term vision, you will not succeed, so don't even attempt it. Nothing more needs to be said.