Moty Aharonovitz

Subscribe to Moty Aharonovitz: eMailAlertsEmail Alerts
Get Moty Aharonovitz: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: SOA & WOA Magazine

SOA & WOA: Article

Beyond SOA Platforms and Tools

Higher integration means more effectiveness

Software reuse process and infrastructure are key enablers for SOA success.

Software engineering spent the better part of the 20th century stubbornly resisting standard engineering disciplines. Project introspection and peripheral management activities accepted by all other engineering fields as mandatory have frequently been avoided by many software development organizations. This resistance has had severe implications - with cost overruns, schedule slippages, quality and reliability issues, and consequent contract litigations becoming disturbing norms in the software industry.

Despite the huge progress and massive changes in development tools, architectures, and operational environments, it is interesting to note that the fundamental issues related to how individuals, teams, and corporations define and deliver software have not changed much. The Mythical Man Month, which is considered by many to be the classical book about the human element in software development, was published about 21 years ago, but has not lost much of its relevancy since then.

Anyone who has managed software projects is quite familiar with the "invariable" risks of the process. Indeed, these challenges manifest themselves over and over again, in thousand of organizations, in project after project. In fact, the changes in the business and technology worlds only make these systemic problems more difficult. Business is becoming increasingly "global," "rapid," "responsive," and "adaptive," and in turn it requires similar changes from its supporting IT processes and infrastructure.

According to a report published by leading industry analyst firm Gartner, "Competitive pressures are growing and the business environment is becoming less predictable, forcing enterprises to adopt the real-time enterprise as a business vision. Enterprises will prosper only if they continually remove delays from their critical processes, detect and respond to events, and accelerate their operations."

Consequently, software delivery cycles have become increasingly compressed and aggressive in an attempt to beat competition to the market as well as to reduce spending. Pressure on software development teams is mounting to predictably deliver technology initiatives that grow the top line while not affecting the bottom line. In other words, IT organizations are constantly required to do more with less. To add to the problem, the complexity of technologies and architecture has increased dramatically, becoming much more difficult to master and use effectively.

The net result of all of these changes is an environment of semi-controlled chaos, where things seem to be under control. In reality, though, it is rare that things are truly under control, and often there is no way to tell whether they are or aren't. All of these factors contribute to the formation of a high-risk environment, where the probability of project failure is significantly higher than its likelihood to succeed.

In examining the problems facing software developers and managers, two issues keep coming up:

  • Alignment of IT priorities and capabilities to the needs and priorities of the business
  • Making development teams and individual roles within teams more effective and productive
Together, business alignment and IT productivity represent the two most critical guidelines for IT agility, speed, and responsiveness. They make it possible for IT to aggressively support business revenue growth while staying within the boundaries of resource constrains. To close the so-called "IT gap," organizations are constantly looking for methodologies, tools, and platforms to facilitate alignment and productivity. The introduction of service-oriented architecture and its increasing adoption presents analysts, architects, developers, and managers with a new and viable paradigm for closing the IT gap.

The Emergence of Service-Oriented Architectures
Judging by the amount of industry buzz, many consider service-oriented architectures (SOA) and Web services to be the new technology silver bullet. More and more organizations are adopting or attempting to utilize SOA to various degrees, with SOA rapidly becoming a leading pattern in enterprise architectures and software development.

SOA represents an enterprise-wide architectural style that promotes stack agnosticism, interoperability, and loose-coupling between service providers and consumers. Web services is a specialization of the SOA approach, which relies on open standards and protocols such as WSDL, SOAP, UDDI, and HTTP, for discovery and communication between service consumers and service providers. This open approach, which enjoys broad-based industry adoption, ensures the future ubiquity and standardization of SOA, and Web services in particular, as the de-facto foundation for enterprise architectures.

Conceptually, SOA attempts to realign IT around the semantics of the business by representing applications and systems as a set of software services, which can be assembled together to support end-to-end business processes.

Services that expose business functionality or technical utilities with a low level of granularity can be composed and orchestrated to create services with higher and higher levels of granularity. The resulting structure can be thought of as a somewhat hierarchical graph of interdependent services. Since services consumers are typically only exposed to the top SOA layer of business services, this means that the behavior (implementation) or quality of service of these top-layer services can be changed on the fly by binding them to different lower-granularity services or components.

SOA represents an evolution of component-based development (CBD). CBD focuses on the assembly of applications using platform- and language-agnostic components, as well as managing the life cycle of components by container platforms. SOA represents a higher level of reuse by focusing on assembly and orchestration of business processes using a set of federated, platform- and language-agnostic services.

Despite being an evolutionary approach, SOA represents a true quantum leap in terms of aligning business and IT and closing the IT gap. It has the potential to deliver the architectural agility, resiliency, and flexibility that are required for delivering software-based economies of scale. However, despite the hype and the great potential, SOA and Web services implementations typically fall short of expectations despite massive investments in development tools and runtime platforms.

While there are several reasons behind such failures, the most critical one is associated with the realization that SOA is much more than a set of standards, tools, and platforms. Relatively little attention has been given to the SOA development process itself, which is very different from the "traditional" development process. In fact, many organizations do not realize that in order to succeed with SOA implementations, a radical cultural change has to occur within IT. The reason for this change is the fundamental role of service reuse, which strives to use existing services as much as possible to compose and orchestrate new services.

