Integrated SOA Governance White Paper

from SOA Software www.soa.com

Many large organizations are reducing costs, improving agility and reducing risk with enterprise SOA programs. In order for SOA initiatives to succeed they need to follow sound Enterprise Architecture practices. Companies realizing the most success are those that have built an Integrated SOA Governance infrastructure that governs a wide range of assets and artifacts through their entire lifecycle.

Integrated SOA Governance helps enterprises:

  • Ensure that services they identify, design and build are relevant and consumable across all distributed and mainframe platforms like Microsoft, SAP and IBM.
  • Make services they expose from applications running on any platform visible to and compliant with enterprise policies defined, enforced and audited across other platforms
  • Promote, ensure and formalize consistent alignment between demand from service consumers and the supply of services through Consumer Contract Provisioning.

In a nutshell SOA Governance is about making sure that the enterprise builds the right things, builds them right, and makes sure that what it has built is behaving right. This breaks down into distinct areas; Planning Governance is about making sure that you are building the right things, Development Governance is about making sure you’re building them right, and Operational Governance is about ensuring that what you’ve built is behaving right.

In the same way that individual platforms could have their own governance solutions, these different governance areas could each have their own policy management solutions. The right approach, however, is to provide a centralized Policy Governance solution that defines, manages, and distributes policies spanning all areas. This ensures consistency of policy across all lifecycle stages and distributed and mainframe platforms.

This whitepaper examines the ideas, objectives and use-cases behind Integrated SOA Governance, and the evolution of the SOA Governance marketplace.

Integrated SOA Governance Defined

Integrated SOA Governance ensures the applicability, integrity and usability of a wide range of assets through all their lifecycle stages from asset identification through deprecation. The full lifecycle is split into planning governance, lifecycle governance, and operational governance.

soa governance framework

Planning Governance – Build the Right Things

Planning governance includes the identification analysis and modeling of candidate services, policies, profiles, processes and information. An effective planning governance tool will manage an organization’s SOA portfolio while examining existing and planned applications and determining which capabilities should be exposed as services, and where applications would benefit from consuming shared services.

Planning Governance is a new area for SOA. It will allow companies to build to plan, and build to priority modeling current and desired architecture and identifying and prioritizing candidate services. Planning Governance solutions will maximize the efficiency of investment in SOA, solidifying the role of existing platforms as foundation service providers.

I.T. has always struggled with balancing long term planning with addressing the immediate and short term needs of the business, in most cases the short term requirements take precedent over long range planning. When this is applied to enterprise architecture, organizations end up with a bunch of services that deliver minimal business value, instead of their goal of SOA.

Planning Governance allows organizations to identify potential services in a planned and managed community including enterprise architects, business analysts and portfolio managers. When utilizing planning governance, services can be proactively built to plan rather than simply reacting and building single use services. This approach reduces the risks of service deployment and facilitates Enterprise Architectural goals by avoiding chaotic service sprawl.

Planning Governance solutions will require integration with a wide range of existing enterprise repositories, application portfolio management, and enterprise architecture planning solutions, to harvest current and desired architectures. The output from the Planning Governance process will be a set of candidate services that feed into the Development Governance process, and candidate policies feeding into the Policy Governance process.

Development Governance – Build Things Right

Development governance marshals an asset through the development process that typically spans the design, development, testing and staging phases of its software development lifecycle. It typically includes a workflow mechanism to approve migration, policy compliance validation, and a clear separation (logically, physically, or both) between lifecycle stages. Development governance is the realm traditionally occupied by registry and repository vendors, although it requires much stronger repository capabilities and much broader integrations with development environments (IDEs and SCMs tools), federation with other registries and much stronger service, standards and taxonomy support than most repositories offer.

The Development Governance solution will depend heavily on Policy Governance for compliance policy definition, management, and validation. It will use policies to determine the relevance, and suitability of services at each lifecycle stage, and to determine if assets meet enterprise standards and guidelines before they can promoted to the next stage of the lifecycle. For example for a service to move from design to development the enterprise may require that there is a design document in the repository, the service has a WSDL, the services is categorized appropriately, and perhaps even that there are registered consumers waiting for the service.

Operational Governance – Ensure What’s Built Behaves Right

Operational Governance controls the runtime aspects of SOA. It typically includes service monitoring, security and management with a runtime policy system. Most Web Services Management and Web Services Security vendors now position themselves as providing Operational Governance solutions.

The Operational Governance solution relies heavily on the Policy Governance solution for discovery of policies for implementation and enforcement. A well architected Operational Governance solution will fully abstract service consumers and providers from the complexity of policy implementation and enforcement, service endpoint location, transport, standards, message exchange pattern, and other impedances to interoperability. It should provide agents, delegates, and a network resident intermediary for service virtualization.

Policy Governance – Uniform Policy for All Governance Areas

Policy Governance defines and manages policies, associates them with various assets, and validates and reports on policy compliance. It manages a wide range of different policy types from metadata compliance policies applied in Planning and Development Governance processes through security, reliability, and service-level policies applied through an Operational Governance solution.

It is critical that the Policy Governance solution ensures consistent policy definition, implementation, enforcement, validation, and audit through all stages of the lifecycle, and across all distributed and mainframe platforms.

Governance Evolution

SOA Governance has become an overused term, with claimed governance solutions ranging from simple registry products and Web services management products, to comprehensive infrastructure solutions. In some cases ESB vendors are positioning their products as governance tools.

The simple fact is that SOA Governance covers a wide range of technical and organizational areas. An Integrated SOA Governance solution needs to address all the facets of SOA Governance while providing tools that simplify participation in the governance process for developers, architects, business analysts, operations and security teams.

As recently as 2006, many vendors offered standalone products for registry, repository, management, and security. Through 2006 and 2007 the market has evolved and customers now require Integrated SOA Governance solutions that combine products into a single infrastructure solution that provides a unified user experience model for policy-based service governance, asset management, operational security, and operational management.

SOA governance evolution

Enterprise customers are no longer satisfied with web services management products, SOA registry products, asset repositories, and XML security products from separate vendors. Enterprise customers are now looking for a unified solution that combines mature, standards-based infrastructure components into an Integrated SOA Governance platform. This approach mirrors SOA Software’s Integrated SOA Governance reference model, first published in 2005.

