Support MC Press - Visit Our Sponsors

 

 

Forums Sponsor

Popular Forums

ANSI to UTF-8 on IFS (624 views) Printing Bar Codes in an internal output spec's (396 views) DB2 Web query vs SEQUEL (196 views) Microsoft Sleeper Silverlight Scores Olympic Knockout (192 views) Schedule Announced for Conference & Workshops on SOA, SaaS, Virtualisation & ECM (162 views) Calling RPG Programs from VB (143 views) Keep Those Batch Jobs Running (Or How to Enjoy Your Off Time) (105 views) Schedule Announced for Conference & Workshops on SOA, SaaS, Virtualisation & ECM (99 views) TechTip: Exploit DB2 Web Query's Defined and Computed Fields (76 views)

Forums

     

 

   Search Sponsor

Popular Searches

POPULAR SEARCHES 1. seiden 2. pdf 3. db2 web query 4. cozzi 5. Subfiles 6. how to start with java 7. AS/400 Subfile Programming 8. Using Dynamic SQL in CL 9. IFS 10. ftp

Search

An ungoverned SOA project can lead to unintended consequences, reversing the cycle and causing SOA to add cost and disrupt processes.

The year was 2004. John was a CTO for an IBM ISV that piloted a supply chain application. The company used a SOAP engine inside the IBM Websphere Application Server (WAS) with Enterprise JavaBeans for the front-end and connections to an i5/OS RPG application using WSDL.

The idea behind this was point-to-point integration, the kind where Web services and consuming applications are designed at the same time. These were easy to create. But as the business changed and more clients requested Statements of Work (SOWs), those point-to-point Web services became obsolete. Worse, since these Web services were easy to build, developers had a blast creating services. The quality of the service was in various states (and some not well thought of).

By 2007, the company had created many Web services, with no thought process. No one was sure which applications were using the Web services. With numerous SOWs created, no one knew the history and ownership.

SOA is great, but unless it's managed, it's just another IT process that can be chaotic. John contacted Gartner Group, and they recommended to put into place an SOA Center of Excellence (COE) to act as a focal point, establish reference architecture, review newly created Web services, communicate and enforce the standards, and encourage a higher degree of service reuse. Implementations are typically coordinated with clients, and unless strict governance exists, different groups or individual developers will make different decisions, increase diversity, and inhibit reuse.

Things had been uncontrolled for some time. John realized that the current mode of operation, with numerous out-of-hand Web services, could not be continually sustained and could not support the numerous SOW requests.

John finally understood the difference between Web services and SOA. It is easy to create Web services, but it takes discipline to deliver meaningful and serious value from them. John had used a spreadsheet to track Web services and all their dependencies, but this became insufficient. Many clients were asking for more details about the various services. John had a hard time keeping the spreadsheet up to date; it was error-prone. A registry and repository for SOA was exactly what he needed. How could John encourage reuse if no one could find information about what services might be available for reuse?

Tim Everett, the CFO of National Parts Distributor (NPD), approached John about modifying NPD's Web service-enabled warehouse management system (WMS). NPD required that various inventory inquiry services be consumed by .NET clients. According to Tim, for time-to-market reasons, the Web services needed to integrate with third-party services to locate parts or preferred distribution centers.

John realized his strategy of point-to-point Web services was over. The need for a whole new chapter of flexible relationship between service consumer and provider became apparent. This, together with understanding the purpose of each Web service and their dependencies, was vital. NPD was not the only customer requesting such changes.

John pondered how to prioritize and execute a solution:

•·        How can we deliver more services to our customers quickly?

•·        How can we prioritize the services that needed to be built?

•·        How can we encourage service reuse so that the cost and time required to get an application running can be reduced?

•·        How can we control the quality of service being implemented?

•·        How can we identify and improve those hard-to-integrate services?

•·        How can we identify best practices and patterns for better services?

•·        How can best practices be enforced?

•·        How can we get a handle on the entire service inventory, the infrastructure those services are required to run on, and the other services or composite applications that depend on them?

Without answers to these questions, John knew he couldn't deliver SOA with the promise of agility. Then John recalled reading about SOA governance a couple of years ago.

What Is SOA Governance?

"SOA governance" is a misunderstood term. Some people use the term to mean service lifecycle governance (governing from creation to implementation). Others coined it as applying runtime policies to services. But is there more to SOA governance than this?

