Application of business process management standards for dynamic information technology management

Processes and integrations include a method for managing a business process application development lifecycle. The method includes initiating, in a planning stage, requirements for an application based on adding new features to the application or a new application, implementing, in a development stage, a service process node (SPN) as a business process, and managing, in an operations stage, software code representing the application in a production environment. The SPN is configured to encapsulate at least one business service object and generate an interface configured to expose internal processes of the at least one business service object.

BACKGROUND

Field

Embodiments relate to using business process management (BPM) tools in information technology processes.

Related Art

Bridging information technology service management (ITSM) processes to Service Operations products has traditionally been a point to point integration. As a result, integrating support processes with automation tools has proven to be cumbersome. Moreover, as more products are acquired and added into a business service management (BSM) eco-system, standards for connecting the products into the core ITSM process are needed. Known visual tools lack a holistic governance and view into the BSM process spanning over several product lines and disciplines. The known visual tools are often disjointed with separate tools for the support side (e.g., information technology infrastructure library (ITIL) and task management workflows) and the automation side (e.g., run books automation/orchestrators).

While BPM is growing rapidly, known ITSM and BSM products poorly link IT management as a BPM discipline suited for the business roles in the IT organization. Known IT management solutions leverage a host of different tools and languages yet none standardize around BPM. Known ITSM products tend to implement their IT management practices with limited flexibility and personalization.

Moreover, development operations (DevOps) is growing as a prominent discipline in BSM. DevOps is talking about the need to bridge the gap between development and testing/QA teams and the operations roles which are responsible for the production environments. As is known, there is a lack of coordination, synchronization and governance around the application life cycle due to missing a standard methodology for articulating an application business process between a product manager that initiates a change, a new feature or a whole new application, to the development team which implements it to the production environment where this application will be deployed eventually and be continuously monitored. This is particularly missing with ITSM products where the process is the essence of the application delivered to the users.

SUMMARY

One embodiment includes a method for managing a business process application development lifecycle. The method includes initiating, in a planning stage, requirements for an application based on adding new features to the application or a new application, implementing, in a development stage, a service process node (SPN) as a business process, and managing, in an operations stage, software code representing the application in a production environment.

Another embodiment includes a non-transitory computer readable medium. The non-transitory computer readable medium including code segments that when executed by a processor cause the processor to implement a service process node (SPN). The SPN is configured to encapsulate at least one business service object and generate an interface configured to expose internal processes of the at least one business service object.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes in a business process model. Example embodiments describe a graphical BPMN standard based environment that spans the process from support to automation, model and track service management processes end to end through to automation services. This standards based hub approach may allow for an open solution that may improve integration of products into the BSM eco-system. Example embodiments may provide a standard methodology to supplement and add to the core ITSM process.

The graphical BPMN tool may span over the holistic IT management process and may enable governance and transparency both through the connection points between the solutions as well as within the products themselves. Example embodiments describe the IT management and ITIL best practices as a BPM discipline, suited for the business roles in the IT. Example embodiments may enable dynamic implementation and modification of IT management processes and best practices.

Example embodiments may be implemented as a layer on top of an active objects (AO) application programming interface (API). Example embodiments describe a BPMN engine with a graphical representation of the ITSM release. In addition, example embodiments describe connection points in ITSM and other products across the BSM eco-system (e.g., business resource planning model (BRPM)). In addition, the each process may expose its internal flows and connection points.

FIG. 1illustrates a service process node (SPN) according to an example embodiment. ITSM and any other product that may integrate with the IT management process may expose at least one SPN. A SPN may encapsulate at least one business services or objects (business service object) and may expose using a BPMN (or alternatively business process execution language (BPEL)) description the internal flow/process of the business service. The process may include known hooks for other processes to connect to. In BPMN the hooks may be represented by events and messages. The SPN may also provide governance over the state of the process (e.g. parameters and a step that an instance is currently executing). Therefore, the SPN may provide a mapping of the underlying code to the exposed process in design-time as well as in run-time.

As shown inFIG. 1, the SPN100includes a SPN interface105, a service API110and service code115. The service API110and the service code115are known to those skilled in the art, and are shown for the sake of completeness. Therefore for the sake of brevity, the service API110and the service code115will not be discussed further.

