Mercury for SOA

Mercury for SOA Service Oriented Architecture

Industry experts say service-oriented architecture (SOA) will soon be the dominant enterprise IT architecture. Why? SOA has the power to transform IT from a bottleneck and cost center into a key source of business flexibility and competitive advantage.

But when implemented incorrectly, SOA service-oriented architecture can disrupt the business. Instead of becoming more agile, your business could become more fragile. Recognizing this, forward-thinking IT leaders are turning to Mercury business technology optimization (BTO).

With BTO and Mercury’s Systinet offerings, you can mitigate risks and deploy high-quality SOA services that deliver measurable business outcomes. And you can start wherever you need, based on the area of greatest risk in your service-oriented architecture SOA initiative.

Mercury is the only company that delivers an integrated solution for managing service-oriented architecture SOA across the lifecycle, from demand through production:

SOA Governance - provides the visibility you need to create trust and to gain complete control over your SOA environment.
SOA Quality - helps you to validate the functionality and performance of your services as well as manage your testing to mitigate the risk of delivering services.
SOA Management - enables you to manage end-user experiences, service levels, and ongoing changes to ensure SOA delivers business results.

SOA Policy Police

SOA Policy Police

Last week, IBM announced their service oriented architecture SOA Governance portfolio of software and professional services designed to help organizations ensure they are achieving their goals and objectives for service oriented architecture SOA adoption.

On one hand service oriented architecture SOA governance can be considered just part of IT governance. Ensuring that business requirements are met, delivering ROI, and meeting SLA is the same for service oriented architecture SOA as any other IT activity. Organizations should not be worrying about putting service oriented architecture SOA governance in place if they don’t already have effective IT governance processes.

SOA service oriented architecture does bring new challenges though. The multi track delivery model requires SLA and contracts are established between providing and consuming organizations, not just between IT and the business. Whilst the federated model requires governance that crosses organizational boundaries. One example of this is that governance is required to ensure that black box services behave exactly as required and deliver their SLA. Another, is that it requires policies to be described as precisely as the Service Specifications themselves so that they too can be shared between participants, so that activities can be governed in the same way regardless of who the participant is.

SOA service oriented architecture also delivers opportunities. Most organizations for example have expectations of shared and standardized Services improving the consistency of business processes and information, and maximising ROI. But this does not happen by accident. It is a consequence of governance ensuring that the appropriate policies are in place and enforced to deliver those shared Services where they are required. For example, what is the RAEW for a Shared Service?

It is no surprise therefore that as the service oriented architecture SOA maturity of organizations gradually rises, then so does the requirement for SOA governance. Organizations now report having legacy Web Services in place. Service Oriented Anarchy is not going to endear service oriented architecture SOA to the business.

Part of the IBM portfolio is the SOA Governance Lifecycle. This is fairly generic lifecycle that might apply to any process or asset, but it is apparent IBM has good insight as to the sort of activities specific to SOA service oriented architecture that should take place within it.

Another part of the portfolio is the IBM WebSphere Service Registry and Repository. Or will be, as this is not available to 2H 2006. IBM intend for this to be Business Services Registry that goes beyond UDDI to provide support for the Service Lifecycle and governance of it.

However, from the information made available so far, the registry seems to have a fairly limited view of the Service Lifecycle in comparison say to CBDI Forum’s own Service Lifecycle. The IBM Service lifecycle appears to be centred around the publish/discover and operational aspects. The Service Lifecycle enables policies and governance activity to be related to specific lifecycle states. For example

CBDI Service Lifecycle State
Key Policies

Planned
Architecture; Standardization

Specified
Design; Specification Standards

Being Provisioned
Sourcing

Provisioned
Design; Quality

Certified
Security; Standards

Published
Publishing; Commercial

Operational
Security; Usage; SLA

Retired
Consumer Notification

Archive
Deletion and Retention

One current challenge for service oriented architecture SOA Governance is there doesn’t seem to be many policy languages around that provide for precise specification of policies. Particularly those that would enable them to be machine automatable. The lack of automation is not too dissimilar to other IT and non-IT governance activities in many organizations of course. Some policies will not easily lend themselves to automation.

Consequently the governance process largely consists of recording governance activity. That is, a governance system records who performed the compliance check, but cannot perform the check itself. The organization has to trust the assessment of the compliance tester.

Whilst some might imagine a dedicated service oriented architecture SOA Governance System, this may become a key role of the Service Registry. That is it becomes the “system of record” for Services, not just a place where they can be discovered.