SOA governance is a concept used for activities related to exercising control over services in SOA. It is an emerging concept used to address management issues that are caused by the loose coupling of services in SOA. SOA governance can be seen as an overlay on IT governance, but it often has more organizational focus than IT governance when services represent business activities.

To achieve SOA governance, John addressed the following:

1. He collected three years worth of artifacts related to service, with a goal of understanding the end-to-end lifecycle of these assets. Artifacts included a multitude of documents from XML, Web services, DL, XLS, Excel, and Word.
2. He established initial policies, standards, and key measurements related to the lifecycle of services and composite applications.
3. He reviewed SOA governance mechanism software that enforces policies, decisions, and processes around end-to-end lifecycle of these artifacts.

Exploring an SOA Governance Solution

System mechanism software plays a major role in the foundation of SOA governance to enforce and automate policies across the service lifecycle. Two of the main components of this system are a registry, which acts a central index of business services, and a repository, which stores policies and other metadata related to the governance of the services.

By themselves, these components are insufficient. The registry and repository must be fully interoperable with each other and other SOA artifacts. They must form a comprehensive system that manages the entire SOA lifecycle.

Define Policies and Procedures

John's initial step was to define the policies for the company. This was done in conjunction with the SOA Center of Excellence (COE) to help communicate policies and other SOA-related decisions. Policies included both business and technical requirements, which helped to create a common source of information and processes. John needed to be able to answer the following questions:

•·        Which policy should be implemented first? What policies are needed now?

•·        Who in the organization is responsible for creating policies?

•·        How will these policies be created? How will they be communicated?

•·        Which policies can be automated?

•·        How will people within the organization discover policies?

•·        What tools will people use to follow policies?

•·        How will management get visibility into the policy compliances?

•·        What actions should be taken for policy violations?

The first step of SOA governance is to define your framework. The framework tells the organization what to consider during policy creation, communication, and enforcement relevant to the project. This governance framework then becomes your outline. Take an iterative, step-by-step or phase approach to your governance. Your initial attempt may include simple policy documentation, but your next iteration includes detailed definitions and the methods you plan to use to enforce such policies.

As companies move up the maturity model, they can create more enterprise-based policies and processes around shareable services. Governance becomes more important and the scope widens as SOA becomes more mainstream and reuse increases. Establish SOA goals, standards, policies, and procedures proportionate to SOA maturity.

Establish an SOA Baseline

John learned to evaluate the business impact of introducing new or changing policies against current artifacts and services already published in the registry and repository. SOA governance involves the enactment of these components: ensure that the artifacts follow policies, publish reports on results and business impacts, and dynamically associate each artifacts and its location. Having an SOA baseline allows John to see the quality of existing artifacts and highlights areas that need review. This dashboard view can be shared with senior management to provide visibility on the current state of the SOA.

Arm yourself with information about where to start: which policies have the highest impact on business and which are out of compliance. Focus on improving services that do not comply with policies and have the highest impact on business. Gradually bring existing services into compliance with your policies.

Establish SOA Roles and Responsibilities

John formed an SOA COE based on Gartner's recommendation. The SOA COE became the governing body and single point of coordination for SOA. Clients now have a focal point to call when they require more details on the Web services. John assigned subject matter experts, business analysts, and IT architects to the COE and assigned each a clear set of responsibilities. John also appointed a manager to chair the COE.

The SOA COE provides the perfect opportunity to see how business objectives can be articulated in SOA. The roles and responsibilities include these:

•·        Act as the SOA focal point

•·        Communicate and enforce standards

•·        Help establish reference architecture

•·        Review newly created services

•·        Encourage a high degree of service reuse

•·        Help set up policies and procedures

•·        Suggest corrective actions when a specific process is broken

•·        Define IT infrastructure to support SOA

•·        Develop clear guidelines for SOA projects

•·        Discover how to implement SOA and Web services to help increase competitive advantage

•·        Adopt proven best practices to optimize SOA

See how INFOR created a Center of Excellence for its System i Platform.

Continuous Governance

After the SOA baseline and COE were created, John could apply the policies accordingly to any artifacts published in the registry and repository as well as ensure continual governance over newly created services and changes to existing ones.