Integrated SOA Governance includes compliance policy and service lifecycle governance functions. This ensures that service designs and documentation comply with enterprise design policies and industry standards, and that approvals and workflow support SOA service publishing and discovery. It includes operational governance functions such as run-time policy management, enforcement, and compliance audit. Integrated SOA Governance capabilities deliver high value in the shared surface area between design-time SOA lifecycle governance and run-time SOA operations governance.

Over the last few years, there have been significant changes in the way customers view SOA Governance solutions, and the way vendors deliver products. We have seen the market evolve from one with separate vendors delivering stand-alone registry products, repositories, SOA management solutions and compliance products to one that now expects to see unified product suites that offer a superset of the functions from each of the stand-alone product areas

Integrated SOA Governance Best Practices

Integrated SOA Governance promotes the core SOA governance best practices of:

Governance Automation

Governance Automation ensures scalability of enterprise processes implementing a lifecycle management workflow to implement development approval processes, integrated provisioning and lifecycle management, and inter-departmental contract management and negotiation.

Uniform Policy Management

Uniform Policy Management ensures consistent policy definition, implementation, enforcement, validation, and audit through all stages of the lifecycle, and across all distributed and mainframe platforms. It ensures that services can be leveraged as first-class citizens throughout an enterprise SOA by complying with enterprise policies that are uniform across all platforms.

Metadata Federation

Metadata Federation provides seamless, heterogeneous SOA Governance and standards-based support for governance automation (UDDIv3, WS-MEX, WS-Policy) to ensure that governance processes are uniformly applied across all platform investments. When metadata is federated and consistent across multiple governance platforms, the business value of service (cost, usage, production issues) becomes visible and measurable across the enterprise service lifecycle.

Service Virtualization

Service Virtualization provides location-transparency, service mobility, impedance tolerance and reliable service delivery without requiring a re-platforming of existing platforms or introducing yet another service platform to support the required solution architecture.

Trust and Management Mediation

Trust and Management Mediation ensures interoperability across disparate partners and platforms, trust enablement and trust mediation complementing threat prevention systems. It provides provide last-mile security, metric collection and reporting, SLA monitoring and management, to ensure that services are governed, managed, and secured, and policy implementation and mediation to allow consumers to communicate with a wide range of mission critical business services exposed from any platform.

Continuous Compliance and Validation

Continuous Compliance and Validation ensures consistent policy implementation and enforcement across all stages of the lifecycle, preserving the fidelity of the governance models, structures and mechanisms supporting enterprise SOA programs and ensure the relevance, applicability and suitability of services.

Change Impact Mitigation

Change Impact Mitigation provides change management and impact analysis processes integrated with the governance workflow to ensure that changes to services or other assets don’t cause major outages by breaking the consumption model.

Consumer Contract Provisioning

Consumer Contract Provisioning provides offer, request, negotiation and approval workflows for service access, capacity, SLA and policy contracts. It ensures that the service provides know which applications and users are consuming their services and allows them to treat different consumers with different priorities and service levels.

Platform Independent Governance Automation

Much of the benefit of SOA is derived from the promise of seamless interoperability between platforms, with applications built using .NET and WCF consumer services exposed from COTS, Mainframe, or Java applications. One of the core goals of SOA Governance is to ensure that services are relevant and consumable between platforms. As such it makes no sense to leverage governance capabilities built into the platforms themselves, as this simple promotes silos of services within platform domains.

Platform Governance Models

Not all platforms are governable; in fact platforms fall into one of 3 categories:

  • Ungoverned Platforms – the purest form of Informal Governance. This often results in “Random SOA” or “Accidental SOA”. This includes any container that doesn’t support policy enforcement natively or with an agent
  • Self-Governed Platforms – a mixture of Formal and Informal. Some tasks and activities are governed, some are not. SOA Governance is as weak as the weakest link in the chain. This category includes containers that use their own tooling without policy integration with a centralized enterprise SOA Governance solution.
  • Governed Platforms – a real or virtual organization exists that is devoted to the promotion of SOA programs and causes that is accepted as a fundamental part of an SOA culture. Governed Service Platforms have:
  • Clear job titles / responsibility support SOA Governance activities
  • Supports clear separation between implementation activities and governance activities
  • Provides standards-based governance integration interfaces

Integrated SOA Governance solutions integrate seamlessly with the platforms providing varying degrees of configuration, policy implementation and enforcement, message handling, and workflow support, largely depending on the level of sophistication of the platform itself.

SOA governance platform

We divide governed platforms into two categories:

Governed Service Platforms

All applications that expose and consume services at runtime are service platforms. These include application services like IBM WebSphere, Microsoft IIS, Oracle/BEA WebLogic, JBoss and others; ESBs from vendors including IBM, Microsoft Oracle/BEA, JBoss, TIBCO and others; mainframe applications running in CICS and IMS; COTS applications like CICS; and SaaS environments like Salesforce.com and Amazon.

As described above, Governed Service Platforms offer standards-based governance integration interfaces, and support the concepts of governance by an external enterprise governance system.

Governed Development Platforms

Most platform vendors provide an integrated development environment (IDE), source code management and version control system, defect tracking/change request tooling, and in many cases, a document management and/or asset management repository. An Integrated SOA Governance solution can provide asset lifecycle management and policy compliance capabilities to ensure that developed software assets (such as services, components and applications) are appropriate and relevant to the enterprise, and that they comply with applicable policies.

Governed Development Platform status means that the development platform integrates with an Integrated SOA Governance solution to make and share decisions about assets and artifacts.

Integrated SOA Governance Use Cases

This section examines some common SOA Governance use-cases ranging from simple service publishing and discovery, through consumer contract negotiation, lifecycle management workflow, contextual collaboration, and folksonomy creation.

Service Publishing (Approvals Workflow)

The act of publishing a service to a registry so that it can be found by a broad audience of interested parties may seem like a simple enough task. In fact, this is one of the most basic, and yet most important functions of an SOA Governance solution.

The essence of governance can be easily captured in the phrase “encouraging desired behavior.” This simple concept provides a backdrop to help understand what a governance solution should be focusing on, and the capabilities it should provide. Essentially it is not enough to merely provide a stick with which to beat developers and architects, we must also provide a carrot to encourage people to participate in governance processes.

With this in mind, we need to think about what is the desired behavior for the participants in an SOA. For many organizations, one of the most important aspects of SOA Governance is the process of ensuring that the services that are published are appropriate. “Appropriate” in this context is another word a little like “desired.” It can mean many things, but the reality is that an “appropriate” service is a service that meets a set of criteria defined by the enterprise, often including the following:

  • Is not a duplicate of, or similar to an existing service
  • Meets design criteria for transport, operation type, schema, etc
  • Is at an appropriate level of business functionality granularity (e.g. a ‘top-down’ design rather than ‘bottoms-up’)
  • Is of broad interest and therefore likely to be reused
  • Complies with appropriate industry standards and recommendation (e.g. WS-I basic profile)

Some of these criteria can be readily automated like WS-I basic profile compliance, other will likely require manual steps. To this end, before a service can be published it should pass through a workflow process that will verify the automatable criteria before requiring a manual approval step. A well designed SOA Governance solution will manage this workflow as a series of customizable, automatable defined process steps and will allow developers and approvers to see services at appropriate phases of this process.

Service Discovery

Service discovery is a slightly overloaded term. It can mean different things:

Deployed Service Discovery

The governance, security and management infrastructure should be able to identify services that are deployed in managed containers. This will ensure that any deployed service will at the very least be a known quantity. Ideally all services should be identified at an early stage in the development lifecycle to avoid any deployment “surprises.” However realistically, some services may not be identified. Therefore, it is important to be aware of all deployed services, and if necessary, automatically register, manage and secure these services while notifying administrators of their discovery.

Developer Service Discovery

An important facet of a governance solution is the ability to provide mechanisms for potential users of services (developers) to search for and find services they would like to use. It is this discovery process that led simple UDDI registry providers to classify themselves as governance vendors.

The importance of true governance in this service discovery process is in ensuring that only authorized users can discover services. This can apply to services in certain taxonomies, organizations, states of lifecycle stages as well as other customized criteria.

Service Lifecycle Management

Services, like all other development assets and applications have their own lifecycle and as such need to be managed through their lifecycle state transitions. Service lifecycle generally models a typical SDLC with stages including design, development, test, QA, production, and deprecation. Many organizations will add versioning into the process between production and deprecation, although in reality each new version of a service will have its own lifecycle.

An SOA Governance product must be able to manage the lifecycle stage of a service and should provide a workflow-based process for migrating services between stages. Often this process will closely mirror the original publication process described above. It will include a set of policies that define criteria a service must meet before it can be migrated. It will also in many cases include manual approval steps.

The lifecycle stage of a service should be used to determine who can discover the service in the registry and who can access the service at run-time. It should also define which policy set is used to determine the run-time capabilities and requirements for accessing the service.

Consumer Contract Negotiation

The idea of a consumer contract for SOA closely models the idea of a business contract. It defines the terms of a relationship between a consumer, or group of consumers, and a service, or set of services. These terms should include:

  • The policies the consumer(s) agree to comply with
  • The access rights the service(s) will provide the consumer(s)
  • The service levels the provider commits to delivering to the consumer(s)
  • Any mediation the provider(s) and consumer(s) agree to and require

The SOA Governance solution has two important roles to play in the contract process:

    1. Contract negotiation – the Governance solution should provide a workflow model allowing potential consumers to interact with service providers to request and negotiate access to, and specific service levels for, a service or set of services.
    2. Contract enforcement – the Governance solution should enforce the contract at run-time. It should seamlessly ensure that the provider meets agreed upon service levels, that any required mediations are delivered, that the consumer(s) are complying with required policies and that the access rights and times are enforced and complied with.

Compliance policy validation

One of the important decision points in the lifecycle workflow is an asset’s compliance with defined enterprise policies. For example, an organization might require that a service have a design document, a description, be properly categorized, and have a defined business case before it can be promoted from the design stage to the development stage of the lifecycle. The SOA lifecycle governance automation system needs to provide an easy way to define and manage compliance policies and associate these policies with lifecycle stages, categories, and other taxonomy or folksonomy structures and types.

Change management notification

Change management notification addresses several different issues. Clearly any complete lifecycle governance has to include a notification model so that submitters and approvers know that action is required, or that a state change has occurred. Also, in SOA governance, there is likely to be a varied constituency interested in the state and stages changes of assets. A simple example is that the group of consumers using a service in production will want to know that there is a new version of the service available and that the current version will be deprecated within a defined timeframe.

Lifecycle stage isolation

Depending on the nature of the process and the requirements of the various lifecycle stages there are different ways of isolating the stages. Some organizations will want to leverage a single registry/repository instance using object-based security to ensure that only users in authorized roles can see assets at various stages of their lifecycle. Other organizations will want to ensure physical isolation between assets in different lifecycle stages. The emerging best practice is a mixed-mode approach. It uses a single registry/repository instance for early lifecycle stages where there is considerable fluidity in lifecycle stage, with physically separate instances for later lifecycle stages to mirror the physical environment.

Contextual Collaboration

If publishing approvals, lifecycle policy, and contract enforcement are the sticks in SOA Governance, then contextual collaboration is one of the carrots.

As architects, developers and other SOA program constituents engage in the communication, promotion and transformation that come with SOA, they will have many questions about the various processes and policies in place. Contextual collaboration capabilities within an Integrated SOA Governance solution allow users to ask questions in the context of a specific asset (service, policy, schema, contract, etc.) and engage others in an ad-hoc collaboration model. It provides a searchable resource for users to quickly ramp-up the requisite subject matter expertise they need to participate effectively in the enterprise SOA program.

Folksonomy Management

A folksonomy is a socially-created tagging model, like del.ico.us, or YouTube. In the SOA context this means providing a model that allows users to tag services and assets with their own keywords and then pivot the search model around these tags, i.e. follow a tag to see which other services and assets are similarly tagged.

This idea may seem very “web 2.0”, and it is. It offers enormous value, essentially allowing the SOA community within the enterprise to add value to the governance framework creating a social network for SOA.

Integrated SOA Governance Solutions

The discussion above provides a high-level, abstract definition of Integrated SOA Governance. Here we take a more practical look at what constitutes actual deployed SOA Governance solutions, and perhaps more importantly the solutions that categorize themselves as SOA Governance and fall short.

Registry/Repository SOA Governance

In the early days of SOA Governance, the UDDI registry vendors classified themselves as SOA Governance solutions. Often they added weak, email-based migration capabilities to their products to claim approvals workflow to partially deliver one of the use-cases described above.

Over time the registry vendors have added repository capabilities to their products and have begun to offer more governance features.

The main challenge facing the registry players is that they have minimal run-time enforcement capabilities. (See the closed-loop governance discussion below.)

SOA Management ≠ SOA Governance

As SOA Governance has gained popularity and enterprise customers identify SOA Governance projects and budgets, the SOA Management vendors have begun to try to compete in this space. Many of these vendors have attempted to position their run-time monitoring solutions as SOA Governance solutions. Most of these offerings do not begin to qualify as SOA Governance solutions. They do not offer complete standards-based registry and repository capabilities, unified management of policy, or any advanced governance use-cases such as those described above.

ESB ≠ SOA Governance

Following the same market dynamic as the SOA Management vendors, the ESB vendors are also jumping on the SOA Governance bandwagon. In addition to the lack of design-time governance capabilities they share with the SOA Management vendors, the ESB vendors drive their customers to re-platform their SOA onto the ESB and their associated application server environment. Consequently, they have the problem of being proprietary, closed environments with no ability to monitor, secure, or manage a complex, heterogeneous, enterprise SOA.

Closed-loop SOA Governance System = Integrated SOA Governance Automation

Integrated solutions bring together registry, repository, security, management and mediation capabilities to deliver true enterprise SOA governance.

The following section of this document expands on the ideas of Integrated SOA Governance Automation.

Integrated SOA Governance Automation

The diagram below shows the relationships between SOA registry/repository, security and management, demonstrating how SOA Policy Management forms a closed-loop of policy, metrics, and audit.

SOA governance automation

The alternative to a closed-loop solution is a set of stand-alone applications for governance, management and security. These solutions may offer loose integration, but we have yet to identify a single organization that has successfully integrated stand-alone solutions in a production environment.

A standalone SOA Governance product can define and enforce policies for design-time compliance, ensuring that services meet policies describing static attributes (typically directly associated with the WSDL or the registry taxonomies). It can also define run-time policies but it has no way of knowing if these policies are being enforced by a run-time platform, or even if these policies are visible to any run-time platform. This is a “define and hope” model of governance, where an administrator defines a policy in a governance product and then hopes that this policy is enforced.

Similarly, a standalone SOA run-time security and management solution will enforce policies at run-time, but these policies will be locally defined and will not be subject to centralized governance. This is the “ready, fire, aim” model of policy enforcement, where the enterprise has no understanding of the policies that are being enforced.

soa run time model

In the rare instances where a standalone SOA Governance solution is integrated with a standalone SOA run-time security and management solution, the run-time system may be able to discover policies from a policy governance solution. However, it will not have any mechanism to report the actual enforcement of these policies to the governance system. In this case, the policy governance system still has no knowledge of whether its policies are being enforced, and no information about how the services themselves are actually behaving.

Integrated SOA Governance Value Add

Stand-alone run-time solutions don't deliver higher value design-time, or governance capabilities. They require their own policy management, don’t offer developer or architect services, and have no understanding of the relationship between a provider and a consumer.

On the other hand, governance solutions can only deliver value when they are built on a run-time foundation. They require a run-time solution to enforce policies; they need the run-time to provide statistics and metrics for demand, capacity, and value monitoring; and they also need the run-time to provide an audit trail to ensure that messages comply with defined policies.

Integrated means:

  • Defining and managing actionable policies in a policy governance solution throughout the lifecycle
  • Enforcing these policies via deep integration with an operational governance solution at run-time
  • Auditing that these policies are being enforced
  • Using industry standards (WS-Policy, WS-MEX) where appropriate for information exchange

Integrated Closed-loop SOA Governance solutions enable demand and value management. Because the governance system has real-world information about how services are actually being used it allows organizations to:

  • Use live, audited information to drive value-based decisions about the effectiveness of different services and organizations
  • Provide developers with up to the minute information about a service in run-time to inform their decisions about which services to use
  • Manage supply and demand to ensure maximum efficiency and benefit from SOA

SOA Infrastructure Reference Model

SOA Infrastructure is the set of tools and technologies that an organization deploys to secure and manage services and service-oriented business applications. It provides the delivery mechanism for a comprehensive governance solution including Registry, Repository, Management, and Security services, and intermediaries to ensure the application and use of these services.

 

soa reference model, soa framework, soa reference framework

The SOA Infrastructure reference model shown above is published by SOA Software, the leading provider of SOA Infrastructure software products. It provides a product and vendor agnostic view of the concepts, components and standards that make up a successful SOA Infrastructure. For more information see SOA Software’s whitepaper – “The SOA Infrastructure Reference Model,” published in May 2006.

Integrated SOA Governance System Elements:

The core elements of the Integrated SOA Governance system are the Registry, Repository, Policy Management System, Virtualization System, Management and Security System, and their associated intermediaries. Also, as described above, governance products and systems not having deep integration between these elements would offer minimal value to an SOA implementation.

SOA Repository

The SOA Repository provides a solution for the governance of development assets and artifacts. Governance in this context includes registration, lifecycle management, run-time and design-time policy management, and business value visibility. The repository implements registry standards for metadata exchange. It is the main source of SOA information for end users and applications.

SOA Policy Management System

The SOA Policy Management System provides a framework for defining and managing policies that are enforced throughout the planning, lifecycle, and operational governance processes. It ensures that policies are applied uniformly across all governed and governable platforms.

SOA Registry

The SOA Registry supports the categorization, classification, tagging, and publication of services. It provides browse and search interfaces for service discovery, a publication interface for service registration, and a subscription interface for synchronization with other registries and repositories.

SOA Management System

An SOA Management solution monitors and manages the reliability, availability and performance of services.

System

An SOA Security solution provides service and message security capabilities including authentication (identity assertion and token exchange), authorization, privacy, non-repudiation and audit.

SOA Intermediaries

SOA intermediaries exist in a number of forms, the most important of which are stand-alone (proxy/router), and agent (embedded in container). Intermediaries enforce and implement policy for Management and Security solutions. The primary role of the agent intermediary is to ensure last-mile policy enforcement, while the primary role of the stand-alone intermediary is to provide service virtualization to isolate consumers from service location, policy, implementation, and change.