The key challenge however is that organizations need to strike a balance with service oriented architecture SOA governance. Governance and policies must be flexible. If many policies must be checked by hand they should not over burden the organization with bureaucracy. Organizations must be sure therefore as to when to enforce, and when to allow optionality.

Few developers are going to welcome the service oriented architecture SOA Policy Police knocking on their cubical!

SOA Link - Half Full or Half Empty?

SOA Link - Half Full or Half Empty?

A group of vendors have recently announced service oriented architecture SOA Link which they describe as an “an end-to-end service oriented architectureSOA Governance Interoperability Initiative.”

I presented a session on SOA Governance at the recent OMG SOA service oriented architecture, MDA and Web Services Workshop. In the presentation I highlighted the challenge of governance in the Service lifecycle when potentially so many different tools are involved in the end-to-end process. For example, the complete set of meta data that specifies the service might be dispersed to several products, across different stages of the lifecycle.

The figure below (which can be expanded) illustrates that

Changing state may mean moving from tool to tool and changing level of abstraction
Service is defined in many different tools. How is consistency of specification maintained? How is the compliance with the specification checked?
How can Policies be applied across different tools? Policies may be defined in a tool specific mechanism. How is compliance maintained?

This isn’t a new problem per se, but traditional configuration management approaches do not address new requirements raised by service oriented architecture SOA, and CM tools may not even recognize Service as an asset type – at least not at all levels of abstraction or in terms of all of the artefacts that might be part of the Service Specification or related to it.

The service oriented architecture SOA Link ought therefore to be a timely announcement. It should be recognized though that this is not a standards group. Rather, it is just a commitment by the various vendors involved to provide interoperability between their respective products. However, because they will not be developing formal interoperability standards it is likely that there will be different links between different products

You can view this as the glass being half full or half empty. Clearly there is a need to start somewhere and this is a step forward in addressing what will be a genuine issue as organizations increase their service oriented architecture SOA maturity. On the other hand the lack of focus on interoperability standards sounds like it may result in a spaghetti of point-to-point interfaces.

According to Infravio the prime vendor behind service oriented architecture SOA Link there will be 3 levels of link that will be shown in the catalogue they will be publishing.

At the lowest level is just the publication by the vendor of the link.
At the secont level the vendors will provide additional such as use cases, etc
At the strongest level the link will show validation by customers
An acid test will be the extent to which the group actually applies service oriented architecture SOA to the problem. If all that results from the initiative is a bunch of proprietary file transfer mechanisms that tightly couple one product to another then it will be of limited usefulness, yet alone contrary to the spirit of service oriented architecture SOA service oriented architecture. If on the other, it prompts some of the vendors to publish proper Service Interfaces with well defined schemas this will be more useful. If those Services can go on to become de facto standards, or submitted to a standards body for further refinement and approval then so much the better.

Enterprise Architecture versus SOA?

Enterprise Architecture versus SOA?

In a provocative post yesterday, David Linthicum suggested that Enterprise Architects should be fired if they don't appreciate SOA Service Oriented Architecture. Not surprisingly, this is resulting in a hostile response from people (Uche Ogbuji, Mark Nottingham) who are saying that it's not Enterprise Architecture that's the problem, it's SOA Service Oriented Architecture. Or rather the Service Oriented Architecture SOA vendors. Mark (who used to work for BEA) blames the Big Vendors.

I have some major concerns with the way Service Oriented Architecture SOA (or some watered-down version of SOA Service Oriented Architecture) is being implemented in large organizations, sometimes with the encouragement of vendors. But I don't think all the blame for this can be placed on the vendors. (Hey, they're vendors, what do you expect from them?)

I also have some major concerns with the way Enterprise Architecture is being implemented in some large organizations - talking endlessly about Business-IT Alignment but reduced to playing meaningless games of Framework Bingo.

In our consulting work, we are increasingly finding that effective SOA Service Oriented Architecture and effective Enterprise Architecture go hand-in-hand - you probably can't do a decent roadmap or business case for one without considering the other.

I think David Linthicum raises some good points in his post, but I don't agree with his conclusion that you should fire enterprise architects who don't appreciate SOA Service Oriented Architecture. It is probably true that some enterprise architects don't deserve that job title - but it's not because they don't appreciate SOA but because they actually aren't very good enterprise architects in the first place.

I have generally found that good enterprise architects are eager to address the issues that matter to their organizations. This certainly doesn't entail (why should it?) an uncritical acceptance of SOA Service Oriented Architecture. In my earlier post on Optimism (in reply to Jeff Schneider) I said that "it is not the role of the architect to be optimistic". But it does entail striving for a flexible and joined-up and cost-effective architecture. Frankly I can't see the point of an enterprise architecture if it doesn't do any of the things on David's checklist.

