• Archive
• Contributors
• Resources
• About

William Perlowitz

SOA addresses enterprise requirements to rapidly respond to changes in business requirements, processes and policies, and continual changes to commercial technologies and implementations. SOA accomplishes this by adoption across heterogeneous enterprises and environments, enabling information sharing, rapid evolution and change to applications, increased investment reuse, and the elimination of duplicative effort. The price for attaining these advantages is that the enterprise, no matter how large or complex, must be unified and uncover, define, and persistently evolve governance (including management, security, and quality) across intricate, often politically charged, environments. To achieve the benefits of SOA, enterprises must realize that traditional approaches to IT project management (where a project is considered in isolation, requirements are defined, and budgets are allocated) can no longer work. This article explores why the shift to treating IT as a continually evolving asset must occur. We describe why a radical change from traditional IT project management to program management and organization must be made and we conclude by introducing the concept of the "Network Organization". Anyone working in IT has moments when they are convinced that business people have limited cranial capacity and no appreciation whatsoever for the vast complexity of an enterprise's systems and...

Robert Schneider

As many enterprises currently carrying service-oriented initiatives have learned the hard way, SOA governance isn't a "nice-to-have" option. Instead, it's vital to the long-term health and effectiveness of the undertaking. What makes governance particularly challenging is the sheer number of interacting software assets found in a typical service-oriented architecture. Forward-thinking organizations have turned to SOA governance automation to help manage this daunting task. This article offers a series of simple tips and tactics to bolster the likelihood of being successful when selecting and implementing SOA governance technology. It also points out the interplay between governance solutions and the major phases of a service-oriented initiative. For many organizations, embarking upon an SOA initiative involves a significant investment in staffing, training, hardware, and software. Unfortunately, far too many of these enterprises overlook the importance of protecting their investment by deploying a well-planned, robust SOA governance infrastructure. In this article, I point out a few best practices that you can employ to help bolster the chances of being successful when bringing SOA governance technology into your organization. I begin by attempting to explain the paradox of how so many organizations are managing to implement their SOA without investing in governance technology, as well as...

Stuart Kerrigan, Richard van Schelven

For many companies in the telecommunications sector, SOA adoption is essential to their growth and survival. This article explores the integration of concepts associated with SOA and service-orientation into a typical telecom enterprise by explaining how key SOA characteristics and principles tie into the typical telecom organizational structure, leading to an opportunity to define business services and establish a Service Solution Set Inventory (SSSI) as the foundation from which services can be repeatedly composed into aggregate applications. Along the way, we will explain some basic terminology related to distinguishing core from context processes and differentiating between the various types of clients and consumers that acquire service-oriented systems (which we'll refer to as "products"). Business transformation is about aligning people, process and technology initiatives with the businesses strategy. Telecom business models are changing to meet enhanced customer expectations and to face increased competition. As a result, telecom businesses must find ways to differentiate themselves. This brings us to the concept of what is "core" and what is "context" to a business. In essence, any corporate activity that increases shareholder value is core. Anything that does not is context. As Geoffrey Moore puts it: "A business process is core when its outcome directly affects the competitive advantage of the company in its targeted markets. Here is...

Wajid Khattak

The success of any IT initiative could be measured in terms of the actual business goals that it fulfills. However, when it comes to SOA based projects, it becomes imperative that such an initiative bears close correspondence with the business requirements as SOA is usually an enterprise wide activity, so any slight deviation from the actual business goals could result in an SOA that is misaligned with the enterprise wide goals. So in order to achieve this required alignment, it stands necessary that before starting off with the service-oriented analysis phase, a high level view of required SOA needs to be in place that ensures that the subsequent analysis phase concentrates on business processes in the order of their preference with respect to the business goals linked with each business process. Business Process Analysis (BPA) offers matrices that help in drawing a correspondence between business goals and high level services. BPA also helps in prioritizing the business processes in terms of the most pressing needs of an organization. This article presents the rationale for BPA, its importance and more importantly it describes the actual steps involved within BPA with the help of a case study. The importance of BPA within traditional application development accounts for a successful end product that is more aligned with...

Thomas Erl, David Orchard, James Pasley

Web services have made it possible to build services with fully decoupled contracts that leverage industry standards to establish a vendor-neutral communications framework. Though powerful and flexible, this framework brings with it an on-going responsibility to effectively manage those service contracts as the services continue to evolve over time. One of the most critical aspects of service governance is contract versioning. This first of two articles, comprised of excerpts from the recently released "Web Service Contract Design & Versioning for SOA" book, explores fundamental service contract issues, including compatible and incompatible versioning requirements. The following article is an excerpt from the new book "Web Service Contract Design and Versioning for SOA" [REF-1] Copyright 2008 Prentice Hall/Pearson PTR and SOA Systems Inc. Note that chapter references were intentionally left in the article, as per requirements from Prentice Hall. After a Web service contract is deployed, consumer programs will naturally begin forming dependencies on it. When we are subsequently forced to make changes to the contract, we need to figure out: • whether the changes will negatively impact existing (and potentially future) service consumers • how changes that will and will not impact consumers should be implemented and communicated. These issues result in the need for versioning. Anytime you introduce the concept of versioning into an SOA project, a number of questions will likely be raised, for example: • What exactly constitutes a new version of a service contract? What's the difference between a major and minor version? • What do the parts of a version number indicate? • Will the new version of the contract still work with existing consumers that were designed for the old contract version?