Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/30—Monitoring
  • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
  • G06F11/3447—Performance evaluation by modeling
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/30—Monitoring
  • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
  • G06F11/3442—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for planning or managing the needed capacity
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q30/00—Commerce
  • G06Q30/02—Marketing; Price estimation or determination; Fundraising
  • G06Q30/0283—Price estimation or determination
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
  • G06F2201/87—Monitoring of transactions

Definitions

• the present invention relates to the field of estimating the cost for a data processing system, and more particularly to sizing of a data processing system.
• Sizing encompasses the determination of the central processing unit (CPU) requirements, volatile memory requirements (e.g. cache memory or random access memory), and mass storage requirements (e.g. hard disk capability) of a data processing system that is capable of running a given software application at acceptable performance levels.
• CPU central processing unit
• volatile memory requirements e.g. cache memory or random access memory
• mass storage requirements e.g. hard disk capability
• US Patent No. 6,542,854 shows a method and mechanism for sizing a hardware system for a software workload.
• the workload is modelled into a set of generic system activities which are not directly tied to a specific hardware platform.
• Suitable hardware systems or components are selected by analysing the workload and hardware profiles in terms of the generic system activities.
• US Patent No. 6,542,893 shows a database sizer.
• the database sizer calculates the total mass storage requirements for a relational database table including database storage requirements, application and software requirements, system table requirements, scratch and sort requirements, log file requirements, and growth requirements.
• the database sizing is done by providing detailed inputs for tables in the database sufficient to calculate the required table size for each table; providing detailed inputs for each index for each table in the database sufficient to calculate the required index size for each table; providing input parameters for each database system including the page size, the fill factor, the log file space, the temporary space, as a percent of the formatted database size including indexes, the space required for operating system and application software, the space required for system databases, the percent growth required for the database, and the page file space; calculating a total storage requirement for the database using the inputs and input parameters; and calculating a storage requirement for the data base management system using the inputs and input parameters.
• the calculated storage requirements include separately output operating system and application software space requirements, system table space requirements, scratch and sort space requirements
• Quick Sizer is a SAP® program product which assists in selecting the hardware and system platform that meets specific business requirements.
• Quick Sizer provides online, up-to-date sizing based on business-oriented figures, such as the number of users or expected number of business processes and documents (cf. http://www.sap.com/andeancarib/soluations/technology/documentacion/Quick%20Sizer ,EdJ).
• the Optimizer Model for SAP is an option to the HyPerformix Integrated Performance SuiteTM (IPS).
• the Optimizer Model for SAP includes models for the major SAP R/3 software modules (e.g. Financials, Sales and Distribution) and combines them with the extensive hardware library found with the HyPerformix Infrastructure OptimizerTM (Optimizer) product. Optimizer enables its users to analyse and optimise end-to-end performance of their SAP application on various hardware configurations.
• the Optimizer Model for Sap takes workload and configuration parameter inputs.
• Workload parameters include the number of users of each SAP R/3 module.
• Configuration parameters include the number of servers at each tier (e.g. web, application) and the number of processes (e.g. Dialogue workers) on each server.
• the Optimizer Model for SAP provides a default set of resource usage metrics for each of the SAP modules. These metrics are similar to those used in SAP Quick Sizer and include both CPU and network usage metrics. Early in the design phase, architects can quickly build models using the default resource metrics to do first-cut sizing performance analysis. Later, models can be calibrated with actual measurements collected during functional testing. Scenarios can then be rerun to ensure the application is still on target to meet its performance goals.
• the present invention provides for a method of providing a cost estimate for a data processing system by determining the hardware requirements for each object of a selected application program and estimating of the corresponding cost.
• the object specific hardware requirements and cost are added up in order to provide the total hardware requirements and the total cost estimate.
• the total of the cost can be broken down into the cost contributions of individual objects.
• the present invention enables a user to make a plausibility test whether a projected data processing system makes sense from an information technology (IT) cost perspective. For example, if the estimated initial IT cost per transaction surpasses the economic value of a typical transaction to be processed by the data processing system, this indicates that the architecture of the data processing system requires an adaptation in order to reduce the data processing cost. This can be done by reducing the level of granularity by which transactions are to be processed in the data processing system. For example, instead of tracking each individual item of a bill of material it can be sufficient to keep track of lots of a class of the item which reduces the data processing and storage requirements. It is a particular advantage of the present invention that the cost contributions of the individual objects are provided which helps a user to identify more efficient and cost effective options for the configuration of the projected data processing system.
• IT information technology
• the user has to select an application program from a set of application programs which are supported by the computer system for making the cost estimate.
• Each one of the application programs has a predetermined number of objects, which are also referred to as 'business objects'.
• Business objects are the data processing entities which in combination constitute a transaction, like the processing of an order. For example the processing of an order includes the business objects 'acceptance of order', 'invoice', ...
• a user has to enter a load profile as a basis for the sizing.
• the load profile only includes the expected dynamic load profile of the data processing system rather than the static load profile. This is advantageous in order to limit the effort required for the sizing and to provide a lower limit of the cost estimate.
• a lower limit for the cost estimate in most cases is sufficient in order to perform a plausibility check whether a project data processing system is acceptable or requires modification from a cost perspective. For example, if the lower limit for a cost estimate per transaction surpasses the economic value of the transaction, such as the value of the ordered item, this means that the plausibility check has failed and that the projected data processing system requires modifications.
• the sizing of the data processing system is done step by step for the business objects of the selected application program.
• sizing coefficients for each business object are retrieved from a database table.
• the sizing coefficients are entered into a sizing model which provides the estimated hardware requirements for the implementation of that individual business object.
• business object specific hardware requirements are used for estimating the implementation cost for that individual business object. After this has been done for each one of the business objects of the selected application program the business object specific hardware requirements and the business object specific costs are added up, respectively. For example, this provides an estimate of a lower limit for the implementa- tion costs and/or the implementation costs per year and/or the implementation costs per transaction.
• the sizing model is a linear sizing model using a set of linear equations.
• the linear equations are parameter- ised by means of the sizing coefficients to provide the hardware requirements per business object.
• each load range is defined linearly. This can be done by assigning different sets of sizing coefficients to different load ranges.
• the cost estimation is done based on a linear cost model.
• the linear cost model includes a cost factor of cost per CPU requirement, cost per memory requirement and cost per mass storage requirement. These factors are multiplied by the projected hardware requirements of the data processing system to provide the cost estimates.
• KPI key performance indicator
• Figure 1 is a block diagram of the first embodiment of a computer system of the invention
• Figure 2 is illustrative of a flow chart for performing sizing and cost estimation
• Figure 3 is illustrative of an alternative embodiment of a computer system of the invention.
• Figure 1 shows computer system 100 having user interface 102 and coefficient database 104.
• Computer system 100 supports a number of application programs A1 , A2 Ai, ... Am.
• Each one of these application programs has a number of business objects.
• application program A1 has business objects BO11 , BO12, ...; likewise application program A2 has business objects BO21 , BO22,... and application programme Ai has business objects BOiI , BOi2,... BOij,... BOin.
• Coefficient database 104 stores the sizing coefficients for each one of these business objects.
• the business object BO11 of application program A1 has an assigned set of sizing coefficients C (BO11)
• business object BO12 has set C(BOI 2), ...
• Linear sizing model 106 provides an estimate for the hardware requirements to implement an arbitrary business object BOij.
• Linear sizing model 106 is parameterised by the set C(BOij) of business object BOij and evaluates a load profile which is entered via user interface 102 by means of a set of linear equations.
• Cost estimator 108 is coupled to linear sizing model 106. On the basis of the hardware requirements per business object delivered by linear sizing model 106 cost estimator 108 calculates a cost estimation for the implementation of that business object.
• the hardware requirements per business object and the cost estimation per business object are stored in result database 110.
• the result database 110 contains an entry for each one the business objects BOij of the application program and its related hardware requirements and cost estimates. On the basis the total of the hardware requirements and the total of the cost is calculated.
• results database 110 can be realised by means of a spreadsheet.
• the load profile data which a user has to enter via userinterface 102 includes the following data:
• CPU (BOij) is the central processing unit requirement for a business object BOij
• Memory (BOij) is the volatile memory requirement for business object BOij
• Disk space (BOij) is the mass storage requirement for business object BOij.
• the coefficients c1 , c2, c3 and c4 constitute the set of coefficients C(BOij).
• a user selects one of the application programs Ai and enters the projected load profile via user interface 102.
• the sizing coefficients for the business objects of the selected application program are retrieved from coefficient database 104 and entered into linear sizing model 106 as well as the load profile data.
• linear sizing model 106 calculates an estimate of the hardware requirements for each one of the business objects of the selected application program. For example linear sizing model 106 outputs a set of three hardware parameters for each business object in order to indicate the hardware requirements in terms of CPU, memory and disk space requirements. The estimation of the business object specific hardware requirements provided by linear sizing model 106 are stored in result database 110.
• Cost estimator 108 calculates the cost estimate for each one of the business objects on the basis of the set of hardware parameters delivered by linear sizing model 106 per business object. For example, this can be done by calculating
• Cost (BOij) CPU (BOij) * a + Memory (BOij) * b + Disk space (BOij) * c,
• SAP SAP Application Performance Standard
• SAPS Sap Application Performance Standard
• b a Euro amount per memory volume
• c a Euro amount per disk space volume.
• SAP Application Performance Standard is a hardware independent unit that describes the performance of a system configuration in the SAP environment. It is derived from the SD Standard Application benchmark, where 100 SAPS are defined as 2,000 fully business processed order line items per hour. In technical terms, this throughput is achieved by processing 6,000 dialog steps (screen changes), 2,000 postings per hour in the SD benchmark, or 2,400 SAP transactions. Fully business processed in the SD Standard Application Benchmark means the full business process
• the resulting estimated cost per business object Cost (BOij) is stored in database table 110.
• the business object specific hardware requirements and the business object specific cost estimates can be added up to provide the total hardware requirements and the total cost estimate.
• the sizing coefficients and the coefficients a, b, c of cost estimator 108 are selected such that the resulting cost estimations provide a lower limit for the actual cost in order to enable a plausibility check.
• Results database 110 can be visualised via user interface 102, e.g. in the form of a spreadsheet.
• FIG. 2 is illustrative of a corresponding flow chart.
• a user enters a selection of one of the application programs supported by the system.
• the user enters a dynamic load profile in order to describe the projected dynamic load of the selected application program running on the planned data processing system.
• the dynamic load profile can be entered in terms of the total number of transaction or the total number of transactions per time unit. In addition the average number of items can be entered to specify the dynamic load profile.
• step 204 the user enters a memory load profile. This can be done by entering an average retention time of business objects being related to a transaction before archiving.
• step 206 the user inputs data which are descriptive of the projected concurrency, i.e. the expected average number of concurrent users.
• step 208 the index j is initialised.
• step 210 the sizing coefficients of the business object BOi 1 of the selected application program Ai are retrieved from the coefficient database.
• step 212 the coefficient set retrieved in step 210 as well as the dynamic load profile, memory load profile and concurrency data are entered into the linear sizing model in order to estimate the business object specific hardware requirements. On this basis a cost estimation for the business object specific costs is performed in step 214.
• step 216 the index j is incremented and the control goes back to step 210 in order to perform the steps 210 to 214 for the next business object BOi2. Steps 210 to 216 are repeated until all business objects up to business object BOin of the selected application program Ai have been processed.
• step 218 the total hardware requirements are calculated in step 218 by adding up of the business object specific hardware requirements.
• the estimated cost total is calculated in step 220 by adding up of the business object specific cost estimates.
• the estimated cost total per transaction is provided in step 222 by dividing of the cost total by the expected total number of transaction per timed unit. This number can be used as a key performance indicator to evaluate the cost effectiveness of the projected data processing system.
• Figure 3 shows a block diagram of an alternative embodiment. Like elements of the embodiments of figures 1 and 3 are designated by like reference numerals having added 200 to designate elements of the embodiment in figure 3.
• computer system 300 has a coefficient database 304 which contains at least two sets of sizing coefficients for each business object BOij. Each one of the sets of sizing coefficients is assigned to a specific load range L1 or L2. This enables to split up the sizing task into linearised ranges rather than a single range for greater precision.
• the load profile entered via user interface 302 is used to select one of the sets of sizing coefficients which are assigned to each one of the business objects BOij. This is done by determining whether the load profile which has been entered via user interface 302 is within load range L1 or load range L2. If the load profile is within load range L2 this means that the set of sizing coefficients which is assigned to that load range L1 is selected. Otherwise the set of sizing coefficients assigned to the other load range is selected.
• linear sizing model 306 analogous to the embodiment of figure 1.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Business, Economics & Management (AREA)
• General Engineering & Computer Science (AREA)
• Physics & Mathematics (AREA)
• Development Economics (AREA)
• General Physics & Mathematics (AREA)
• Computer Hardware Design (AREA)
• Accounting & Taxation (AREA)
• Strategic Management (AREA)
• Finance (AREA)
• Quality & Reliability (AREA)
• Bioinformatics & Computational Biology (AREA)
• Bioinformatics & Cheminformatics (AREA)
• Entrepreneurship & Innovation (AREA)
• Evolutionary Biology (AREA)
• Game Theory and Decision Science (AREA)
• Life Sciences & Earth Sciences (AREA)
• Economics (AREA)
• Marketing (AREA)
• General Business, Economics & Management (AREA)
• Stored Programmes (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=33155181

Family Applications (1)

Country Status (3)

Families Citing this family (19)

Family Cites Families (20)

• 2003
  • 2003-06-06 EP EP03012947.2A patent/EP1484684B1/de not_active Expired - Lifetime
• 2004
  • 2004-06-01 WO PCT/EP2004/005892 patent/WO2004111850A2/en active Search and Examination
  • 2004-06-04 US US10/860,123 patent/US7747449B2/en active Active

Also Published As

Similar Documents

Legal Events