Skip to main content

skip to main content

developerWorks  >  SOA and Web services  >

Adopt an SOA in a service-oriented enterprise

developerWorks
Document options
PDF format - Fits A4 and Letter

PDF - Fits A4 and Letter
29KB

Get Adobe® Reader®

Document options requiring JavaScript are not displayed

Discuss


Rate this page

Help us improve this content


Level: Intermediate

Judith Myerson (jmyerson@bellatlantic.net), Systems Engineer and Architect

01 May 2008

Want to know how to adopt Service-Oriented Architecture (SOA) in a service-oriented enterprise (SOE)? In this article, regular developerWorks author Judith Myerson focuses on issues related to transitioning to an SOE, transformation initiatives, the impact of organizational changes, and implementing SOE while avoiding the usual organizational pitfalls. Get suggestions on how to close the gaps in the SOE.

Introduction

My article, "SOA services in a grid and netcentric world" (developerWorks, Mar 2008), covered issues related to harnessing unused resources for computer power that's too intensive for a stand-alone machine. I gave solution examples, such as monitoring change in grid scale, and Global Information Grid (GIG) and SOA testing methodology. What the article did not go into is that you need to step up to the SOE for effective SOA governance as a way to ensure successful implementation of SOA services in the grid.

In this article, you look at some organizational and managerial practices behind the SOE as well as at governance and other incentives to get service providers and consumers to collaborate in different service types in a grid. Then you find out what's missing from the SOE and get some solutions to fill in the gaps in the grid.

Recapping SOA

This recap focuses on the paradigm shift to the dynamic sharing of resources, using GIG to achieve information superiority, and the value of a grid monitor to harness unused resources.

Paradigm shift

Moving Web services that connect the applications and systems to the grid represents a paradigm shift from the idea of a static queue of a stand-alone machine's resources at one location to dynamically sharing resources of multiple machines in parallel at any location. Because the load of resources can be balanced in the grid with unused resources, grid computing is like an extreme form of load balancing between SOA applications.

Global Information Grid

The GIG evolved in response to the need for an environment in which users can access, share, collect, process, store, disseminate, and manage information on demand from any location in the grid. The GIG aims to achieve information superiority in a network-centric environment by enabling various systems and messaging-based Web services to interoperate with each other in parallel. The GIG lends itself to an SOA on the grid, carrying information on demand via Web services because grid computing relies on an open set of standards and protocols, including key SOA standards for Web services. GIG users can post and retrieve information from Web services and make real-time decisions rather than relying on historical information from multiple automated information systems applications.

Grid monitor

The problem with the grid is that Web services, normally loosely coupled, run whether the resource is scarce or not. You need to ensure that the resources on multiple workstations aren't wasted when they're in the grid.

One solution is to develop a grid monitor of how the unused resources of each workstation are harnessed and shared by other workstations. If the system finds that the unused resources on any workstation aren't properly harnessed, it should send an alert to the grid and system administrators so they can look up details in the logs for resolution. To keep up with the rapid change and short development life cycles expected from the system builders of GIG and SOA, tests have to be ready to conduct in timescales, ranging from machine-specific functional to grid enterprise.



Back to top


Step up to SOE

This section explains why you need SOE to govern SOA. In particular, it focuses on the transition to SOE, transformation initiatives, and the impact of organizational changes during the transition.

Transition to SOE

In making the transition to SOE, you need to govern SOA to ensure successful implementation of complex relationships between Web services and SOA applications in a grid. The more Web services are added to the SOA, the more complex the relationships between them become, particularly when unused resources in multiple workstations are harnessed in the grid. Associated with the SOE are organizational changes that take place between the organizations within an enterprise. These organizations must be loosely coupled based on the role of definitions of service consumers, service providers, and service brokers, and the understanding of how they are all related to one another.

If you don't govern SOA adoption, the organizational structure will remain unchanged during the transition. The realization of an enterprise's SOA will be less than satisfactory, and you won't achieve some or all objectives of SOE.

Transformation initiatives

You need to ensure the transition is based, in part, on the governance of SOA to bring about the organizational transformation of the enterprise into the SOE. The problem with governance is that there might be redundant governance models and redundant resources and investments to achieve common objectives in an enterprise. To reduce this redundancy, you need to focus on transformation initiatives that result in more policy-enabled service-oriented organizations.

You must look at your IT investments to determine what you should use that will result in the pooling of program funding to support enterprise services. You should have in place a governance model that rewards incentives for the sharing of resources at a lower cost and that doesn't allow redundant investments.

