Source: https://patents.google.com/patent/US20110004564
Timestamp: 2018-02-18 09:05:48
Document Index: 725281236

Matched Legal Cases: ['application No. 200702356', 'application No. 200702363', 'application No. 200702377', 'application No. 200702600', 'art 720', 'art 740', 'art 700', 'art 700']

US20110004564A1 - Model Based Deployment Of Computer Based Business Process On Dedicated Hardware - Google Patents
US20110004564A1
US20110004564A1 US12808229 US80822910A US20110004564A1 US 20110004564 A1 US20110004564 A1 US 20110004564A1 US 12808229 US12808229 US 12808229 US 80822910 A US80822910 A US 80822910A US 20110004564 A1 US20110004564 A1 US 20110004564A1
US12808229
This application relates to copending U.S. applications titled “SETTING UP DEVELOPMENT ENVIRONMENT FOR COMPUTER BASED BUSINESS PROCESS” (applicant reference number 200702145), titled “VISUAL INTERFACE FOR SYSTEM FOR DEPLOYING COMPUTER BASED PROCESS ON SHARED INFRASTRUCTURE” (applicant reference number 200702356), titled “MODELING COMPUTER BASED BUSINESS PROCESS FOR CUSTOMISATION AND DELIVERY” (applicant reference number 200702363), titled “MODELING COMPUTER BASED BUSINESS PROCESS AND SIMULATING OPERATION” (applicant reference number 200702377), titled “AUTOMATED MODEL GENERATION FOR COMPUTER BASED BUSINESS PROCESS”, (applicant reference number 200702600), and titled “INCORPORATING DEVELOPMENT TOOLS IN SYSTEM FOR DEPLOYING COMPUTER BASED PROCESS ON SHARED INFRASTRUCTURE”, and previously filed US application titled “DERIVING GROUNDED MODEL OF BUSINESS PROCESS SUITABLE FOR AUTOMATIC DEPLOYMENT” (Ser. No. 11/741878) all of which are hereby incorporated by reference in their entirety.
The invention relates to methods of automated deployment managed by a service provider, of a computer based business process, and relates to corresponding systems and software.
Another example of difficulties in modeling is WO2004090684 which relates to modeling systems in order to perform processing functions. It says “The potentially large number of components may render the approach impractical. For example, an IT system with all of its hardware components, hosts, switches, routers, desktops, operating systems, applications, business processes, etc. may include millions of objects. It may be difficult to employ any manual or automated method to create a monolithic model of such a large number of components and their relationships. This problem is compounded by the typical dynamic nature of IT systems having frequent adds/moves/changes. Secondly, there is no abstraction or hiding of details, to allow a processing function to focus on the details of a particular set of relevant components while hiding less relevant component details. Thirdly, it may be impractical to perform any processing on the overall system because of the number of components involved.”
Aris from IDS-Scheer is a known business process modeling platform having a model repository containing information on the structure and intended behaviour of the system. In particular, the business processes are modeled in detail. It is intended to tie together all aspects of system implementation and documentation.
Aris UML designer is a component of the Aris platform, which combines conventional business process modeling with software development to develop business applications from process analysis to system design. Users access process model data and UML content via a Web browser, thereby enabling processing and change management within a multi-user environment. It can provide for creation and communication of development documentation, and can link object-oriented design and code generation (CASE tools). It relies on human entry of the models.
a method of automated deployment managed by a service provider, of a computer based business process having a number of functional steps, for a given enterprise, the method having the steps of:
generating a model of the business process, the model having a representation of an arrangement of software application components, for implementing the functional steps, and having a representation of computing infrastructure, for running the software application components on specified enterprise dedicated hardware, and suitable for automated deployment, to meet given non functional requirements if there are any, and
deploying the model on the hardware dedicated to the enterprise, with an interface for the service provider to enable ongoing management of the deployed process by the service provider.
By giving the enterprise dedicated hardware rather than using shared hardware as in a conventional data centre, the service provider can offer a combination of some of the advantages of in house services with advantages of out sourced service provision. For example the enterprise can reduce or control some of the limitations of having to use shared hardware in centralised data centres. For example, having dedicated hardware means the location of the hardware can be arranged to suit the enterprise. This means limitations such as bandwidth or latency of WAN links, can be addressed by choosing the location of the dedicated hardware to be on or near the enterprises premises. Having dedicated hardware can also increase trust of security compared to that of the shared data centres. This can be addressed for example, by the enterprise having control of physical access to the dedicated hardware and data for example. These benefits are facilitated by the automated model driven deployment, which can help enable the service provider to provide such deployments on different types of hardware with less need for skilled personnel and can reduce the need for the hardware to be centrally located. This also reduces the need for the enterprise to maintain specialist expertise in house. The service provider can also benefit by reducing the load (in terms of computing and power consumption) on resources in a shared data centre by distributing some of the load onto hardware that operates outside the service provider's data centre.
Another aspect provides a system, for automated deployment managed by a service provider, of a computer based business process having a number of functional steps, for a given enterprise, the system having:
a model generation part arranged to generate a model of the process, the model having a representation of an arrangement of software application components, for implementing the functional steps, and having a representation of computing infrastructure, for running the software application components on the enterprise dedicated hardware, and suitable for automated deployment, to meet given non functional requirements if there are any, and
a deployment part arranged to provide automated deployment of the model on the hardware dedicated to the enterprise, with an interface for the service provider to enable ongoing management of the deployed process by the service provider.
FIG. 16 shows an embodiment of a system for deployment on enterprise dedicated hardware,
FIGS. 17, 18, 19 and 20 show steps according to embodiments, and
FIG. 21 shows a system according to another embodiment.
“enterprise dedicated hardware” encompasses hardware such as physical servers, storage and communications links which is for the exclusive use of that enterprise and thus its location can be chosen by the enterprise. It need not be owned by the enterprise, it can be leased or paid for in any way as part of the cost of the service. It cannot be reallocated or removed except with the permission of the enterprise. Constituent components and identifiers of the parts of the hardware can generally be changed by the service provider to meet the needs of the enterprise. The enterprise may permit the service provider to allow other enterprises to make use of spare capacity on a temporary basis.
“Functional steps” can encompass any type of function of the business process, for any purpose, such as interacting with an operator receiving inputs, retrieving stored data, processing data, passing data or commands to other entities, and so on, typically but not necessarily, expressed in human readable form.
“Deployed” is intended to encompass a modeled business process for which the computing infrastructure has been allocated and configured, and the software application components have been installed and configured ready to become operational. According to the context it can also encompass a business process which has started running.
“business process” is intended to encompass any process involving computer implemented steps and optionally other steps such as human input or input from a sensor or monitor for example, for any type of business purpose such as service oriented applications, for sales and distribution, inventory control, control or scheduling of manufacturing processes for example. It can also encompass any other process involving computer implemented steps for non business applications such as educational tools, entertainment applications, scientific applications, any type of information processing including batch processing, grid computing, and so on. One or more business process steps can be combined in sequences, loops, recursions and branches to form a complete Business Process. Business process can also encompass business administration processes such as CRM, sales support, inventory management, budgeting, production scheduling and so on, and any other process for commercial or scientific purposes such as modeling climate, modeling structures, or modeling nuclear reactions.
“computing infrastructure” is intended to encompass any type of resource such as hardware and software for processing, for storage such as disks or chip memory, and for communications such as networking, and including for example servers, operating systems, virtual entities, and management infrastructure such as monitors, for monitoring hardware, software and applications. All of these can be “designed” in the sense of configuring and/or allocating resources such as processing time or processor hardware configuration or operating system configuration or disk space, and instantiating software or links between the various resources for example. The resources may or may not be shared between multiple business processes. The configuring or allocating of resources can also encompass changing existing configurations or allocations of resources. Computing infrastructure can encompass all physical entities or all virtualized entities, or a mixture of virtualized entities, physical entities for hosting the virtualized entities and physical entities for running the software application components without a virtualized layer.“parts of the computing infrastructure” is intended to encompass parts such as servers, disks, networking hardware and software for example.
The present invention can be applied to many areas, the embodiments described in detail can only cover some of those areas. It can encompass modeling dynamic or static systems, such as enterprise management systems, networked information technology systems, utility computing systems, systems for managing complex systems such as telecommunications networks, cellular networks, electric power grids, biological systems, medical systems, weather forecasting systems, financial analysis systems, search engines, and so on. The details modeled will generally depend on the use or purpose of the model. So a model of a computer system may represent components such as servers, processors, memory, network links, disks, each of which has associated attributes such as processor speed, storage capacity, disk response time and so on. Relationships between components, such as containment, connectivity, and so on can also be represented.
An object-oriented paradigm can be used, in which the system components are modeled using objects, and relationships between components of the system are modeled either as attributes of an object, or objects themselves. Other paradigms can be used, in which the model focuses on what the system does rather than how it operates, or describes how the system operates. A database paradigm may specify entities and relationships. Formal languages for system modeling include text based DMTF Common InformationModel (CIM), Varilog, NS, C++, C, SQL, or graphically expressed based schemes.
A location of the dedicated hardware can be remote from the service provider and the interface can be arranged for remote management. This is useful to distribute the load away from resources at a service provider location, and to ease bandwidth and latency limitations, especially if the location of the dedicated hardware is at an enterprise premises or at a local trusted internet service provider of the enterprise.
The computing infrastructure can comprise virtualized entities. This is one way of increasing flexibility of allocation of resources, and thus enabling improved efficiency of use of the resources.
The model can incorporate redundant hardware capacity of suitable size to enable virtualized entities to be moved off their corresponding hardware components onto the redundant hardware while the process is still running. This redundancy would normally not need to be included in a model for deployment in a shared data centre as the data centre management would provide redundant capacity on a shared basis. Redundant capacity can also be used to support growth in loads or increases in loads due to changes in functional steps.
The system can have an update part arranged to enable the enterprise to input alterations to functional steps or non functional requirements, and to cause the model generation part to generate an updated model based on the alterations, and determine any changes in requirements for the dedicated hardware corresponding to the altered functional steps or non functional requirements.
The system can have a download part to download at least the model generation part to run at an enterprise location. This can help distribute the processing, to reduce the load on resources at the service provider, and can ease security concerns by enabling the enterprise to avoid sending sensitive data to the service provider for example.
The model can have a monitoring part to monitor behaviour of the deployed process in use and to send an indication of the behaviour through the interface to the service provider. This can enable the service provider to monitor the deployed process and take appropriate action. A basic level of service might involve reporting to the enterprise. A higher level of service could involve taking action to deal with infrastructure failures or routine upgrading. A yet higher level of service could involve analysing the behaviour and determine proposed changes to the model to improve a match of the computing infrastructure to the monitored behaviour. This could improve efficiency of use of resources or finding opportunities to improve flexibility to respond to time varying demands or changes to requirements for functional steps for example.
The model generation part can be arranged to select one of a number of predetermined templates of computing infrastructure design, choose parameters to fill the selected template, evaluate the filled template by simulating operation to see how well the non functional requirements are met, and alter the selection of template or alter the parameters according to the evaluation. This use of an infrastructure design template can reduce the number of options to be evaluated and can help reduce the complexity of the task of generating a model which can be deployed and which makes efficient use of resources. This in turn can help enable a more highly automated method, or can enable more complex business processes to be deployed more efficiently, and managed more efficiently. Where the infrastructure includes virtualized entities, the increased flexibility tends to increase the complexity of the task of infrastructure design, and the use of templates becomes even more appropriate and valuable in this case.
The system can have non functional requirements comprising any one or more of: a number of concurrent users, throughputs for functions, an indication of desired response time, an availability level, a security level, and limits of available dedicated hardware available. These are typically significant for the design of the computing infrastructure.
The system can be arranged to determine from the model a specification of requirements for the dedicated hardware. This can enable appropriate hardware to be set up ahead of the deployment. An alternative, encompassed by other claims, if the dedicated hardware is pre existing, would be to set limits on the performance required of the dedicated hardware in the non functional requirements. Then the model will be constrained to stay within such limits so that the model can be successfully deployed on the pre existing hardware.
Where a 3-D visual interface is provided with a game server to enable multiple users to work on the same model and see each others changes, developers can navigate complex models more quickly. Reference is made to above referenced copending application No. 200702356 for more details of examples of this. Combining this with using enterprise dedicated hardware with an interface to the service provider to enable ongoing management can enable such ongoing management to be provided more efficiently.
An enterprise interface can be provided to enable the enterprise to customise the non functional requirements independently of each other. Reference is made to above referenced copending application No. 200702363 for more details of examples of this. Combining this with using enterprise dedicated hardware with an interface to the service provider to enable ongoing management can enable more complete customisation to the enterprise's needs.
Where the operation of the business process can be simulated or where multiple test deployments can be made in parallel, development can be accelerated. Reference is made to above referenced copending application No. 200702377 for more details of examples of this. Combining this with using enterprise dedicated hardware with an interface to the service provider to enable ongoing management can enable the advantages of both to be enhanced.
Where annotations are inserted in the source code to assist in modeling or in documentation, then documenting the history of changes can be made easier. Reference is made to above referenced copending application No. 200702600 for more details of examples of this.
Setting up of a development environment can be facilitated by providing a predetermined mapping of which tools are appropriate for a given development purpose and given part of the model, or by including models of tools to be deployed with the model. Reference is made to above referenced copending application Nos. 200702145, and 200702601 for more details of examples of this. As the use of enterprise dedicated hardware with an interface to the service provider can add complexity to the setting up of the development environment, it is all the more valuable to facilitate such setting up.
A general aim of this model based approach is to enable development and management of the business process to provide matched changes to three main layers: the functional steps of the process, the software application components used to implement the functional steps of the process, and configuration of the computing infrastructure used by the applications. Such changes are to be carried out automatically by use of appropriate software tools interacting with software models modeling the above mentioned parts. Until now there has not been any attempt to link together tools that integrate business process, application and infrastructure management through the entire system lifecycle.
A model is an organized collection of elements modeled in UML for example. A goal of some embodiments is to use these data models for the automated on-demand provision of enterprise applications following a Software as a service (SaaS) paradigm.
Using Model-Based technologies to automatically design and manage Enterprise Systems can offer powerful predictive power, and the capability to automatically design, deploy, modify, monitor, and manage a running system to implement a business process, while minimizing the requirement for human involvement.
The Enterprise System can be modeled at 4 interconnected layers:
This model is called the Enterprise System Model. At each layer, it consists of two sets of models—the Automation Model and the Document Model.
The Automation Model describes the structure and behaviour of the System, and is used to automatically generate, evaluate, deploy, and modify designs for Enterprise Systems. Monitored data from the deployed physical system at each of the 4 layers can be correlated with modeled behaviour and used to make run-time management decisions based on actual measurements.
The Automation Model is composed of two sub-models—the Static Model and an Operational Model. The Static Model describes the static structure of the system—the selection and configuration options of candidate designs of the Enterprise System. The Operational Model describes the internal structure, run-time operation, and performance demands (such as CPU, memory, disk, or network I/O) of the infrastructure and software. It is these Operational Models that allow simulation and evaluation of how well a candidate design will meet the non-functional requirements of the System.
The output from Monitoring and Reporting Services could also be classified as a special case of the Document Model, describing the run-time behaviour and performance of the system in human-readable form. Enterprise Systems are very complex, and the Models underlying the modeling techniques are correspondingly complex and difficult to create. The Models may change over time as systems are modified, patched and redesigned. Additionally, the models may depend on the actual data and configuration contained within a specific System and the observed behaviour of a running system.
The embodiments are concerned with providing a mechanism to automatically generate key aspects of the required Automation Models of an Enterprise System, together with additional Document Models to be used by humans to understand and analyse the system.
Embodiments are concerned with configuring an enterprise application solution for an enterprise application computing appliance. This can involve accepting a customized description for an enterprise application system and deploying it to hardware (also called an appliance). The appliance can in some cases be specially designed using virtualization features to enable ongoing and remote management for the enterprise application and appliance and be tested for performance to verify that service levels requested are met. The appliance may operate on an enterprise premises or at an ISP of the enterprise's choosing for example. Enterprises want to have a choice whether to operate enterprise applications in shared environments or within an enterprise application appliance that operates at a location of their choice.
This approach provides choice for enterprises which want enterprise applications but prefer to outsource management, i.e., remote management coupled with on-site maintenance when necessary. Vendors providing an application appliance need to offer the right amount of capacity, too much or too little causes extra costs, the risk may prohibit the success of enterprise application appliances. An enterprise appliance that is verified to support the non-functional requirements of enterprises prior to delivery can lead to greater enterprise trust.
The use of virtualized infrastructure, e.g., with virtual machine migration, better support remote maintenance e.g., new hardware can be introduced and virtual machines migrated to it without shutting down the application e.g., new versions of software can be deployed and tested in the appliance prior to any upgrade of the operational software. Automatically deploying management services with enterprise application services can better enable consistent remote management and facilitate on-site maintenance when necessary.
Such model based configuration compares well to configuration done by hand, which can lead to differences in enterprise application environments which increases the complexity of remote management.
Infrastructure deployed by hand rather than being automated can mean the sizing method for particular parts of infrastructure, is ad hoc, increasing the risk of an incorrect amount of capacity in an appliance. Currently service providers only offer hosting in a shared environment even if an enterprise wants to operate an enterprise application appliance locally or in some other facility.
Some advantages which can arise include the following:
A customized solution can be provided via automation technologies rather than via scarce skilled human consultants. Enterprises can host solutions locally or at any location they desire thereby reducing dependency on wide area networks and application service providers. A combination of enterprise application services from multiple vendors can be provided on a single appliance. A combination or remote and on-site servicing can reduce the in house skills needed by enterprises to host their services locally. A single enterprise appliance places a less concentrated power and cooling burden on the public power grid than a large data center.
EXAMPLE Operation of an Embodiment
A: Enterprise specifies requirements for system.
B: Design appropriate infrastructure to support the system and its management.
C: Render the infrastructure to an enterprise application appliance & deploy the enterprise and management services.
D: Affirm non-functional requirements are satisfied via testing.
E: Ship the enterprise appliance to enterprise.
F: Enterprise connects appliance to networks for use by users & for remote management.
G: Continuously apply remote and on-site management as appropriate, and implement changes in Enterprise requirements.
Step A: An enterprise uses one or more configuration tools to specify and configure a legal combination of enterprise application services. The enterprise application services may be offered by enterprise application service vendors, ISVs, (Internet Service Vendors) or be customizations that are tolerated by the overall framework presented in this application.
Configuration tools may be offered by enterprise application software vendors or ISVs and/or the enterprise application provider
Step B: designing a virtualized infrastructure for the enterprise application that can be hosted on an enterprise application appliance. Enterprise specifies non-functional requirements for the system and/or its services
E.g., performance, security, reliability, maintainability.
Design service recommends a configuration for an infrastructure design that supports the non-functional requirements for a particular enterprise application appliance. Infrastructure design includes support for firewalls, web servers, application servers, database servers, other kinds of servers, additional management software, hardware to support maintenance (i.e., roll over to a new version of software), it may include multiple servers and networking support.
Step C: render the application and management services to the virtualized infrastructure. A virtualized infrastructure is rendered to enterprise dedicated hardware in the form of an appropriately sized application appliance. This can be any size as appropriate to the needs of the business process, and in a typical example is a server or a rack of servers. Enterprise application and management services such as the remote management interface to the service provider are deployed to the infrastructure on the appliance.
Step D: validation tests are conducted to affirm support for non-functional requirements. Tests are conducted to ensure that each non-functional requirement is satisfied. If appropriate, tuning mechanisms are used to enable satisfaction of the requirements.
Step E: ship a configured appliance to an enterprise's desired location for the enterprise application appliance. The configured appliance is shipped to the enterprise's desired location for the enterprise application appliance. The location may be at the enterprise's site, at a hosting site chosen by the enterprise etc., it is any location deemed jointly acceptable to the enterprise and to the enterprise application appliance provider.
Step F: Enterprise need only turn on the appliance and connect it to networks for use by users. In all cases remote management services management and maintain the enterprise application appliance. In other embodiments the appliance is shipped first and configured remotely.
Step G: ongoing remote management/maintenance for the enterprise application and appliance. Remote maintenance can include support for:
Software and hardware upgrades and additions
Recognizing when on-site maintenance is needed and scheduling it On-site maintenance can include support for:
Hardware failure management and hardware upgrades
Services not successfully accomplished remotely
The enterprise may change the requirements for the system,—E.g., adding/removing services that are supported by the enterprise application appliance or modifying non-functional requirements. The impact of these changes is evaluated by remote management services and a combination or remote and, if required, on-site management actions are performed to implement the changes.
FIG. 16 shows some of the principal parts of an embodiment of the invention. It shows enterprise side items on the left side and service provider side items on the right side. An enterprise interface 710 is used to pass non functional requirements and functional steps of the desired business process to the service provider side. Here a model generation part 720 generates a model 730 of the business process. This can be stored at either the enterprise side or the service provider side. It may have a layered structure with an arrangement of software application components for implementing the functional steps, and a design of computing infrastructure for miming the software application components to meet the non functional requirements. More details of an implementation of the model generation part are shown below with reference to a model information flow and FIGS. 1 to 15. There is also shown in FIG. 16 a deployment part 740, located either at the enterprise or the service provider side. This creates a deployed business process 750 formed of the deployed modeled software application components and computing infrastructure. This is formed on enterprise dedicated hardware 770. Monitored data from the deployed business system can be fed back to a remote management services part 700. Management services 712 are provided in the service provider side to communicate with the enterprise side via the corresponding remote management services part 700. This provides an interface to enable the service provider to manage the activities at the enterprise side. The service provider side parts are typically software parts running on hardware in the form of shared data centre resources 780.
As shown in FIG. 17, an example of steps of the system of FIG. 16 in operation starts with receiving the inputs from the enterprise at step 805. This can include non functional requirements, and other items such as functional steps of the business process (or a choice of predetermined steps from a catalog for example), and a service level agreement if needed. At step 815 a model of software application components to implement the functional steps is generated by the model generation part. This can be implemented in various ways, and example is described in more detail with reference to FIGS. 1 to 15 below.
At step 825, a model of computing infrastructure for use in running the software application components is generated. This can be physical infrastructure, virtualised infrastructure, or commonly a mixture of both, some of the physical infrastructure for running the components and some for hosting the virtualised infrastructure. All is designed to meet the non functional requirements. The design may be semi automated in the sense of having an operator make decisions but being prompted and guided by design service software, such as the design template approach described in more detail below. At step 835, the enterprise dedicated hardware is set up to match the requirements of the model. At step 845 the model is deployed on physical infrastructure, complete with an interface to the service provider. This helps enable ongoing management of the deployed process, provided at step 855.
FIG. 18 shows steps according to another embodiment, with testing. At step 800 a model is generated according to functional steps and non functional requirements. A specification of the dedicated hardware is preferably generated and output at step 810. The hardware is set up for testing, according to the specification at step 820. The model is deployed on the dedicated hardware at step 830. It can be tested to verify it meets the non functional requirements at step 840. The dedicated hardware can be at the service provider's location for testing. If so, it after testing, having the business process deployed on it, it can be moved to the enterprise's chosen location at step 850. There, remote management should be set up at step 860, and the business process can be activated at step 870.
FIG. 19 shows steps according to another embodiment, for existing dedicated hardware. At step 900 a model is generated according to functional steps and non functional requirements, and according to limitations of existing enterprise dedicated hardware. The model is deployed on the existing dedicated hardware at step 910. Remote management can be set up at step 920. It can be tested to verify it meets the non functional requirements using the remote management part, at step 930. At step 940, the Enterprise proposes changes to functional steps or non functional requirements. These are passed to the model generation part. The service provider uses this part to generate a revised model with revisions to infrastructure design or software application components, to implement the proposed changes. A test deployment can be carried out at the data center at step 970, and the remote management parts be used to send the revisions and deploy them at step 972.
FIG. 20 shows another embodiment showing actions of an update part, which can be one part of the remote management services. For changes prompted by any party such as the enterprise, a software supplier, or the service provider, the update part determines which modeled entities should be revised at step 975. This can be parts in lower layers or higher layers of the model. The changes can be during development or during ongoing management of a live process. The update part creates a test environment either at the enterprise or at the service provider location. Possible ways of setting up test environments are shown in more detail in the above referenced copending cases '2145 and '2601. The update part generates at step 985 a test deployment of changes in the test environment, according to the infrastructure design template. If the changes are verified as allowable, meeting template requirements, the update part will cause the changes to be implemented at step 987.
FIG. 21 shows another embodiment similar to that of FIG. 16. Similar reference numerals have been used as appropriate. In addition, some parts are located at an ISP (Internet Service Provider) local to the enterprise. In this view the parts located at the ISP are shown in the center of the figure. The enterprise interface is still at the enterprise. The remote management services, the model generation part, the model store, and the deployment part are located at the ISP, though they could be located elsewhere such as at the service provider location. The enterprise dedicated hardware is part of the ISP hardware 771. So the deployed business process 750 formed of the deployed modeled software application components and computing infrastructure is formed on the ISP hardware 771. Also shown here is a test environment 717, at the service provider's location so that ISP resources are not occupied by it.
Program Code or Program Models may be generated via tools, such as graphical editors, or directly by humans. The syntax and language used to describe Source Content may vary widely.
The resulting computational model can be used to automate the simulation, evaluation, and design of the system.
Next the computing infrastructure such as virtual machines, operating systems, and underlying hardware, is designed. This can use templates as described in more detail below, and in above referenced previously filed application Ser. No. 11/741,878 “Using templates in automated model-based system design” incorporated herein by reference. A template is a model that has parameters and options, by filling in the parameters and selecting options a design tool transforms the template into a complete model of a deployable system. This application shows a method of modeling a business process having a number of computer implemented steps using software application components, to enable automatic deployment on a computing infrastructure, the method having the steps of:
All of this can use SAP R/3 as an example, but is also applicable to other SAP systems or non-SAP systems. Template technology as described below can include not only the components needed to implement the business process and the management components required to manage that business process, but also designs for computing infrastructure.
General Model: The starting point, for example a high level description of business steps based on “out-of-the-box” functionalities of software packages the user can choose from, and the generic business processes and their constituent business process steps.
Custom Process Model: defined above and for example a specialization of the previous model (General Model) with choices made by the enterprise. This model captures non-functional requirements such as response time, throughput and levels of security. Additionally, it specifies modifications to the generic business processes for the enterprise. Additionally, it can specify modifications to the generic business processes for the enterprise.
Resource Configuration Service (RCS): its role is to create/update the virtual infrastructure.
Software Deployment Service (SDS): installs and configures the applications needed to run the business processes, and potentially other software.
The deriving of the grounded model from the unbound model can involve specifying a mapping of each of the application components to a server. This is part of configuring the application components to suit the design of adaptive infrastructure. The template may limit the range of possible mappings, to reduce the number of options, to reduce complexity of finding an optimised solution for example.
The deriving of the grounded model from the Unbound Model can involve specifying a configuration of management infrastructure for monitoring of the deployed business process in use. This monitoring can be at one or more different levels, such as monitoring the software application components, or the underlying adaptive infrastructure, such as software operating systems, or processing hardware, storage or communications.
More than one grounded model can be derived, each for deployment of the same business process at different times. This can enable more efficient use of resources for business processes which have time varying demand for those resources for example. Which of the grounded models is deployed at a given time can be switched over any time duration, such as hourly, daily, nightly, weekly, monthly, seasonally and so on. The switching can be at predetermined times, or switching can be arranged according to monitored demand, detected changes in resources, such as hardware failures or any other factor.
Two notable points in the modeling philosophy are the use of templates to present a finite catalogue of resources that can be instantiated, and not exposing the hosting relationship for virtualized resources. Either or both can help reduce the complexity of the models and thus enable more efficient processing of the models for deployment or changing after deployment.
The template selected can also be used to limit changes to the system, such as changes to the business process, changes to the application components, or changes to the infrastructure, or consequential changes from any of these. This can make the ongoing management of the adaptive infrastructure a more tractable computing problem, and therefore allow more automation and thus reduced costs. In some example templates certain properties have a range: for example 0 to n, or 2 to n. A change management tool (or wizard, or set of tools or wizards) only allows changes to be made to the system that are consistent with template. The template is used by this change management tool to compute the set of allowable changes, it only permits allowable changes. This can help avoid the above mentioned difficulties in computing differences between models of current and next state, if there are no templates to limit the otherwise almost infinite numbers of possible configurations.
The management system has a visual interface to an infrastructure management operator 200, possibly with a 3D visual representation, as described in the corresponding copending application referenced above. This operator can be service provider staff, or in some cases can be trained staff of the business owning the process. The service provider staff may be able to view and manage the processes of different businesses deployed on the shared infrastructure. The operators of a given enterprise would be able to view and manage only their own processes. As discussed above, the interface can be coupled to the management system 210 to enable the operator to be able to interact with the various types of models, and with the infrastructure design template.
FIG. 2 shows a schematic view of some operation steps by an operator and by the management system, according to an embodiment. Human operator actions are shown in a left hand column, and actions of the management system are shown in the right hand column. At step 500 the human operator designs and inputs a business process (BP). At step 510 the management system creates an unbound model of the BP. At step 520, the operator selects a template for the design of the computing infrastructure. At step 530, the system uses the selected template to create a grounded model of the BP from the unbound model and the selected template. In principle the selection of the template might be automated or guided by the system. The human operator of the service provider then causes the grounded model to be deployed, either as a live business process with real customers, or as a test deployment under controlled or simulated conditions. The suitability of the grounded model can be evaluated before being deployed as a live business process, an example of how to do this is described below with reference to FIG. 3.
FIG. 4 shows some of the principal elements of the MIF involved in the transition from a custom model to a deployed instance. For simplicity, it does not show the many cycles and iterations that would be involved in a typical application lifecycle—these can be assumed. The general model 15 of the business process is the starting point and it is assumed that a customer or consultant has designed a customized business process. That can be represented in various ways, so a preliminary step in many embodiments is customising it. A custom model 18 is a customization of a general model. So it is likely that a General Model could be modeled using techniques similar to the ones demonstrated for modeling the Custom Model: there would be different business process steps. A custom model differs from the general model in the following respects. It will include non-functional requirements such as number of users, response time, security and availability requirements. In addition it can optionally involve rearranging the business process steps: new branches, new loops, new steps, different/replacement steps, steps involving legacy or external systems.
FIG. 8 shows parts of a master application server for the embodiment of FIG. 7. An enqueue process 110 is provided to manage locks on the database. A message server 120 is provided to manage login of users and assignment of users to slave application servers for example. An update server 130 is provided for managing committing work to persistent storage in a database. A print server 140 can be provided if needed. A spool server 150 can be provided to run batch tasks such as reports. At 160 dialog worker processes are shown for running instances of the application components.
The next part of this document describes in more detail with reference to FIGS. 10 to 15 examples of models that can be used within the Model Information Flow (MIF) shown in FIGS. 1 to 9, particularly FIG. 4. These models can be used to manage an SAP application or other business process through its entire lifecycle within a utility infrastructure. The diagrams are shown using the well known UML (Unified Modeling Language) that uses a CIM (common information model) style. The implementation can be in Java or other software languages.
A BPStep may have a set of non-functional requirements (NonFunctionalRequirements) associated with it: performance; availability, security and others. Availability and security requirements could be modeled by a string: “high”, “medium”, “low”. Performance requirements are specified in terms of for example a number of registered users (NoUsersReq), numbers of concurrent users of the system, the response time in seconds and throughput requirement for the number of transactions per second. Many BPSteps may share the same set of non-functional requirements. A time function can be denoted by a string. This specifies when the non-functional requirements apply, so different requirements can apply during office-hours to outside of normal office hours. Richer time varying functions are also possible to capture end of months peaks and the like.
FIG. 11 shows an example of a custom model instance for the SD Benchmark. The top two boxes indicate that the business process “BPModel” contains one top level BPStep: “SD Benchmark”, with stepType=Sequence. Two lines are shown leading from this box, one to the non-functional requirements associated with this top-level BPStep, and shown by the boxes at the left hand side. In this particular case only performance requirements have been specified—one for 9 am-5 pm and the other for 5 pm-9 am. Other types of non-functional requirements not shown could include security or availability requirements for example. In each case the performance requirements such as number of users, number of concurrent users, response time required, and throughput required, can be specified as shown. These are only examples. other requirements can be specified to suit the type of business process. A box representing the respective time function is coupled to each performance requirement box as shown. One indicates 9 am to 5 pm, and the other indicates 5 pm to 9 am in this example.
On the right hand side a line leads from the SD Benchmark BPStep to the functional requirements shown as six BPSteps, with stepType=Step—one for each SAP transaction shown in FIG. 10 (VA01, VL01N, etc). For convenience the name of the first dialog step for each transaction shown in FIG. 10 is used as the name of the corresponding BPStep shown in FIG. 11 (“Create sales order”, “Create outbound delivery”, “Display customer sales order”, “Change outbound delivery”, “List sales order”, and “Create delivery document”). For each of these steps the BPStepToApplicationComponentMapping relation specifies the details of the dialog steps involved. For example in the case of CreateSalesOrder, FIG. 10 shows that the BPStepToApplicationComponentMapping needs to specify the following dialog steps are executed in order: “Create Sales Order”, “Fill Order Details”, “Sold to Party” and “Back”. In addition it might specify the number of line items needed for “Fill Order Details”. At the right hand side of the figure, each BP step is coupled to an instance of its corresponding ApplicationComponent via the respective mapping. So BPstep “Create Sales order” is coupled to ApplicationComponent VA01, via mapping having ID:001. BPstep “Create outbound delivery” is coupled to ApplicationComponent VL01N via mapping having 1D:002. BPstep “Display customer sales order” is coupled via mapping having ID:003 to ApplicationComponent VA03. BPstep “Change outbound delivery” is coupled via mapping having 1D:004 to ApplicationComponent VL02N. BPstep “List sales order” is coupled via mapping having 1D:005 to ApplicationComponent VA05. BPstep “Create delivery document” is coupled via mapping having 1D:006 to ApplicationComponent VF01.
One or more ApplicationModules are contained within a product. So for example SAP R/3 Enterprise contains SD. ApplicationModules can be dependent on other ApplicationModules. For example the SD Code for the Application Server depends on both the SD Data and the SD Executable code being loaded into the database. The Application Packaging Model shows the ApplicationExecutionComponent that executes an ApplicationComponent. This could be a servlet running in an application server or a web server. It could also be a thread of a specific component or a process. In the case of SD's VAO1 transaction it is a Dialog Work Process. When it executes, the ApplicationComponent may indirectly use or invoke other Application-Components to run: a servlet may need to access a database process; SD transactions need to access other ApplicationComponents such as the Enqueue Work Process and the Update Work Process, as well as the Database ApplicationExecutionComponent.
The ApplicationExecutionComponent can be contained by and executed in the context of an ApplicationExecutionService (SAP application server) which loads or contains ApplicationModules (SD) and manages the execution of ApplicationExecutionComponents (Dialog WP) which, in turn, execute the ApplicationComponent (VA01) to deliver a BPStep.
Performance constraints on ApplicationExecutionServices—e.g. do not run an application server on a machine with greater than 60% CPU utilization Other examples of constraints include ordering: the database needs to be started before the application server. Further constraints might be used to encode deployment and configuration information. The constraints can be contained all in the templates, or provided in addition to the templates, to further limit the number of options for the grounded model.
The Component Performance Model Taken together, the models of the Unbound Model specify not only the non-functional requirements of a system, but also a recipe for how to generate and evaluate possible software and hardware configurations that meet those requirements. The generation of possible hardware configurations is constrained by the choice of infrastructure available from a specific Infrastructure Provider, using information in an Infrastructure Capability Model, and by the selected template.
As discussed above, two notable features of the modeling philosophy described are:
FIG. 13 shows an example of an infrastructure design template having predetermined parts of the computing infrastructure, predetermined relationships between the parts, and having a limited number of options to be completed. In this case it is suitable for a decentralised SD business process, without security or availability features. The figure shows three computer systems coupled by a network labelled “AI_network”, the right hand of the three systems corresponding to a master application server, and the central one corresponds to slave application servers as shown in FIG. 7. Hence it is decentralized. AI is an abbreviation of Adaptive Infrastructure. The left hand one of the computer systems is for a database. The type of each computer system is specified, in this case as a BL20/Xen. The central one, corresponding to slave application servers has an attribute “range =0 . . . n”. This means the template allows any number of these slave application servers.
The master and slave application servers and the database computer system have an operating system shown as AI_disk: OSDisk. The master application server is shown with an AI_Disk: CIDisk as storage for use by the application components. For the network, each computer system has a network interface shown as AI_Nic1, coupled to the network shown by AI_Network :subnet1.
In some examples the server may only have an OS disk attached; that is because the convention in such installations is to NFS mount the CI disk to get its SAP executable files. Other example templates could have selectable details or options such as details of the CIDisk and the DBDisk being 100 GB, 20MB/sec, non Raid, and so on. The OS disks can be of type EVA800. The master and slave application servers can have 2 to 5 dialog work processes. Computer systems are specified as having 3 GB storage, 2.6 GHz CPUs and SLES 10-Xen operating system for example. Different parameters can be tried to form candidate Grounded Models which can be evaluated to find the best fit for the desired performance or capacity or other criteria.
It is not always the case that for the MIF all tools and every actor can see all the information in the model. In particular it is not the case for deployment services having a security model which requires strong separation between actors. For example, there can be a very strong separation between a utility management plane and farms of virtual machines. If a grounded model is fed to the deployment services of the management plane by an enterprise, to deploy the model, it will not return any binding information showing the binding of virtual to physical machines, that will be kept inside the management plane. That means there is no way of telling to what hardware that farm is bound or what two farms might be sharing. What is returned from the management plane could include the IP address of the virtual machines in the farms (it only deals with virtual machines) and the login credentials for those machines in a given farm. The management plane is trusted to manage a farm so that it gets the requested resources. Once the deployment service has finished working, one could use application installation and management services to install, start and manage the applications. In general different tools will see projections of the MIF. It is possible to extract from the MIF models the information these tools require and populate the models with the results the tools return. It will be possible to transform between the MIF models and the data format that the various tools use.
1. A method of automated deployment managed by a service provider, of a computer based business process having a number of functional steps, for a given enterprise, the method having the steps of:
generating a model of the business process, the model having a representation of an arrangement of software application components, for implementing the functional steps, and having a representation of computing infrastructure, for running the software application components on specified enterprise dedicated hardware, and suitable for automated deployment, and
11. A system, for automated deployment managed by a service provider, of a computer based business process having a number of functional steps, for a given enterprise, the system having:
a model generation part arranged to generate a model of the process, the model having a representation of an arrangement of software application components, for implementing the functional steps, and having a representation of computing infrastructure, for running the software application components on specified enterprise dedicated hardware, and suitable for automated deployment, and
US12808229 2007-12-20 2007-12-20 Model Based Deployment Of Computer Based Business Process On Dedicated Hardware Granted US20110004564A1 (en)
PCT/US2007/088336 WO2009082386A1 (en) 2007-12-20 2007-12-20 Model based deployment of computer based business process on dedicated hardware
US20110004564A1 true true US20110004564A1 (en) 2011-01-06
ID=40801485
US12808229 Granted US20110004564A1 (en) 2007-12-20 2007-12-20 Model Based Deployment Of Computer Based Business Process On Dedicated Hardware
US (1) US20110004564A1 (en)
CN (1) CN101946258B (en)
EP (1) EP2223277A4 (en)
WO (1) WO2009082386A1 (en)
US20140082116A1 (en) * 2011-03-15 2014-03-20 Omron Corporation Design assistance device of network system
US9596124B2 (en) * 2011-03-15 2017-03-14 Omron Corporation Assistance device of network system
CN101946258A (en) 2011-01-12 application
WO2009082386A1 (en) 2009-07-02 application
CN101946258B (en) 2013-05-29 grant
EP2223277A1 (en) 2010-09-01 application
EP2223277A4 (en) 2012-02-29 application
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ROLLA, JEROME;EDWARDS, NIGEL;BELROSS, GUILLAUME ALEXANDRE;AND OTHERS;SIGNING DATES FROM 20100524 TO 20100527;REEL/FRAME:025091/0777