BACKGROUND
The invention relates generally to service catalog, and more particularly relates to actionable information technology (IT) service catalog framework.
The IT Service catalog is a solution that helps IT organizations showcases the value of IT services they deliver to their business customers. It focuses specifically on articulating and documenting these services facilitating service request and fulfillment and modeling /modifying service portfolios.
The disconnect between business goals and IT priorities consistently ranks among the top three issues facing chief information officers (CIOs) year after year. At the heart of this problem is a lack of trust between customers and IT, where Business customers and end-users do not trust that IT organization is capable of taking the business forward. Faced by these challenges, many IT organizations are in the midst of transforming to a customer-centric & deniand-driven service model. Service Catalog is essentially the first step - and a fundamental requirement - in transforming the IT organization by re-establish the trust between IT and Business
IT Infrastructure Library (lllL) V2 & V3 provides an overview of the need for a Service Catalog, however dire is no practical guidance on how to build and manage them.
Service catalog products and software tools available in the market provide a variety of functionalities for organizations to help them configure services. However they do not provide the step-by-step guidance to implement services, in alignment with service stakeholders and customer needs, and manage them in the catalog.
During Service Catalog adoption, large IT organizations typically face the following challenges: Determining the scope of services and identification of service owners; Understanding the moping of Multiple vendors' and internal IT services, for

bundling into the Service Catalog; Define to-be state for services and manage their overall lifecycle; and Drive improvements to services and the catalog.
Organizations tried to address the Service Catalog implementation from a conventional technology solution standpoint, assuming that tike technology will enable them to design and manage services end-to-end. However there were many critical aspects with respect to the program that the technology or even the best practices framework like IllL cannot address.
Due to the lack of reference standards in this area, organizations are increasingly looking at practitioner guidance and direction in building and managing actionable service catalogs.
Hence, there was need for strategic framework that provides end to end guidance to manage the lifecycle of services through service discovery and drive improvements to the service experience and customer satisfaction. The proposed framework components enable an organization to jumpstart and manage a service catalog program end-to-end.
BRIEF DESCRIPTION
In one embodiment of the present technique, a method for developing an IT service catalog at large organizations is disclosed. The method is comprising of service domains for services to move through various lifecycle stages within the IT service catalog from their point of inception to it's decommission; and domain components for each service domain to fulfill certain objectives during the services' journey through tiie IT Service Catalog. The proposed method is a process oriented framework to the development of IT Service Catalog at large organizations.
The proposed method (or framework) provides end to end guidance to manage the lifecycle of services through service discovery and drive improvements to the service experience and customer satisfaction. The framework components enable an organization to jumpstart and manage-a service catalog program end-to-end.

In another embodiment of tiie present technique, a method defmes five lifecycle domains called Service Domains. The lifecycle activities of services in these domains are facilitated through four domain components viz. Processes, Process Assets, Domain metrics and Process roles. The proposed fi-amework is scalable and can be utilized as a framework for building and managing business or technology oriented service catalogs.
DRAWINGS
These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in w^ich like characters represent like parts throughout the drawings, wherein:
FIG. 1 is a schematic representation of a proposed framework for actionable IT service catalog, in one embodiment of the present technique;
FIG. 2 is a block diagram of a service domains of the proposed framework, in one embodiment of the present technique;
FIG 3 is a block diagram of a domain components of the proposed framework, in one embodiment of the present technique;
I FIG. 4 is a diagram showing tfae various processes associated with the service
acquisition domain of the proposed framework, in one embodiment of the present
technique; >
FIG 5 is a diagram showing the various processes associated with the service design domain of the proposed framework, in one embodiment of the present technique;
FIG, 6 is a diagram showing the various processes associated with the service deployment domain of the proposed framework, in one embodiment of the present technique;

FIG. 7 is a diagram showing the various processes associated with the service improvement domain of the proposed framework, in one embodiment of the present technique;
FIG. 8 is a diagram showing tiie various processes associated with the service decommission domain of the proposed framework, in one embodiment of the present technique; and
FIG. 9 is a system illustrating a generalized computer network arrangement, in one embodiment of the present technique.
DETAILED DESCRIPTION
The following description is full and informative description of the best method and system presently contemplated for carrying out the present invention v^iiich is known to the inventors at the time of filing the patent ^plication. Of course, many modifications and adaptations will be ^parent to those skilled in the relevant arts in view of the following description in view of the accompanying drawings and the appended claims. While the system and method described herein are provided with a certain degree of specificity, the present technique may be implemented with either greater or lesser specificity, deperiding on the needs of the user. Further, some of the features of the present technique may be used to advantage without the corresponding use of other features described in the following paragr^hs. As such, the present description should be considered as merely illustrative of the principles of the present technique and not in limitation thereof, since the present technique is defined solely by the claims.
As a preliminary matter, the definition of the term "or" for the purpose of the following discussion and the upended claims is intended to be an inclusive "or" That is, the term "or" is not intended to differentiate between two mutually exclusive alternatives. Rather, the term "or" -w^en employed as a conjunction between two elements is defined as including one element by itself, the other element itself, and combinations and permutations of the elements. For example, a discussion or recitation employing the terminology "A" or "B" includes: "A" by itself, "B" by itself