The SPN interface105includes a business process. Example embodiments are not limited to the business process as shown. The business process may include several process steps including a working group active step120, a time step125, a check status of working group step130, a working group active step135, and a send current issue list step140. The business process may also include access to some form of data shown as an issue list145.

The example business process shown inFIG. 1may send an issue list (e.g., issue list145) at regular time intervals if a working group is active. Otherwise, the business process ends. As shown inFIG. 1, the process sequence flows are illustrated as solid lines, message flows are illustrated as dashed lines and associations (e.g., data associations) are illustrated as dotted lines. As one skilled in the art will appreciate, the business process is more than a static data in/data out process. By contrast, messages may be input/output at varying points (e.g., states) of the process. For example in the business process shown inFIG. 1, not only is there a data output (e.g., issue list145is sent), but there is also a message output (e.g., outgoing message types).

FIG. 2illustrates an implementation of a service process architecture (SPA) according to an example embodiment. Service architectures, programming languages as well as integration frameworks in general introduce components and allow interaction and integration between components through APIs. SPA may leverage a business process approach in addition to the traditional interaction patterns. The pattern may utilize SPNs (e.g., SPN100) as building blocks of the SPA100. Example embodiments may utilize business process connectivity between sub-processes such that each sub-process is implemented by a business service that implements SPNs and may be orchestrated through an orchestration tool associated with BPMN or BPEL.

SPA may be an architectural structure overlaid on top of a known object-oriented programming and service oriented architecture, and would apply to the business layers of the product (e.g., program code). Example embodiments may provide modular services with greater freedom of composition. For example, modular business processes with declaration and governance of the business process as part of the modular service.

Programmer developers and architects typically approach integrations, composition and modularity from the technical and engineering angle. SPA adds on top of that a business process design where the product is directed to a business model. Example business services (unlike the “lower” technical layers of the software) therefore may describe a business process, one that exists in design time, is governed in run time and is the basis for all business integrations (through a unique process external interface/SPN interface).

As shown inFIG. 2, the implementation of a SPA includes database tables205, create, read, update and delete (CRUD)/access object210, coarse grained objects with additional operations215(e.g., validation), infrastructure and basic assembly objects/services220, business service225, business process/flow orchestration230, and SPA235.

The database tables205, create, read, update and delete (CRUD)/access object210, coarse grained objects with additional operations215(e.g., validation), infrastructure and basic assembly objects/services220, business service225, and business process/flow orchestration230are generally known to those skilled in the art. Example embodiments provide SPA235overlaid on the business service225, and business process/flow orchestration230layers. The SPA may be configured to provide process connectivity between processes and/or sub-processes such that each process/sub-process may be implemented by a business service that implements SPNs and can be orchestrated through an orchestration tool (e.g., business process/flow orchestration230) that understands BPMN or BPEL.

Example embodiments add to the orchestration tool (e.g., AO, any orchestration and/or enterprise service bus (ESB) product) a new BPM layer supporting a graphical BPMN engine. The new layer will include a studio which will allow the display of processes as well the creation of new IT management processes based on the provided catalog of SPNs. Moreover, the new layer will have a runtime governance user interface (UI) configured to enable embedding the new layer into the UI. As such, both ITSM and BRPM may be able to expose the state of the holistic process within their own UIs

FIG. 3illustrates an application development lifecycle method according to an example embodiment. For example,FIG. 3shows the DevOps process and the stages through which SPA may enable a full application life cycle and provide a well-defined process bridging between design, implementation and operations.

As shown inFIG. 3, in step S305, in a planning stage, initiate requirements for new software/content, whether based on resolving incidents, new features or completely new applications. For example, roles (e.g., product managers) may provide (e.g., by leveraging a BPM like standard such as BPMN, BPEL, and the like) a description of the business process or changes for an existing business process. The roles may consider the demarcation of sub-processes and the interfaces between the sub-processes. The roles may emphasize modularity and loose coupling (e.g., of business processes) which may enable freedom of composition and integrations in future run-time scenarios. For example, each process/sub-process may be translated into an SPN definition with a well-defined SPN interface consisting of the incoming and outgoing events that each process/sub-process recognizes/supports.