SOA Software’s Integrated SOA Governance Solution

SOA Software builds its Integrated SOA Governance solution around its Policy Manager™, Repository Manager™, and Service Manager™ products for SOA Policy Governance, Development Governance, and Operational Governance.

soa solution framework, soa architecture framework

SOA Software’s Repository Manager™, Policy Manager™, and Service Manager™ combine to form a comprehensive Integrated SOA Governance Automation solution.

Repository Manager provides a platform-independent SOA asset management and metadata federation solution. It governs leading development platforms, ensuring consistent definition and management of services and other assets across all development environments.

Policy Manager provides a comprehensive SOA Policy Governance solution, and extends it adding powerful governance automation capabilities. Governance automation minimizes the overhead associated with governance processes, and turns governance from a painful workload into a productivity tool.

Service Manager automatically implements and enforces policies from Policy Manager for Services in Repository Manager. It generates usage, performance and policy compliance metrics that it reports to Policy Manager so that it can audit that policies are being enforced through a closed-loop process.

Using this solution architects, developers, security administrators, and operations managers can define and govern policies that are applied to services throughout the appropriate stages of their lifecycle.

About SOA Software

The world’s largest companies including Merrill Lynch, Verizon, and Pfizer use SOA Software to quickly and safely realize the value of SOA. SOA Software’s platform-independent Integrated SOA Governance and Mainframe SOA products process over 500 million mission critical transactions per month, ensuring the relevance, security, reliability, and performance of services and applications. For more information, please visit http://www.soa.com

SOA Software, Policy Manager, Repository Manager, Service Manager, and SOLA are trademarks of SOA Software, Inc. All other product and company names herein may be trademarks and/or registered trademarks of their registered owners.

SOA Software, Inc.

12100 Wilshire Blvd, Suite 1800

Los Angeles, CA 90025

866-SOA-9876

www.soa.com

This e-mail address is being protected from spambots, you need JavaScript enabled to view it

Copyright © 2007 by SOA Software, Inc.

 
SOA Governance is hot

 

SOA Software Acquires LogicLibrary

 

Combines SOA Governance Leaders to create a dominant Integrated SOA Governance Automation Solution

 

Los Angeles, Calif., May 12th, 2008SOA Software, a leading Integrated SOA Governance Automation vendor, today announced that it has acquired LogicLibrary, a leading SOA Repository and Governance vendor. This acquisition combines two recognized leaders, creating a dominant SOA Governance company with an impressive customer base.

soa software acquires logiclibrary, soa, service oriented architecture, soa governance, integrated governance

SOA Software is positioned by Gartner, Inc. in the leader’s quadrant of the “Magic Quadrant for Integrated SOA Governance Technology Sets, 2007” [1] report. The Magic Quadrant for Integrated SOA Governance Technology Sets evaluated 18 vendors and summarizes the state of the market for SOA Governance. The company focuses on SOA Policy Governance and SOA Operational Governance with strong registry, policy management, and service management capabilities.

Forrester Research ranks LogicLibrary as a leader in The Forrester Wave: SOA Service Life-Cycle Management Q1 2008 [2]. Forrester states that LogicLibrary provides a broad and comprehensive set of features with the strongest reporting and analytics capability. LogicLibrary focuses on SOA Development Governance with a best-of-breed enterprise repository providing broad support and governance for development assets /services and deep integration and federation with IDEs and application development point solutions.

The combination of the two companies creates the most comprehensive Integrated SOA Governance Automation solution that spans all lifecycle stages and governance types from Planning to Development, Policy, and through Operational Governance. This allows enterprises to accelerate their full adoption of SOA with the rapid delivery of relevant consumable services for distributed and mainframe environments. The discipline of SOA can deliver great cost, agility, and risk management benefits, but with these benefits come a set of challenges imploring the enterprise to make the “right” SOA architecture and governance decisions. This coupled with the rapid maturing of the enterprise SOA environment has driven companies to demand a comprehensive solution for all of their SOA Governance needs.

“We are able to strengthen our company with the addition of LogicLibrary’s complementary technology, team and customers,” said Paul Gigg, president and chief executive officer of SOA Software. “This acquisition combined with our ability to continue to drive product innovation extends our leadership in the Integrated SOA Governance Automation market and makes SOA Software the strongest candidate to succeed as the platform-independent leader in this fast growing market. Now customers have a clear choice for governance across all assets, lifecycle stages, and constituencies that span distributed and mainframe environments”

With enterprise applications and service platforms from companies like IBM, Microsoft and SAP offering built-in platform-optimized governance capabilities it is essential that companies have an enterprise wide SOA Governance solution so that they can be confident that their platforms won’t compromise the fidelity of the governance systems and structures defined in an enterprise SOA program. The addition of LogicLibrary’s technology extends SOA Software’s integration capabilities across Governed Development Platforms (such as IBM, Microsoft and Open Source) as well as Governed Service Platforms (such as IBM, JBoss, Microsoft, and SAP). SOA Software’s platform-independent Integrated SOA Governance Automation solution and Governed Service Platform certification processes ensure that Governed Service Platforms can implement and enforce governance policies proving reporting data to enable a closed-loop audit process.

“The combination of SOA Software’s governance products, with LogicLibrary’s strategy to provide federation with other leading repositories, creates a single solution that provides unparalleled lifecycle and policy governance across all major platforms,” said Alan Himler, chief executive officer and chairman of LogicLibrary. “We are excited to join forces and capitalize on our complementary capabilities by creating the most comprehensive, closed-loop Integrated SOA Governance Automation solution.”

[1] Gartner, Inc. “Magic Quadrant for Integrated SOA Governance Technology Sets, 2007” by L. Frank Kenney, Daryl C. Plummer, December 31st 2007.
[2] The Forrester Wave: SOA Service Life-Cycle Management, Q1 2008 by Larry Fulton.

About the Magic Quadrant
The Magic Quadrant is copyrighted December 31st, 2007 by Gartner, Inc. and is reused with permission. The Magic Quadrant is a graphical representation of a marketplace at and for a specific time period. It depicts Gartner’s analysis of how certain vendors measure against criteria for that marketplace, as defined by Gartner. Gartner does not endorse any vendor, product or service depicted in the Magic Quadrant, and does not advise technology users to select only those vendors placed in the “Leaders” quadrant. The Magic Quadrant is intended solely as a research tool, and is not meant to be a specific guide to action. Gartner disclaims all warranties, express or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