and any combination thereof, such as "AB" and/or "BA." It is worth noting that tiie present discussion relates to exemplay embodiments, and the appended claims should not be limited to the embodiments discussed herein.
The present invention relates to service catalog, and more particularly to actionable information technology (IT) service catalog framework.
_ The disconnect between IT and Business has triggered the need for an actionable Service Catalog, vAere IT communicates its values to its customers and is treated as a profit center rather than a cost center. To run IT in a customer oriented and service centric fashion, the service customers need to be provided with transparency and visibility into the services and value delivered by IT. Actionable catalog offers a service interface for business, IT and end-users to request, approve and track services and its delivery.
The IT Service catalog is a solution that helps IT organizations showcases tiie value of IT services they deliver to their business customers. It focuses specifically on articulating and documenting these services, facilitating service request and fiUfillment and modeling /modifying service portfolios. Organizations are increasingly adopting actionable service catalogs and adopting a "services" view as recommended by industry standard frameworks as in ITIL V3. Service catalogs are made actionable by incorporating Service Request and Service portfolio functions for the in scope services. This c^ability should allow customers and end-users to browse through services, their attributes, options and costs and request them as needed.
In one embodiment of the present technique, a method for developing an IT service catalog at large organizations is disclosed. The method is comprising of service domains for services to move tiirough various lifecycle stags within the IT service catalog from their point of inception to it's decommission; and domain components for each service domain to fulfill certain objectives during the services' journey through the IT Service Catalog. The proposed method is a process oriented fi-amework to the development of IT Service Catalog at large organizations.

The proposed actionable service catalog method is a strategic framework that has components that will help organizations jumpstart or manage Service catalog
initiative.
The proposed method or framework help organizations plan, design and implement actionable service catalog and manage the life cycle of the services effectively and predictably through thje usage of framework components.
Refeiring to FIG. 1 which is a block diagram of the proposed framework for actionable service catalog. The Service Domains 100 represent flie different stages in the life cycle of a service. Each Domain fulfills its objectives through the Domain components 110.
Referring to FIG. 2 which shows the service domains i.e. the different stages within the lifecycle of a service. Services move through various lifecycle stages wdthin the catalog from their point of inception to its decommission. These stages within the lifecycle of a service are called Service domains 200. Each domain represents a unique nature of a service in terms of its structure, composition and behavior. There are following service domains as shown in the FIG 2: Service Acquisition 210, Service Design 220, Service Deployment 230, Service Improvement 240, and Service Decommission 250.
Service Acquisition 210: This is a domain where the needs for services are validated and service information are gathered effective & timely through structured service engagements.
" Service Design 220: This is a domain w^iere the service requirements are translated to design specifications to facilitate ati automated request and fulfillment
processes.
Service Deployment 230: This is a domain w^ere the service design specifications are translated into configurable, service objects and exposed to customers.

Service Improvement 240: This is a domain wAere services are constantly improved in terms of delivery and' user experience through a constant cycle of monitoring, reporting and enhancements.
Service Decommission 250; This is a domain w^iere the services are optimized in a cost effective manner by transforming services or decommission of services with minimal or no organizational impact, ••
. •
Referring to FIG. 3, which shows the different domain components of tiie proposed method/framework. There are following domain components 300 as shown in the FIG. 3: Processes 310, Metrics 320. Assets 330, and Process Roles 340.
Processes 310: These are sequence of activities performed to manage services in its lifecycle domains.
Metrics 320: These are set of parameters defined for tracking and improvement of services within their Domains.
Assets 330: This enables decision making and movement of Services through the Service domains.
Process Rol« 340: These are roles that facihtate the end to end flow of services through the Service Domains.
Each Service domain fulfills certain objectives during the services' journey through the IT Service Catalog. The Domain objectives are fiilfiUed through the foUovnng Dom^n components are as follows:
Processes 310: The processes provide a step by step procedure for the Service Domains to accomplish their objectives.
j Process Roles 340: The roles that control and monitor the Domain processes
Assets 330: Various process assets that captures service information & enable effective decision making

Metrics 320: The measurement and ijoiprovement of services are enabled through metrics.
J In another embodiment of the present technique, there are several service groups are associated with the proposed method/framework. Following Table I shows the various service groups and their roles and functions in the proposed framework.

Service Groups Role Description / Functions
Service Relations group (SRG) Service Relations Group (SRG) is a group responsible for Coordinating the new service engagements. They create awareness about tlie service catalog program among the service stakeholders and engage service owners to absorb services in the catalog.
Service
Implementation group (SIG) Service implementations Group (SIG) oversee the service
•
design and deployment activities and coordinates activities between the service owners, design teams and deployment teams for effectfve service development and rollout.
Service Assurance group (SAG) Service Assurance Group (SAG) ensure timely improvements for services and'service catalog including delivery process, usability, training and support. Th^ also ensure controlled change management for service improvements and decommissioning so that end users are least impacted and business continuity is ensured.
Service Anchors Service Anchors coordinate all project level activities for tiie service absorptipn and support. They periodically
•
communicate the status to higher mans^ement. They provide direction to project / delivery teams for task execution and information updates to SRG & SIG
Service Enhancers Service Enhancers coordinate the service improvement activities by keeping track of improvement opportunities and obtaining required approvals for executing changes. They

