The solution approach encapsulated in this invention is summarized below in the four steps below:
Advantages of using this invention are as follows:
Outsourcers, both IBM and our competitors, have approached customer engagements indicating that delivery efficiency and optimization will be obtained by a transformation to a standard set of tools. This implies that the outsourcing provider has monolithic control over scope and architecture for the customer environment. The trend, however, is selective outsourcing, customer architectural control of IT solutions and account retention of legacy tools. Although the premise of optimization by standardization is still correct, the target environments are extremely heterogeneous and the ability to influence that is less an outsourcer dictate then in the past. We have a requirement for collaboration and dealing with heterogeneity. In addition our competitors are gaining market share by embracing the heterogeneity and selling what is known as “lift and shift”. This invention differentiates us in this outsourcer space. The value and IP of this invention is enabling IGS to deal with non-standard things in a standard way. It enables selective transformation and ROI driven adoption of standards.
Another way an embodiment of the present invention can summarized is with a modification of the above steps are listed as follows:
Business performance model captures the Key Performance Indicators (KPIs), relationships between the KPIs, algorithms and data for computing the KPIs, business situations that are triggered by KPIs, and actions that need to be performed to remediate the situations.
Key Performance Indicators (KPIs) are quantifiable measurements, agreed to beforehand, that reflect the critical success factors of an organization. Typically, an organization uses KPIs to measure progress toward the organizational goals. Thus, KPIs vary depending on the type of business and the goals.
To capture a detailed definition of a KPI, the following KPI Template is introduced:
Scope: (The level the KPI is created for, e.g. Service Order/Service Plan, Service Order Task)
Each KPI is qualified by one or more dimensions. For the data fields listed in the same source, if they are qualified by dimensions, they must be the same set. For example, if one of the data field uses time and performer Id as dimensions, all the related data fields used for calculation must also use the same time period and performer Id as dimensions.
A sample KPI definition using the above template is listed below:
KPIs are organized by the business artifacts.
Service order KPIs are computed from data contained in service order artifact instances and from temporal data collected when the service order tasks are executed.
A business situation is defined as logical condition over a set of KPIs and/or metrics.
Mostly, a situation is simply binary metric of which value is either true or false. The definitions of situations are also related to organizational goals. A negation of a goal is likely to be defined as a situation. For example, the goal of 80% on time service Order by queue in a quarter can be translated into a situation, e.g. the on time percentage by queue is less than 80% in the quarter, if a company attempts to manage its business by exceptions.
In actuality, situations each account wants to track can vary widely, and it would difficult to make them uniform. That is, depending on the priority, an account may want to track a certain subset of all potential situations that can occur based on the list of KPIs. Please refer to the section that follows for a summary of all the potential situations for the service orders.
To capture the details of the definition of a business situation, a situation template is created for that purpose as follows:
Priority: (priority of the situation: high, medium, low)
KPIs involved: (one or more KPIs that defines this situation)
An example of a high priority business situation for Service Delivery is described as follows:
Example: For Service orders, report “Service Order elapse time exceeding threshold situation”. For the ‘planned time’ of a Service Order, e.g. 20 hours, evaluate the exceeding threshold situation when 90% time has past since the SO is created, i.e. 18 hr, alert if the service order is not yet completed.
KPIs involved: Elapse time of a Service Order
Situation Rule: when elapse time is 90% of a Service Order planned time, which is calculated using the following formula:
90%*planned time of a service order
The following work products are created in this phase:
Referring to
Operation model 900 for Service Order enablement is a formal specification of the operations that create, consume, modify, or use business artifacts to manage the end-to-end lifecycle of a service order and perform the requested service.
There are four types of organizations that participate in this process:
The focus of the operational model 900 is on the tasks being performed by the Service Delivery team to manage the service order and coordinate the service delivery with Service Provider teams, account teams, and customers.
Service Order is the key business artifact that drives the Service Order enablement.
The service request received from the customer is correlated with the appropriate service definition in this internal catalog. Next it goes through an approval process and if approved, a Concrete Plan is created to provision the service request. The plan identifies the tasks that need to be performed and the service providers who perform these tasks. This plan is created using the service plan, but customizes the plan to suit the specific service order instance. Next, service delivery team negotiates with the service providers and the account team to secure commitments and finalize the plan. A Commitment Task is created for each commitment that needs to be secured. If change management is needed, a change request is created and change management process kicked off. Change management is outside the scope of the Service Order enablement operation model and hence we do not list Change Request as an artifact. Instead, we send a service request to a change management service. Once change is approved, Service Order Tasks are created from the concrete plan in the Service Order. Each Service Order Task corresponds to the Atomic Services that make up the Service Plan. As part of completing the Service Order Task, atomic services are executed. When all the work is done satisfactorily, service order is closed.
This operation model is created using WBI Modeler.
Next step in the transformation process is to create a platform-independent UML model of the Service Request process. Creation of the platform-independent model comprised of several key steps:
Generation of initial solution model from the BOM model: Using WBI2UML MDBT plugins an initial UML solution model was auto-generated for the Service Request process from the Operation Model. This includes ABOs, resources, data model, default views/list-views, action stubs, and use cases.
Augmentation of the initial solution model: An augmented solution model was created as an extension to the generated mode, to incorporate:
ABOs are at the heart of the solution model. ABOs are automatically generated from the operation model by a computer program. This program examines the business artifacts in the operation model and identifies artifacts that undergo lifecycle changes. The program generates an ABO for each such artifact. For service order enablement process, Service Order and Service Order Task are modeled as ABOs in the solution model. Tasks in the operation model are mapped to Use Cases. Views are created to support the Use Cases. The Views are then associated with appropriate ABOs. Behavior of each ABO is defined using a state machine. Transition actions of the state machine are associated with data actions and remote actions. A data graph is used to model the information content in all of the artifacts. Data actions are facilitated with the data graph and remote actions are mapped to service invocations.
In addition to the solution model, we define a UML-based observation model to formally capture the KPIs, Situations, and Actions described in the earlier section.
Rational Software Architect (RSA) is used to model the solution model in UML. MDBT Toolkit is used to define a profile in RSA to enforce the necessary constraints to create a semantically and syntactically correct solution model. MDBT Toolkit is also used to autogenerate the initial solution model from the business operation model.
Once a platform-independent solution is created, next step is to implement the solution on a specific target platform. The target platform is a combination of middleware products and applications. The target platform for the PoT is a combination of WebSphere Business Integration Server Foundation (WBI-SF), newScale, eESM, ITSM Change Management, DB2 AlphaBlox, and TPM. We take the following steps to create an implementation:
The work product from this phase is an operational prototype deployed on WBI-SF and integrated with newScale, TPM, eESM, and ITSM. This system is code named BlueCat.
For the KPIs that were determined as relative low priority, which means no escalation of the situation is required, they will appear on the BPM Dashboard, which has periodical data refreshing rate as frequent as one or two minutes.
For details of what KPIs are designated for dashboard reporting, please see details of the highlighted KPIs of the
The figure that follows depicts a sample performance metric reporting capability for Service Orders Tasks.
Additional embodiments of the present invention will be described with reference to the following figures.
Referring to
A representative hardware environment for practicing the embodiments of the invention is depicted in
It should also be obvious to one of skill in the art that the instructions for the technique described herein can be downloaded through a network interface from a remote storage facility or server.
The described techniques may be implemented as a method, apparatus or article of manufacture involving software, firmware, micro-code, hardware and/or any combination thereof. The term “article of manufacture” as used herein refers to code or logic implemented in a medium, where such medium may comprise hardware logic [e.g., an integrated circuit chip, Programmable Gate Array (PGA), Application Specific Integrated Circuit (ASIC), etc.] or a computer readable medium, such as magnetic storage medium (e.g., hard disk drives, floppy disks, tape, etc.), optical storage (CD-ROMs, optical disks, etc.), volatile and non-volatile memory devices [e.g., Electrically Erasable Programmable Read Only Memory (EEPROM), Read Only Memory (ROM), Programmable Read Only Memory (PROM), Random Access Memory (RAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), flash, firmware, programmable logic, etc.]. Code in the computer readable medium is accessed and executed by a processor. The medium in which the code or logic is encoded may also comprise transmission signals propagating through space or a transmission media, such as an optical fiber, copper wire, etc. The transmission signal in which the code or logic is encoded may further comprise a wireless signal, satellite transmission, radio waves, infrared signals, Bluetooth, visible light signals, etc. The transmission signal in which the code or logic is encoded is capable of being transmitted by a transmitting station and received by a receiving station, where the code or logic encoded in the transmission signal may be decoded and stored in hardware or a computer readable medium at the receiving and transmitting stations or devices. Additionally, the “article of manufacture” may comprise a combination of hardware and software components in which the code is embodied, processed, and executed. Of course, those skilled in the art will recognize that many modifications may be made without departing from the scope of embodiments, and that the article of manufacture may comprise any information bearing medium. For example, the article of manufacture comprises a storage medium having stored therein instructions that when executed by a machine results in operations being performed.
Certain embodiments can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
Furthermore, certain embodiments can take the form of a computer program product accessible from a computer usable or computer readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
The terms “certain embodiments”, “an embodiment”, “embodiment”, “embodiments”, “the embodiment”, “the embodiments”, “one or more embodiments”, “some embodiments”, and “one embodiment” mean one or more (but not all) embodiments unless expressly specified otherwise. The terms “including”, “comprising”, “having” and variations thereof mean “including but not limited to”, unless expressly specified otherwise. The enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms “a”, “an” and “the” mean “one or more”, unless expressly specified otherwise.
Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries. Additionally, a description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary a variety of optional components are described to illustrate the wide variety of possible embodiments.
Further, although process steps, method steps, algorithms or the like may be described in a sequential order, such processes, methods and algorithms may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously, in parallel, or concurrently.
When a single device or article is described herein, it will be apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be apparent that a single device/article may be used in place of the more than one device or article. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments need not include the device itself.
Certain embodiments may be directed to a method for deploying computing instruction by a person or automated processing integrating computer-readable code into a computing system, wherein the code in combination with the computing system is enabled to perform the operations of the described embodiments.
At least certain of the operations illustrated in here in may be performed in parallel as well as sequentially. In alternative embodiments, certain of the operations may be performed in a different order, modified or removed.
Furthermore, many of the software and hardware components have been described in separate modules for purposes of illustration. Such components may be integrated into a fewer number of components or divided into a larger number of components.
Additionally, certain operations described as performed by a specific component may be performed by other components.
The data structures and components shown or referred to are described as having specific types of information. In alternative embodiments, the data structures and components may be structured differently and have fewer, more or different fields or different functions than those shown or referred to in the figures.
Next, a determination is made on whether the process software is be deployed by having users access the process software on a server or servers 2302. If the users are to access the process software on servers then the server addresses that will store the process software are identified 2303.
A determination is made if a proxy server is to be built 2400 to store the process software. A proxy server is a server that sits between a client application, such as a Web browser, and a real server. It intercepts all requests to the real server to see if it can fulfill the requests itself. If not, it forwards the request to the real server. The two primary benefits of a proxy server are to improve performance and to filter requests. If a proxy server is required then the proxy server is installed 2401. The process software is sent to the servers either via a protocol such as FTP or it is copied directly from the source files to the server files via file sharing 2402. Another embodiment would be to send a transaction to the servers that contained the process software and have the server process the transaction, then receive and copy the process software to the server's file system. Once the process software is stored at the servers, the users via their client computers, then access the process software on the servers and copy to their client computers file systems 2403. Another embodiment is to have the servers automatically copy the process software to each client and then run the installation program for the process software at each client computer. The user executes the program that installs the process software on his client computer 2412 then exits the process 2308.
In step 2304 a determination is made whether the process software is to be deployed by sending the process software to users via e-mail. The set of users where the process software will be deployed are identified together with the addresses of the user client computers 2305. The process software is sent via e-mail to each of the users' client computers. The users then receive the e-mail 2405 and then detach the process software from the e-mail to a directory on their client computers 2406. The user executes the program that installs the process software on his client computer 2412 then exits the process 2308.
Lastly a determination is made on whether the process software will be sent directly to user directories on their client computers 2306. If so, the user directories are identified 2307. The process software is transferred directly to the user's client computer directory 2407. This can be done in several ways such as but not limited to sharing of the file system directories and then copying from the sender's file system to the recipient user's file system or alternatively using a transfer protocol such as File Transfer Protocol (FTP). The users access the directories on their client file systems in preparation for installing the process software 2408. The user executes the program that installs the process software on his client computer 2412 then exits the process 2308.
The present software can be further deployed to third parties as part of an additional service wherein a third party VPN service is offered as a secure deployment vehicle or wherein a VPN is build on-demand as required for a specific deployment. A virtual private network (VPN) is any combination of technologies that can be used to secure a connection through an otherwise unsecured or untrusted network. VPNs improve security and reduce operational costs. The VPN makes use of a public network, usually the Internet, to connect remote sites or users together. Instead of using a dedicated, real-world connection such as leased line, the VPN uses “virtual” connections routed through the Internet from the company's private network to the remote site or employee. Access to the software via a VPN can be provided as a service by specifically constructing the VPN for purposes of delivery or execution of the process software (i.e. the software resides elsewhere) wherein the lifetime of the VPN is limited to a given period of time or a given number of deployments based on an amount paid.
The process software may be deployed, accessed and executed through either a remote-access or a site-to-site VPN. When using the remote-access VPNs the process software is deployed, accessed and executed via the secure, encrypted connections between a company's private network and remote users through a third-party service provider. The enterprise service provider (ESP) sets a network access server (NAS) and provides the remote users with desktop client software for their computers. The telecommuters can then dial a toll-free number or attach directly via a cable or DSL modem to reach the NAS and use their VPN client software to access the corporate network and to access, download and execute the process software.
When using the site-to-site VPN, the process software is deployed, accessed and executed through the use of dedicated equipment and large-scale encryption that are used to connect a companies multiple fixed sites over a public network such as the Internet.
The process software is transported over the VPN via tunneling which is the process of placing an entire packet within another packet and sending it over a network. The protocol of the outer packet is understood by the network and both points, called tunnel interfaces, where the packet enters and exits the network.
If a VPN does exist, then proceed to 2575. Otherwise identify a third party provider that will provide the secure, encrypted connections between the company's private network and the company's remote users 2576. The company's remote users are identified 2577. The third party provider then sets up a network access server (NAS) 2578 that allows the remote users to dial a toll free number or attach directly via a broadband modem to access, download and install the desktop client software for the remote-access VPN 2579.
After the remote access VPN has been built or if it been previously installed, the remote users can access the process software by dialing into the NAS or attaching directly via a cable or DSL modem into the NAS 2565. This allows entry into the corporate network where the process software is accessed 2566. The process software is transported to the remote user's desktop over the network via tunneling. That is the process software is divided into packets and each packet including the data and protocol is placed within another packet 2567. When the process software arrives at the remote user's desktop, it is removed from the packets, reconstituted and then is executed on the remote users desktop 2568.
A determination is made to see if a VPN for site to site access is required 2562. If it is not required, then proceed to exit the process 2563. Otherwise, determine if the site to site VPN exists 2569. If it does exist, then proceed to 2572. Otherwise, install the dedicated equipment required to establish a site to site VPN 2570. Then build the large scale encryption into the VPN 2571.
After the site to site VPN has been built or if it had been previously established, the users access the process software via the VPN 2572. The process software is transported to the site users over the network via tunneling. That is the process software is divided into packets and each packet including the data and protocol is placed within another packet 2574. When the process software arrives at the remote user's desktop, it is removed from the packets, reconstituted and is executed on the site users desktop 2575. Proceed to exit the process 2563.
It is to be understood that the provided illustrative examples are by no means exhaustive of the many possible uses for my invention.
From the foregoing description, one skilled in the art can easily ascertain the essential characteristics of this invention and, without departing from the spirit and scope thereof, can make various changes and modifications of the invention to adapt it to various usages and conditions.
It is to be understood that the present invention is not limited to the embodiments described above, but encompasses any and all embodiments within the scope of the following claims: