Magic Quadrant for Integrated SOA Governance Technology Sets, 2009

Introduction

The recession and the need for cost optimization, combined with the market’s need of service-oriented architecture in 2008 and the “cover your back” mentality, have caused many companies to rethink the importance they give to SOA governance and related technologies.

Service-oriented architecture (SOA) governance technologies, much like any other set of technologies, are striving to address needs beyond the SOA realm. Process governance, governing cloud interactions and interactions with business partners (brokerages) are on the radar for most technology providers. Getting the basics correct is a necessity, but these technologies will likely be used to govern peripheral activities.

Market Overview

The market for SOA governance technologies is still in turmoil, with acquisitions, mergers, new players, and (most importantly) the dramatic maturation of companies procuring and deploying SOA infrastructure and SOA governance technologies. In creating the 2009 Magic Quadrant for Integrated SOA Governance Technology Sets, we immediately noticed a dramatic shift of all the participants toward the median of the quadrant. When assigning vendor weightings for this Magic Quadrant, we detected, via our analysis, client interactions and vendor briefings, maturity of the market. A few key data points became very apparent:

  • Customers are no longer looking for just a registry; instead, they were looking for a suite of projects.
  • A growing percentage of customers are including SOA governance technologies in their initial SOA projects.
  • Customers and technology providers are putting more emphasis on SOA validation and monitoring; the latter is seen as critical to monitoring metrics and measuring success.
  • Customers are deploying SOA centers of excellence, supported by the architecture group and empowered by the CIO.
  • Customers are looking for solutions to easily integrate with their SOA and integration platforms.
  • Customers are looking to govern their interactions with business partners and services provided via the cloud.

However, it’s not just the market shifting. A few new players have entered the market that represent various niches of customer wants and needs, focused on life cycle management, monitoring and policy enforcement. Vendors that offer some or most of this functionality include:

  • Alcatel-Lucent
  • Intel
  • MuleSource
  • Nastel
  • Oracle
  • Sensedia
  • Sonoa Systems

In addition, some vendors from the 2008 Magic Quadrant were acquired, and, as a result, the acquiring company has entered this market. Oracle, which acquired BEA Systems in 2008, is now a player in this space. An impressive number of acquisitions have taken place, with vendors in this market acquiring vendors in markets peripheral to the SOA governance technology market. Examples include:

  • Oracle acquiring ClearApp
  • SOA Software acquiring LogicLibrary
  • Progress Software acquiring Mindreef

These acquisitions highlight the vendors’ acknowledgement that monitoring, validation and life cycle management are core to SOA governance.

The job of integrating SOA governance among disparate domains remains complex, because, although obtaining SOA governance technologies from your installed middleware vendor may be less expensive than from a third-party vendor (in many cases, new technology licenses can be combined with existing ones), ensuring that the technology supports heterogeneous environments is essential. Interoperability can sometimes be difficult, and SOA governance standards and specifications are immature in some areas, such as WS-Federation (WS-FED), and nonexistent in others (governance interoperability). Ensuring that your vendor participates in some governance interoperability specification can help ease deployments, especially in best-of-breed situations, where appropriateness can no longer be ignored.

Market Definition/Description

As the SOA governance market matured in 2008, organizations that had been new to the market began to gain a new level of sophistication in the understanding of organizational requirements and vision for SOA deployments. Still, the market for SOA governance is a varied one, with many different types of products providing support for governing the behavior of an SOA. SOA governance is about ensuring and validating that assets and artifacts within the architecture are operating as expected and maintaining a certain level of quality. Now in its second year, this Magic Quadrant reduces the market to one set of technologies with strong architectural cohesion (integration), promoting ease of use and the interoperability of products. This integration includes the idea that multiple personas will be involved in governing an SOA. Each of these personas will bring a different perspective to the process of performing different kinds of tasks. However, all these tasks must be part of a unified governance effort, instead of a different, but related, effort.

To read and download the full report – click here.

Oracle to Buy AmberPoint, Strengthen APM and SOA Governance

Oracle on 8 February 2010, Oracle announced that it has agreed to acquire AmberPoint , SOA Management, Business Transaction Management and run-time Governance software. The deal is likely to close in 1H10.

Acquisition is expected to extend Oracle’s leadership in Fusion Middleware and provide customers with advanced capabilities in SOA Governance and SOA management.  Amberpoint is among leaders in SOA Management mainly to enforce policies that improve security, and to diagnose transactions not only within composite application but also across different applications.

For further reading on AmberPoint’s Governance and Management System click here  and for AmberPoint Express click here.

Extending Service Boundaries to Infrastructure Resources

The article appeared in the MSDN Architecture Journal, Issue #21, Sep 2009.

To download a copy of this edition of the MSDN Architecture Journal, click here.


Extending Service Boundaries to Infrastructure Resources

by Nayan B. Ruparelia and Salim Sheikh

With data centers considering infrastructure resources as service-on- demand resources and amalgamating them with application services, we redefine an SOA service as comprising the server-side application and the infrastructure that hosts it.