provide inputs to monitoring and reporting team, user interface teams and delivery team to execute service improvements and changes
User Interface team User Interface team is responsible for identifying end user satisfaction levels. They also provide inputs for service design for the service and catalog usability and also review service design / improvements for usability.
Delivery team Delivery teams are the project teams responsible for service deign, deployment, improvement and decommissioning execution.
Monitoring and reporting team Monitoring and.reporting teams maintain and measure service and catalog metrics and provide timely reports to SAG.
Table 1: Service Groups and their Functions
Each service domain has various processes associated with it. Referring to FIG. 4 which shows the processes associated with the Service Acquisition domain. Service Acquisition 400 aims at obtaining alignYnent & sponsorship from organization Service group leadership on service t^talog program and enables Relationship team to gather requirements and translate to build an Engagement Plan. Service Acquisition 400 also lays the foundation for initpal 'assessments and validation of services in the engagement plan to help create a Release Plan for the implementation team.
Referring to FIG. 4, the Discover process 410 sets the base for enabling absorption of services into the Service Catalog: It defines a mechanism to build an engagement plan tiirough a leadership aligned Strategy. The process engages service groups to create awareness and set expectations for the Kigagement through workshops. The project teams for service engagements are identified and initial engagement plan is created. A high-level, initial list of services to start the service engagements is identified and validated with service owners during this process. It also enables a mechanism to capture ad-hoc requests (dynamic requests that may rise during engagements). Templates/Assets are used to facilitate the processes. All details

relevant to the engagements are updated in a'single repositoiy referred to as the Service Knowledge base (SKB).
Referring to FIG. 4, the absorb process 420 helps effective c^ture of service information to enable appropriate analysis and design of the Service in die IT Service Catalog. It provides high level procedures to collate service requirements pertaining to usability, business requirements, provider requirements, technical and system requirements. The readiness of the gathered requirements is assessed during tiiis process and requirements gathering is re-initiated as needed.
Referring to FIG, 4, the confirm process 430 helps collates the requirements gathered in the previous phase and defines, verifies and validates the service Point of Arrival (POA) model. The POA model is validated witii all service stakeholders during this process. The POA model defines high-level funding and resourcing needed for executing the implementation plim. A System Analysis Report (SAR) is created to document the analysis of requirements, POA model and design expectations. SAR is used as reference point for Service design documentation and Service deployment.
Referring to FIG. 4, the agree process 440 helps ensure that all stakeholders are aligned with the System Analysis Report (SAR), The SAR need to be in-line with the service strategy recommendations. If there me acceptance issues, the SAR needs to be modified to incorporate changes. The approval of SAR kicks off the design activities. The engagement plan needs to be updated with the details of approval / rejection & lessons learnt. A high level Release plan is finalized. The process ensures that all documentation is stored at central location for access by varioiK teams during subsequent processes.
The following Table 2 shows the process assets and their role description and usage with respect to the service acquisition domain.

Process Assets Description Usage Process Areas
Engagement Plan A plan that keeps track of Service engagements Helps in identifying potential groups that need to be engaged and tracks die ongoing engagements Discover
Catalog Overview deck Overview of Service Catalog program Provides insight of the program to service stakeholders Discover
Initial Services
list List of potential services to start discussions for tiie engagement Initial list of services for the engagement, that would eventually be validated and accepted for the Release Discover
Initial Project plan C^ture initial project plan details for service engagement The initial Project Plan is crated based on understanding & updated periodically to reflect status of the engagement Discover
ER / Ad-hoc ER Engagement Request & ad-hoc requests Record for tracking specific service engagement Discover
Service Requirement gathering template Gather Provider & Business requirements Used by Service Owners / SME / Provider to capture service needs Absorb
Usability & SLA Requirements Customer needsin terms of usability and SLAs
1 SLA & usability requirements that are captured and validated with providers & customers Absorb

Hi^-level
technical
requirements Detailed technical requirements gatiiered for the service Detailed requirements used in Creating the POA model Absorb
Reporting requiiements Detailed Service related reporting requirements Detailed requirements used in developing the service related reports within Service Catalog Absorb
Project plan Initial Project plan Project Plan created based on high level infonnatlon gatfiered Absorb
Service readiness checklist Readiness criteria for the information gathered Used to validate level of acduat^ & completeness of information gathered Absorb
Service standards (SLAs) Required SLAs for services Provides Service level related recommendations based on current & business ne^ Confirm
Usabihty recommendations Required usability standards Recommendations based on Client and business needs Confirm
POA model Point of arrival model for service POA model for services created based on the current and. future service needs Confirm
POA
recommendations & Cost est. report Point of Arrival & cost estimation report Report feasibility of POA model & recommend any required changes Confirm
System Analysis Report (SAR) High-level Service Analysis Report SAR provides a summary of service needs, POA model its feasibility, cost & Confirm

resource estimate to the committee layer to enable approval of the engagement request
Potential Release Plan Estimated calendar for Service releases Potential release dates for services within the engagement plan Confirm
Release Plan Release timelines for services C^ture services scheduled as part of a release, capture dependencies and order of release Agree
Key learnings document Detail theleaming from the engagement Used to leverage learning in future engagements Agree
Design Handover checklist Handover checklist Checklist to ensure completeness of service requirements documents before it proceeds for design phase Agree
Table 2: Process Assets for Service Acquisition Domain
Referring to FIG. 5, which shows the processes associated with the Service Design domain. Service Design 500 aims at translating the service requirements gathered into design specifications for services that need to be populated in the catalog. Service Design SCO provides tiie foundation for definite & validating service configuration and workflows for the implementation team.
Referring to FIG. 5, the initiate process 510 facilitates the formal handover of all relevant documentation from the Acquisition phase to the Design phase. It involves engaging project team for detailed analysis of POA model & requirements enabling evolution of design for tiie service. The Project team liaises with tiie