About SOA Software
SOA Software is a leading provider of comprehensive integrated SOA Governance and Mainframe SOA solutions. With a full suite of mature and market-proven products, SOA Software helps enterprises accelerate the full adoption of SOA through all stages of the enterprise lifecycle. SOA Software products provide a comprehensive closed-loop SOA governance solution (Workbench), a strong federation capable SOA repository management solution (Logidex), a high-performance, scalable SOA security, mediation, and management solution (Service Manager), and a mainframe SOA solution for CICS applications (SOLA). SOA Software products process over 500 million mission critical transactions a month and are used by the largest Fortune 1000 corporations, including Merrill Lynch, Verizon, and Pfizer. For more information, please visit http://www.soa.com

SOA Software, Workbench, Logidex, Service Manager, and SOLA are trademarks of SOA Software, Inc. All other product and company names herein may be trademarks and/or registered trademarks of their registered owners.
 
Business Case for SOA PDF Print E-mail

SOA

Service-oriented architecture (SOA) is gaining momentum and companies worldwide are turning to the promise of agility and interoperability a SOA strategy can deliver. As a professional software developer, a thorough understanding of the benefits a SOA approach can deliver is critical – helping you examine when and where a SOA is appropriate and how to build a business-case for SOA in your organization when the time is right. In this paper, we take an objective look at the benefits of SOA, as well as the costs and risks of this architectural approach, and arm you with a list of key questions that will help you determine if SOA makes sense for your project.

The SOA model, leveraging the power of Web services and service orientated development, has captured the attention of organizations worldwide with its promise of interoperability between legacy systems and new applications, and IT decision-makers are turning to this promising technology to enable their business applications to adapt to customer needs and market changes over time. In March 2004, Westbridge Technologies released the results of a survey of 273 Global 1000 and public sector institutions showing that 43 percent of respondents are structuring their development roadmaps to use SOA principals.

More recently it was reported that many companies of all sizes have already adopted SOA or have it on their radar for 2005, according to a report from Forrester Research Inc., in which 116 North American corporate decision makers were surveyed. The Cambridge, Mass.-based research firm found that more than 70% of large enterprises, 28% of medium-sized enterprises and 22% of small to midsized businesses (SMBs) are using SOA today. When factoring in those firms expecting to adopt SOA by year's end, the numbers soar to 89%, 61% and 40%, respectively. Survey respondents diverged on a number of issues related to how they use SOA. They primarily used SOA for internal integration (37%) and much less for external integration (15%). They also used SOA for multi-channel applications (9%) and strategic business transformation (9%).

So, what exactly is SOA and how does it compare to traditional architectures? SOA isn’t contrary to object-oriented (OO) architectures. Rather, SOA can be viewed as “macro” OO because both models are based on the same key principles. OO introduced the concept of encapsulation – hiding the implementation details of an object behind a well-defined interface. However, in OO, what an object does (its functionality or behavior) is intrinsically tied to the data itself. Over time, professional developers recognized the limitations of this approach and envisioned an alternative in which behavior could be duplicated and evolved outside of data over time. This vision led to the evolution of SOA, an approach where each coherent piece of business logic is split into a specific service at the design stage. Each service isolates behavior from data and has little knowledge of other services beyond what functionality they provide, making it significantly easier to deal with change and delivering agility, reusability, and integration at the business level. The SOA project lifecycle also differs from that of a traditional application. In contrast to a traditional application, building a service-oriented application requires considerably more discipline and upfront focus on the application design. Skilled architects must think through the best approach to solving the business problem, the most beneficial way to partition functionality into services and the ideal coupling of these services into a working application. This increased focus on the design phase of the project means that it will likely take more time and resources to deliver the first version of a serviceoriented application. However, the rapid integration and reusability benefits gained by making this initial investment mean that future enhancements to the SOA application can be delivered faster and with less risk and cost.

Business Case for SOA

While SOA promises agility and a number of other benefits, it is important to look at the full picture, including any trade-offs you will need to make to achieve these benefits. In this section, we’ll take a closer look at the benefits of SOA as well as the costs and risks involved in using this approach to application development.

Benefits of SOA

SOA is gaining momentum because it offers substantial benefits to organizations, including:

- Business agility

- Interoperability with enterprise systems

- Deployment flexibility

- Reusability

- Phased rollout

- Improved end-user experience

Let’s examine each of these benefits in more detail.

Business Agility

By increasing the focus on the design phase of the project, SOA leads to better application design and better design leads to business agility. In contrast to traditional applications, the solid design of SOA applications makes it considerably easier and more efficient to enhance, modify, and extend functionality as needs change over time. Because SOA applications are designed from the start for change, software development teams can adapt them to meet new business requirements in days or weeks rather than in months or years.

With SOA, it is very straightforward to add a new service to enhance your business process or to modify the flow of information between services to reflect a change in work flow. For instance, many organizations today are faced with an increasing barrage of regulatory issues such as meeting Sarbannes-Oxley requirements. This climate is causing constant adjustments in day-to-day processes and controls. As an example, assume that a “hole” in an order-entry process is discovered, requiring an additional audit/approval step prior to shipping a product. Using SOA, the solution can be as simple as inserting one additional notification/approval “node” into the current process, fully addressing the new requirement.

Interoperability with enterprise systems

The purpose of any SOA implementation is to “tie together” existing legacy and new software assets. Organizations can no longer afford the “total rewrite” approach popular in the 1990s, yet they must adapt to constant changes in the competitive and business landscape. SOA offers a unique ability to support this capability. Several technologies exist to interoperate with legacy enterprise systems, including:

Web services exposed by most popular packaged software vendors (e.g., SAP, Oracle Financials, Peoplesoft, etc.). With the rapid expansion of such published interfaces, it becomes increasingly easy to adapt new business processes that incorporate functionality from installed applications. For example, a customer look-up to an ERP application can be used in a SOA-enabled business process design to enable validation and follow-up of sales leads. Several existing tools enable Web services access to legacy applications, including those that run on IBM mainframes, iSeries, and other mid-sized computing platforms. In many cases, programmatic APIs allow legacy developers to expose functionality directly as Web services; in others, intelligent “screen scraping” can be used to expose services via terminal emulation. While direct access is often more efficient, terminal access is the least invasive, and guaranteed to conform to existing application functionality and established security requirements.