Impact of organizational changes

Businesses need to focus on the impact of organizational changes on business capabilities in order to stay competitive in the market. Organizations should view themselves as federations of capabilities (for example, business functions) that allow collaboration with one another in an enterprise.

Given that governance models and IT investments aren't redundant, the business capabilities of the enterprise can be transformed into a complex interaction hierarchy of loosely coupled Web services to the greater extent and tightly coupled Web services to the lesser extent. When SOA applications require an enterprise to interact with another to provide common services, the hierarchies of capabilities and resulting Web services become even more complex.



Back to top


Work with an SOE

In this section, take a look at how a traditional enterprise compares with an SOE framework. Let's also explore what you need to do to implement an SOE and what pitfalls to avoid when adopting SOA as an organizational initiative in making the transition to SOE.

Traditional enterprise

SOE differs from traditional enterprise in two ways:

  • It's possible that you separate business needs (service consumption) from fulfillment (service provision). Unlike the traditional enterprise, the same business need can be fulfilled by multiple providers in the SOE.
  • To enable benefits from SOA, you need to bring about organizational changes in an enterprise, sharing services among the organizational units that make up the SOE. I'm not talking about services specific to a unit or utility services used by all organizational units to deliver centrally, as the traditional enterprise does.

Implement SOE

In the transition to the SOE, you treat SOA adoption as an organizational change initiative. After you get executive support for the transformation initiative, you establish a program plan for SOA. Different organizational units might have different ways of adopting SOA as an organizational initiative, so you need the coordinating committee to adopt the SOA in a common way across the organizational lines within the enterprise.

After the funds for the change initiative are approved, you build community processes and collaborative platforms, then establish policies on SOA governance. Next you develop a policy on developing, testing, and evaluating services. You need to ensure that the unused resources can be harnessed by these services. After determining that a set of services is working properly as planned, you establish service funding and charging mechanisms.

Avoid organizational pitfalls

Here are some of the pitfalls you need to avoid when working with the SOE:

  • Avoid vendor proprietary service offerings. Interoperability problems can negate organizational initiatives.
  • Avoid the latest open standards that are known to be unstable. Unstable standards may contribute to interoperability and resulting organizational issues.
  • Avoid running into resource overloads that can result in system crash. Know the organizational and management constraints of SOA services.
  • Avoid wasting unused resources when invoking or implementing Web services. Set a policy on harnessing and controlling unused resources. Know when Web services need to be tightly coupled to conserve scarce resources.
  • Avoid waterfall development approach. Make sure a service life cycle management (for example, life cycle incremental approach) can maintain multiple versions of service.


Back to top


What's missing from SOE

With the SOE, effective governance isn't just about control, policing, and enforcement functions, it's also about providing essential services and sharing them between the loosely coupled organizations of an enterprise and between the enterprises. Governance has jurisdictional boundaries with programs as well as at the enterprise level.

However, the current state of SOE doesn't address the issues of governance having cross-jurisdictional boundaries in a grid. The issues come into play when Web services, normally loosely coupled, run whether the resource is scarce or not. You need governance with cross-jurisdictional boundaries to ensure that the resources on multiple workstations aren't wasted when the services run in the grid.



Back to top


Conclusion

You need a team of developers, system administrators, managers, and executives to collaborate on adopting SOA in the SOE. You must plan ahead for establishing governance policies and system requirements of developing and deploying SOA services, while closing the gaps in the grid. Resolving these issues makes your job of adopting SOA a lot easier.

You can use IBM® Rational® Portfolio Manager to provide insight into the optimization and investment funding, as well as IBM Rational Method Composer plug-in to plan your implementation of the SOA governance framework and to amend the processes when changes are identified. You can also use IBM Rational ClearQuest® and IBM Rational Tester for SOA Quality to increase productivity by reducing testing and defect-tracking time.



Resources

Learn

Get products and technologies
  • Innovate your next development project with IBM trial software, available for download or on DVD.


Discuss


About the author

Judith M. Myerson is a systems architect and engineer. Her areas of interest include middleware technologies, enterprise-wide systems, database technologies, application development, network management, security, RFID technologies, and project management.




Rate this page


Please take a moment to complete this form to help us better serve you.



 


 


12345
Not
useful
Extremely
useful
 


Share this....

digg Digg this story del.icio.us del.icio.us Slashdot Slashdot it!



Back to top


IBM, the IBM logo, ClearQuest, developerWorks, Rational, and Redbooks are registered trademarks of IBM in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.