Relationship team, service owners, business & providers for any additional information required as part of their analysis. The team develops the Design document detailing to be workflows and configuration. A draft project plan is created to start the design phase activities. Based on the detailed design, the project plan and the resource plan are updated.
Referring to FIG. 5, the confirm & agree process 520 involves gaining alignment from service stakeholders on the service design. Once the high-level design is created, the project team obtains alignment from service owner for the configuration and design of service & subsequently obtains alignment fi-om Service Anchors Team for resource requirements and release timeliness. In tiie instance of non-alignment the 'Initiate' process is triggered to re-validate the Design document and incorporate modifications. The details are updated in the final project plan and Service Knowledgebase (SKB) is updated based on the findings of tiie design stage. The process 520 also takes care of preparation for design walkthrough by the design team to the development teams,
, The following Table 3 shows the process assets and their role description and usage with respect to the service design domain. ■

Process Assets Description Usage Process Areas
Design Handover
checklist Handover checklist ■Checklist to ensure completeness of service requirements documents before it proceeds for design phase
i: Initiate
Service
configuration
template Template to gather service configuration information Instructions and guidelines to c^ture different customizations for service (configurations) and workflows associated Initiate

Design document Document that provides design specifications for the Service _i 1
Detailed design specifications for the service along with detailed workflows & configuration det^ls Initiate
Design phase
summary
document Document that provides design specifications summaiy for the Service Design phase summaiy document provides a high level overview of the design for Committee layer review Confirm & Agree
Finalized Project plan Project plan Updated Project Plan based on ^proved design documents, resource and cost estimate Confirm & Agree
Walkthrough documents Design
vrtilkthrough
documents Documents needed for Development ■ team walkthrough Confirm & Agree
Table 3: Process Assets for Service i!)esign Domain
■1 Referring to FIG, 6, vAich ^ows the processes associated with the Service
Deployment domain. Service Deployment 600 aims at translating service design
specifications into configurable service objects within the Service Catalog. Service
Deployment 600 ensures diat required documentations and training are executed and
communication is rolled out to enable .effective usage of services rolled out.
Referring to FIG. 6, the configure process 610 focuses on creating initial service design prototype/mockup and validating it with service stakeholders. It outlines the steps associated wifti configuring services in the development environment including the provisioning system.. Test cases for the services are created and validated. Unit level testing is performed and test plan is updated. The unit testing is conducted during this process in the development environment and furdier tests or design changes are derived based on the result of testing.

Referring to FIG. 6, the simulate process 620 focus on conducting system testing for the configured services in test environment The defects identified are validated for configuration or design level changes. All tfie defect resolution changes are carried out in the development environment with controlled version changes. Based on the test results and validation, services are promoted to the production environment for conducting UAT. The process 620 also facilitates exception ^proval for those issues tiiat are not configuration or design related. In the instance of un^proved exceptions the 'Design' domain for the'service is revisited.
Referring to FIG. 6, tiie release process 630 ensures release of service into production environment. The process outlines various pre-requisites that enable this movement including deployment plan verification, identification of support teams, readiness assessments, and creation of training manuals and FAQ for support teams. The rollout and back out plans are also created for the service and approved from service implementations teams before the final rollout to ensure minimal impact to production environment. In the instance of an unsuccessfiil deployment, the service is backed out & a post implementation review is conducted for review and documentation of leaming's. The process 630 ensures effective transition of service to production environment and readiness levels of support teams. It also initiate retirement activities for any existing service to be retired as per new service plans.
Referring to FIG. 6, the transition process 640 covers service transition to the support teams. The support is transitioned in a phased manner to ensure knowledge transfer and reduced impact to services. Transition plan and support handover documents are prepared for this purpose. Communication to the stakeholders and user community plays important role in this process for effective transition of service support. The knowledge transfer is carried out in two phases to ensure and validate the ability of support team to support the transitioned services. A formal transition sign-off procedure is followed to ensure readiness of the support team to support the service.
The followng Table 4 shows the process assets and their role description and usage with respect to the service deployment domain.

Process Assets Description Usage Process
Areas
Service Mock-up Template A document used to detail flie mock-ups for services Used for conducting mock-ups and documenting key learnings Configure
Test Document A document for planning and testing of the services in Test env. Testing plan for service with detailed test cases and timelines Configure
Services in Dev Services in Development Environment Services are configured in Dev environment during service build Configure
Defect Details form Defects c^ture Record for tracking specific .defects Simulate
Defects Tracker Defects Tracker Track defects identified during development & testing Simulate
UAT Results User Acceptance Testing results Details of user acceptance
testing
Provide details of any
anomalies observed Simulate
Training manuals and service FAQ Training manuals and Frequently Asked Questions related to service Information on service usage in and list of FAQ to answer queries of users Release
Rollout & back-out plan Service rollout and backout plan Step by step instructions on ■ service roll out and back (in case of roll out failure) Release

Service Readiness checklist Service Readiness checklist for production readiness ; Check service readiness for enabling it to end users. Release
Implementation review Review of roll Out or back out Used to record details & analyze the implementation Release
Handover docs r— -^ ^- .^ ^_
Handover document for ^ support team Capture issues and other knowledge documents related to service support Transition
Transition plan Service support transition plan Plan with timelines and instructions for service support transition to support team Transition
Transition Checklist Transition Checklist . Checklist to ensure completeness of transition Transition
Table 4: Process Assets for Service Deployment Domain
Referring to FIG. 7, vAiich shows the processes associated with the Service Improvement domain. Service Improvement 7O0 aims at improving Ihe services, service delivery and the end user experience of the service and Service Catalog tool through a constant cycle of reviewing, reporting and recommending improvements to the services. Service Improvement 700 ensures that timely i^igrades are provided for services, bugs are fixed, tool is enhanced and aligned with product plan so that end to end service experience can be maintained and improved.
Referring to FiG. 7, the collect process 710 outlines the types of data that need to be collated periodically to review the service catalog performance. The data include service performance feedback, service delivery information, catalog performance data and usability related data. The reporting team creates custom reports based on the performance data collated by monitoring team.'The process 710 ensures that the reports are validated before sending it to the Service Level manager for further