Software reuse as a concept has tremendous advantages, and many have tried to implement various reuse methodologies. Success, however, remains elusive. Beyond the reuse aspects of CBD, SOA adds service-level reuse typically required by process orchestration. In fact, the concepts of service production and service consumption explicitly imply and require service reusability. The reuse process has a life cycle of its own, which needs to be naturally integrated into the "normal" development process. It is therefore important to realize that establishing a service-oriented reuse process, which can be governed and monitored, is a key milestone on the road to SOA success.

Service-Oriented Reuse Process and Roles
Any large-scale implementation of SOA has to consider two groups of end users that are very distinct, have different skill sets, and require different tools to do their job. These two groups, the service producers (SP) and service consumers (SC), communicate via the SOA reuse process.

Service producers are typically architects and developers. Their part in the SOA reuse process is the production and publication of meaningful business services. Services are typically created from scratch by implementing and wrapping components with remote/SOAP interfaces, or delivered via a "service façade" on top of legacy or packaged applications.

As a group, service producers are required to consider the low-level design decisions that make SOA happen. They deal with issues such as service interface design, service granularity, component design and implementation, deployment decisions such as colocating components based on interaction dependencies, as well as working with the operations team to support a host of required quality of service parameters, such as security, performance, scalability and availability.

In general, most service producers live in a code-centric world. They require sophisticated IDEs and software design tools to model, design, and implement their work products. They are responsible for the "produce" life cycle of the SOA reuse process. As such, they need to identify IT areas with reuse potential, and then specify, design, implement, document, and publish reusable services that expose these areas for service consumers. Special consideration has to be given to interface design and service granularity, as well as to building services in a generic enough fashion (i.e,. not with project-specific details) to enable reuse in as many contexts as possible and prevent service proliferation.

In contrast, service consumers are typically business analysts, although often developers and sometimes business persons also act in this role. In contrast to the service producers, who are experts in the solution and technical domains, service consumers own the business domain expertise. They understand the current business processes, and have the knowledge that is required to model, transform, and optimize them. In addition, they may define additional processes as a result of new business initiatives.

Service consumers essentially act as a liaison between the business requirements and the IT infrastructure. But in contrast to other methodologies, SOA makes this link very explicit by enabling service consumers to assemble and orchestrate business processes by reusing existing services that were defined and implemented by service producers. In a sense, service consumers provide the most coarse-grained services (the top SOA layer), which represent the software realization of the core business processes conducted by the enterprise.

The tools used by service consumers are very different compared to those used by service producers. Being business-oriented and nontechnical in nature, service consumers require assembly tools, which enable them to search and locate existing services, and then wire and orchestrate them to form end-to-end business processes. These tools need to provide "soft" and intuitive modeling capabilities that fit the typical skills of business analysts and business people (see Figure 1).

Critical Infrastructure for the SOA Reuse Process
In order to succeed, the SOA reuse process requires automation, enforcement, and monitoring. Effective collaboration between service consumers and service producers mandates the utilization of the following solution stack:

  • A process engine that is deeply integrated with the development tools used by service producers and consumers (i.e., code-centric IDEs and assembly tools). The purpose of this engine is to enable the definition, enactment, and monitoring of the SOA production and consumption processes, as well as streamline and accelerate information flow and collaboration between producers and consumers.
  • A dashboard that provides managers critical information about reuse level for any software project in the portfolio. This information could be used to reward both producers and consumers who contribute to the SOA reuse process.
  • A service repository used to publish, document, search, and manage services. The service repository serves as the primary communication mechanism between service producers and consumers.
  • A requirements management solution. Both consumers and producers need infrastructure to manage their requirements, which are very different. While consumers manage business-level requirements associated with core business processes, producers manage domain-specific and quality of service requirements.
  • Code-centric IDEs and formal modeling tools (i.e., UML based) as the primary workbench for service producers.
  • Process assembly and orchestration tools as the primary workbench for service consumers.
Needless to say, the higher the integration between these stack components, the higher the effectiveness of the SOA process.

Software Delivery Optimization and SOA
Borland, through its Software Delivery Optimization strategy, is one of the primary companies helping software development organizations close the "IT gap," optimizing the way they manage risk across the complete life cycle of software creation from the line-of-business through development and operations.

Software Delivery Optimization views the process of producing software as a critical business process. As such, it strives to make it more predictable and reliable, similar to other engineering or manufacturing processes. It also views SOA as the dominant architectural style of the future, fully recognizing its advantages and viability.

Borland's Software Delivery Optimization platform today includes critical components that enable partial implementation of the SOA production and consumption processes. Currently it has a very strong offering for the service production role, and its roadmap includes the SOA stack components required to automate the service consumption role to deliver a fully automated and integrated SOA process.

More Stories By Moty Aharonovitz

Moty Aharonovitz is a senior director of product strategy at Borland Software Corp, where he is responsible for directing the vision and direction for the Borland?s solution platform. Prior to Borland, Moty acted as chief architect and VP of engineering for companies in the enterprise application space, such as diCarta Inc and Diligent Software Systems.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.