Previous column

Next column


Who Took the Cookie from the Cookie Jar?

Mahesh H. Dodani, IBM Software, U.S.A.

space REFEREED
COLUMN


PDF Icon
PDF Version

1 CHANGE HAPPENS

“Behaviors, not strategy, create value.” – Peter Weill and Jeanne Ross, http://harvardbusinessonline.hbsp.harvard.edu/b02/en/common/viewFileNavBean.jhtml

Service Oriented Architecture (SOA) continues to entice enterprises by promising flexibility, agility and alignment of IT with business objectives; along with the ever elusive advantages of increased reuse, better security, control over integration expenditures, and reduced IT maintenance costs. However, as we have learned over the last two decades achieving these benefits has more to do with behaviors, policies and procedures rather than the quality of the strategy, architecture or code.

Lets look at the following scenarios to see the challenges that enterprises’ typically face in making SOA work:

  • Many companies get into SOA to address their customers’ pain of having to interact with each Line of Business (LOB) in differing, inconsistent and non-integrated ways. For example, insurance companies face this challenge with their home, life and auto insurance LOBs working with their customers separately. They soon realize that they are using similar business processes and the benefits of implementing a one-stop shopping experience for the customer. So, the business asks IT to support their needs, who in turn decide to leverage SOA to build this common view of customers across their LOBs. Several SOA projects are started as part of this effort to integrate services from each LOB, and very soon these projects stalls. The different organizations involved in the effort get embroiled in issues of ownership, funding, organizational structure, etc. as the enterprise understands how to build reusable services, share these services across LOB applications (exposed as services), and maintain these services through their natural lifecycle. The basic issue is that the organization has not changed their behaviors and understood their new roles and responsibilities to make SOA effective.
  • Another common entry point into SOA is to support an enterprises’ need for flexibility in the services they provide that need to be tailored to meet local requirements. These high-value business services are the basis for deriving the value that companies need to realize from implementing SOA. As a typical example, consider multi-national companies that are expanding into new geographies with differing regulatory requirements. An SOA allows shared reusable business services to be bundled or unbundled as required to enable compliance in each geographical area. However, designing and implementing such flexibility into the business services is difficult, requiring interaction and collaboration between the business analysts, architects, local business and IT councils. This difficulty is further exacerbated by the immaturity of the approaches and methods that facilitate the design of flexible business services. Note that we faced the same problems in designing flexible objects and components – which after almost two decades is still considered an art!
  • Once companies start adopting SOA they continue to face challenges as services proliferate their IT landscape. One such challenge arises when changes (e.g. to add new policies, behavior, etc.) need to be made to handle business requirements. The development team finds it hard to identify which applications and services are impacted by the new change. However facing deadlines and pressure to meet the business needs, the team makes changes to known areas and puts the updated services into production. In most cases, this change will cause some application or service that relied on the unchanged version to break or have problems. Such uncoordinated proliferation of services impedes the enterprises’ ability to efficiently implement changes.
  • Another key challenge arises when services are reused. One of the key advantages of SOA is to allow services to be leveraged quickly to realize new business needs. These common services (e.g. customer information retrieval) are the “crown jewels” that can help the enterprise attain agility. However, the reuse of services must be coordinated and managed carefully to ensure that it does not negatively impact other service characteristics through the lifecycle. Reused services increase the workload on the infrastructure, which can in turn negatively impact response times, performance, and the cost of delivering the service. Appropriate service level agreements must be defined along with the resources to deliver on agreed-to qualities of service. Furthermore, the usage and utilization rates of services must be monitored and measured to support billing and charges to recover the cost of delivering the service.

As the preceding scenarios show, we have big challenges to address with getting any organization to adopt SOA and be successful. The primary issues that we have to deal with include changes in behavior, ensuring rules and policies are followed; making right decisions; finding, using and sharing services; defining high-value business services; ensuring service characteristics are appropriately defined and managed; and facilitating communication and collaboration – simply put, social re-engineering :-). How do we get this accomplished?

2 SOA GOVERNANCE

Governance establishes decision-making rights along with the associated policies and mechanism to control and measure how these decisions are carried out. SOA governance focuses on the decisions across the entire service lifecycle to enable organizations to realize the business benefits of SOA and mitigate the risks inherent in SOA adoption. Specifically, SOA Governance defines the principles, processes, and roles required to manage, use and update the SOA. The following articulates the key objectives of SOA Governance:

  • The primary goal of SOA Governance is to derive maximum value from Service Oriented Architecture by promoting its implementation, use and evolution.
  • SOA Governance provides the basis to ensure that SOA (and its associated models) are managed and updated in response to changes in business needs and available technologies.
  • SOA Governance is fundamental in enabling an enterprise to make conscious decisions about IT, the acquisition of IT assets, and the design and implementation of new IT solutions to meet business needs