The business benefits of this type of architecture are twofold—a reduced infrastructure footprint and a lower cost of service delivery— and are enunciated as follows:

  • Commoditization of services enables true SOA-service rationalization that takes place at the service level, instead of separately at the software and hardware boundaries. This reduces the data-center (or infrastructure) footprint for the business and, thus, provides a more environmentally friendly SOA service at lowered costs.
  • Encapsulation of an SOA service across the hardware-software stack provides a complete measure of return on investment (ROI)—from application to infrastructure. This gives a more transparent, accurate, and rationalized view of the cost of a service and its time-to-market (TTM) cost. These factors drive down the cost of an SOA service, because it allows the business to measure reusability of the SOA service across all tiers of IT and, thereby, create a framework for more efficient use of services.

Problem Statement

Generally, an SOA service comprises applications that serve client (or consumer) applications. The management of infrastructure resources that the service consumes—specifically, in relation to capacity and performance—is left to the engineer to plan and model manually. This means that service demands might not always be met within the required time constraints, if the capacity management is reactive instead of proactive; thus, there is a danger that the infrastructure will act as a bottleneck.

Conversely, infrastructure resources can remain idle should the service demand be below that which is provisioned by capacity planning. This represents a waste of money on unused infrastructure. Furthermore, capacity planning and modeling, when performed properly, can itself be a very costly and time-consuming exercise and would need to be performed regularly in order to track changing SOA-service workloads over time. Therefore, a more efficient and cost-effective solution is needed for designing and implementing SOA services.

In this context, we refer to infrastructure resources as the hardware platform and its related services that are required for hosting the SOA applications, not the ESB.

Proposed Solution

We propose an SOA service that makes up the entire hardware- software stack. We term such an SOA service a “composite service element” that would be provided in a virtualized environment, in order to better provision the resources of the service and measure its resource usage.

The host platform (comprising hardware computing resources such as CPU, RAM, and local storage) as well as the operating system would be provisioned as a virtual machine (VM). The VM, as much as the software that it hosts, can be considered a service; we denote this VM as an SOA service element. Furthermore, the entire hardware-software stack can be virtualized to include the storage (such as SAN and NAS devices), the LAN, and the interfaces to both of these. This means that all of the layers in the architecture that comprise the logic, data- access, and data-storage layers can be virtualized and provisioned as part of a single SOA service.

To address performance, scalability, and availability requirements, the VM can be configured in a cluster to provide both integrity and workload sharing. The number of VMs that are used in the cluster would be defined by orchestration software that would instantiate VMs as needed. Indeed, the resources of the physical computer that hosts the VM would also be provisioned to suit demand.

In addition, virtualization of the storage and the LAN means that these components can be provisioned individually to meet the workload demand. Demand forecasting can be performed by instruments that measure the resource requirements and predict their usage over certain timeframes by using various load-prediction models.1 This demand forecast can then be used to drive workflow- automation software (such as the HP Blade Matrix System) that would provision the virtualized resources to meet the predicted demand.

Service-Element Pattern

A pattern is a solution to a common problem that is documented in a consistent format and used as part of a larger collection.2 We propose the service element as a pattern that is defined by a VM; thus, the SOA-service design pattern comprises the producer application and its virtual host.

Conclusion

In this article, we redefine an SOA service as being composed of the entire hardware-software stack; we refer to this type of service as a composite service element. Furthermore, virtualization is used so that we might be able to provision our SOA service in an efficient and complete manner and with the smallest cost overhead possible. Also, our approach predicts the workload demand and integrates it with workflow-orchestration technologies, so as to automate the provisioning of resources that are used by the composite service element. Apart from a reduction in cost, a benefit of this approach is that it reduces resource consumption in an environmentally friendly manner.

Resources

For additional information, please refer to the blog of the lead author.

References

  1. Andreolini, Mauro, and Sara Casolari. “Load-Prediction Models in Web-Based Systems.” ACM International Conference Proceeding Series. Vol. 180, October 2006.
  2. Erl, Thomas. SOA Design Patterns. Upper Saddle River, NJ: Prentice Hall, 2009. Page 86.

Nayan B. Ruparelia (nayan@acm.org) is an IT Architect at EDS, part of Hewlett Packard’s TSG group.

Salim Sheikh (salim.sheikh@gmail.com) is an Independent Consultant and Enterprise Architect, certified in a number of frameworks including TOGAF, Zachman, COBIT and ITIL. He is also a Certified Process Professional and LEAN/Six Sigma practitioner.

The Business Case for SOA & The Role of NextGen Architects

ABSTRACT

Five years ago, the business case for Service-Oriented Architecture (SOA) didn’t matter. Organizations pursued SOA initiatives based on a desire to achieve ‘competitive advantage’ and ‘agility’ without specifying clear metrics and success criteria. A great deal of time and effort is spent on technology architecture, governance and vendor assessments, which is good, but the fundamental point is that SOA is about business.

 Today’s budgetary environment of doing less with less, coupled with the current economic climate, makes it important for SOA champions to make their business cases for investment compelling and to create and maintain momentum.

What is required is a new generation of architects capable of taking a business-led and multi-disciplinary approach to SOA enabling better Business/IT alignment. Next generation (NextGen) architects are no longer part of an IT department or individual IT projects. NextGen architects are “architects of the business” – organizational resources delivering business-led SOA solutions to directly support new business initiatives, oversee business change, governance and budgetary controls.

This webinar includes advices and recommendations based on actual experiences and successes across a range of Public and Private industries.

FUTHER INFORMATION

Join me on 26 Feb 2010 at 11:00 am (GMT) by clicking here.

This presentation has been postponed. I will provide further updates once a new date/time has been agreed.

Apologies for any inconvenience.