What is IBM SOA governance?

Service Oriented Architecture SOA governance is an extension of IT governance that focuses on the lifecycle of services and composite applications in an organization’s service-oriented architecture SOA. The function of SOA governance is to define:

Decision rights for the development, deployment and management of new services.
Monitoring and reporting processes for capturing and communicating governance results. Because Service Oriented Architecture SOA applications are intrinsically fragmented, they introduce new governance challenges. But with the proper policies, principles, standards, procedures and processes in place, businesses can realize the full benefit of service orientation. An effective Service Oriented Architecture SOA governance platform not only helps business and IT teams better identify which projects contribute most to business goals, but it also empowers employees to work and collaborate more efficiently by clearly defining their roles and responsibilities.

What is service lifecycle management?

Once the Service Oriented Architecture SOA governance framework is implemented, it will be used in the model, assemble, deploy and manage phases within the SOA lifecycle. Related to the operational aspects of implementing SOA governance, service lifecycle management addresses how services will be developed, deployed and managed.

Service lifecycle management focuses on the development and deployment of services. SOA governance supplies the decision rights, processes and policies for those activities. Once a service is deployed, there must be management aspects in place to control and monitor the service.

Within service lifecycle management there is a set of functions that will need to be in place and governed to ensure that the value proposition of Service Oriented Architecture SOA, particularly reuse and cost reduction, is achieved.

For more information on how to advance your SOA governance procedures, visit: ibm.com/software/solutions/soa/entrypoints/advancing_soa_governance.html

Service Oriented Architecture SOA Quality Management is the next component of SOA Governance and Service Lifecycle Management

March, 2006 - IBM announced our SOA Governance strategy and direction and tooling
October 2006 - Service Lifecycle Management was added to detail how SOA Governance will be operationalized within the SOA Lifecycle.
December 2006 - IBM featured Empowering the ‘A’ in SOA, which included a number of new and updated products targeted at approach to Service Lifecycle Management Architecture component.
Today - IBM is adding SOA Quality Management to our SOA Governance and Service Lifecycle Management
The announcement today focuses on extending the overall SOA Governance and Service Lifecycle Management capabilities with a set of new Rational test tools and updates to Tivoli products and GTS (Global Technology Services) Offerings.

Why is Governance important to SOA

The increased flexibility and cross-organizational nature of business services that SOA facilitates, requires that organizations establish a framework to implement active decision-making, accurate tracking, improved serviceability and better communication.

SOA governance is the mechanism to ensure that the decision making structure is solid, relationships between services and parties are managed and that there is compliance with the laws, policies, standards and procedures under which an organization operates.

Specifically SOA governance

Creates higher return from focused SOA investments
Aligns IT and business strategies, creates communication paths
Reduces coordination costs: less time wasted due to poorly-managed conflicts
Institutes efficient and effective decision making and clarity executing roles and accountability
Measures effectiveness of SOA
An enterprise that fails to realize the importance of an effective governance structure may not stand to benefit much from a SOA transition.

Source: www.IBM.com

Oracle SOA Governance

Comprehensive Service Oriented Architecture SOA Governance Capabilities from Oracle. Service Oriented Architecture SOA governance is the key to realizing your SOA goals. It defines and enforces the set of policies, procedures, roles, and responsibilities within your enterprise to guide your SOA-related behavior and deliverables. Proper Service Oriented Architecture SOA governance assures an organization will realize the important benefits of SOA—increased business agility, protection of IT investments, and greater business and IT alignment.

ORACLE SOA GOVERNANCE CAPABILITIES
Oracle Fusion Middleware's SOA Service Oriented Architecture offerings provides a comprehensive set of capabilities to define and enforce SOA governance:

Identify, categorize, version, and publish services
Provide service change notifications to developers and applications
Securely view available services within the enterprise and govern the provisioning of new services
Centrally manage security polices and service-level agreements, including authentication, authorization and encryption policies
Centrally manage service-level agreements for performance, guaranteed response time, and high availability and failover on services
Out-of-the-box functionality to implement common governance requirements for business process auditing and canonical data models; and
Metadata repository services to capture and track service interactions and store SOA artifacts and metadata for Web services, service orchestrations and policies.

COMPONENTS
Oracle SOA Suite—A comprehensive SOA offering that includes policy definition and enforcement agents with metadata repository services and APIs for governing service interactions and orchestrations
Oracle Service Registry—A secure UDDI v3-compliant enterprise registry for service lifecycle management
Oracle JDeveloper—An integrated SOA development environment with design-time governance features for service development

Source: www.Oracle.com