As part of policy enforcement, John can configure criteria of publication acceptance and rejection. In certain situations, he can allow publication even though the artifact is not compliant and can mark via the metadata that this artifact should not be exposed as production quality. John is aware there are exceptions to every rule; as artifacts are checked for compliance, users may want to request exception from complying with these policies. Exceptions must be managed as well.

The Foundation of SOA Governance

SOA governance cannot be purchased out of the box. However, the foundation of SOA governance is the ability to enforce and automate policies across the SOA lifecycle. A set of mechanisms can enable automation and enforcement. To do this, you need a place to store policies (policy repository) and a place to enforce them (policy enforcement point). These two locations represent where policy "lives" and where it "goes to work."

The SOA lifecycle consists of three stages:

1. Design time
2. Run time
3. Change time

Regardless of the lifecycle stage, the registry and repository are the Policy Store for all the stages. Having a single context for policies enables SOA lifecycle management of policies and provides a means to establish enterprise-wide policies.

The policy enforcement point (PEP) changes on the lifecycle stages. As illustrated above, during design time, the registry/repository itself is the PEP. During run time, the message transport system (your ESB) is the PEP. And finally, during change time, the management and security system is the PEP.

Design Time

•·        Architect designs a service contract or plans a service implementation.

•·        Developer searches for an existing service before building a new one.

•·        Developer requests that the SOA COE approve the creation of the service.

•·        Tester simulates a new service to execute a test plan.

During design time, policies such as namespace validation, schema validation, interoperability validation, approvals, document access control, audits, and resource utilization need to be enforced. If the policy repository is combined with service registry, then typical best practice is for the SOA registry/repository system to also serve as the enforcement point.

Run Time

•·        IT operations monitor a business process.

•·        IT operations confirm compliance of a service with policies (or SLA).

•·        Operations manager monitors level of service reuse.

•·        Operations manager handles service exceptions.

The run time system is responsible for message transport. Enterprise Service Bus (ESB) is typically used. The ESB brokers the transaction between service provider and consumer and frequently handles function, such as data transformation, reliable messaging and message queuing, security, and other operations. In Web services, the emphasis is on supporting SOAP and extensions like WS-Security. These systems can act as run time PEP.

Change Time

•·        Business analyst plans a change within a certain business process.

•·        IT administrator adjusts quality-of-service requirements for a service.

Change time governance is the act of managing services through the cycle of change. Since most services will be modified through time, this is an essential component of long-term governance. During change time, users connected to services, taxonomies, or policies receive notification to approve, review, or recognize when any of those assets are modified. Furthermore, change time governance enables policies to dictate whether a service or even another policy can change and if so, who approves it. If change is planned (e.g., version upgrade, service decommission, etc.), then the event is recorded and described to allow dependent parties to adjust their processing.

SOA Lifecycle Within SDLC

The whole point of SOA is to create an agile environment, making it easier to build a fully integrated environment from the get-go. This is our goal. If our services do not allow us to build service-oriented applications, then we waste money and time. SOA governance is about making sure we don't waste time and money by building services we don't need or failing to build services we do need.

The highlighted Web services are areas often covered by SOA governance system mechanism. While these are important "strategic" governance, they are only about 20 percent of the whole SOA governance.

Bottom Line

An ungoverned SOA project can often lead to unintended consequences, reversing the cycle and causing SOA to add cost and disrupt processes. There is no "one size fits all" SOA strategy. Thus, there is no such thing as a single set of policies and procedures that constitute governance with SOA. We should not forgo SOA because of the risk, but rather define strategy for SOA that builds governance. Ungoverned SOA can result in these costs:

•·        Lack of reuse by compromising trust and causing consumers to decide against reusing service because of unpredictable quality and performance issues.

•·        Process disruption caused by failure to assess the impact of change or by publishing services that do not conform to standards or SLAs.

•·        Escalations in support costs through an onslaught of help-desk and support calls resulting from service issues and outages.

•·        Lack of interoperability resulting in silos of business services and perpetuating the same issues of traditional "tightly coupled" architecture.

•·        Non-compliance by failing to associate key policies with the services that have implications for industry or governmental regulations.

•·        Security breaches by allowing arbitrary data access.

•·        Overall SOA failure by allowing chaos, perpetuating a "garbage in, garbage out" environment.

Governance is not an option for SOA; it is necessary. SOA governance requires more than a registry and repository. It requires an integrated solution that provides support for all SOA stakeholders throughout the SOA lifecycle.