In order to achieve these objectives SOA Governance establishes the following overarching processes:

  • SOA Definition Process – This process specifies the architectural design activities that define, build, and deploy components of the SOA. This process includes modeling of business components, business services, and the design of service components that will enable the business activities. It also defines the different organizational roles and associated responsibilities required to support the process.
  • SOA Vitality Process – This process maintains the applicability and currency of the architecture, reflecting the business and IT direction and strategy, as well as anticipated changes. It continuously refines the SOA and associated processes along with the supporting roles, organization and business functions to ensure its on going usage and relevance. The architectural principles are used to help guide this process
  • SOA Compliance Process – This process reviews and approves/rejects the design of a solution against the Service Oriented Architecture and the associated best practices, standards, and technologies. This process can be activated at various checkpoints during the SOA lifecycle. In many cases, it is an add-on to an existing enterprise architecture review/quality process. This process also allows for projects to appeal the non-compliance of a solution design or an IT investment with the architecture and be granted an exception
  • SOA Communications Process – This process is aimed at socializing the architecture across the organization. Socialization of the architecture includes communication, education, enablement of various roles to participate in the SOA journey, and providing the foundation for collaborative efforts among the various stakeholders.

These processes enable the enterprise to maintain alignment of business and IT and ensure the benefits from SOA. The SOA Governance lifecycle, shown in Figure 1, facilitates an incremental and iterative approach of determining the focus and scope of SOA governance, defining the governance model to address the scope, implementing the governance model, and measuring & monitoring its effectiveness. This lifecycle is supported by the Governance processes and emerging practices which makes it easy to do things in the right way and difficult to do it the wrong way.

Figure 1: SOA Governance Lifecycle

3 LEADING PRACTICES AND GUIDELINES

As should be evident from the preceding discussion, implementing SOA Governance requires a comprehensive governance and management method that addresses the entire lifecycle augmented by best practices, methodology, processes, tools and technologies. This method should facilitate the establishment of decision rights along with the necessary policies, measurements, and controls to enable people to make the decisions. This is in stark contrast to current approaches to SOA Governance that focus on particular supporting technologies (e.g. service registries) or on a particular part of the governance lifecycle (e.g. planning.)

Let us focus on a key best practice. SOA Governance is primarily focused on behavioral changes by facilitating dialog and socializing the rules and policies to ensure SOA is effective. The key enabler of SOA Governance is therefore a change agent which has the responsibility of ensuring that all the aspects are handled. The Center of Excellence (COE) is a proven organizational model for governance and management. The primary responsibilities of the SOA COE include:

  • Socialize the SOA by communicating the framework, best practices, assets, patterns, templates, recipes, methods and other blueprints.
  • Provide direct project assistance to drive architecture and gain feedback on the vitality and viability of the architecture, along with the ability to harvest assets.
  • Identify skills gaps and create development roadmaps and drive use of new technologies.
  • Manage service, service component, pattern, and data re-use processes to reduce project risk and accelerate delivery.
  • Provide expert resources to accelerate delivery of critical architecture practices.
  • Enable infrastructure teams to execute on building/deploying services, performance tuning, and metrics reporting.
  • Perform independent design and architecture reviews for key applications.
  • Continuously assess, refine and socialize the architecture framework along with supporting assets based on internal and external influences.

When making strategical decisions, consider these emerging guidelines. The most important and far-reaching SOA Governance best practice is for the CIO to report to the CEO. This best practice ensures the appropriate alignment of IT to business needs within the enterprise backed by proper sponsorship. Furthermore, successful enterprises consistently demonstrate a willingness to sacrifice function to sustain architectural integrity. This is a good indicator of the maturity of the enterprise in establishing decision rights and their ability to make informed decisions. It is important to have the IT investment approval process within an enterprise-wide IT governance plan. Without such an approach, IT investments invariably build toward localized rather than enterprise goals. Finally SOA will not be successful without a well-established peer relationship between IT and the business units.

From a tactical perspective, consider these emerging guidelines when making decisions. It is important for an enterprise to understand the difference between governance and management. Governance determines who makes the decisions. Management is the process of making and implementing these decisions. To ensure that appropriate high-value business services are implemented, consider the following characteristics:

  • Within a business process, each interaction with an IT asset is a potential service.
  • A service that mirrors (and executes) a business process, can be used to allocate IT costs and provide IT justification by correlating costs with business process results.
  • In an agile business, incremental business services – mirroring business process steps – become IT’s core deliverable.

A key indicator that a company has achieved competitive agility is when a change in business process no longer requires a change to application programming logic. Note that through SOA, IT can definitively prove business value through business results measurements. Finally, business-savvy IT architects provide the best hope a company has to bridge IT and the business units.

4 CONCLUSION

In conclusion, you better know who has their hands in your enterprises’ service cookie jar, and ensure that you know where those cookies are going. The effective implementation of SOA Governance can help you on your journey.


About the author



 

Mahesh Dodani is a software architect at IBM. His primary interests are in enabling communities of practitioners to design and build complex on demand business solutions. He can be reached at dodani@us.ibm.com.


Cite this column as follows:Mahesh Dodani: “Who Took the Cookie From the Cookie Jar?”, in Journal of Object Technology, vol. 5, no. 4, May-June 2006, pages 23-28 http://www.jot.fm/issues/issue_2006_05/column3


Previous column

Next column