In step S310, a development-test stage, implement a SPN as a business process. For example, roles (e.g., development and QA teams) may be code software from scratch, and/or alternatively, working with an existing product. Regardless, the roles may demarcate code based on the defined business processes/sub-processes. The roles may implement the SPN by enveloping the relevant business process/sub-process code with a governance module associated with the business process/sub-process. For example, the governance module may expose (e.g. to any SPN orchestration tool) a run-time “state” of the business process/sub-process according to a given definition and based on the BPM standard (e.g. BPMN or BPEL). The governance module may also provide (e.g., at run-time) implementation to the defined process events which the SPN supports.

In step S315, an Operations stage, manage the software in a production environment. For example, operations roles may review changes in applications before the applications have been implemented by, for example, reviewing the applications updated/new SPN(s). The operations roles may leverage a SPN orchestration software to integrate, monitor/govern and remediate software that is based on an SPN architecture.

For example, the operations roles may integrate software in a dynamic manner by combining SPN(s) through SPN interfaces in an orchestration planning UI. The operations roles may track running instances of SPN(s) by visualizing the state they reside in at any given time. The operations roles may determine if issues with the applications based on the above monitoring/governance (e.g., leading to intelligent incident management). The operations roles may devise a mechanism to resolve the problem by taking specific route in accordance to the SPN process definition. The operations roles may participate back in the planning stage (e.g., starting over again the application life cycle) where the operations roles may comment on business needs or problems with a given business process.

The following describe example embodiments through example implementations. However, the example embodiments are not limited by the aspects of any given implementation.

FIG. 4illustrates an example implementation of service process nodes according to an example embodiment. As shown inFIG. 4, the process sequence flows are illustrated as solid lines, message flows are illustrated as dashed lines.FIG. 4shows a first example embodiment through an example implementation of business processes using SPNs and SPAs.FIG. 4illustrates ITSM integration with BRPM as an example.

ITSM integration with BRPM integrates two products from two different product lines. Those skilled in the art should see this example as an intuitive use-case, as products from different business units may be expected to remain loosely coupled. ITSM and BRPM may provide SPNs through which example embodiments may perform the release process integration between the two products. ITSM release may be constructed of a few phases (e.g., collaboration, build, test and deploy). Each of these phases may relate in some way to a BRPM process.

Example embodiments break the ITSM flow into a sub-process (e.g., SPN) in order to keep the example short. In example embodiments, the two SPNs interact and connect using messages. These message types may be declared as part of each SPN interface, denoting outbound messages as well as receptors of inbound message types (e.g., for either events or activities).

As shown inFIG. 4, ITSM change initiate and build node405and BRPM build QA/test environment node410are implemented as a set of process blocks. According to the example embodiment, with SPA both change and incident may be enveloped as SPNs and implement a connection through a set of messages, events and activities. For example, the process blocks may be converted into BPMN flows, declaring a set of messages that may formalize the proper interaction and building SPNs around the relevant code in each of ITSM change initiate and build node405and BRPM build QA/test environment node410. The AO may be configured to connect the SPNs into the desired flow and executed accordingly.

The ITSM change initiate and build node405includes process blocks request for change (RFC)415, detect and categorize420, assign priority and planning425, ask for initial approval430, build435, ask for build approval440. The ITSM change initiate and build node405further includes a declared set of messages including request QA/test environment message480, request approval message485, build succeeded message490, and build approved message495.

Process block request for change (RFC)415may be configured to initiate an RFC. Process block detect and categorize420may be configured to determine information about the RFC and categorize the RFC based on the information. Process block assign priority and planning425may be configured to determine and assign a priority to the RFC based on the information and plan (e.g., determine steps and timeline) for executing the RFC. Process block ask for initial approval430may be configured to obtain approval (e.g. from an engineering manager) for performing the RFC. Process block build435may be configured to order a prototype of the product built with the change. Process block ask for build approval440may be configured to obtain approval (e.g. from an operations manager) for performing a build of the prototype. Each of the process blocks may include code segments that when executed by a processor cause the processor to perform as a special purpose computer configured to perform the tasks associated with the process blocks.

The BRPM build QA/test environment node410includes process blocks request for QA/test environment442, gateway445, decision block450, build and package455, deploy in QA/test460, test465, decision block470, and gateway475. The BRPM build QA/test environment node410includes a declared set of messages including request QA/test environment message480, request approval message485, and build succeeded message490.