analysis. These reports are reviewed to identify improvement opportunities. The Service level manager maintains a log of the improvement opportunities identified to enable tracking of enhancements to the services.
Referring to FIG. 7, the bfenchmark process 720 deals with analyzing the service delivery reports to identify improvement opportunities with respect to service delivery, catalog performance and usability of services. The service enhancers' team reviews the reports with servdce stakeholders to identify improvement opportunities. These opportunities are analyzed & action items tracked and reported. The process 720 outUnes the steps to conduct service review meetings to identify and validate improvement opportunities and recommendations. Improvement proposals are created for identified opportunities based on recommendations from service stakeholders.
Referring to FIG. 7, the plan-process 730 focuses on evaluating the impact of service improvement on service strate©' of ^e organization, service delivery, catalog performance and other related or composite services. Based on the impact levels, subsequent actions and t^iprovids need to be facilitated. The process ensures that all improvement opportunities are tracked and updated with all the subsequent actions and approvals. The process 730, ensures Aat the end-users are proactively communicated about any changes to the services. Service stakeholders also need to be communicated on any downstream /upstream, process or delivery related changes-Referring to FIG 7, the rollout process 740 focus on deployment of service improvement changes through controlled > change execution. The service improvements are executed based on the type of change required and monitored for successful execution. The improvements are routed to the appropriate groups to enable effective roll out and execution of Change with minimal impact. An implementation review report is prepared and summary of the activities are provided to stakeholders and PMO. If the improvement execution fails, the back-out plan is executed and incident is reviewed to recommend proactive measures for future changes.

The following Table 5 showsthe process assets and their role description and usage with respect to the service improvement domain.

Process Assets Description Usage Process Areas
SIO Tracker Service improvement opportunity tracker record Capture & track service
improvement
opportunities Collect
Survey questions
&
Portal Questions for user feedback Platform for the surv^s Survey questions to capture end user feedback on service delivery, catalog performance, usability Collect
Usability Reports Usabili^ analysis report User feedback analysis on services & deiivety of service through the catalog Collect
Service Feedback
report Feedback on fulfillment of services Feedback report based on end user perception on service fiilfillment Collect
Service Delivery report Report on day to day tracking of delivery of services Track service delivery against SLAs Collect
Service review meeting agenda Service review meeting agenda Detail out the discussion points considered, related to service improvement opportunity Benchmark

Service Issues &
Opportunities
Tracker Issues & Opportunities Tracker Capture and track service improvement opportunities along with details Benchmark
SIO Proposal Proposal for improvement Proposed focus areas, action items to be considered for Service improvement Benchmark
SIO criteria document Service Improvement Opportunity - Impact criteria Ctiteria used to assess the level of impact of SIO on Strategy, service operations & delivery processes Plan
Service
Improvement
Plan Detailed plan to execute Service Improvements Detailed plan with associated timelines & dependencies for service improvement Plan
Implementation review Review of roll out or back out Uspd to record details & analyze the implementation Roll out
Table 5: Process Assets for Service Improvement Domain
Referring to FIG. 8, which shows tfie processes associated with the Service decommission domain. Service Decommission 800 aims at obtaining alignment from organization Service group leadership on leUrement of services in order to optimize services in a cost effective maimer. Service Decommission 800 also ensures effective contingency plan for flie retired services by providing communication and training to the users enabling a seamless & transparent user experience.

I Referring to FIG. 8, the trigger process 810 initiates the service decommissioning procras by identifying the requirements and reviewing the request drivers. Upon receiving a request for retirement the service enhancer team retrieves all service information including tiie service's 'System analysis report' & unique identification number from the service knowledge base. Appropriate team shall be engaged based on identified information. In essence, the Retire process 830 triggers the decommissioning of services by identifying tfie impacted teams and initiate discussion with those teams.
Referring to FIG. 8, the align & agree process 820 deals with requirements gathering for service decommissioning. A detailed service decommission plan is prepared based on the discussions, analyzed requirements and effort/costs estimations for decommissioning. Approval is sought from service stakeholders and PMO based on readiness levels documented in the retirement plan. Once the approval is obtained, the SDR and project plan are updated and retirement is initiated. The process 820 ensure timely communications to and participation fi-om all impacted areas during the decommission of services. Training materials and FAQs are developed for effective awareness & communication of the decommissioned services.
Referring to FIG. 8, the retire process 830 deals with the execution of the plan for retirement of services. The process 830 ensures that the pre retirement activities like ensuring the completion of retirement documents, handover checklist and training to support teams are complete. Th^ service is decommissioned based on the pre-^proved plan. Back-out plan needs to be triggered in case of failure. All the stakeholders and end-users are communicated alDout the retirement of services. A decommission closure report is abated and updates are provided to the Change Manager to enable formal closure of decommission of service. A parallel track for Training and knowdedge sharing is followed to enable appropriate levels of knowledge to the support teams. , The following Table 6 ^ows the process assets and their role description and usage with respect to the service decommission domain.

