WO2005003968A1

WO2005003968A1 - Procedure implementation

Info

Publication number: WO2005003968A1
Application number: PCT/AU2004/000832
Authority: WO
Inventors: Mark Pickering; John Brizee; Paul Simpson; Sam Raco
Original assignee: Bay Technologies Pty Ltd
Priority date: 2003-07-02
Filing date: 2004-06-24
Publication date: 2005-01-13

Abstract

This specification describes a system for installing software in a computer on a network. The user may select the desired software packages and this system automatically installs that software taking into account the configuration of the particular computer. It also automatically attends to licensing, security features, user authorities, IT governance, etc.

Description

PROCEDURE IMPLEMENTATION

Background of the Invention

The present invention relates to a method and apparatus for performing procedures and in particular for performing procedures using a processing system coupled to a communications network.

Description of the Prior Art

The reference to any prior art in this specification is not, and should not be taken as, an acknowledgment or any form of suggestion that the prior art forms part of the common general knowledge.

Typically when it is desired to perform a procedure, such as installing software applications on end stations in a business environment, this is a substantially manual process. In particular it is necessary for a user to submit a request to an IT department, who will then be responsible for performing a manual installation or to manually initiate the installation of the software. This may be achieved via a communications network, for example by using remote controlling software, such as PC Anywhere. Furthermore, in some circumstances, this may be achieved by adding the respective user's name to a group and then having the software automatically deployed in accordance with the grouping. In any event, this is a manual process and relies on an operator of the IT department being available to control the installation process, or at least maintain the grouping. This manual implementation leads to a number of additional problems.

For example, the operator must assess on a case by case basis the manner in which the installation is to be achieved to take into account the configuration of the end station onto which the software is installed. This means that each time problems occur these must be handled during the installation procedure, which can be time consuming.

In addition to this, with this procedure being performed substantially manually many enterprises have difficulty policing licensing requirements, and controlling which individuals have access to which software applications, which can be an issue for security purposes.

It will be appreciated that a number of automated installations procedures, such as the Microsoft Windows update procedures, are known. However, these installations do not take into account factors such as the existing configuration of the end station on which the software is to be installed, and as a result, this often results in the installation causing additional problems, such as conflicts with existing software applications. Furthermore, there are few in built control mechanisms to be determine if the proposed installation will be beneficial. Furthermore, these techniques are also specific to software installation and cannot be applied to more generic procedures. Thus, existing processes for installation of software, or for performing other business procedures, do not include any provisions for associated workflow. Accordingly, these processes assume the end-user is totally empowered to make the installation, so there is little opportunity for business or IT governance to be applied.

Summary of the Present Invention

In a first broad form the present invention provides a method of performing a service, wherein the method includes, in a processing system: (a) selecting a defined procedure embodying the required service; (b) determining, using the procedure, one or more entities involved in the procedure; (c) determining, using the procedure, one or more jobs to be performed by each entity; (d) generating, using the determined one or more jobs, indicating data indicative of the one or more jobs to be performed; and, (e) transferring the indicating data to the one or more entities, the entities being responsive to received indicating data to perform the one or more jobs.

Typically the method includes, in the processing system: (a) determining an entity indication using a least one of: (i) the procedure; (ii) collected data; and, (iii) a rules engine; and, (b) transferring the indicating data to the entity processing systems using the determined entity indications.

Typically the procedure is indicative of a sequence, and wherein the method includes transferring the indicating data to the entities in accordance with the sequence.

If an entity is a user of an entity processing system, the method generally includes, in the processing system, generating indicating data indicative of instructions, the entity processing system being responsive to the indicating data to present the instructions to the user.

If an entity is an agent installed on an entity processing system, the method generally includes, in the processing system, generating indicating data indicative of a set of instructions, the agent being responsive to the indicating data to execute the instructions.

The method typically includes, in the processing system: (a) determining if an agent is installed on the entity processing system; and, (b) cooperating with the entity processing system to install an agent thereon in response to an unsuccessful comparison. The indicating data generally includes at least one of: (a) one or more job files; and, (b) one or more messages.

The indicating data can be in the form of an XML file.

The method generally includes, in a data collection stage, and in the processing system: (a) determining using the procedure, data to be collected from one or more respective entities; (b) transferring indicating data to the respective entities, the entities being to the indicating data to determine the data to be collected, and provide an indication of the collected data to the processing system; (c) receiving the indication of the collected data; and, (d) causing the procedure to be performed using the collected data.

The method can include in an authorisation stage, and in the processing system: (a) determining one or more entities for providing authorisation, using at least one of: (i) collected data; (ii) the procedure; (iii) a rules engine; (b) transferring the indicating data to respective entities, the entities being responsive to determine an authorisation and provide an indication of the authorisation in the indicating data; (c) receiving the indicating from the entities; and, (d) using the authorisation indication to determine if the procedure is to be performed.

The method preferably includes in a performance stage, and in the processing system, transferring the indicating data to respective entities, the entities being responsive to the indicating data to perform a respective job defined therein.

The method typically includes in a completion stage, and in the processing system, transferring the indicating data to respective entities, the entities being responsive to the indicating data to perform a respective job defined therein.

The method typically includes: (a) transferring the indicating data to respective entities, the entities being responsive to the indicating data to provide an indication of the completion of a respective job in the indicating data; (b) receiving the indicating from the entities; (c) using the completion indication to determine if the procedure is completed; and, (d) generating a notification of the completion in response to a successful determination. The method can include, in the processing system: (a) communicating with one or more entities to determine a scheduling indication; and, (b) performing the procedure using the scheduling indication.

The scheduling indication may be indicative of at least one of: (a) a time for performing one or more jobs within the procedure; and, (b) a priority for performing one or more jobs within the procedure.

The one or more jobs can include at least one of: (a) user interaction with a respective processing system; (b) installing one or more software applications on a processing system; (c) executing technical commands; and, (d) business procedures.

If a procedure includes installation of a respective application on a target processing system, the method typically includes, in the processing system: (a) determining the target processing system; (b) determining one or more specifications for the target processing system; (c) determining one or more predetermined rules; (d) comparing the specifications to the one or more predetermined rules; and, (e) cooperating with the processing system to install the respective application in response to a successful comparison.

The predetermined rules may include: (a) technical rules; (b) IT governance rules; and, (c) business rules.

The method can include, in the processing system, determining the specifications by collecting data from an agent installed on the target processing system.

The method typically includes, in the processing system: (a) determining if a licence is required to install the selected software applications; and, (b) at least one of: (i) obtaining authorisation for use of a licence; and, (ii) determining if sufficient licences are available for the selected software applications.

The method can include, in the processing system: (a) determining a proposed installation time; (b) transferring an indication of the proposed installation time to any users of the target processing system, the users being responsive to the proposed time to provide a response; (c) receive the response; (d) determine if the proposed installation time is acceptable in accordance with the response; and, (i) in response to a successful determination, define an installation job in accordance with the installation time; and, (ii) in response to an unsuccessful determination, determine an alternative installation time.

The method typically includes, in the processing system, update a calendar or diary on the target processing system to thereby indicate the determined installation time.

The procedure can include at least one of: (a) an installation script; (b) the one or more predetermined rules; and, (c) a validation script for determining if the respective software application has been successfully installed. i a second broad form the present invention provides a method of obtaining a service, wherein the method includes, in an end station: (a) selecting the service; (b) determining, using the selected service, a service request; (c) transferring the service request to a processing system, the processing system being responsive to the procedure request for: (i) selecting, using the service request, a procedure embodying the service; (ii) determining, using the procedure, one or more entities involved in the procedure; (iii) determining, using the procedure, one or more jobs to be performed by each entity; (iv) generating, using the determined one or more jobs, indicating data indicative of the one or more jobs to be performed; and, (v) , transferring the indicating data to the one or more entities, the entities being responsive to received indicating data to perform the one or more jobs.

The method can include, the end station, cooperating with the processing system to perform the one or more jobs.

Typically at least one entity includes at least one: (a) an agent installed on the end station; and, (b) a user of the end station.

The processing system is typically adapted to perform the method of the first broad form of the invention, in which case the end station may be an entity processing system. hi a third broad form the present invention provides a method of performing a job forming part of a service, wherein the method includes, in an entity processing system: (a) receiving indicating data from a processing system, the indicating data being indicative of a set of instructions at least partially indicative of the job, and being determined by the processing system from a defined procedure; (b) determining the job using the indicating data; and, (c) causing an entity to perform all or part of the job, the entity being at least one of: (i) a user of the entity processing system, the method including presenting the instructions to the user to thereby allow the user to perform the instructions; and, (ii) an agent installed on the entity processing system, the method including causing the agent to execute the instructions.

The processing system is typically adapted to perform the method of the first broad form of the invention.

In a fourth broad form the present invention provides apparatus for performing a service, the apparatus including a processing system for: (a) selecting a defined procedure embodying the required service; (b) determining, using the procedure, one or more entities involved in the procedure; (c) determining, using the procedure, one or more jobs to be performed by each entity; (d) generating, using the determined one or more jobs, indicating data indicative of the one or more jobs to be performed; and, (e) transferring the indicating data to the one or more entities, the entities being responsive to received indicating data to perform the one or more jobs.

In a fifth broad form the present invention provides apparatus for obtaining a service, the apparatus including an end station for: (a) selecting the service; (b) determining, using the selected service, a service request; (c) transferring the service request to a processing system, the processing system being responsive to the procedure request for: (i) selecting, using the service request, a procedure embodying the service; (ii) determining, using the procedure, one or more entities involved in the procedure; (iii) determining, using the procedure, one or more jobs to be performed by each entity; (iv) generating, using the determined one or more jobs, indicating data indicative of the one or more jobs to be performed; and, (v) transferring the indicating data to the one or more entities, the entities being responsive to received indicating data to perform the one or more jobs.

The processing system is typically adapted to perform the method of the second broad form of the invention.

In a sixth broad form the present invention provides apparatus for performing a job forming part of a service, the apparatus including an entity processing system for: (a) receiving indicating data from a processing system, the indicating data being indicative of a set of instructions at least partially indicative of the job, and being determined by the processing system from a defined procedure; (b) determining the job using the indicating data; and, (c) causing an entity to perform all or part of the job, the entity being at least one of: (i) a user of the entity processing system, the method including presenting the instructions to the user to thereby allow the user to perform the instructions; and, (ii) an agent installed on the entity processing system, the method including causing the agent to execute the instructions.

The processing system is typically adapted to perform the method of the third broad form of the invention.

In a seventh broad form the present invention provides a procedure defining a service, the procedure including: (a) an indication of one or more entities involved in the procedure; (b) an indication of one or more jobs to be performed by each entity; and, (c) a set of instructions for performing each job.

The procedure can be using in the method of the first broad form of the invention.

In an eighth broad form the present invention provides a method of defining a procedure for using in performing a service, wherein the method includes, in a processing system: (a) determining one or more jobs to be performed; (b) determining a mechanism for associating each job with a respective entity; and, (c) generating indicating data at least partially indicative of a set of instructions for performing each job.

The method can include using a model indicative of respective procedures, the model having a number of components including at least one of: (a) objects, the objects being at least partially indicative of jobs forming the procedure; (b) properties, the properties being at least partially indicative of jobs forming the procedure; and, (c) methods, the methods being at least partially indicating of specific instructions used in implementing the procedure.

The method typically uses a hierarchical model including at least: (a) a common level, components at the common level defining at least the jobs required to perform the procedure; (b) a provider level, components at the provider level defining at least some details of the manner of implementation of the jobs required to perform the procedure; and, (c) a site level, components at the site level defining instructions for implementing the jobs required to perform the procedure.

The method generally uses a hierarchical model including at least: (a) a common level, components at the common level being general to organisations; (b) a provider level, components at the provider level being specific to groups of organisations having related requirements; and, (c) a site level, components at the site level being specific to particular requirements of an organisation.

The method can include: (a) selecting a component within the hierarchical model; and, (b) further defining the component to thereby create a component at a lower level in the hierarchy by at least one of: (i) defining further objects; (ii) defining further properties; (iii) defining methods.

The method typically includes, in the processing system: (a) determining one or more entities required to perform the jobs; and, (b) determining one or more entity indications by at least one of: (i) determining the identity of the entities; (ii) determining data to be collected to determine the identity of the entities; (iii) determining rules for determining the entities; and, (c) defining the procedure using the determined entity indications.

The method may include, in the processing system: (a) determining a sequence for performing the jobs; and, (b) defining the procedure using the sequence.

The indicating data can include at least one of: (a) one or more job files; and, (b) one or more messages.

The indicating data is typically in the form of an XML file.

The method may include, defining at least one of: (a) a data collection stage, for collecting data from one or more respective entities; (b) an authorisation stage, for obtaining authorisation for the procedure from one or more entities; (c) a performance stage, for causing the entities to perform a respective job; and, (d) a completion stage, for determining completion of the procedure.

The one or more jobs can include at least one of: (a) user interaction with a respective processing system; (b) installing software application on a processing system; and, (c) business procedures.

If a procedure includes installation of a respective application on a target processing system, the method generally includes, in the processing system: (a) determining one or more specifications for which predetermined rules must be satisfied by the target processing system; and, (b) defining the procedure using the determined predetermined rules.

The method generally includes, in the processing system: (a) determining if a licence is required to install the selected software applications; and, (b) determining an approval mechanism; and, (c) defining the at least one of: (i) obtaining authorisation for use of a licence; and, (ii) determining if sufficient licences are available for the selected software applications.

The method typically includes determining at least one of: (a) an installation script; and, (b) a validation script for determining if the respective software application has been successfully installed.

The procedure is generally used in the first broad form of the invention. Brief Description of the Drawings

An example of the present invention will now be described with reference to the accompanying drawings, in which: -

Figure 1 is a schematic diagram of an example of a system for procedure implementation; Figure 2 is a flow chart showing an overview of the operation of the system of Figure 1;

Figure 3 is a schematic diagram of an example of a network based system for procedure implementation;

Figure 4 is a schematic diagram of an example of one of the end stations of Figure 1;

Figure 5 is a flow chart of an example of the process of procedure implementation;

Figure 6 is a schematic representation of the service centre; Figures 7A to 7D are diagrams of the data flow in a first specific example;

Figures 8A to 8C are a flow chart of the operation of the system of Figure 1 in a second specific example;

Figure 9 is a flow chart of the operation of the system of Figure 1 during software installation;

Figures 10A and 10B are a flow chart of the operation of the system of Figure 1 during packaging of software for installation;

Figure 11 is a schematic diagram of an example of a model; .

Figure 12 is a schematic diagram of an example of a model hierarchy;

Figure 13 is a schematic diagram of an example of a GUI for modifying a model;

Figure 14 is a schematic diagram of the configuration of a specific implementation of the base station; Figure 15 is a schematic diagram of the work flow in an audit process;

Figure 16 is a schematic diagram of the work flow in a client agent installation process; and,

Figure 17 is a schematic diagram of the flow of how a lists of available procedures is displayed to the user.

Detailed Description of the Preferred Embodiments An example of a methodology for automated procedure implementation will now be described with reference to Figures 1 and 2.

In particular, the methodology is generally performed utilising a processing system, such as the processing system 10, shown in Figure 1. In this example, the processing system includes a processor 20, a memory 21, an input output device 22, such as a keyboard and display, and external interface 23, coupled together via a bus 24 as shown. In use, the external interface may be used to couple the processing system 10 to a network, or to a database 11 as shown.

In use, the processing system is adapted to receive details of a procedure to be performed, and then cause the procedure to be implemented. Accordingly, it will be appreciated that the processing system may be any form of processing system suitably programmed to perform the procedure, as will be described in more detail below. The processing system may therefore be a suitably programmed computer, laptop, palm computer, PDA, mobile phone, specialised hardware or the like.

In any event, in use, the methodology for performing a procedure is outlined in Figure 2. In particular, the methodology involves having a user determine a procedure to be performed at step 100. The procedure is usually predefined as a set of instructions required to implement the procedure, and is stored within the database 11 in a form which can be interpreted by the processing system 10, such as an XML file. Accordingly, the selection may be achieved by having the user select a procedure from a predetermined procedure list presented by the processing system based on the defined procedures stored in the database 11.

At step 110 any data required to complete the procedure is collected. This may be performed using manual or automated processes as will be described in more detail below. At step 120 any authorisation for implementation of the procedure is optionally obtained. This may be required for example if the procedure involves the installation of applications software on the processing system 10, or on an end station, or other processing system, which requires licensing approval, or the like.

At step 130 the processing system 10 operates to perform the defined procedure, with the procedure being completed at step 140.

Whilst this technique may be implemented on a stand alone processing system as shown in Figure 1, it is typical for this to be implemented in a network environment, an example of which is shown in Figure 3.

In this example, the system includes a base station 1, formed from the processing system 10 coupled to a database 11. The base station 1 is coupled to a number of end stations 3 via respective communications networks 2, 4. In this example, the communications network 2 is a communications network such as the Internet, a WAN (Wide Area Network) or the like. Similarly the communications networks 4 may be smaller scale networks such as a LAN (Local Area Network) or the like.

It will therefore be appreciated from this that it is typical for this system to be implemented within organisations, with the communications network 4, corresponding to internal networks within the organisation, and the communications network 2 corresponding to an external network. However, this is not essential and any form of communications networks may be used to provide a distributed architecture.

In addition to this, it will also be appreciated by persons skilled in the art that the communications networks, and the connections to the base station 1 and/or the end stations 3 can be via wired or wireless connections. It is also feasible to provide a direct connection between the base stations 1 and the end stations 3, or to provide peer-2-peer functionality. An example of suitable end station 3 is shown in Figure 4. In this example, the end station 3 includes a processor 30, a memory 31, an input/output device (I/O) 32 and external interface 33, coupled together via a bus 34. Thus, it will be appreciated that the external interface 33 is utilised to allow the end station to be connected to the base station via one of the communications networks 2, 4.

In use, a user of one of the end stations 3 can request procedure implementation which is then controlled utilising the base station 1. Accordingly, it is necessary for the end station 3 to be able to communicate with the base station 1, and allow users to interact with services provided thereon. In one example, this is achieved using a web-style interface, with the end station 3 and base station 1 being adapted to communicate through the use of standard protocols such as IP protocols.

Accordingly, it will be appreciated that the end station 3 may be any form of processing system suitably programmed to communicate with the base station 1. The processing system may therefore be a suitably programmed computer, laptop, palm computer, PDA, mobile phone, or the like. Alternatively, specialised hardware or the like may be used.

The methodology will now be described in more detail with respect to Figure 5. In particular, at step 200, the user of one of the end stations 3 accesses a "service centre" provided by the base station 1. This is typically achieved by having the user of one of the end station 3 utilise a web browser to access a web page, shown for example in Figure 6.

This web page represents an interface which allows the user to request the services provided by the base station 1 and therefore typically displays a number of options corresponding to procedures that can be performed. This will be achieved, for example, by having the processing system 10 access the defined procedures in the database 11 and use this to generate a list of available procedures.

At step 210 the user selects a desired procedure from the list which in turn causes the processing system 10 to access the procedure from the database 11 at step 220. Whilst the procedure may be in any order of a number of forms, in a preferred example, the procedure is in the form of an XML file having a predetermined document type definition (DTD), and which therefore specifies each of the steps required in implementing the procedure. This will be described in more detail below.

In general, the implementation of a procedure requires four stages main stages, including: • data collection, • determining authorisation, • performing the procedure; and • completion. At step 230 the processing system 10 operates to use the procedure to determine any data required, and then obtain the data by generating data requests which are transferred to entities able to provide the required data.

In this regard, the entities may include users of any one of the end stations 3, with the processing system 10 asking the user to provide certain information, such as specific details of the required procedure. Thus if the procedure is installation of software, the user may be requested to provide information regarding the version of the software required, an indication of the computer on which the software should be installed, or the like. In this case, the data request may be in the form of an appropriate prompt presented via a service centre, or an e-mail, instant message or the like. This may be specified in the procedure definition.

Alternatively, the entities may include agents executed by respective ones of the end stations 3 or the processing system 10. The agents are software applications executed by respective end station 3 or processing system 10, which operate to collect data and transfer this back to the processing system 10. In this case, the data request is typically in the form of an XML file, which includes a set of instructions for obtaining the data required.

Thus, in the case of software installation this may therefore correspond to providing information regarding the existing applications installed on the respective end station 3, the operating system used or the like.

At step 240 the processing system 10 determines if authorisation is required. This will tend to be indicated in the procedure as will be appreciated by a persons skilled in the art. In the event that authorisation is required, the processing system 10 generates an authorisation request at step 250 and transfers this to a respective entity. This is, in one example, a manager within the organisation who is in charge of allocating software licenses or providing other forms of authorisation as will be appreciated by persons skilled in the art.

Thus the identity of the authoriser may be determined either from the procedure, where it is defined explicitly, or by invoking a rules engine, to determine the authoriser from the data collected during step 230. If authorisation is not provided at step 260 the process ends at step 270 with an indication of this being provided to the user.

Otherwise, or if authorisation is not required, the processing system 10 determines a next job to be performed from the procedure. The processing system 10 causes the next job to be performed at step 290 and determines if this has been performed successfully at step 300. Thus, the job will typically correspond to a certain step or action the processing system 10, an agent or a user is required to perform. If the job is performed by an agent, the processing system 10 will send an indication of the job to the agent causing the agent to perform the job as required. Similarly, if the job is performed by a user, an indication of the job will be transferred to the user, typically via a respective end station 3, allowing the user to interact with the end station 3 so as to perform the specified job. In either case, this will typically be achieved using an XML file as set out in more detail below.

If this process fails at any stage, the process will again end step 270 with an indication of this being transferred to the user.

Otherwise, the process moves on to step 310 to determine if the procedure has been completed. If not the processing system 10 determines the next job at step 280. Otherwise, the process is determined to be completed at step 320 at which point the process finishes. This will typically result in the processing system 10 providing confirmation to the user that the procedure has been performed, as well as finishing any agents or the like as required.

In general, any action that must be performed by an entity is referred to generally as a job. It will therefore be appreciated that the procedure generally includes a number of jobs, each to be performed by respective entities. However, this is not essential and a procedure may contain only one job. Furthermore, jobs may also be performed by a number of entities in conjunction.

In addition to this, it will be appreciated that the data collection stage are also representative of respective jobs. However, as these stages are not essential to the implementation of all procedures, these are generally separated out in the description above for clarity purposes.

In addition to the functionality outlined above, it is also possible for the procedures and jobs to be performed in accordance with a schedule.

In this instance, once authorisation for a procedure to be performed is received, the processing system 10 will transfer an indication to the user, typically in the form of an e-mail or calendar update proposal, requesting a scheduled time at which the procedure, or jobs defined therein, is to be performed. The user responds, with the processing system 10 operating to provide an indication of this time to a scheduling manager which updates a job schedule accordingly.

In use, the schedule manager will periodically examine the job schedule and the current time and determine the next job to be performed. At the allotted time, the schedule manager will alert the processing system 10 causing the processing system 10 to perform the job as required.

First Specific Example

A first specific example will now be described which relates to the procedure of a hiring manager initiating a request to establish a computing environment for a new starter at an organisation. Such a request would generally include creation of a logon account, a mailbox, home drive space on a network, and the configuration of new computer with all the software required by the new starter. This is a complex scenario that would require the use of multiple agents and users to complete.

Before describing the example in detail it is worth highlighting how this might be achieved without the above described system. In particular, the process would include the general steps as follows: 1. A hiring manager is required to fill out a form with details about the new starter. This includes information such as the new starters full name, personal details, cost centre, role description etc. 2. The form is routed (typically via internal mail processes) to an e-mail administrator who manually allocates the new starter's mailbox to one of the mailbox servers and records the server name on the form. 3. The form is routed to the cost-centre manager for approval on the purchase a new computer. 4. The form is routed to the licence compliance manager to confirm that sufficient software licences are available for the software to be installed. 5. The form is routed to a server administrator who uses it to create the username, mailbox and the home-drive. 6. The form is routed to the desktop administrator who waits until a new computer arrives and connects it to the network and initiates a download of the software for that user. 7. The request is marked as complete and the form is filed.

In contrast to this, the above described system allows a user to initiate a procedure request from the "service centre", which in one example can be accessed via an Internet browser. This allows the procedure to be initiated and at least partially performed by computers provided at locations remote to the implementing organisation. An example of this will now be described with respect to Figure 7 A.

In this example, the hiring manager is utilising an end station 3 in the form of a computer A, which is external to the organisation, such as a home computer or the like. The computer A is coupled to the base station 1 via communications networks 2, 4, such as the Internet or the like as shown. In this example, the base station 1, which is provided at the organisation, implements the functionality shown and in particular, implements web service applications 40, a job manager 41 as well as providing access to an authorisation database 42 and a procedures database 43.

In use, prior to requesting the implementation of a procedure, it is necessary for the user, which in this case is the hiring manager, to be authenticated using an authentication process shown generally at 44. The nature of the authentication process is not important for the purposes of the present invention and, it will be appreciated, that any suitable authentication process can be used. Thus, typically this will involve having the hiring manager submit a user name and password via the Internet 4, which is compared to a predetermined user name and password thereby allowing the hiring manager to be authenticated. The hiring manager will also be authorised during this process. Thus, having authenticated the identity of the hiring manager, the base station 1 will access data stored in the authorisation database 42 and determine from this what procedures the respective hiring manager is able to request. Thus, the base station 1 will determine if the hiring manager has authorisation to perform the procedure selected via the "service centre" GUI. It will be appreciated that this can be performed either by allowing a hiring manager to select a procedure and then determining if the hiring manager is authorised for the selected procedure, or by determining those procedures for which the hiring manager is authorised and then allowing the hiring manager to only select from those procedures.

In this case, assuming it is determined that the hiring manager is able to request the establishment of a computer environment for a new starter, this will be indicated by the authorisation data stored in the database 42 and determined by the base station 1. Accordingly, in this instance, the hiring manager is both authenticated and authorised.

Once this is completed successfully, the job manager 41 creates required jobs and allocates reference numbers which can be used to track the procedure throughout its lifecycle. In this example, a number of jobs are used for the entire procedure, although alternatively a single job may be defined, depending on the implementation.

To achieve this the job manager accesses the procedure in the procedures database 43, which is written in XML and represents the sequence of steps and hence the jobs required to perform the respective procedure. In particular, each stage of the procedure is encapsulated in a <workflow> node, as shown in the example XML file below. Thus as shown, the workflow defines the four basic stages for the process, namely data collection, approval, fulfilment and closure:

If the procedure requires one or more agents to gather information during the data collection stage an <agentinstruction> section is provided for each agent. In this example, an agent is provided on an end station 3 in the form of the computer C, as shown in Figure 7B, and this is required to run a visual basic script that automatically generates a username and an email address for the new starter. This is also shown in the second example sample below.

The <userinput userid="requestor"> node, nested within the <workflow id="data collection"> node defines the information that must be supplied by the hiring manager and the web page that will be used to collect that information. Each <textbox> node within the <userinput> node defines a text-box control to be displayed on the form to collect "string" data. It also gives the variable name that is used later to reference the information. Similarly the <combobox> defines a list of choices, displayed to the hiring manager as a drop-down list. <workflow id = "data collection"> Λ <userinput userid~'"> ] XML defining the data input required by a user </userinput> ' XML defining data r collection Workflow ogentinstructions, agentid-'"> XML defining the commands to be executed by an AOE Agent </agentinstructions> J </workflow> J <workflow ID = "Approval', Approval=""> </workflow> <workflow ID= "Fulfilment¹, Fulfilment- '"> </workflow> <workflow ID= "closure'^ <status id-'data collectiorf' value="aborted"> <userinput userid-'"> XML defining </userinput> > workflow that should be followed if data ogentinstructions, agentid-'"> collection is aborted </agentinstructions> </status> <status id="approval' value="denied'> </status> <status id="fulfilmenf value ="success"> </status> <status id="fulfilmenf value='Tailed"> </status> <status id-'fulfilmenf value='aborted"> </status> </workflow>

Thus, in this example, the XML file specifies that the hiring manager must supply personal and role details for the new starter, via the GUI, which in this case is presented as a web page. This is typically achieved using an appropriately configured XML file, defining the inputs required for this procedure.

There will be one <userinput> node within the data collection <workflow> node for each user that is required to supply information. In this example, the e-mail administrator is also required to allocate the new starters mailbox to one of the e-mail servers. Therefore the would be another <userinput> node as shown in the XML file portion below.

As described above, during data collection, the job manager 41 creates a job XML file from the procedure, and sends the job XML file (or the relevant section of it) to the computer A, causing the generation of an appropriate GUI, allowing the Hiring Manager, to fill in the required information and sub it it The job file is returned to the job manager 41 and the process is repeated, allowing data to be collected from the e-mail administrator and the agent on computers B and C, respectively as shown in Figure 7B.

If the request is cancelled at any stage during data collection the job will move to the closure stage and execute the instructions contained withm the <status ιd="data collection" value="aborted"> section. If data collection is completed the process will move to the approval stage, which is shown in Figure 7C. <workflow ιd="data collectiorf' status=""> <useπnputuseπd- requestor^ <textbox name-'FTitle" label="Job Title " value-'" mandatory="0" type=Strιng" description- "7> <combobo name-'Depart ent" label-'Department " value="" mandatory="0" decπption-"' > <ιtem value="Accountιng" /> <ιtem value="Admιnιstratιon" /> <ιtem value- 'Engineering" /> <ιtem value="Purchasιng" /> </combobox> </useπnput>

<useπnput useπd- email

«textbox name-'FTitle" label-'Mailbox Server " value-"' mandalry="0" type="stπng" descπptιon=""/> </userιnput> Ogentinstructions agentid-Computer C> <run cmd- UsemameGenerator vbs" /> </agentιnstructιons>

In the present example, two approvals are required, the cost centre manager, using an end station 3 in the form of the computer D, is required to approve the purchase of the new computer. Secondly it is necessary to check that sufficient licences are available for the software to be installed, this will be performed by an Agent on the computer C. If licences are available they will be assigned to the new starter.

The Job manager 41 sends the Job XML to the cost centre manager via computer D who views it as a web page, signifies approval (or denies it) and submits it. The job file is returned to the Job Manager and the process is repeated for the agent on computer C.

The procedure (and job file) will contain one <usermput> and one <agentmstructιon> section withm the <workflow ιd="approval"> section of the procedure. If the request is approved, the job will proceed to the fulfilment stage, if the request is denied the job will move to the closure stage and execute the instructions contained within the <status id="approval" value="denied">, as shown in Figure 7D.

The process flow is similar to previous stages, and the job manager 41 sends the job file to each user or agent in turn. The <workflow id="fulfilment"> section of the procedure contains one <userinput> sections for each user involved in fulfilment and one <agentinstruction> section for each agent.

Some actions that are performed by the agent might need to be scheduled to occur at a specific time, in this case the <agentinstruction> will have a <schedule=> attribute set.

In this example shown in Figure 7D, the process involves: • The agent on computer C executes a series of commands that will create a logon account and mailbox for the new starter. • An agent on a Server A creates home drive for the new starter • A new computer is provided at the premises (either by delivery or by retrieval from storage) arrives and is connected on the network. An operator "bootstraps" the process of loading an operating system onto the computer and once this is done an agent is automatically loaded on the computer. • The agent completes all of the software installation and configuration procedures for the new computer.

Closure is then performed, which, as for all other processes one or more users and one or more agents may be required during closure. The <workflow id="closure"> section of the procedure contains one <userinput> sections for each user involved in closure and one <agentinstruction> section for each agent. The closure stage is used to notify the requestor of the success or failure fulfilment of the request and to perform any clean-up processes as required, to release licences for example.

At any time after the request is initiated the hiring manager and users with relevant permissions can view the status of the procedure and any jobs via a web page. An audit is maintained of all stages of the request. This can be used for security purposes as well as a means of assessing if service levels are being met.

It is also possible to perform the above functionality as part of a subscription process as opposed to preforming the process on demand. In this case: • A user initiates a subscription request in a similar manner to the on-demand service request, via the service centre GUI, or via other applications that have been modified to make use of the Web Service. • The user is authenticated and rules in the database determine if the user is authorised to subscribe. • One or more jobs are created from a corresponding procedure which has fours stages as described in the on-demand process. • Data collection and approval proceed as described in the "on-demand" process. • The fulfilment stage occurs repeatedly according to a schedule. • Closure is executed if the user un-subscribes or if the subscription is terminated by the base station 1.

The on-demand and subscription processes described above are initiated by a user at the user's discretion. However, it is also possible to implement the functionality based on policies in which the user has no choice over the implementation of the job which is instead initiated from the base station 1. Thus, the use of policies represents a third manner in which job performance can be implemented so as to allow central control of jobs to be performed. This may be used for example, to implement required business policies, such as ensuring that all of the end stations 3 are upgraded to a new operating system.

Thus, the above described system allows for users and organisations to: • automate complex IT procedures as demonstrated in out scenario • automate simple procedures such as "password reset". • assist in diagnosis of computer problems.

This may be achieved by using predefined a procedures provided as respective XML document containing one or more <userinput> and/or <agentinstruction> nodes processed by the base station 1 according to rules defined in the XML document. Through the use of parameters and the ability to nest <agentinstruction> and <userinput> nodes have a high potential of being reusable. It will be appreciated by persons skilled in the art that whilst the use of XML files has been described, this is not essential to the implementation of the invention. In. addition to this, it is also possible for the procedure to be stored in a different format within the procedures database 42, and then converted into an XML as required.

Second Specific Example

A second specific example will now be described with reference to Figures 8A, 8B and 8C which show a flow chart for the situation in which the LAN 2 is an internal LAN within a corporation, with operators of the end stations 3 being employees, and the base station 1 being a server provided within an IT department.

In this example, each end station 3 may be associated with a number of different individuals, such as: • an owner - the person or department associated with the cost centre for that end station • one or more users - any employee(s) who uses that computer on a regular basis • one or more administrator(s) - any person authorised to manage the computer on behalf of the owner, (this may extend to the IT department)

It will be appreciated that in this example, the user, the owner and the administrator may all be the same person, although this is not required, depending on the circumstances in which the invention is used. Thus, for example, the administrator may be a member of the IT department, a secretary, or the like with the owner being the main user of the end station 3.

In this example the procedure is used to allow a user to request that software is installed on their own end station 3. Accordingly, in this example, the user's end station 3 is also the target end station 3 for the installation, however, it will be appreciated that a similar process may be used to allow software to be installed on a different end station 3.

In any event, at step 400 a user making a request (in this example referred to as a requestor) accesses the service centre services using the end station 3. As described above, in one example, the service centre is implemented as an interactive web-page generated by the processing system 10, and is therefore accessed via the LAN 2. However, the service centre may be implemented in the form of applications software installed on the end station 3 itself, or as add-ons or plug-ins to as existing applications. Thus, procedures may be assessed via respective macros or toolbars provided within an application, so that Microsoft Word™ might have a macro button which when selected initiates the process of downloading the latest update, so that the service centre functionality is integrated into existing applications.

Having selected that an installation procedure is to be performed at step 410, the base station 1 checks the software applications that can be installed on the target end station 3 at step 420, and this is usually determined based on the identity of the owner and/or the computer.

Thus, for example, employees may be employed within different departments within the company, with each department being assigned a different combination of software applications based on their use requirements. In order to achieve this, security groups are provided in the database 11, with each security group listing all the owners, or owner types, having permission to receive installations of one or more respective software applications. The groups can be allocated on any basis, such as roles (positions), business unit, enterprise wide, etc. It will be appreciated that this represents one example only and in practice how software will be assigned to users/computers might vary depending on the organisations requirements.

The processing system 10 must therefore be able to determine the identity of the owner of the target end station 3. This is achieved in accordance with user data stored in the database 11, which specifies the owner of each end station 3 based on a unique identifier associated with the end station 3, such as an IP or MAC address, a Global Unique Identifier (GLTD), or the like. Accordingly, the processing system 10 determines the end station identifier and then accesses the user data to determine the owner, or at least the owner type. The processing system 10 then uses this information to access rules in the database and determine the software that may be installed on the respective end station 3.

This step may be optional, as additional checking is subsequently performed, as will be described in more detail below. However it is typically performed to achieve an initial screening of software requests.

Additionally, the processing system 10 may be adapted to only accept installations requests from certain types of user. In particular, the user should be: • Authorised to use the system; and, • Authorised to make changes to the respective end station.

Accordingly, the processing system 10 may determine the identity of the requestor before proceeding further, for example, through the use of logon procedures, such as the provision of a user name and password, as will be appreciated by persons skilled in the art. In any event, this check will normally be performed when checking the software that can be installed on the respective end station 3, as part of the respective procedure, but may alternatively be performed at any time, such as before providing access to the service centre.

At step 430 the processing system 10 generates an indication of the software applications which can be installed, with an indication of this being shown to the requestor on the web page.

An example of this is shown in Figure 6, in which the web page includes a table 50 including the name version and description of a number of different software applications. A number of selection of boxes 51 are provided to allow the requestor to select software applications for installing.

The requestor selects the software applications for installation at step 440, and in this example the requestor has selected the Adobe Acrobat, HTML Kit McAfee Virusscan 4.5 and Winzip 8.0 software applications at step 460.

At step 450, the base station 1 determines one or more procedures associated with the installation of the requested software applications. Thus, a respective procedure may defined for the installation of each application, or a single procedure may be defined for a number of applications. It is also possible for procedures to be grouped in profiles, to allow a number of procedures to be implemented simultaneously. Thus, for example, procedures associated with common upgrades can be grouped together into a profile. In this case, when a requestor selects a single profile, this will cause each of the procedures associated with the profile to be implemented, thereby causing each of the associated upgrades to be provided. In any event, the base station 1 determines from the procedures if agents are required on any of the end stations 3 at step 460. This can be achieved in a number of ways, such as by accessing information stored in the database 11 to determine the required agents, or executing appropriate scripts, or the like.

The client agent is a software application hosted by a respective one of the end stations 3, which allows the end station 3 to cooperate with the base station 1 to perform steps required in the process. In this example, an agent is required on the target end station 3, and it may be that no agent is required on the requestor's end station 3 if this is not the target end station 3.

The agents may also perform additionally functionality, such as other communications that may be required with the base station 1, as described in more detail in the previous example.

If the base station 1 determines that the client agent is not installed on the target end station 3, then the base station 1 operates to transfer the agent to the target end station 3 at step 470, thereby causing the agent to be installed.

At step 480 the processing system utilises the procedure to determine if a license is required for the respective software application. Thus, in the case of the HTML Kit and the Adobe Acrobat reader, these are freeware and accordingly, no licence is required. However in contrast to this, the McAfee Virusscan 4.5 is proprietary software and user licences will typically be required. It will be appreciated that if multiple installations are requested, the following steps must be performed in parallel for each software application.

In any event, if it is determined that a license is required, the processing system 10 operates to determine if there are available licences, at step 490. Thus, for example, there may be a number of licences purchased for the software which have not yet been used. An indication that there are no licences available may be displayed to the requestor on the screen shown in Figure 6, allowing the requestor to assess the licence situation before making an installation request. This is not essential, and instead the number of available licences may be displayed, or the like. However, in general the requestor and other users do not need to be aware of this information and it is therefore preferable if they are only provided with an indication in the event that no licences are available, as this will impact on the installation procedure.

If it is determined that no licences are available at step 490, the processing system 10 proceeds to determine a licence approver, who is typically an individual in charge of authorising expenditure on the software applications, such as an IT manager, financial manager, or the like at step 500. In any event, the licence approver will be determined in accordance with predetermined rules stored in the database 11, and may depend on the nature of the software, the end station owner, or the like. In any event, at step 510, the processing system 10 generates a license request, and transfers this to the licence approver. Communication of this form is typically achieved by having the processing system generate an e-mail indicating the relevant software application and the number of licences required, and transferring the e-mail to the relevant individual. The licence approver responds by sending a response, typically in the form of an e-mail, including a "yes" or "no" indication, or something similar, to thereby indicate rejection or the approval of the licence request at step 520. At step 530 the processing system 10 determines if the licence has been approved and if not proceeds to step 540 to generate an installation failure notification, indicating that the requested software application will not be installed. The installation failure notification is typically achieved by causing the processing system 10 to generate an e-mail indicating the software application requested, and the reason for the installation failure, with a copy of this being transferred to at least the requestor and the owner.

If the license is approved, available, or not required, then the process proceeds to step 550, in which the processing system 10 operates to determine technical rules for the software installation. In particular, this may be achieved by having the processing system 10 access a list of technical rules stored in the database 11 , using a rules engine, as will be described below, or by using rules set out in the procedure.

The technical rules will define the specification requirements for the end station 3 in order for the installation to be successful. Thus, for example, the technical rules for a software upgrade would include the requirement that an upgradable version of the application software is installed on the end station. Requirements for processor speed, memory availability, hard drive space and the like may also be included as will be appreciated by a person skilled in the art.

Thus, in order for installation to occur a procedure must be written which sets out the rules defining how the software is to be installed onto the target end station 3. The process of creating the procedures and their operation will be described in more detail below.

In any event, at step 560 the processing system 10 will operate to determine specifications of the target end station 3, to allow these to be compared to the technical rules. In order to obtain the specifications of the end station 3, this will typically be achieved by having the processing system 10 send a job to the agent provided on the end station 3 describing what it needs to know about the end station 3. The agent will then interrogate the end station 3 and return the results to the base station 1.

At step 570 if it is determined that the end station does not satisfy the required technical rules then the processor proceeds to step 540 and a installation failure notification is generated as described above.

Otherwise, at step 580 the processing system 10 goes on to determine from the procedure if an installation approver is required, and if so, the approver identity. The installation approver, or approvers as there may be more than one, is an individual within the company who is authorised to approve the installation of the respective applications software for the respective owner, and will therefore typically be the owner's supervisor, or the like. Thus, it is the installation approver's job to assess whether the owner has a genuine requirement for the software.

Again, the installation approver may be determined in accordance with predetermined rules stored in the database 11 or maybe be determined from the data collected in the data collection phase. This may depend on a number of factors such as the nature of the software, the end station owner, or the like. Alternatively, the requestor may select the appropriate approver from a list of names provided by the processing system 10.

At step 590 the processing system generates an installation request and transfers this to the installation approver. Again, this is typically achieved by having the processing system 10 generate an e-mail including in the body of the e-mail an indication of the owner and an indication of the requested application software. It will be noted that there is significant similarity between the licence and installation approval procedures. Accordingly, in the event that the licence and installation approvers are the same individuals, it is possible to combine these processes into a single procedure, such that the approver is asked for approval for both the licence and installation simultaneously.

The installation approver responds by sending a response, again typically in the form of an e-mail, including a "yes" or "no" indication, or something similar, to thereby indicate rejection or the approval of the installation at step 600. At step 610 the processing system 10 determines if the installation is approved and if not proceeds to step 540 to generate an installation failure notification as described above.

Following successful approval, or if no approval is required, at step 620 the processing system 10 goes on to apply IT governance rules. The IT governance rules are intended to provide the IT department with the ability to override business rules. For example to prevent a user from installing software on a target end station which might impact on other user's of the target end station 3, on other software applications installed on the end station 3, or on other ones of the end stations 3. Thus it will be determined if the installation of the software will effect the implementation, data integrity, virus control etc of the end station, as well as other business units or indeed the whole enterprise.

Whilst it is possible that some IT governance rules have already been applied to this software application before it was made available for installation, additional IT governance may be applied at this point for example to ensure that the installation process does not overly load the available network bandwidth. In any event, the IT governance rules will typically provide an indication of software applications which may conflict with each other or which may compromise the security of the system.

In order to assess the IT governance rules, the processing system 10 maintains an understanding of the topology of the network in the database 11. IT governance rules are typically assigned to network segments to control when that link may be used for software installation and how many requests can be concurrently handled the respective segment, especially for applications that have a heavy footprint. It will be appreciated that this is just an example of IT Governance rules which relates to bandwidth control, but that other rules might include policies that the IT department is mandated to enforce, for example "no user shall have a computer that is more than one Service Pack out of date", or the like.

In any event, at step 630 the processor system determine if there are any restrictions on the installation based on the IT governance rules. If it is determined at step 640 that the software installation cannot proceed, then the process returns to step 540 to generate an installation failure notification. Otherwise, the process moves on to step 650, at which point the processing system 10 operates to schedule an installation time.

In particular, in order to do this the processing system 10 may generate an e-mail including a proposed installation time at step 650. The e-mail is transferred to the requestor and/or the owner. At step 660 the requestor and/or the owner of the target end station 3 responds to the selected time indicated in the e- mail to indicate whether the target end station 3 will be available at that time. If the proposed time is deemed not to be acceptable at step 670 the processing system 10 will operate to determine an alternative time at step 680. Alternatively, the user may be. asked to propose a time, with this being checked by the processing system 10 against an installation schedule stored in the database 11.

Prior to performing this, the processing system may, when proposing an initial time, access the requestor and/or the owner's calendar stored by the end station 3 and determine any time at which the target end station 3 is not in use. Again, this process will be controlled in accordance with instructions in the procedure definition.

In any event, once the time is deemed acceptable at step 670 the processing system operates to schedule an appointment at step 690. In general, this will be achieved by having the processing system 10 communicate with the end station and add an appointment into an appropriate calendar, such as in the Microsoft Outlook application. In addition to the processing system will update an installation schedule data stored in the database 11, which indicates for each installation, the time, the software to be installed, and the end station 3 on which the software is to be installed.

Subsequent installation of the software may then be performed as will be described in more detail below.

It will be appreciated that a number of variations on the above described process may be implemented. Thus, for example, it is possible to apply the technical and/or IT governance rules prior to obtaining licence or installation approval. This has the added benefit that there is no need to obtain approval if it is determined that the applications software cannot in any event be installed. It will be appreciated that the order selected will be determined in accordance with providing the optimum efficiency within the business, and may therefore depend on the existing business structure or policies. In any event, the process of installing software will now be described with reference to Figure 9.

In particular, once installation is approved using the process described above with respect to the flow chart in Figures 8A-8C, the processing system 10 determines the software that is to be installed at step 800, and operates to select a procedure from those stored in the database 11. In particular, his occurs as the user will have selected the software applications for installation by one or more software applications that will correspond to respective procedures or profiles, as will be appreciated by persons skilled in the art.

At step 810, the processing system 10 creates a job which defines the target end station 3 the software application is to be installed, and when this should occur, in accordance with the scheduled appointment. The job is determined from the procedure, which in turn may form part of a profile.

The job is provided to a job delivery manager at step 820. The job delivery manager is a module that will be implemented by the base station 1. It will be appreciated that the functionality provided by the base station 1, or the processing system 10 may be implemented as a distributed processing system, in which case, the job delivery manager may be implemented on a different processing system to other elements of the base station 1.

In any event, at step 830, the job delivery manager monitors the jobs currently queued, and determines when a job is to be performed. At step 840, when it is determined that a job is to be performed, then the job delivery manager transfers the job to the respective end station 3.

The agent installed on the end station 3 will receive the job at step 850, before unwrapping the job and installing the applications software in accordance with the installation script.

At step 860 the client agent will execute the validation script to determine if the applications software has been installed correctly. If the software has not installed correctly, an installation failure notification is generated and transferred to the base station 1 and optionally to the owner, and/or the requestor at step 870. Otherwise an installation complete indication is transferred to the base station 1, the owner and the requestor at step 880.

In any event, this example describes a technique for allowing users to request software installations and have these completed substantially automatically with little input required from operators or the like.

This has a number of benefits. Firstly, as the installation is automatic once the approval has been obtained, this allows the user to schedule the installation for when the end station 3 is otherwise not in use. This helps reduce times at which the end station 3 is out of effective action due to software installation processes being performed. Secondly, the installation is performed in accordance with pre-tested specifications, thereby increasing the likelihood of a successful, trouble free installation.

Thirdly, by using script based installation, this ensures standardisation in the way in which the software applications are installed, thereby helping to ensure consistency throughout the respective organisation, which in turn helps with maintenance, or the like, as will be appreciated by persons skilled in the art.

Fourthly, the scheduling process ensures that a record is maintained of which software applications have been installed on which machines. This helps with licence auditing procedures, and ensures that a complete record of each user's applications are available. This in turn allows a user's specific software configuration to be easily recreated should the end station 3 be updated due to hardware failure or the like.

Finally, the centralised automated deployment of the software vastly reduces the workload on operators in the IT department, in turn reducing resource requirements for companies implementing the process.

Procedure Development

An example of the procedure for creating a suitable procedure, will now be described with reference to Figures 10A to 10B. This example, will be described with respect to a procedure relating to the installation of applications software, but it will be appreciated that a similar process will be performed for defining other procedures.

In particular, at step 900 an operator of the system will determine new software for potential installation. This may be performed by a member of the IT department, although alternatively, requests may be submitted by owners or users of the end station 3. In any event, at step 910 the operator attempts to obtain authorisation to perform at least a trial installation to assess for example the impacts of the software application on the system. This authorisation may be obtained from superiors, or be in the form of instructions to test installation of new software, as will be appreciated by persons skilled in the art. In any event, if it is determined that authorisation is not provided at step 920 the process will end at step 930. Otherwise, at step 940 the operator will perform an initial impact assessment. This typically includes a review of the software applications specifications or the like to determine if it serves the desired purpose.

At step 950 an optional trial installation is performed on a suitable end station 3. At step 960 the operator determines if the software is suitable for installation on the system. The software application may not be suitable for installation for a number of reasons, such as if it causes conflicts with existing software applications, or it may be deemed to compromise the security. In this case, the process again ends at step 830. Otherwise, if it is deemed that the software is suitable, at step 970 the operator will use the processing system 10 to generate a procedure defining how to handle the installation of the software In particular, the procedure includes: • Scripts for installing/uninstalling the software application; • Rules controlling the software installation such as the technical, business, or IT governance rules; and, • A validate script which is used to determine if the installation is successful.

The procedure may be determined from first principles, by having the operator determine a sequence of steps which must be performed, or may be derived from existing procedures, as will be described in more detail below.

At step 980 the operator will perform a test of the installation. If it is determined that the test is unsuccessful at step 990 the procedure will be revised at step 1000. Otherwise, the process proceeds on to step 1010 at which point an authorised licence manager defines the licence requirements. This is typically achieved by recording the number of licences purchased for that application in the database.

Otherwise, the operator optionally creates one or more profiles that are used to control the implementation of a group of procedures, such as the installation of multiple software applications for respective types of users/owners, at step 1020. Thus, certain users may only require certain components of software applications, other users may require additional components, such as the installation of appropriate macros, or the specification of certain settings, or the like. In any event, the operator can create these profiles in accordance with different user and/or owner types, or roles, such that the procedure represents a default installation, with the profile defining any additional installation requirements over the default, as required by the respective owner type.

At step 1030, the procedure is optionally associated with one or more existing profiles, before being uploaded into the database 11 to allow the procedure to be used in installations. Corresponding updates may be made to the service centre options, as well as the installation data.

Procedure Models

The above described system enables new procedures to be developed rapidly and provides a framework to facilitate the reusability of the workflow defined by the procedures. This is achieved using an infrastructure object model (IOM), which includes objects, properties and methods. An example of the model is shown in Figure 11.

As shown the top level of the model consists of objects relating to any one of: • users - anything related to a user, such as account, mailbox, etc. • computers - anything related to a user's personal computer • servers - anything related to a network server.

An object such as the "Account" object shown in Figure 11, can contain other objects, such as the "Password" object and can have associated properties such as "full name" which is a property of the "Account" object. Objects and properties can also have associated methods, such as the "Archive" method associated with the "Account" object, defining the manner of their implementation.

Objects and properties are software vendor and version independent, whereas methods contain software and hardware vendor and version specific XML to be used in the procedure. Accordingly, each method has a data collection, approval, fulfilment and closure XML

In one example, this allows the system to support a three tiered Infrastructure Object Model, as shown in Figure 12.

7J^'er 1 - The Common Model • There is only one common model and this is typically owned and maintained by a single entity. • Procedure writers can submit new objects and properties and methods via a stringently controlled submission and release process. • The common model owner will typically update the model when new software or hardware is released

Tier 2 - Provider Models • There can be many provider models, and these will tend to be used for groups of entities, such as clients of a respective consultancy service, or the like. • Thus, any service provider who runs an IT base station 1 for multiple customers, can create their own central model from the common model. This allows common models to extend across all of their customer sites.

Tier 3 - Site Models • There can be many site models. Any organisation can create a site model from the common model, or a provider model. • The site models include methods and are therefore specific to the implementation within the organisation, based for example on the specific network architecture and operating systems used within the organisation.

The use of models in this manner allows users of the system to use a higher level model to form the basis of a lower level model, thereby providing a technique for knowledge re-use.

The model also helps force complex procedures to be broken down into small components, so that respective portions of procedures can be re-used, thereby further facilitating knowledge re-use Thus, when an organisation develops a component of model, such as a method, this can be submitted to the controlling entity, which following a review can add the new component to the model. The submitted component will therefore represent the knowledge captured by the organisation in developing a technique for implementing a respective process. From this, it will be appreciated that the transfer of knowledge between the models occurs at the level of individual methods, properties or objects, although other forms of knowledge re-use are not excluded.

In future, when another user wishes to perform the same procedure, they can access the stored model, and re-use the knowledge therein. In this case, the procedures performed may need to be implemented using different model methods, for example, due to the use of different network architectures within the respective organisations. However, the higher level steps will typically remain the same, and the user therefore re-uses the steps contained within the tier 1 or tier 2 levels of the model, providing their own implementation methods.

It will be appreciated that in this case, remuneration can be provided to users or organisations that submit components for storage in the central database, for example, based on the models use by third parties, to thereby encourage model submission and re-use.

In order to allow methods to be created from either the common, a provider or a site infrastructure object model, specific applications software can be provided. An example of the GUI interface for performing this is shown in Figure 13.

In this example, the GUI 70 includes a tree frame 71 containing a tree view of the infrastructure model, a workflow frame 72 containing a flow chart representation of the four main stages involved in the procedure, and a code frame 73, which shows the XML code for the procedure.

In use, the user can select respective stages in the model, by selecting respective ones of the four stages using the workflow frame. The objects, properties and methods associated with the respective workflow stage are displayed in the tree frame 71, allowing the user to select these, which in turn causes the applications software to present a corresponding portion of XML code in the code frame 73. This allows a user to modify the XML code, thereby allowing the method to be implemented as required.

In general, to further assist with this, predetermined methods can be dragged and dropped into the models, thereby guiding the author of the model through the stages of the procedure as required.

For example, Clicking on "data collection" displays a list of optional and mandatory parameters in the tree view. The model will contain the XML necessary to write the <userinput> node(s) for the procedure such that: 1. The author selects multiple parameters to be supplied by a user 2. the author specifies the value of the userid attribute, which may be: • an e-mail address, • a distribution list • a key phrase such as "requestor", "licence compliance manager", • generated at run time by the AOE Rules Engine. userid=Rules.GetUser(argl , arg2, ...). 3. The editor creates a <userinput> node and a suitable control node such as <textbox> for each parameter. The XML is displayed in the bottom RHS pane. 4. The process is repeated for any other user(s) required to supply parameters

The model may also contain software vendor and version specific command(s) that could be executed by an agent to get the value of a parameter. 1. The author selects multiple parameters to be supplied by an agent 2. The author specifies the value of the agentid attribute, this may be a. A unique agent id. b. a key phrase such as "requestors computer", "licence management server", c. generated at run time by the AOE Rules Engine. agentid=Rules.GetAgent(argl, arg2, ...). 3. The editor creates an <agentinstruction> node to be included in the procedure. These commands may be (although unlikely for data collection) grouped into assessment, procedure, and validation commands with a decision point after each. 4. The process is repeated for any other agent(s) required to supply parameters

It will be appreciated by persons skilled in the art, that commands associated with respective parameters will depend on the level at which the model is being modified. Thus, for example, the common model (tier 1 level of the hierarchy) will contain command parameters that are totally generic e.g., "available disk-space", "processor speed", whereas the lower levels in the hierarchy will contain additional commands for the respective parameters. Thus the tier 2 level will include commands that are common across all of a service provider's customer sites, whilst the tier 3 level of the hierarchy contain commands focussed on the specific site.

Once the data collection parameters are defined, the user will select "approval" model workflow causing one or more <userinput> and <agentinstruction> nodes to be presented in the tree frame 71.

The model may contain XML necessary to write the <userinput> node(s) for the approval stage of the procedure, depending on the model level. Thus, the common model is unlikely to have any <userinput> nodes, with the site model being most high likely to have <userinput> nodes.

The model may also contain the software & hardware vendor and version specific command(s) that could be executed by an agent participating in the approval process. It will be appreciated that this procedure can be performed for each stage in the workflow, allowing a procedure to be defined.

Rules Engine

An^' organisation may sometimes mandate specific users or agents to perform certain jobs associated with respective procedures. For example: • The manager of a user who is making a request to install software might be required to approve the consumption of a software licence, by that user. • The agent installed on a helpdesk computer might be the only agent allowed to reset passwords.

As these governance "rules" may vary from organisation to organisation, it is typical to utilise a rules engine, which codifies these rules and is custom to an organisation. This may be performed using, for example, a DLL file which is produced from a model driven, software development process. This allows rules to be automatically applied to a procedure at run-time, so that the base station 1, can obtain data/approval from the appropriate user or agent at runtime.

Further Additional Features

The system can be adapted to record transaction information at a number of occasions throughout the process, allowing these to be analysed so that the process can be adapted and personalised as required, thereby helping improve the effectiveness of the process.

For example, a respective software application may prove to be problematic when installed automatically. In this case, an indication of this is recorded and the IT department is automatically informed and so the process can be switched to a manual installation. The manual installation can then be used until the procedure can be repaired and further testing performed.

Alternatively, it may be that a particular user or end station 3 has problems installing software so when they make a request instead of an automated installation an IT department person carries out the installation. It may even be that a particular requestor sets a preference to have IT install the applications.

A particular requestor may seem to be an early adopter of new software, so when the IT department wishes to promote the availability of new software they target these users first to help perform an informal pilot.

A wide range of architectures can be employed. Thus, the functionality of the base station 1 above maybe divided between one or more processing system 10, or even be implemented in a distributed manner by thereby obviating the need for a single server type processing system, which is particularly advantageous for smaller organisations.

Furthermore, whilst this example has been described with respect to updating software via a LAN, it will be appreciated that equivalent functionality could be achieved using any form of connection between the end station 3 and a suitable base station 1. This allows the updates to be installed at remote locations, such as, for example, via a wide area network via the Internet, or the like.

In this instance, security would also generally be an issue. Accordingly, the job may be encoded in accordance with a predetermined encryption algorithm, the key to which is known only by the base station 1 and the client agent installed on the respective end station 3. As a result, if the job were intercepted by a third party, it would be unfeasibly difficult for them to extract and execute the procedure, thereby preventing them from fraudulently obtaining the software, as well as to prevent modification of the procedures to allow viruses, or other Trojan Horse programs to be infiltrated into the system.

Specific Implementation In a specific example, the base station 1 (hereinafter referred to generally as an AOE Server) will typically be based on a SQL 2000 engine which provides the database and workflow functions, and an example of this is shown in Figure 14. The database 11 is treated as the data layer in a three-tier application with business rules functions being split between the workflow engine and custom components. Microsoft's .Net Framework will be used for development and server components will be exposed as web services where applicable, however the primary use for .Net is the improved data interface layer to SQL.

The components installed on the end station 3 (hereinafter referred to as the "client PC") will typically be written in ASP .Net and pages will be served from the base station 1, however the design will cater for additional client servers. AOE Core and AOE Task are C++ executable programs

A number of features of this system will now be described.

Communication

Response information to base station requests and other communications is achieved using SMTP e- mail. The core service on the client sends any data found in an SMTP drop directory to the base station whose address is specified in the registry. No attachments are required and all data can be held in the body of the message. At the end of processing most jobs will be sent to the SMTP drop directory. The core service reads the job headers and format the subject line as: job mode:machine name:profile name:request id. The job mode is taken from the profile mode attribute of the job file and would generally be one of install, validate and audit although other options may be added. The profile name is the profile listed in the job header although several profiles may exist in the file, this is the first profile in a potential call chain. The machine name is also read from the job header and generally requires a fully qualified DNS name.

A simple example is: audit:fred.somewhere.com:full_software:1098

The base station receiving process is an SMTP event sink that listens on a particular mail address. Email routing outside the scope of AOE server is to be configured to allow mail to be sent to the server. A mail subdomain of the primary mail domain is most suitable. The SMTP filter does not process the incoming mail but simply deposits the message onto a message queue and transfers the mail subject to the message queue label and the mail body to the message queue message body.

The message queue is configured with one or more triggers based on parsing the message label. This would be the job mode tag, audit: etc, from the received message. The queue is set to peek at messages and not retrieval mode to maintain queue trigger compatibility between Windows 2000, XP and 2003. Each trigger talks to a COM+ component that is responsible for that message type. The "Design Components" section covers the implementation requirements of these components. Figure 15 shows an example audit job and the process path it would follow. A number of AOE Servers are shown to indicate that each process is not reliant on being on the same physical machine as the other services.

AOE Client Agent The client agent is responsible for handling local job schedules, transmitting data to the central server and running installation and audit programs. This can be implemented as an extension of PCBuild and PCVal and use a modified XML format. A core service is installed on each client end station that then invokes the procedures to be run. The service can operate under a local administration account to have sufficient privilege to install software.

AOECore invokes AOE Task, therefore procedure runs at the same permission level as Core. Procedure has code to run as different user accounts to enable different levels of installation including a standard user, domain user, local admin, domain admin or local system. The following table shows the accounts that can be impersonated within Procedure given an account level of Core.

An example of the process flow for installing the client agent on the end station 3 is shown in Figure 16.

The agent may run on some machines with higher permissions than others, so that privileged activities can be restricted to certain computers. For example on a workstation the agent should only be allowed to execute commands that effect that computer and not others... password may only be reset by an agent on a nominated computer. Agents are only installed on computers that are required to execute work instruction and can be deployed as needed. There is no need to keep an up to date database.

The Agent is "open" meaning that it can execute any command. Thus, for example the agent may initiate a Microsoft Systems Management Server Job.

The architecture is such that such that operating specific versions of the agent can be written. These agents communicate via an open standard (such as XML) to a AOE System running on Microsoft Windows.

Software Request

The software request handles the end-to-end delivery of new software installation job to target machines.

The request is initiated by a user who accesses the system through the client web front-end. They are presented a list of choices based on their security level and the levels of the software applications. That is, they only see applications that they are allowed to install. The available applications are also governed by the hardware level of the client PC which would be pre-determined before the applications list is displayed. An example of the work flow for a software request is shown in Figure 17.

Core Client

The core client component is an NT service (AOEcore.exe) that monitors the drop directory for file system changes. It uses NT event notifications and not polled IO to determine when new jobs are to be processed.

AOEcore.exe invokes a procedure handler, AOETask exe and pass it the job file to run. The job file contains two sections, a jobs and a profiles section. AOEcore.exe only parses the jobs section which contains the schedule information and which profile is to be run. The profile as well as the job file is passed to AOETask exe. Jobs are copied to the jobs\workmg directory before AOE Task is run. If it the last run of a job it will be deleted from the future directory after it is copied to the working directory. Failure to invoke AOE Task will mark the job result as failed and move the job to the failed directory.

Jobs to be run in the future will be moved into the jobs\future directory which can be checked every 30 minutes by AOEcore.exe.

A new copy of AOE Task. exe is typically invoked for each job file and a job file may contain more than one job.

Completed j obs are moved into the j obs\completed directory. If the job returns a failure code, it is moved into the jobsYfailed directory. If the job has an email attribute it can be placed in the SMTP drop directory regardless of final status (completed, failed, etc..)

One special job can be kept in the bin directory and that is a validation job that checks the directory and file structure of the core file set and registry keys. This is run whenever the service is started. The service can be upgradeable through a standard job which stops the service, update the AOECore and restart the service. An upgrade job also provides a new validation job file. Where this core validation routine fails the client re-installs from its original location that is specified by InstallSource in the registry.

To avoid name clashes, AOEcore renames files on each copy operation. That is, when a new job is received in the drop directory, it has a new and unique job file name assigned when copied to either the future or working directories. A job that recurs maintains its name in the future directory, but has a new name when copied to the working directory. These name control functions are performed by AOEcore. AOE Task does not perform any file name functions, but simply move completed jobs to either the completed or failed or SMTP directories.

Job Files

The job files are an XML formatted definition file that is an extension of PCBuild.

Job Delivery Manager

The delivery manager is similar in operation to AOECore in that it waits on file system events and processes files as they appear. The delivery header is removed from the work file before being handed on.

The delivery manager executable, JobMan.exe, runs as a service under a domain administrator equivalent privilege. This allows it to copy files to remote machines through file shares, C$ etc.

Catalogue

The catalogue is based on the status monitor collection program which is a WMI enabled tool. Two internal methods of auditing are enables, WMI and file scanning which are defined by wql and scan tags in an audit job. See AOE Procedure Definition for the full syntax.

The establishment of audit jobs is a three step process; • Create a query in the form of a select statement to access WMI information. The type of information can be tested using AOE Task from the command line with the -q -n and -s options (-s provides schema details including data types and key fields). Enter the query, namespace, table name, stored procedure name in the tblAuditSchema. • Create a database table to hold the final data. Two columns must always be defined, fldMachinelD (of type int) that is a reference to a PC in the Machines table and fldDateCreated (of type datetime) which is the data and time when the record was written. The other columns are dependant on the query type. At least one of the wmi keys should be coupled with the machine id field to form a composite primary key on the data table. The table name should be of the form tblA_xxxxxx indicating an Audit table. • Create the stored procedure which creates new records or updates records. The name should be of the form ap_auditXxxxxx.

Rules Engine The rules engine is used to control the IT governance, Business Unit and Technical rules, as described above. A combination of these defines whether an action is to be undertaken. Rules are applied to the workflow approval or transition paths, procedure availability, etc.

The rules engine will typically be a DLL that is custom developed for each installation of AOE server, the DLL will be produced from Bay's Model Driven Software Development process.

IT Governance

The top level of the tree is the IT governance or strategy rules which are like an on-off switch to control what is available and not how it is made available. Rules would be of the form: • Win2K to WinXP upgrade available for 500 users. • WinXP upgrade available between 1700 and 0630.

Business Unit

The AOE Server concept is based on the premise of self service and hence user initiated requests that require an approval before commencement. The business unit rules provide that authorisation and model the organisations management structure. Rules would be of the form; • Approver = user .manager (an approver is the person who has the manager role in AD of the requesting user.) • Win2K to WinXP upgrade available for 15 users.

Technical

The technical rule-set is derived from the hardware and software inventory of each PC and Server in the network. It comprises logical tests such as; • CPU > 733 & DiskFreePercent > 35 & Memlnstalled > 255 • OSVer = 'Wm2K' & SvcPack = 3 Accordingly, the above described system provides a technique for the development and implementation of automated workflow. This is achieved in a versatile manner which allows the techniques to be applied to a wide range of circumstances including but not limited to "IT" processes involving people and/or computers. This automation results in a large cost reduction in the implementation of such processes and makes it possible for an IT department to offer users a wider choice of software applications which cannot generally be easily achieved within the constraints of a traditional Standard Operating Environment (SOE).

Persons skilled in the art will appreciate that numerous variations and modifications will become apparent. All such variations and modifications which become apparent to persons skilled in the art, should be considered to fall within the spirit and scope that the invention broadly appearing before described.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS-

1) A method of performing a service, wherein the method includes, m a processing system. (a) selecting a defined procedure embodying the required service, (b) determining, using the procedure, one or more entities involved m the procedure, (c) determining, using the procedure, one or more jobs to be performed by each entity; (d) generating, using the determined one or more jobs, indicating data indicative of the one or more jobs to be performed; and, (e) transferring the indicating data to the one or more entities, the entities being responsive to received indicating data to perform the one or more jobs 2) A method according to claim 1, wherein the method includes, in the processing system: (a) determining an entity indication using a least one of: (l) the procedure; (n) collected data; and, (in) a rules engine, and, (b) transferring the indicating data to the entity processing systems using the determined entity indications.

3) A method according to claim 1, wherein the procedure is indicative of a sequence, and wherein the method includes transferring the indicating data to the entities in accordance with the sequence.

4) A method according to claim 1 , wherein if an entity is a user of an entity processing system, the method includes, in the processing system, generating indicating data indicative of instructions, the entity processing system being responsive to the indicating data to present the instructions to the user.

5) A method according to claim 1, wherein if an entity is an agent installed on an entity processing system, the method includes, in the processing system, generating indicating data indicative of a set of instructions, the agent being responsive to the indicating data to execute the instructions.

6) A method according to claim 5, wherein the method includes, in the processing system: (a) determining if an agent is installed on the entity processing system; and, (b) cooperating with the entity processing system to install an agent thereon in response to an unsuccessful comparison. 7) A method according to claim 1, wherein the indicating data includes at least one of: (a) one or more job files; and, (b) one or more messages.

8) A method according to claim 1 , wherein the indicating data is in the form of an XML file.

9) A method according to claim 1, wherein the method includes, in a data collection stage, and in the processing system: (a) determining using the procedure, data to be collected from one or more respective entities; (b) transferring indicating data to the respective entities, the entities being to the indicating data to determine the data to be collected, and provide an indication of the collected data to the processing system; (c) receiving the indication of the collected data; and, (d) causing the procedure to be performed using the collected data.

10) A method according to claim 1, wherein the method includes in an authorisation stage, and in the processing system: (a) determining one or more entities for providing authorisation, using at least one of: (i) collected data; (ii) the procedure; (iii) a rules engine; (b) transferring the indicating data to respective entities, the entities being responsive to determine an authorisation and provide an indication of the authorisation in the indicating data; (c) receiving the indicating data from the entities; and, (d) using the authorisation indication to determine if the procedure is to be performed.

11) A method according to claim 1, wherein the method includes in a performance stage, and in the processing system, transferring the indicating data to respective entities, the entities being responsive to the indicating data to perform a respective job defined therein.

12) A method according to claim 1, wherein the method includes in a completion stage, and in the processing system, transferring the indicating data to respective entities, the entities being responsive to the indicating data to perform a respective job defined therein. (a) transferring the indicating data to respective entities, the entities being responsive to the indicating data to provide an indication of the completion of a respective job in the indicating data; (b) receiving the indicating data from the entities; (c) using the completion indication to determine if the procedure is completed; and, (d) generating a notification of the completion in response to a successful detennination.

13) A method according to claim 1, wherein the method includes, in the processing system: (a) communicating with one or more entities to determine a scheduling indication; and, (b) performing the procedure using the scheduling indication.

14) A method according to claim 13, wherein the scheduling indication is indicative of at least one of: (a) a time for performing one or more jobs within the procedure; and, (b) a priority for performing one or more jobs within the procedure.

15) A method according to claim 1, wherein the one or more jobs include at least one of: (a) user interaction with a respective processing system; (b) installing one or more software applications on a processing system; (c) executing commands; and, (d) business procedures. 16) A method according to claim 1, wherein if a procedure includes installation of a respective application on a target processing system, the method includes, in the processing system: (a) determining the target processing system; (b) determining one or more specifications for the target processing system; (c) determining one or more predetermined rules; (d) comparing the specifications to the one or more predetennined rules; and, (e) cooperating with the processing system to install the respective application in response to a successful comparison.

17) A method according to claim 16, wherein the predetermined rules include: (a) technical rules; (b) IT governance rules; and, (c) business rules.

18) A method according to claim 16, wherein the method includes, in the processing system determining the specifications by collecting data from an agent installed on the target processing system. 19) A method according to claim 16, wherein the method includes, in the processing system: (a) determining if a licence is required to install the selected software applications; and, (b) at least one of: (i) obtaining authorisation for use of a licence; and, (ii) determining if sufficient licences are available for the selected software applications. 20) A method according to claim 16, wherein the method includes, in the processing system: (a) determining a proposed installation time; (b) transferring an indication of the proposed installation time to any users of the target processing system, the users being responsive to the proposed time to provide a response; (c) receive the response; (d) determine if the proposed installation time is acceptable in accordance with the response; and, (i) in response to a successful determination, define an installation job in accordance with the installation time; and, (ii) in response to an unsuccessful determination, determine an alternative installation time.

21) A method according to claim 20, wherein the method includes, in the processing system, update a calendar or diary on the target processing system to thereby indicate the determined installation time.

22) A method according to claim 16, wherein the procedure includes at least one of: (a) an installation script; (b) the one or more predetermined rules; and, (c) a validation script for determining if the respective software application has been successfully installed.

23) A method of obtaining a service, wherein the method includes, in an end station: (a) selecting the service; (b) determining, using the selected service, a service request; (c) transferring the service request to a processing system, the processing system being responsive to the procedure request for: (i) selecting, using the service request, a procedure embodying the service; (ii) determining, using the procedure, one or more entities involved in the procedure; (iii) determining, using the procedure, one or more jobs to be performed by each entity; (iv) generating, using the determined one or more jobs, indicating data indicative of the one or more jobs to be performed; and, (v) transferring the indicating data to the one or more entities, the entities being responsive to received indicating data to perform the one or more jobs.

24) A method according to claim 23, wherein the method includes, the end station, cooperating with the processing system to perform the one or more jobs.

25) A method according to claim 23, wherein at least one entity includes at least one: (a) an agent installed on the end station; and, (b) a user of the end station.

26) A method according to claim 23, wherein the processing system is adapted to perform the method of claim 1.

27) A method of performing a job forming part of a service, wherein the method includes, in an entity processing system: (a) receiving indicating data from a processing system, the indicating data being indicative of a set of instructions at least partially indicative of the job, and being determined by the processing system from a defined procedure; (b) determining the job using the indicating data; and, (c) causing an entity to perform all or part of the job, the entity being at least one of: (i) a user of the entity processing system, the method including presenting the instructions to the user to thereby allow the user to perform the instructions; and, (ii) an agent installed on the entity processing system, the method including causing the agent to execute the instructions.

28) A method according to claim 27, wherein the processing system is adapted to perform the method of claim 1.

29) Apparatus for performing a service, the apparatus including a processing system for: (a) selecting a defined procedure embodying the required service; (b) determining, using the procedure, one or more entities involved in the procedure; (c) determining, using the procedure, one or more jobs to be performed by each entity; (d) generating, using the determined one or more jobs, indicating data indicative of the one or more jobs to be performed; and, (e) transferring the indicating data to the one or more entities, the entities being responsive to received indicating data to perform the one or more jobs. 30) Apparatus according to claim 29, wherein the processing system is for performing the method of claim 1.

31) Apparatus for obtaining a service, the apparatus including an end station for: (a) selecting the service; (b) determining, using the selected service, a service request; (c) transferring the service request to a processing system, the processing system being responsive to the procedure request for: (i) selecting, using the service request, a procedure embodying the service; (ii) determining, using the procedure, one or more entities involved in the procedure; (iii) determining, using the procedure, one or more jobs to be performed by each entity; (iv) generating, using the determined one or more jobs, indicating data indicative of the one or more jobs to be performed; and, (v) transferring the indicating data to the one or more entities, the entities being responsive to received indicating data to perform the one or more jobs. 32) Apparatus according to claim 31, wherein the processing system is for performing the method of claim 22.

33) Apparatus for performing a job forming part of a service, the apparatus including an entity processing system for: (a) receiving indicating data from a processing system, the indicating data being indicative of a set of instructions at least partially indicative of the job, and being determined by the processing system from a defined procedure; (b) determining the job using the indicating data; and, (c) causing an entity to perform all or part of the job, the entity being at least one of: (i) a user of the entity processing system, the method including presenting the instructions to the user to thereby allow the user to perform the instructions; and, (ii) an agent installed on the entity processing system, the method including causing the agent to execute the instructions.

34) Apparatus according to claim 33, wherein the processing system is for performing the method of claim 27. 35) A procedure defining a service, the procedure including: (a) an indication of one or more entities involved in the procedure; (b) an indication of one or more jobs to be performed by each entity; and, (c) a set of instructions for performing each job.

36) A procedure according to claim 35, the procedure being using in the method of claim 1. 37) A method of defining a procedure for using in performing a service, wherein the method includes, in a processing system: (a) determining one or more jobs to be performed; (b) determining a mechanism for associating each job with a respective entity; and, (c) generating indicating data at least partially indicative of a set of instructions for performing each job.

38) A method according to claim 37, wherein the method includes using a model indicative of respective procedures, the model having a number of components including at least one of: (a) objects, the objects being at least partially indicative of jobs forming the procedure; (b) properties, the properties being at least partially indicative of jobs forming the procedure; and, (c) methods, the methods being at least partially indicating of specific instructions used in implementing the procedure.

39) A method according to claim 38, wherein the method uses a hierarchical model including at least: (a) a common level, components at the common level defining at least the jobs required to perform the procedure; (b) a provider level, components at the provider level defining at least some details of the manner of implementation of the jobs required to perform the procedure; and, (c) a site level, components at the site level defining instructions for implementing the jobs required to perform the procedure.

40) A method according to claim 38, wherein the method uses a hierarchical model including at least: (a) a common level, components at the common level being general to organisations; (b) a provider level, components at the provider level being specific to groups of organisations having related requirements; and, (c) a site level, components at the site level being specific to particular requirements of an organisation.

41) A method according to claim 39 or claim 40, wherein the method includes: (a) selecting a component within the hierarchical model; and, (b) further defining the component to thereby create a component at a lower level in the hierarchy by at least one of: (i) defining further objects; (ii) defining further properties; and, (iii) defining methods.

42) A method according to claim 38, wherein the method includes, in the processing system: (a) determining one or more entities required to perform the jobs; and, (b) determining one or more entity indications by at least one of: (i) determining the identity of the entities; (ii) determining data to be collected to determine the identity of the entities; (iii) determining rules for determining the entities; and, (c) defining the procedure using the determined entity indications.

43) A method according to claim 38, wherein the method includes, in the processing system: (a) determining a sequence for performing the jobs; and, (b) defining the procedure using the sequence. 44) A method according to claim 38, wherein the indicating data includes at least one of: (a) one or more job files; and, (b) one or more messages.

45) A method according to claim 38, wherein the indicating data is in the form of an XML file. 46) A method according to claim 1, wherein the method includes, defining at least one of: (a) a data collection stage, for collecting data from one or more respective entities; (b) an authorisation stage, for obtaining authorisation for the procedure from one or more entities; (c) a performance stage, for causing the entities to perform a respective job; and, (d) a completion stage, for determining completion of the procedure. 47) A method according to claim 38, wherein the one or more jobs include at least one of: (a) user interaction with a respective processing system; (b) installing one or more software applications on a processing system; (c) executing commands; and, (d) business procedures. 48) A method according to claim 38, wherein if a procedure includes installation of a respective application on a target processing system, the method includes, in the processing system: (a) determining one or more specifications for which predetermined rules must be satisfied by the target processing system; and, (b) defining the procedure using the determined predetermined rules. 49) A method according to claim 48, wherein the predetermined rules include: (a) technical rules; (b) IT governance rules; and, (c) business rules.

50) A method according to claim 48, wherein the method includes, in the processing system: (a) determining if a licence is required to install the selected software applications; and, (b) determining an approval mechanism; and, (c) defining the at least one of: (i) obtaining authorisation for use of a licence; and, (ii) determining if sufficient licences are available for the selected software applications. 51) A method according to claim 48, wherein the method includes determining at least one of: (a) an installation script; and, (b) a validation script for determining if the respective software application has been successfully installed. A method according to claim 38, wherein the procedure is used in the method of claim 1.