Do you know where your services are and who’s using them? New applications and services developed are taking advantage of public and private API’s that are based on an SOA architectural style because of the way that public (and private) API’s and SaaS-based applications deliver their business functions. Does that mean that governance is no longer required? Is there some magic that makes application development and delivery easier when using public API’s? What about internal private API’s? How are they implemented? What is their functionality? Who is using them? Are they performing well? Are there SLA’s that are in place to define the performance and availability levels of the services? Are there SLA’s in place for public API’s or SaaS-based applications that are being used? New technology trends, such as Big Data, Cloud, API’s (both public and private), Mobile Computing and the Internet of Things all require a level of visibility as they are used to deliver new applications and services that provide greater application functionality and business value.
The reality is that governance required and is more important than ever as the business invests in these public and SaaS business functions. A pragmatic approach to governance managing the application and service life cycles is required regardless of whether internal services (private API’s) or external services (public API’s and SaaS-based applications) are being used. SOA is the architectural style that will be forced upon you as you develop new applications and take advantage of new business functionality offered by SaaS applications (the most well known is Salesforce.com) and public API’s (e.g., Facebook, Twitter, LinkedIn and others). However, building and delivering a new application still requires that a life cycle approach be used to manage the overall process and provide visibility into the design-time and runtime artifacts associated with SOA.
Application Services Governance
With the acquisition of SaaS-based business functionality or the usage of public API’s, a new governance capability is required to provide more visibility to the use and performance of such services. That, coupled with the usage of on-premise services, requires that a formal approach to governance is required. According to Gartner, application architectures using a service-oriented architecture (SOA) approach are becoming more common than ever with packaged application vendors and SaaS providers taking service orientation for granted and exposing functionality as they sell Web API’s. They have defined “application services governance” as the design, implementation, publication, operation, maintenance and retirement of API’s and services which need to be governed and managed carefully. The term refers to the union of SOA governance technology and API management. API management is the process of publishing, promoting, and overseeing application programming interfaces (API’s) in a secure scalable environment including the creation of end user support resources that define and document the API. SOA governance is the set of activities related to exercising control over services in a service-oriented architecture in accordance with recognized practices, principles and government regulation.
The question is, can you afford to implement application services governance (ASG)? The cost of implenting ASG depends on the adoption and cost of technology to manage governance processes as well as the governance model adopted. Using open source technology options, the cost of implementation can be reduced but it takes more than that. A governance model and framework needs to be developed and implemented. Developing a governance framework that is specific to an organization can take a lot of time and money. Consideration of a governance framework such as ITIL v3 that can be implemented using an open source registry/repository and API manager (e.g., WSO2 Governance Registry and API Manager) results in lower costs and reduces the amount of time to implement.
Why is Application Services Governance Needed?
The goal of governance in general is to align people, processes and technology. Addressing each of these is critical to assure that business and IT priorities are aligned and provides the organization with insight into process as well as IT resources. By taking a standard approach to building, deploying and maintaining applications and services, business agility can be improved and lower total cost of ownership realized. There are many reasons why ASG should be considered. From a more strategic perspective, lack of visibility into services and users of the services leads to poor decision making regarding new investments. Service reuse is not fostered and results in wasted investments when services that have been developed are unknown to other teams within the business. Determining what services are causing application or service performance problems requires visibility into the performance of the services. Regardless of these problems, the perceived cost of implementation of governance is assumed to be too expensive. More and more visibility is required to: 1) understand what API’s (services) are in use (from a design perspective) and what applications are using them, 2) assure security, 3) understand the performance of services being used (from a runtime perspective), and 4) close the loop on continual service improvement. That is not to say that there are no governance processes being used to manage service and application life cycles, but the processes may be very informal and specific to a project team or application and are ad hoc in nature and known by only a few in the organization. If additional motivation is needed to understand why governance is needed, a Forrester survey in 2009 showed that of 579 companies implementing SOA, 25% of the companies received maximum benefit from implementing SOA, 36% received some benefits and planned to continue to take advantage of SOA and 20% of the companies did not receive any significant benefit from SOA. The adoption of processes and best practices was an important first step in starting a governance initiative with appropriate governance technology required to efficiently manage the process. Due to the cost of governance technology, the survey suggested that best practices and processes are implemented first in order to justify the high cost of governance technology.
There are ways to implement ASG that do not require a large investment in time, resources and money. Open source software provides a cost-effective way to provide the technology components that address the life cycle phases (e.g., design-time and runtime phases). The discovery and assessment of existing informal processes created by siloed project teams is expensive and time consuming. More importantly, if the company is a startup, there are typically few or no processes developed simply because the goal is to get a product into the hands of customers as fast as possible. To reduce the effort in developing unique governance processes for your organization, adopting a well known framework such as ITIL v3 provides process identification for ASG implementation. Using ITIL v3 as a governance model and framework reduces the time and effort to implement governance processes.
Application and Service Life Cycle
The application and service life cycles generally include the planning, design, develop and deploy (implementation), runtime and optimization phases. For those familiar with ITIL v3, you will recognize that these phases very closely map to the ITIL v3 phases of Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement. ITIL is not a prescribed method for implementation but a framework that can be used to fit the organization based on its current state. For example, a mature organization may implement all of the ITIL processes and functions while a startup organization may (and should) adopt a minimalist implementation of the ITIL processes and functions. Regardless of the size of the company, there are a core set of functions and processes that inevitably are addressed even if a formal approach to governance is not considered.
The common phases of the application and service life cycle process are generally: 1) Plan, 2) Design 3) Develop and Deploy, 4) Run and 5) Optimize. The ITIL phases include: 1) Service Strategy, 2) Service Design, 3) Service Transition, 4) Service Operation and 5) Continual Service Improvement. The mapping of the phases is shown in Table 1.
Application Life Cycle and ITL v3 Mapping |
|
Application Life Cycle Phases |
ITIL v3 Phases |
Plan |
Service Strategy |
Design |
Service Design |
Develop and Deploy |
Service Transition |
Run |
Service Operation |
Optimize |
Continual Service Improvement |
Table 1. Application Life Cycle and ITIL v3 Mapping
A full implementation of ITIL implementing all processes and functions within an organization is not likely simply because of the time, effort and cost of doing so. There is much effort put into the definition of bespoke application and service life cycle processes that have typically grown out of necessity to manage requirements and artifacts associated with a project. However, much of this effort is decoupled and is maintained as a work effort within project teams in the organization. The governance processes are normally incomplete or non-existent. Using ITIL v3 as the governance model, application services governance can be implemented with less effort and less expense but can take advantage of the organization’s existing processes that have been developed over time.
Using WSO2 Middleware for the Technology Component of Application Services Governance
A governance model, best practices, people, processes and technology are required to fully implement application services governance. Integration between technologies that help to support the design-time and runtime processes is an important consideration as it supports the governance processes and functions implemented. Choosing the right technology will be critical to overall success of your governance project since there are many integration points that need to be considered. Rather than spending time (and money) integrating technologies into a mixed technology environment, one should consider a common technology environment that includes technologies that are integrated out of the box. WSO2 open source software integrates technologies and functions across the application life cycle and includes a governance registry and repository and API management components. A reference for implementation is shown in Figure 1. where best practices is the coupling between governance and technology wrapped by a governance model to assure that application services governance is successful. Note that API management is part of the technology support required for implementation and provides visibility to the mix of public and private API’s that are commonplace in today’s business applications.
Figure 1. Application Services Governance Implementation
A centralized registry and repository is a key component of ASG. It is used to manage the artifacts that describe the application or service from a design and runtime perspective. API management provides runtime visibility to public and private API’s that make up part of an application. Service reuse will be more commonplace since many of the application components that are used in new application or service development are public API or SaaS-based and require more visibility as they affect the performance and availability of applications that use these functions. In most cases, the reuse of existing private (internal) services is non-existent because there is no central registry of services that are being used and by whom and typically are known only to the project team that implemented them. Core technology required is a service registry and repository as shown in Figure 1. along with supporting technology that provides information on service availability and performance including API management. API management, a part of application services governance according to the Gartner definition, provides a level of visibility to services being used including the ability to throttle or control the level of service that a user has agreed to. This type of information is required from an operations perspective (see ITIL processes discussed previously) but it is also required to assure that services are meeting agreed upon service level requirements.
ITIL v3 Implementation
ITIL v3 consists of seven governance processes, nineteen operational processes and four functions. They are categorized under the five phases of the ITIL framework. There are many reasons why companies do not implement all of the processes and functions with some of them being cost, no customer support, time constraints, ownership and others (1). If you are implementing an SOA project where governance is not considered to be important (using the “time constraint” or “cost” arguments), there are a core set of functions that are carried out from an SOA life cycle perspective that can be mapped to governance processes. ITIL v3 provides a governance framework can be identified and implemented. It is made up of twenty six (26) processes and four (4) functions but, because it is a framework, the components of the framework should be selected in a “fit for purpose” manner rather than attempt a full implementation. Time constraints and costs will always affect the level of adoption but more capability can be implemented over time as the organization matures in its governance proceses. WSO2 Governance Registry and other WSO2 middleware technologies are very effective ways to reduce the costs of implementing governance since it is open source. Adopting a ready-made model like ITIL v3 for application services governance also reduces the time involved in implementing a governance solution. More importantly, it maps to the application life cycle process. Table 2. below provides a list of core processes and functions that map to the ITIL v3 phases. Of the complete list of processes and functions identified in ITIL v3, there are eighteen functions and processes that should be considered as part of an initial ASG implementation. The core set of processes that are normally in place (but likely not identified as a governance process) are shown in Table 2:
Pragmatic SOA Governance Model Using ITIL v3 Framework |
||||
Continual |
||||
Service |
Service |
Service |
Service |
Service |
Strategy |
Design |
Transition |
Operation |
Improvement |
Strategy Generation |
Service Catalog Management |
Change Management |
Incident Management |
Service Improvement |
Service Level Management |
Release and Deployment Management |
Problem Management |
Service Reporting |
|
Availability Management |
Service Asset and Configuration Management |
Request Fulfillment |
||
Capacity Management |
Event Management |
|||
Service Desk |
||||
Technical Management |
||||
IT Operations Management |
||||
Applications Management |
Table 2. Core ASG Implementation Processes and Functions
ITIL Phase and Technology Requirements
Table 3. shows the ITIL phase and technology requirements. Using open source solutions such as WSO2 (referenced in the table), cost can be reduced in implementing ASG. Using a ready-made governance framework like ITIL v3 can dramatically reduce the time to implement since the processes and functions are already defined as part of the ITIL v3 framework. Mapping existing bespoke life cycle processes into the ITIL v3 framework assures that you can take advantage of your existing processes or provides a guide for adding to or creating additional processes. The value is that the life cycle is no longer a series of silos but a continuous process where applications and services are continuously developed and improved.
Governance Technology Matrix |
|||
Governance |
|||
ITIL v3 Phase |
Process/Function |
Technology |
Phase |
Service Strategy |
Design-time |
||
Strategy Generation |
WSO2 Governance Registry |
|
|
Service Design |
Design-time |
||
Service Catalog Management |
WSO2 Governance Registry |
||
Service Level Management |
WSO2 Governance Registry |
||
Availability Management |
WSO2 Governance Registry |
||
Capacity Management |
WSO2 Governance Registry |
||
Service Transition |
Design-time |
||
Change Management |
WSO2 Governance Registry |
||
Release and Deployment Management |
WSO2 Governance Registry |
||
Service Asset and Configuration Management |
WSO2 Governance Registry |
||
Service Operation |
Runtime |
||
Incident Management |
WSO2 Business Activity Monitor |
||
WSO2 Complex Event Processor |
|||
WSO2 Governance Registry |
|||
JIRA |
|||
Problem Management |
JIRA |
||
Request Fulfillment |
JIRA |
||
Event Management |
WSO2 Business Activity Monitor |
||
WSO2 Complex Event Processor |
|||
WSO2 Governance Registry |
|||
Service Desk |
JIRA |
||
Technical Management |
WSO2 Business Activity Monitor |
||
WSO2 Complex Event Processor |
|||
WSO2 Governance Registry |
|||
WSO2 API Manager |
|||
IT Operations Management |
WSO2 Business Activity Monitor |
||
WSO2 Complex Event Processor |
|||
WSO2 Governance Registry |
|||
Applications Management |
WSO2 Business Activity Monitor |
||
WSO2 Complex Event Processor |
|||
Continual Service Improvement |
Runtime |
||
Service Improvement |
WSO2 Governance Registry |
||
Service Reporting |
WSO2 Business Activity Monitor |
Table 3. ITIL v3 Core Processes and Technology Requirements
WSO2 is an excellent choice of technology to implement ASG since it: 1) provides many of the technologies required to manage and support an SOA initiative, 2) provides technology integration from a life cycle and runtime perspective, and 3) eliminates software license costs that can become a large part of the SOA initiative. WSO2 is named a “visionary” in Gartner’s Application Services Governance Magic Quadrant published in August 2013.
Application Services Governance – The Value Versus the Effort
Application services governance is a critical part of managing the application life cycle and improving existing services that have been developed. With today’s applications being developed using a mix of public and private API’s and SaaS-based applications, there is a greater need for accountability and visibility as businesses pay for performance and function. Many companies, from startups to more mature organizations, do not take the time to address ASG. It is not easy nor inexpensive unless there are approaches that will save time and money. There are two major cost items involved in implementing governance solutions which are: 1) discover, develop and implement management processes, and 2) technology costs. Using ITIL v3 as a governance model framework for ASG and WSO2 middleware technology, both of these costs can be minimized creating greater value for the enterprise and promoting greater reuse of existing services.
References
1. Fry, M., “ITIL Lite A road map to full or partial ITIL implementation”, The Stationery Office (2010).
David Ching
David has founded or co-founded companies that delivered cutting edge monitoring and management products. He spearheaded the development of one of the first business transaction monitoring products in the APM market. David currently is the founder of iBIT, a consultancy that delivers application consulting, implementation and managed services using an open source middleware platform from WSO2. He believes that the use of open source software will become mainstream among both enterprise and small medium business organizations. He has Bachelor of Science, Master of Civil Engineering and Doctorate in Civil Engineering degrees from the University of Minnesota.
Recent Comments
- minecraft on ITIL v3, WSO2 Middleware and Pragmatic Application Services Governance
- chaussure mercurial on WSO2Con 2013 US – Customer Adoption of Open Source Middleware
- Accelerating Your Knowledge on WOS2 Open Source Middleware | iBIT Blog on WSO2Con 2013 US – Customer Adoption of Open Source Middleware
- Analysts View of WSO2 Open Source Middleware | iBIT Blog on WSO2Con 2013 US – Customer Adoption of Open Source Middleware
Archives
Categories