Process Assets Description Usage Process Areas
SDR Service
decommission
request A record for tracking specific service decommission progress Trigger
Service decommission criteria checklist Service decommission criteria checklist Used to validate criteria for service decommission Trigger
Decommission Project Plan Project Plan Project Plan based on understanding of requirements, drivers for retirement and details the resource and cost estimate along with activities that need to be executed for retirement Align
&
Agree
Training materials & FAQs Training material for end users & support team Provides instructions / guidelines on support provided during / after service is decommissioned Align
&
Agree
Decommission Summary doc. Decommission
summary
document C^ture summaiy of service retirement request, retirement requirements, retirement plan, effort and cost estimates and contingency plan. Align
&
Agree
Decommission
Readiness
checklist Decommission Readiness checklist for retirement readiness Check readiness for disabling Service to end users Retire
Handover Handover Checklist to ensure completeness of Retire

checklist - Checklist service requirements documents before
Decommission it proceeds for design phase
Summary report A report that summarizes the high level
Closure report on service : details of completed retirement Retire
retirement activities for review by leadership
Table 6: Process Assets for Service Decommission domain
In order to meet the Service Domain' objectives and drive continuous
improvement to services and catalog, k^ performance indicators and associated
metrics are identified. Metrics are defined for each of the Domain areas as shown in
the following table 7. •

Service Domains J ^ —"
Metncs Process Areas
Service Acquisition ■ No. of Engagement requests (ERs)
cjQ)tured '.
■ No. of engagement completed
■ No. of engagements iii progress
■ No. of ad-hoc requests raised Discover

■ No. of Service POAs created
■ No. of Service POAs approved Confirm

■ No of System Analysis Reports
(SAR) submitted
■ No of Sysftem Analysis Reports
(SAR) ^proved
" Average duration from the time of request initiation to SAR completion Agree
Service Design " No. of ERs for wiiich the handover to the design team is complete
" No. of handovers completed as against SARs (System Analysis reports) completed
• Averse time to handover Initiate
Service
T-l. .1 . ■ Duration spent by a Service in the Dev environment Configure

Deployment ■ Duration sp^t by service in E2
environment
■ No. of defects identified during
testing
■ No. of defects identified during
testing due to design issues
■ No. of exceptions raisM
■ No. of exceptions approved
■ Duration spent by a Service in Test
environment
■ No. of services scheduled Simulate
Service Deployment ■ No. of services implemented
■ No. of service issues post
Deployment
■ No. of unsuccessful deployments
■ No. of backed out deployments Release

■ No. of issues raised by severity
■ No. of support documents /FAQs
created Transition
Service Improvement ■ No. of services covered
■ No. of vendors covered
■ No. of fiilfillment teams covered
■ No. of usability survey? completed
■ % of reports completed on time Collect

■ No. of Service review conducted
■ No. of recommendations suggested
■ No. of SIOs created based on
recommendations Benchmark

■ % of SIOs implemented
■ No. of SIOs implemented as against
SIO realized Roll out
Service Decommission ■ Number of decommission opportunities identified Trigger

■ Number of service issues post
decommission
■ Number of retirements backed out Retire
Table?: Service Domain Metrics
The following Table 8 describes the service domain objectives and their scope in one embodiment of the present tedinique.

Service Objectives Scope
Domains ;
Service • Identification of potential • The Domain processes
Acquisition Services that may be^ c^ture requirements

offered through Ae IT for Request and
Service Catalog Fulfillment aspects of
• Enable a stioictured Services and not
approach for service ^plicabletothe
information gathering and delivery aspects of the
validation service
• Ensure leadership • Tlie to be state of
alignment and continual services consider the
support for Service means to offer services
engagements through the catalog
• Facilitate collaboration interface and not
between Service enhancements to the
stakeholders and Catijlog backend delivery
team to define & align on a mechanisms and
to be model for services processes
Service Design • To model a request and • The service design and
fiilfillment process for the configuration in this
identified services domain ad^esses the
• Define and validate the request and fulfillment
design for services aspect of the services
configuration and and not the design for
automation actual services itself
* To aisure that all the • The inputs considered
design documents, models for service design are
and analysis reports are service requirements
properly handed over to the (request & fulfillment).
service d^loyment tfiam usability and SLA
-. requirements
Service • Effective translation of • Deployment involves
Deployment service design configuration of

specifications into services within the
configurable objects in ITSC and its interaction
production environment. with Provider's
• Deployment of validated & rehable services in the production environment
« Smooth deployment and phased support of the services With minimal or no impact to users fijfillment tools.

Service • A methodical c^ture;of • Scope of the Domain
Improvement Usability,, Process, &, processes are limited to

Service delivery related changes that bring
data tangible improvements
• Effective arialysis to to tiie service attributes
identify ^propriate defined in the Catalog
Service Improvement (Eg: Service Levels &
opportunities • Mechanism for successful implementation of improvements Cost)
Service • Optimization of services to • Decommission of
Decommission improve services and. services and service

reduce costs components are limited
• Proactive management of to the service
service decommission to components in ITSC
minimize effect of and m^ not consider
retirement upon service the components in the
quality & user perception Provider environment
Table S: Service Domain Objectives and scope
Thus the proposed actionable service catalog method offers a service interface for business, IT and end-users to request, ^prove and track services and its deliveiy. The Actionable Service Catalog method/framework will deliver benefits to:
Business Users - Increased transparency for services & its cost and assist in annual planning & budgeting for services;
End-users - A shopping cart view few requesting, and tracking of services that they are entitled to; and
Service Delivery Managers - Help" manage Service delivery by ensuring service deliveiy in alignment with the agreement
The service catalog is made actionable by building a layer of request and fulfillment over the cataloged services and its attributes as described in one embodiment of the present technique. This allows the customers to view services and the options available, request and avail'IT services' as needed.
Exemplary Computing Environment