Process block request for QA/test environment442may be configured to initiate a QA and/or test environment. Process block gateway445may be configured to convert a state (e.g., change approved) to a corresponding message. Process block decision block450may be configured to determine whether or not a change is approved. Process block build and package455may be configured to build and package the prototype. Process block deploy in QA/test460may be configured to deploy (e.g., develop or configure) quality assurance checks and/or tests for the prototype. Process block test465may be configured to perform the quality assurance checks and/or tests on the prototype. Process block decision block470may be configured to determine if the quality assurance checks and/or tests passed for the prototype. Process block gateway475may be configured to convert a state (e.g., test passed) to a corresponding message. Each of the process blocks may include code segments that when executed by a processor cause the processor to perform as a special purpose computer configured to perform the tasks associated with the process blocks.

The declared set of messages including request QA/test environment message480, request approval message485, and build succeeded message490. Each of the messages communicate information (e.g., state and status) between the ITSM change initiate and build node405and the BRPM build QA/test environment node410. As discussed above, a typical software code block includes one input and one output instance (each potentially including several variables). The example embodiment provides interfaces for exchanging messages communicating, for example, events, states and/or activities. The interface may allow for exchanging messages at intermediate steps during the process flow. The interface may allow for exchanging messages during design-time and run-time. In the example embodiment, process blocks or steps may continue to execute while awaiting a message and/or wait in a hold until the message is received.

FIGS. 5A and 5Billustrate another example implementation of service process nodes according to an example embodiment. As shown inFIGS. 5A and 5B, the process sequence flows are illustrated as solid lines, message flows are illustrated as dashed lines.FIGS. 5A and 5Bshow a second example embodiment through an example implementation of business processes using SPNs and SPAs.FIGS. 5A and 5Billustrate ITSM change and incident management.

The example implementation illustrates the process integration of two products from the same product line (e.g., ITSM incident management (FIG. 5A) and ITSM change management (FIG. 5B)). ITSM change management and incident management are typically tightly coupled. However, there are benefits to move towards SPA instead. For example, simplifying integrations for other incident or change management tools.

As shown inFIG. 5A, ITSM incident management includes process blocks user contacts service desk505, request form submitted by user or specialist510, incident request registration520, change management required decision block525, incident request tracking530, incident request resolution by specialist535, escalation required decision block540, incident escalation handling545, recovery at continuity site most efficient way to resolve incident decision block550, incident request closure555, and solution approval560. ITSM incident management includes a declared set of messages including a message from a plurality of other management process515, messages to and from change management amongst other shown messages.

Process block user contacts service desk505may be configured to initiate an incident. Process block request form submitted by user or specialist510may be configured to capture information related to the initiated incident. Process block incident request registration520may be configured to register (e.g., store the information and assign an incident number) the incident with the incident management system. Process block change management required decision block525may be configured to determine if a product or process change is required. If no product or process change is required, processing continues to the incident request tracking530and request resolution by specialist535process blocks.

Process block incident request tracking530may be configured to add a marker (e.g., unique number) to the incident to track resolution of the incident. Process block incident request resolution by specialist535may be configured to request special skills personnel to investigate and resolve the incident. Process block escalation required decision block540may be configured to determine if the incident should be brought to the attention of special (e.g., management) personnel. Process block incident escalation handling545may be configured to notify the special personnel. Process block recovery at continuity site most efficient way to resolve incident decision block550may be configured to determine (e.g., by the special personnel) if resolution at the continuity site is the most efficient way to resolve the incident. Process block incident request closure555may be configured to close (e.g., mark as closed in the incident registry) the incident. Process block solution approval560may be configured to enable authorized personnel to approve the closing of the incident. Each of the process blocks may include code segments that when executed by a processor cause the processor to perform as a special purpose computer configured to perform the tasks associated with the process blocks.

As shown inFIG. 5B, ITSM change management includes process blocks request for change review565, release management required decision block570, change planning572, change approval574, application change decision block575, infrastructure change implementation580, application change implementation585, and planned change closure590. ITSM incident management includes a declared set of messages including messages to and from incident management amongst other shown messages.