Deployment flexibility

Another key benefit of SOA is deployment flexibility, the technical counterpart to business agility. In the SOA model, what the application does is separate from how it is deployed. Optimally, functionality decisions and deployment decisions are almost completely unrelated. This means that developers can code and test on a single machine and deploy on an army of machines without changing code. There’s no need to go back to the development drawing board if deployment requirements change – the services can be adapted “in the wild.” With the advent of the SOA model, vendors have delivered a host of tools to improve the efficiency of service-oriented development. These tools handle many of the complex infrastructure issues that developers had to deal with directly in earlier models, including:

- Message creation and decomposition (understanding the message)

- Message and user authentication and validation

- Message transmission (networking, HTTP, queues, enterprise service bus, etc.)

- Service location management

Because they handle these details, SOA development tools make it very straightforward for developers to deal with technical requirements that frequently occur over the lifecycle of the application such as new hardware platforms, methods of accessing data or load requirements. For example, developers can easily move specific services to new Linux-based hardware or scale the application to handle a 25% increase in users.

Reusability

Re-use can’t be an afterthought – it must be built into a project from the start. To achieve re-use, development teams must consider issues that could hinder reusability during the design phase of the project. The SOA model emphasizes solid application design, and this focus on the design phase means that development teams can take the time to consider issues that will affect reuse. In addition, the use of services enables developers to take advantage of legacy applications, which may house core data and system functionality, but can’t be leveraged in building new applications unless they are exposed as services. The ability to reuse core logic and functionality within legacy applications saves a good deal of time and cost in building new applications that work cooperatively with legacy systems.

Phased rollout

Because SOA applications are modular, they can be developed and deployed in a series of small steps. Rather than postponing deployment until the full feature set is completed, organizations can use a phased approach to deployment, rolling out discrete pieces of functionality as they are finalized. This modular method helps companies bring new services online rapidly, reducing the time to market for even complex projects. For example, consider a call-center application designed to improve efficiency of call-routing and response times. Rather than re-write the entire application, such an organization can start with a single phase of the project, such as caller identification and matching to an existing customer record. Based on this information, the call can be more effectively directed to the right agent, after which the remainder of the process can continue to depend on the existing application functionality.

Improved end-user experience

By delivering business agility and the option to roll out functionality in phases, SOA applications can provide a better experience for end users. With the SOA approach, development teams can quickly deliver enhancements to help ensure that the application closely mirrors the business process as it evolves throughout the lifecycle of the application. In turn, this helps end users of the SOA application do their jobs better and more productively. Why? Because they have access to tools that automate the business process as it exists today rather than having to manually work around a tool that doesn’t support the latest work flow. Many organizations use the “swivel desk” approach to application integration, meaning that a customer service representative must switch between two or more applications in order to handle a customer request. This is common in telecom environments, especially considering the rapid amount of industry consolidation, forcing the use of multiple disparate applications by a single end user. Using SOA tools, developers can create a single work flow for the end user, spanning several distinct applications to provide a unified user experience. This “composite application” paradigm is not new to SOA, but SOA assists in making such capabilities far easier to develop and deliver.

SOA cost and risks

While it’s clear that SOA offers a number of valuable benefits, it’s important to balance the discussion by examining some of the key costs and risks associated with moving to SOA. These include:

- Increased reliance on developer tools and infrastructure

- Higher design costs

- Speed-to-market sacrifice

- New development frontier

- Performance considerations

Let’s examine each of these costs and risks in more detail.

Increased reliance on development tools and infrastructure

In preparing for a SOA environment, many architects quickly come to understand that the efficiency and speed at which a SOA is designed and built relies heavily on the planning and selection of the tools supplied to the development team. The limitations of these tools will inherently affect your SOA design requirements – just as tools engineered to reinforce best practices in design will help preserve your infrastructure standards and extend the longevity, functionality, and flexibility of your SOA. In choosing tools upfront for SOA implementation, it is important to note:

Tools that reinforce good design principles are worth the upfront investment, both to extend the life and usefulness of your SOA and to eliminate the need to spend valuable time writing the infrastructure for your SOA.

Services platform and development tools are much more important in a SOA than in traditional architecture; they play a critical role for the duration of a SOA project development and deployment where transitions are more gradual and done in phases to accommodate a more flexible timeframe and where variables and limitations need to be defined prior to building your application.

SOA development tools can handle much of the infrastructure needs for your organization – which means they can make or break your application. If you clearly understand what tools can and can’t do, you can select tools that meet your project requirements and avoid re-tooling later as your business requirements change.

Higher design costs

A successful SOA deployment relies on a sound and well-thought out approach to application design and construction. It demands attention to detail in areas that developers have not always had the forethought to incorporate. Because flexibility and adaptability to business requirements is the key goal of SOA, applications must be designed to weather change as efficiently as possible. This precipitates the ongoing involvement of the software architect in the early planning and building of a SOA project. These are duties that can’t be offloaded to development resources who do not understand the organization’s business requirements intimately. As you may imagine, the need for these highly-skilled senior architects and professional developers can cause the initial release of a SOA application to be more costly than non-SOA designs. However, this upfront effort will often save money over the life of the application as requirements can be more readily incorporated to meet future needs, and, can greatly ease the maintenance, upkeep, and integration demands often thrust on developers down the road.

Speed-to-market sacrifice

With an increased focus on design and infrastructure, it is not unusual for the first release of a SOAapplication to take additional time to reach the market. As it takes longer to design and architect an application to adapt to change over the life of your business and account for various variables and limitations in your processes, the initial release of a traditional application may be delivered faster than the initial release of a service-based application. That said, as noted above, the likelihood that this time will be made–up over the life of the application is high, and the investment in the initial design of the application will allow for less time-consuming and more efficient modifications and extensibility in the future.

Where additional time-to-market becomes a critical issue in SOA adoption within your organization is in setting up-front expectations with executive management. As it is much easier for a development team to receive approval for a prototype budget or proof of concept that can quickly demonstrate application usefulness, it is more difficult to educate your organization on the long-term benefits and short-term sacrifices SOA brings.

New development frontier

SOA allows for increased agility and helps break-down the barriers to system integration, however, it is also a new and pioneering approach to development. In the early period of any new discipline, it can be difficult to anticipate all of the challenges it may bring, and to find skilled, professional developers who have experience building SOA applications. There are many new elements to a SOA approach, and often times there is a learning curve for developers and architects alike. This is where an experienced consultative tools vendor can be an invaluable asset – helping to identify potential stumbling blocks in the design process and providing best practices and guidelines to help your development team avoid pitfalls. Understanding how a consulting team can help your team take advantage of the tools provided to them, and building in timelines for ramping the team up, are essential steps in preparing for SOA deployment.

Performance considerations

While the SOA model is promising because of its compelling flexibility and agility benefits, these benefits often come at the expense of performance. In a traditional application, messages can be processed almost instantaneously because they occur within the same application – there’s no need to encode/decode the message or send it across the network. In contrast, the services in an SOA application must deal with:

- Encoding - services must speak the same language or undergo costly transformations

- Networking – services need to send messages over the wire

- Reliability – services must validate that messages are properly received and correctly structured

These remote message delivery requirements of SOA can dramatically degrade application performance, particularly when your application involves many messages or huge payloads. While there is no way to avoid the performance overhead of SOA entirely, careful design-time decisions – such as grouping performance-sensitive logic so that it can operate as a single service or as a closely-located set of services – can help reduce the impact. You can also alleviate this problem by selecting SOA development tools that help optimize performance in the key areas of encoding, networking and reliability.

Where does SOA make sense?

So far in this paper, we’ve given you a lot of high-level things to think about as you consider whether or not SOA makes sense for your organization. Now, let’s get down to more concrete questions that will help you determine if SOA makes sense for your specific project. In this section, we’ll raise some questions that will help you determine if SOA makes sense for your particular project. You can use this information to help craft a case to get approval to use SOA for your project or to show that it isn’t the right approach for the situation.

What is the anticipated lifespan of your application?

Because the chief return on investment for SOA design comes as an application evolves over time, SOA may not be appropriate for short-lifespan applications. If you are uncertain as to whether the project at hand involves an application that will be used long enough to reap the rewards of SOA agility, you should consider whether SOA is right for this project. Generally, a good rule of thumb is to ask:

1.Will the application be used to solve an ongoing business problem?

2. Could the application be used in other areas of the business to solve a similar problem, even if it isn’t needed for a long period of time?

3.Will the application be used as an integral part of a larger, more time consuming project?

How critical is this application to your business?

If the SOA application you are designing is intended to enhance your business in a way that directly increases your ability to serve your customer, overcome performance barriers, or break new and innovative ground in accomplishing your company’s primary business objectives, chances are, you are designing an application that is critical to your business. Specific questions developers might ask to this end are:

1. Is the application directly tied to customer service or interaction?

2. Does your organization require or anticipate a significant increase in message volume thatthe application must process?

3. Are the messages processed by the application critical to vital operational areas of the organization?

How much change do you anticipate during the lifespan of this application?

If the application in question is, for the most part, isolated from many of the other systems in your business, or if, over the life of the application, the requirements and demands of the application are relatively stagnant, SOA may not be the most appropriate approach for your project. Where business needs are stable and don’t greatly affect other areas of your operations, an application doesn’t need to grow and evolve substantially over time – the key area of strength for SOA – and a traditional approach may be adequate

Do you anticipate that your technical requirements for this application will change over time?

SOA is exceptionally valuable when building applications that may undergo significant change in:

- Platform requirements – such as new OS or new hardware

- Load requirements – like an increase or decrease of the volume of users or the volume of transactions

- Integration requirements – including legacy data sources, new business rules and new partners

- Access control requirements – namely secure, stable and multiple levels of data and functionality access

- Scalability – such as use by new areas of your business or modified to meet similar but distinct business challenges

- Business dynamics – including changes to business logic to incorporate new regulations, new industry challenges or new competitive threats

Where IT requirements are concerned, the nature of SOA allows services and software to scale in ways that are less resource and cost prohibitive than continually adding new hardware. And, in today’s business climate where performance and through-put demands grow exponentially each year – the limits ofhardware capacity, governed by the law of physics, will be unable to accommodate these changes the way that software optimization can.

Does your application have an end-user component or is it purely back-end application?

If the application you are designing has an end-user component, it probably has a good deal more moving parts and pieces, and is subject to additional volatility and requirement changes than a backend application. In addition, while the application user interface may need to be adjusted frequently, it may rely on core, stable applications for a majority of its processing and logic power. In this instance, SOA can aide in both easing the pain of frequently changing business flow or logic in applications, while leveraging existing systems and core applications where appropriate.

Conclusion

Service-oriented architecture (SOA) is a powerful method to realize agility and interoperability in software development. Armed with a clear understanding of the business benefits of SOA, as well as when and where a SOA will best fit your organization’s development needs, you can act as a catalyst for innovation and help promote adoption of this useful methodology. Building a business-case for SOA in your organization is critical to help your team understand the costs, risks and long-term value of SOA. By asking smart, insightful questions about the appropriateness of SOA for your specific project at the start of design, you can maximize SOA development efforts. Today, development teams are often faced with changes in business and technical requirements while an application is being designed and built. Architecting an application for change has become just as critical as any other application feature. Many companies are turning to SOA to help them achieve application agility. However, this benefit often comes at the expense of performance. SOA requires remote message delivery, introducing encoding, networking and reliability issues that can dramatically degrade application performance. There are tools on the market today that help address these performance bottlenecks – many of which can also help you achieve efficiencies in building and deploying your SOA applications. In evaluating your application project for SOA appropriateness, you may also want to consider tools of this nature at the onset.

 

 
Service Oriented Architecture PDF Print E-mail

Service Oriented Architecture or SOA is an application architecture, in which application components or "services" are defined using common interfaces utilizing a set of common protocols and tools to define how services will be invoked, and interact in a loosely coupled manner

  • SOA is evolution from component based architecture, object oriented model and distributed systems (DCOM, CORBA, J2EE etc)
  • SOA is not ESB but ESB is a component to enable SOA
  • SOA is not a Web Service, but SOA enables Web Services
  • SOA is the next evolutionary step in computing world
  • SOA is yet to have a standard reference model
  • SOA is still progressing towards maturity