One or more of the above-described techniques may be implemented in or involve one or more computer systems. Figure 9 illustrates a generalized example of a computing environment 900. The computing environment 900 is not intended to suggest any limitation as to scope of use or functionality of described embodiments.
With reference to Figure 9, the computing environment 900 includes at least one processing unit 910 and memory 920, In Figure 9, tiiis most basic configuration 930 is included within a dashed line. The processing unit 910 executes computer-executable instructions and may be a real or a virtual processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. The memory 920 may be volatile memory {e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two. In some embodiments, the memory 920 stores software 980 implementing described techniques.
A computing environment may have additional features. For example, the computing environment 900 includes, storage 940, one or more input devices 950, one or more output devices 960, and one or more communication connections 970. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing environment 900. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing enviroimient 900, and coordinates activities of the components of tiie computing environment 900.
The storage 940 m^ be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, Ci)-RWs, DVDs, or any other medium which may be used to store information and vv^ich may be accessed within the computing environment 900. In some embodiments, the storage 940 stores instructions for the software 980.
The input device(s) 950 may be a touch input device such as a keyboard, mouse, pen, trackball, touch screen, or game controller, a voice input device, a scanning device, a digital camera, or another device that provides input to the

computing environment 900. The output device(s) 960 may be a display, printer, speaker, or another device that provides output from the computing environment 300,
1 The communication connection(s) 970 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, audio or video information, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired or wireless techniques implemented with an electrical, optical, RF, infrared, acoustic, or otiier carrier.
Implementations may be described in the general context of computer-readable media. Computer-readable media are any available media that may be accessed within a computing environment. By w^y of example, and not limitation, wifliin the computing environment 900, computer-readable media include memory 920, storage 940, conununication media, and combinations of any of the above.
Having described and illustrated the principles of our invention with reference to described embodiments, it will be recognized that tiie described embodiments may be modified in arrangement and detail witiiout departing from such principles. It should be understood that the programs, processes, or methods described herein are not related or limited to any partici^ar type of computing environment, unless indicated otherwise. Various types, of general- purpose or specialized computing environments may be used with or perform, operations in accordance with the teachings described herein. Elements of the described embodiments shown in software may be implemented in hardware and vice versa.
In view of the many possible embodiments to vouch the principles of our invention may be applied, we claim as our invention all such embodiments as m^ come within the scope and spirit of the following claims and equivalents tiered,
I While the present invention has been related in terms of the foregoing embodiments, those skilled in the art will recognize that the invention is not limited to

He embodiments depicted. The present invention may be practiced with modification and alteration within tie spirit and scope of the appended claims. Thus, tile description is to be regarded as illustrative instead of restrictive on die present invention.

WE CLAIM:
1, A process oriented métier for developing an information technology
(TF) service catalog in business environment the method comprising:
defining unique characteristics of services as services move through various lifecycle stages within the IT service catalog their point of inception to its decommission using service domains and
fulfilling objectives during the services' joinery through the IT service catalog using domain components for service domain.
2. The method as recited in claim 1, wiremen service domains further
comprising:
validating the need for services and for gathering the service information effectively and timely through structured service engagements;
translating the service requirements to design specifications to facilitate an automated request and fulfillment process;
translating the service design specifications into configurable service objects and exposing to customers;
improving the services in terms of delivery and user experience through a constant cycle of monitoring, reporting and enhancements; and
optimizing the services in a cost effective manner by transforming services or decommissioning of services with minimal or no organizational impact.

3. The method as recited in claim-2, wherein validating the need for services further comprising:
engaging stakeholders to communicate IT Service Catalog value and build direction for service engagements;
partnering with stakeholders to gaudier accurate and complete service information;
building a Point of Arrival (POA) model for services and obtain alignment from Service stakeholders; and
gaining aliment on the to-be model and formally obtain sign-off for the service engagement.
4, The method as recited in claim 2, wherein translating the service requirements to design specifications further comprising:
analyzing requirements and prepare detailed service design document & workflows; and
validating and signoff design-document and finalize service implementation
plan.
5. The method as recited in claim 2, wherein translating the service design specifications into configurable service objects and exposing to customers further comprising:
Building and validating mock-ups and configuring services in the service development environment;
conducting testing, validating results, fixing defects, tracking and obtain signoff for lest results;

releasing services to the production environment and communicate to service stakeholders; and
transitioning services to support team and provide ongoing support for services and service catalog.
6. The method as recited in claim 2, w4ierein improving the services in terms of delivery and user experience, furdier comprising:
collecting service performance data to identify opportunities for in^rovement;
validating performance data with service stakeholders and collate recommendations;
preparing detailed service improvement plan and engage stakeholders as needed; and
executing improvements by coordinating with Process teams, service delivery and development teams.
7. The method as recited in claim 2, wherein optimizing the services in a cost effective manner further comprising;
initiating decommission by creating decommission request and validating die triggers;
preparing decommission plan and obtaining signoff from stakeholders & interface areas; and
executing decommission based on readiness levels, document and communicating outcomes.

8. The method as recited in claim i; wherein domain components further comprising;
processes to provide step by step procedures for the Service Domains to accomplish their objectives and sequence of activities performed to manage services in its lifecycle domains;
metrics for tracking and improvement of services within their Domains using set of defined parameters;
assets to enables decision making and movement of Services through the Service domains; and
process roles to facilitate the end to end flow of services tiirough the Service Domains.
9. A process-oriented method for developing an information technology (IT) service catalog in business environment, the method comprising.
Service Relations Group (SRG) for coordinating die new service engagements;
Service implementations Group (SIG) for overseeing the service design and deployment activities and coordinates activities between Ihe service owners, design teams and deployment teams for effective service development and rollout;
Service Assurance Group (SAG) for ensuring timely improvements for services and service catalog including delivery process, usability, training and support;
Service Anchors for coordinating all project level activities for the service absorption and support and periodically communicate the status to higher management;