Process block request for change review565may be configured to initiate an appropriate change review. Process block release management required decision block570may be configured to determine if release management (e.g., product is in a configuration control system) is required. Process block change planning572may be configured to plan the steps required for executing the change. Process block change approval574may be configured to approve the change plan. Process block application change decision block575may be configured to determine if there has been an application (e.g., product use or software application) change.

Process block infrastructure change implementation580may be configured to implement an infrastructure change. Process block application change implementation585may be configured to implement an application change. Process block planned change closure590may be configured to close the change review. Each of the process blocks may include code segments that when executed by a processor cause the processor to perform as a special purpose computer configured to perform the tasks associated with the process blocks.

The declared set of messages for both the ITSM incident management (FIG. 5A) and ITSM change management (FIG. 5B) include messages to and from each other amongst other shown messages. Each of the messages communicate information (e.g., state and status) between the ITSM incident management (FIG. 5A) and ITSM change management (FIG. 5B). For example, interface ‘A’ shows a message from process block change management required525of the ITSM incident management (FIG. 5A) to the request for change review process block565of the ITSM change management (FIG. 5B). Further, for example, interface ‘A’ shows a message from the planned change closure process block590of the ITSM change management (FIG. 5B) to the incident request closure process block555of the ITSM incident management (FIG. 5A).

As discussed above, a typical software code block includes one input and one output instance (each potentially including several variables). The example embodiment provides interfaces for exchanging messages communicating, for example, events, states and/or activities. The interface may allow for exchanging messages at intermediate steps during the process flow. The interface may allow for exchanging messages during design-time and run-time. In the example embodiment, process blocks or steps may continue to execute while awaiting a message and/or wait in a hold until the message is received.

A third example embodiment (not illustrated) exemplifies process integration of three modules within a single product. The ITSM problem management application may include three modules that define an overall problem management business process. These modules are ‘Problem Investigation’, ‘Known Error Handling’ and ‘Solution Management’. On one hand, the ITSM problem management application may provide SPA that may enable governance of the ITSM problem management applications business process. The SPA may further enable process integration between itself with other applications (e.g. ITSM incident management). But on the other hand such architecture would also mean an opportunity to break its business logic into more granular SPNs. This would allow each module to be loosely coupled instead of the typical tightly coupled nature of the code. Designing the application with SPA may allow an example embodiment to deactivate components and given that the example may include SPNs defined for the ‘Problem Investigation’ module, creating “adaptors” to integrate other modules into the problem management process to fulfill the ‘Known Error handling’ and/or ‘Solution management’ process may be possible.

Example embodiments provide design and architect business services according to the product's intended process; break the business logic into modular services according to the process rather than other (e.g. technical) considerations; produce an interface for business services which exposes the process that they fulfill (in a standard notation, e.g. BPMN, BPEL); expose further through the interface the state of that process in run-time; plan the integration between products and services with a process orchestration tool, leveraging the new process interface; and govern the overall process in run-time leveraging the process orchestration tool as well as the process interfaces, allowing for a deep insight into the business flow. Example embodiments apply this methodology over ITSM, promote the methodology for process integration with operational product lines, as well as between ITSM products. Even consider breaking up ITSM products into more modular processes allowing for a greater freedom of composition.

Example embodiments allow Support and IT operations/DevOps/ALM groups who typically work in organization silos, the combination of processes between silos. Example embodiments allow organizations to plan process integration, between the organization's products, but also to the central ITSM process that drives BSM.

Methods discussed above, some of which are illustrated by the flow charts, may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine or computer readable medium such as a storage medium. A processor(s) may perform the necessary tasks.

Specific structural and functional details disclosed herein are merely representative for purposes of describing example embodiments. Example embodiments may, however, be embodied in many alternate forms and should not be construed as limited to only the embodiments set forth herein.

In the above illustrative embodiments, reference to acts and symbolic representations of operations (e.g., in the form of flowcharts) that may be implemented as program modules or functional processes include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types and may be described and/or implemented using existing hardware at existing structural elements. Such existing hardware may include one or more Central Processing Units (CPUs), digital signal processors (DSPs), application-specific-integrated-circuits, field programmable gate arrays (FPGAs) computers or the like.