Service Enliancers for coordinating tiie service improvement activities by Iceeping track of improvement opportunities and obtaining required sqjprovals for executing changes;
User Interface team for identifying end user satisfaction levels and for providing inputs for service design for the service and catalog usability and reviewing service design / improvements for usability;
Delivery teams for service deign, deployment, improvement and decommissioning execution; and
Monitoring and reporting teams for maintaining and measuring the service and catalog metrics and providing timely reports to SAG,
10. The method as recited in claim 9, vi4ierein the Service Assurance Group (SAG) fiirther ensures controlled change management for service improvements and decommissioning to ensure business continuity and least impact on end-users.
11. The method as recited'in claim 9, vi4ierein the Service Anchors further provide direction to project / delivery teams for task execution and information updates to SRG&SIG.
12. The method as recited in claim 9, w^ierein the Service Enhancers further provides inputs to monitoring and reporting team, user interface teams and delivery team to execute service improvements and changes.

13. A computer program product comprising a computer usable medium having a computer readable program- code embodied therein to develop a process-oriented information technology (IT) service catalog in business environment, the method comprising:, the method comprising:
program code adapted for defining unique characteristics of services as they move through various lifecycle stages within the IT service catalog from their point of inception to it's decommission using service domains; and
program code ad^ted for fulfilling objectives during the services' journey through the IT service catalog using domain components for service domain.
14. The product of claim 13, w4ierein service domains further comprising:
program code adapted for validating the need for services and for gathering
tiie service information effectively and timely through structured service
engagements;
i program code adapted for translating the service requirements to design
specifications to facilitate an automated request and fulfillment process;
program code adapted for translating the service design specifications into configurable service objects and exposing to customers;
program code ad^ted for improving the services in terms of delivery and user experience through a constant cycle of monitoring, reporting and enhancements; and
program code adapted for optimizing the services in a cost effective manner by transforming services or decommissioning of services with minimal or no organizational impact-

15. The product of claim 14, \^erein validating the need for services further comprising:
program code adapted for engaging stakeholders to communicate TT service catalog value and build direction for service engagements;
program code adapted for partnering with stakeholders to gather accurate and
complete service information;
'i program code adapted for building a Point of Arrival (POA) model for
services and obtain alignment from Service stakeholders; and
program code adapted for gaining alignment on the to-be model and formally obtaining sign-off for the service engagement.
16. The product of claitn 14, wherein tran^ating the service requirements to design specifications further comprising:
program code adapted for analyzing requirements and preparing detailed service design document & workflows; and
r
program code adapted for validating andsignoff design document and finalize service implementation plan.
17. The product of claim 14, wiierein translating the service design specifications into configurable service objects- and exposing to customers further comprising:
program code adapted for building and validating mock-ups, and configuring services in tiie service development environment;
program code adapted for conducting testing and validating results and fixing defects and tracking and obtaining signoff for test results;

program code ad^ted for releasing services to the production environment and communicating to service stakeholders; and
program code adapted for transitioning services to support team and provide ongoing support for services and service catalog.
18. The product of claim 14, w4ierein improving the services in terms of delivery and user experience further comprising:.
program code adapted for collecting service performance data to identify opportunities for improvement;
program code adapted for validating performance data with service stakeholders and collating recommendations;
program code adapted for preparing detailed service improvement plan and engaging stakeholders as needed; and
program code ad^ted for executing improvements by coordinating with process teams, service delivery and development teams.
19. The product of claim 14, wherein service optimizing the services in a cost effective manner further comprising:
program code ad^ted for initiating decommission by creating decommission request and validating the triggers;
program code adapted for preparing decommission plan and obtaining signoff from stakeholders & interface areas; and
program code adapted for executing decommission based on readiness levels, document and communicating outcomes.

20. The product of claim 14, wherein domain components further comprising;
program code ad^ted for processes to provide step by step procedures for the Service Domains to accomplish their objectives and sequence of activities performed to manage services in its Ufecycle domains;
program code ad^ted for metrics for tracking and improvement of services within their Domains using set of defined parameters;
program code adapted for assets to enables decision making and movement of Services through the Service domains; and
program code adapted for process roles to facilitate the end to end flow of services through the Service Domains' -
21. A computer program product comprising a computer usable medium having a computer readable program code embodied therein to develop an IT service catalog at large organizations, the method comprising:
program code adapted for Service Relations Group (SRG) for coordinating the new service engagements;
program code adapted for Service implementations Group (SIG) for overseeing the service design and deployment activities and coordinates activities between the service ovmer, design teams and deployment teams for effective service development and rollout;
program code dated for Service Assurance Group (SAG) for ensuring timely improvements for services and service catalog including delivery process, usability,
*
training and support;

program code adapted for Service Anchors for coordinating all project level activities for the service absorption and support and periodically communicate the status to higher management.;
program code addled for Service Enhancers for coordinating the service improvement activities by keeping .track of improvement opportunities and obtaining required approvals for executing changes;
program code adapted for User Interface team for identifying end user satisfaction levels and for providing inputs for service design for the service and catalog usability and reviewing service design / improvements for usability;
program code dated for Delivery teams for service deign, deployment, improvement and decommissioning execution; and
program code adapted for Monitoring and reporting teams for maintaining and measuring the service and catalog metrics and providing timely reports to SAG,