USING A WORKLOAD INFORMATION REPOSITORY

Mapping Businesses and Applications to Servers and Processes

Dr. Tim R. Norton

Inovant LLC, A Visa Solutions Company, PO Box 266001, Highlands Ranch, CO 80163, USA

Keywords: Workload characterization, modeling, application analysis, business metrics, business drivers.

Abstract: Workloads are often defined differently within an organization, depending on the purpose of the analysis,

making it difficult to compare analysis from different points-of-view. WIRAM (Workload Information Re-

pository for Analysis and Modeling) is a preliminary implementation of a database repository to collect ap-

plication and system information about workload groupings and their relationships. This information can

then be used as a component of the ITIL CDB to define consistent workloads from business products to

computer systems, regardless of the analysis or modeling tools used or the objectives of the analysis.

1 INTRODUCTION

The term “Workload Characterization” has been de-

fined, redefined, discussed, explored, categorized,

investigated and researched until it seems like there

would be little mystery left. Why then are there still

so many papers, articles and new techniques on the

subject? The initial reaction is to say that it’s be-

cause the “right” definition hasn’t been found. But

what if it has? What if ALL the definitions are

“right” definitions? Maybe the question shouldn’t be

“Which is the right definition?” but rather “When

should each definition be used?” Consider that each

of the proposed definitions is absolutely correct

given the perspective and point-of-view of its crea-

tor. Therefore, instead of addressing the term

“Workload Characterization” let’s look at the defini-

tion of the workload itself and the relationships be-

tween workloads.

To begin, we must ask what "workload" means?

It's a common term so everyone assumes they know

what it means, but are they using the same meaning?

The American Heritage Dictionary (1994) defines

“workload” as:

work·load (wûrk“l½d”) n. 1. The amount of

work assigned to or expected from a worker in

a specified time period. 2. The amount of work

that a machine produces or can produce in a

specified time period.

Modifying the above definition to fit the needs

of the computer systems capacity planner at the most

general level, the term "workload" means the work

(processor time, I/O’s, etc.) expected from a ‘com-

puter worker’ (a collection of processes, users, ap-

plications, etc.) that can be thought of as a single en-

tity. Using such a general definition means a number

of problem areas need to be considered. The first is

that different people have different objectives so

they tend to look at what things belong together dif-

ferently (Norton, 2002). Another is that the avail-

ability of measurements also influences what can or

should be grouped. The third is the meaningfulness

of any analysis to the business. The use of manage-

ment tools, such as Balanced Scorecard, that connect

all aspects of the business (company financial per-

formance, customer satisfaction, employee perform-

ance, Information Technology resources, etc.) (Leb-

sack, 2002) require a consistent set of definitions

across the entire company. One source of such defi-

nitions is the ITIL (Information Technology Infra-

structure Library) framework (OGC, 2003). The

ITIL Service Delivery book includes a section that

describes the general requirements of the CDB (Ca-

pacity Database) (OGC, 2003, Section 6.5 Planning

and Implementation). A detailed analysis of all

these areas is beyond the scope of this paper, but we

can touch on all of them by looking at a practical

approach to identifying and tracking workload in-

formation.

Permission is

ranted to

ublish this article in the 2005 International Conference on Enter

rise Information S

stems P

oceedin

403

R. Norton T. (2005).

USING A WORKLOAD INFORMATION REPOSITORY - Mapping Businesses and Applications to Servers and Processes.

In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 403-408

DOI: 10.5220/0002516304030408

 SciTePress

Given these constraints, what’s really needed is a

way to capture all the important information about

these entities and their relationships so that views of

what’s going on can be generated from different per-

spectives. Some initial work was done at MCI to de-

velop a system called AITS (Application Informa-

tion Tracking System) that would collect informa-

tion about applications into a single repository

(Boyd, 1996). AITS was intended to interconnect

existing information sources, such as the security

database, naming standards and the inventory con-

trol system, with system configurations and applica-

tion details. AITS was never completed due to or-

ganizational changes and the eventual outsourcing of

most of the IT staff.

2 WIRAM OVERVIEW

This paper presents a preliminary implementation of

WIRAM (Workload Information Repository for

Analysis and Modeling), a database repository of

definitions and relationships that provides workload

consistency from business products to computer sys-

tems. While inspired by AITS, WIRAM has a much

narrower scope with focus on just the information

necessary to understand the workload definitions

used in performance, capacity and modeling reports.

The high-level objectives of WIRAM are:

1. Define what is in workloads.

2. Define what drives workloads.

3. Define what measures workloads.

WIRAM provides consistency across a company

whenever computing resources are discussed. For

example, a business level report might show that an

application is extremely profitable because it uses so

few computer resources but managers may not agree

with the assessment of what resources are used. In

addition, if there is disagreement as to what consti-

tutes the application, or even worse, widespread con-

fusion because other presentations have used the

same application name but shown vastly different

resource usage values, then the focus shifts from

presenting a positive business situation to bickering

about the meaning of data points. By creating a

WIRAM, a company has a central repository of re-

cord that defines what resources each application

uses and how applications are combined into busi-

ness products.

The ITIL CDB requirements identify a number

of general areas for data collection that include

“business data from the business plans and strategy”

(OGC, 2003, Section 6.5), but do not address a

mechanism to connect the business information with

actual resource consumption data. The WIRAM

provides that connection.

3 WIRAM DESIGN

The design of a WIRAM is based on the concept

that everything should support the business.

That

means that all of the computing resources used in a

company should be accounted for as part of what is

required to implement the objectives of the business.

The purpose is simply to report on current usage and

predict future usage based on business forecasts in-

stead of system measurements. What’s the differ-

ence? Consider that the product line business man-

agers have a better view of growth projections based

on their sales objectives. After all, those are the

numbers the sales staff is trying to make happen be-

cause that’s what their commission (or whatever per-

formance review measurements the company use) is

based on. The problem is that product projections

cannot be directly correlated to resource usage. The

WIRAM defines what the business is called, what

drives the volume and what components that make it

work (applications, systems, computers, etc.) should

be included. The repository does not contain the ac-

tual business forecast or performance data but does

define the source of that data and the relationship to

the business. This allows everyone in the company

the opportunity to provide input into the definitions.

The end result is that everyone agrees about the

meaning of a business or product, how it’s projected

to grow and what gets rolled into it.

Of course the implementation of a WIRAM will

depend on the specifics of each individual company.

The author has chosen to use the Business Metric of

Interest (BMI) approach (Kaminski, 2003) but other

techniques for quantifying business activity could be

used. How to identify and measure appropriate busi-

ness metrics is beyond the scope of this paper.

Techniques for actually measuring resource usage

and reporting it are beyond the scope of this paper as

well, but there are many excellent papers that ad-

dress these areas (Domanski, 2002; Johnson, 2003;

Kaminski, 2003).

Throughout this paper the term “business” is used to

mean any structured organization with defined objectives.

While commonly used to mean a for-profit company, such

as Visa USA, it can also mean a non-profit company, a

military organization or a service club. Each of these has

“products” (goods, services, or bombs) that they deliver. If

computing resources are used in the creation and delivery

of the products then a WIRAM could be used.

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

404

4 WIRAM LAYERS

As stated above, the design of a WIRAM should be

tailored to the requirements of the company. How-

ever, there seems to be a general design that could

provide a starting point for customization and it may

work as is in many cases. This design is based on a

layered approach that puts a business product at the

top. The term ‘layer’ is used because each is built

on, or layered on top of, what’s below it. Figure 1

shows an entity relationship diagram with these lay-

ers, called Major Categories, down the center (the

other entities, called Modifier Categories, will be

discussed in the following subsection).

The Major Categories are:

1. Business

2. Product

3. Application

4. Application Component

5. Workload

4.1 Major Categories

Each business is composed of individual related

products. Products are implemented with applica-

tions, which are composed of application compo-

nents. Notice that the top three levers are totally

business focused. They describe things that everyone

in the company should be able to relate to because

they are what the company does. These levels allow

us to talk about resource usage and capacity re-

quirements in broad business terms but still have

enough granularity to address idiosyncrasies unique

to each application. The Application Component

layer is where we start mapping the business to the

computing infrastructure. Application Components

are associated with workloads in the more traditional

sense. It isn’t until this level that we start looking at

things we can measure with all of the wonderful per-

formance and modeling tools at our disposal.

4.1.1 Business Layer

A Business defines an overall, or strategic, objective

of the company. A Business is a set of one or more

related products that are available to customers and

address a common set of customer needs and re-

quirements. For example, a company may be con-

sidered in the automotive business because it sells

new cars, used cars and car parts. A company does

not have to include all of the possible or usual prod-

ucts in a Business (as the above example does not

include car repair or manufacture) and in fact may

have only a single product (a company only selling

new cars would still be in the automotive business).

The name used for a Business is unique throughout

the company and usually the industry.

4.1.2 Product Layer

A Product is a conceptual customer deliverable and

is associated with something a customer can buy or

subscribe to. A Product is generally what the mar-

keting or sales staff offers to customers (a car or a

part or a service contract). The name used for a

Product is unique throughout the company and pos-

sibly the industry. A Product name is often trade-

marked and identified with both the business and the

company.

4.1.3 Application Layer

An Application is the implementation of a Product

that provides a tangible customer deliverable. An

Application can be a product in itself (a used car

sold as is) or one of several different deliverables

that may be either required by the nature of the

Product (the new car) or provide optional “extras”

that enhance the Product (such as a specific trim

package). An Application name is unique throughout

the company because it identifies a unique imple-

mentation within the company. Even if a COTS

(Commercial Off-the-Shelf Software) product is

Zero to many

Zero or one

At least one

One and only one

Business

(Business

Segment)

Application

(Implementation of a

Product)

Product

(Implementation of a

Business)

Group

(Processing

Group)

Application

Component

Purpose

(How workload

is used)

Workload

Platform

(Hardware

and O/S

Implementation)

Name

(optional

description)

Name

(optional

description)

Legend

BMI

(Business Metric

of Interest)

Globally unique

name

Name can reoccur

Relationships

Entities

Modifer

Categories

Figure 1: WIRAM Entity Relationship Diagram.

USING A WORKLOAD INFORMATION REPOSITORY - Mapping Businesses and Applications to Servers and

Processes

405

used, the implementation name (which may or may

not be the same as the COTS product name) only

identifies something internal to the company. The

Application name is generally not unique in the in-

dustry, and may or may not be known to customers.

4.1.4 Application Component Layer

An Application Component is one of the parts of an

Application that has meaning only within the context

of a specific application. It is more about the imple-

mentation and working of the Application than about

the Product objectives. Even though an Application

Component is associated to only a single Applica-

tion, the name of the Application Component may be

used as the name of a Component of another Appli-

cation. Two Application Components having the

same name means that the two components perform

the same type of function for their respective Appli-

cations, not that they are the same component. Be-

cause one of the objectives of a WIRAM is to pro-

vide aggregation of low-level workloads into busi-

ness functions, an Application Component can be

part of only one Application. If it appears that an

Application Component needs to be associated with

two Applications then those Applications are proba-

bly defined too granular and should be merged into a

single Application. Following on the automotive

analogy, an Application Component could be a fi-

nancing package that would have the same name and

function for both new and used cars but the term de-

tails would be different (shorter for a used car be-

cause it isn’t expected to last as long). An Applica-

tion Component name may or may not be unique

throughout the company, is almost certainly not

unique in the industry, and is seldom known to cus-

tomers.

4.1.5 Workload Layer

A Workload identifies how resources are used, or

consumed, by an Application Component. The exact

meaning of a Workload is dependent on the associ-

ated Application Component but it can also be mean-

ingful to refer to the Workload as a general category.

Each of the required forms to buy a car can be con-

sidered a workload; each car needs the same forms

but how they are completed will differ with each

type of car (Application) and each specific car (Ap-

plication Component). We can note how long it

takes to fill out the form for a car in general, for a

sedan vs. an SUV, or for a specific car. We can also

note how much time is spent each month filling out

a specific form. All are valid views into how the re-

source (the salesman’s time) is used. A Workload

name may or may not be unique throughout the

company. While a Workload name is almost cer-

tainly not unique in the industry there are many

standard names that have generally the same mean-

ing throughout the industry, such as ‘database’ and

‘OLTP’ (on-line transaction processing) and may be

known to customers in that context. Care should be

taken when assigning these names so that they do

not conflict with the implicit meaning of the name or

that they are not so general that they are not useful.

A Workload name of “Database” would be so gen-

eral, and used by so many Application Components,

that it would loose its meaning. A Workload name of

“OE-DB” would be more meaningful, even if it was

used by several Application Components, because it

would be more specific to the processes, user-ids,

etc. associated with the O

NLINE-ORDER Application

Component. Because a Workload Name is not

unique, it requires the associated Application and

Application Component Names for identification.

Using “OE-DB” does not identify a specific Work-

load because that name can be used in several Appli-

cation Components. Examples of fully qualified

Workload Names could be names like O

RDER-

NTRY.ONLINE-ORDER.OE-DB or ORDER-

NTRY.INVENTORY.OE-DB, both of which are part

of the same Application (O

RDER-ENTRY) but in a

different Application Component (O

NLINE-ORDER

and

INVENTORY). They are different workloads be-

cause they contain different processes, or different

user-ids, or different terminals, or different some-

thing. If both Application Components actually use

the same workload, then there would have to be a

proration amount at the Application Component

level. While the WIRAM does not require or enforce

uniqueness of names, it is suggested that unique

names be used wherever possible. It is the responsi-

bility of the implementer to insure name uniqueness

and to derive proration rules.

A workload is defined by anything that can be

identified, such as process names, user-ids, terminal

addresses, accounting codes, system names, etc.

Therefore, the definition can become quite large and

hard to maintain if everything is explicitly identified.

Wildcards or patterns can be used but care must then

be taken to avoid double counting (i.e., if workload

X includes process=ABC and workload Y includes

process=*, then process=ABC is really included in

both workloads). There is deliberately a great deal of

flexibility in these workload definitions because real

applications are seldom very orderly. Shared data-

bases and reuse efforts can lead to a workload being

spread across many application components. The

proration field allows multiple Application Compo-

nents to reference the same workload definition (al-

though it would look like different definitions be-

cause the name in part of the key and therefore in

multiple records). However, there is nothing in the

design of the WIRAM to prevent the sum of these

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

406

proration from exceeding 100% and the implementer

should use this feature with care.

4.2 Modifier Categories

Modifier Categories apply an additional level of

constraint to one of the Major Categories so that it

can be viewed differently for a specific purpose.

The Modifier Categories are:

1. Group

2. Purpose

3. Platform

4. BMI

4.2.1 Group Modifier

The Group Modifier Category provides granularity

at the Application level that is independent of how

the application works. A Group Modifier could be

used for business reasons (car rental Premier clients

versus normal clients) or for load balancing (east

region versus west region) or anything else that

makes sense. An Application can be view as a whole

(all new cars) or as a modified group (all four-door

red sedans). It is generally more meaningful if the

groups are such that an Application belonging to one

Group cannot belong to another Group, but this is

not a requirement. It is also possible to have multiple

Group level modifiers, in which case each would

have a unique name instead of “Group” (such as the

Color Group and the Body Style Group).

4.2.2 Purpose Modifier

The Purpose Modifier Category provides granularity

at the Workload level that is independent of how the

workload is defined; instead, it addresses how a

workload is used (a four-door red sedan could be

used as personal car, a taxi or the fire chief’s official

car). When looking at computer systems, common

Purpose Modifiers might be production, test, devel-

opment, etc. The objective of the Purpose Modifier

is to allow an application to be viewed from differ-

ent business perspectives. For example, when look-

ing at the total cost of the O

RDER-ENTRY applica-

tion it doesn’t matter if it’s production or test, it all

goes into the cost. On the other hand, when looking

at the resource requirements for an increase in the

number of orders processed, we only want to look at

the part of the application (production) that applies.

The same can be said for adding new features (de-

velopment) or tracking down a major problem (test).

Each of these uses the same definition of the work-

load but distinguishes what should be included in the

study by how it is used. A BMI is associated with a

Purpose to provide the meaningful context for the

BMI. As in the above example, the number of orders

placed by customers would be a good indicator for

only the part of the application associated with the

Purpose P

RODUCTION. Workloads associated with

other Purposes would not be affected by changes in

the number of orders placed but might change with

some other BMI, such as the number of developers.

4.2.3 Platform Modifier

The Platform Modifier Category provides granular-

ity at the Workload level that is dependent on how

the workload is implemented at the hardware and

operating system level. For example, a component of

the OE-DB workload might be an entity called D

A-

TABASE

that is defined as service class DB01 on

MVS and process

DATAB-MAIN1 (with all child proc-

esses) on Unix. The Platform Modifier Category

fills two key requirements: first, it allows for plat-

form specific definitions of workload entities and,

second, it allows analysis to be done at the platform

level (“How much will the MVS part of O

RDER-

NTRY grow?”).

4.2.4 BMI Modifier

The BMI (Business Metrics of Interest) Modifier

Category connects the Application Component level

to the business by identifying what part of the busi-

ness affects the workloads that apply to the Applica-

tion. In the example of the O

RDER-ENTRY applica-

tion, by tracking the Business Metric of O

RDERS-

NTERED against the resources consumed for the

NLINE-ORDER workloads (the workloads defined

by the O

NLINE-ORDER Application Component) we

can see the resources required for each order. In ad-

dition, other organizations within the company can

often provide very accurate forecasts of these busi-

ness metrics because they are related to sales goals

and quotas. If we know what it takes to process an

order, and we know how many orders the sales staff

expects to enter, then it is a relatively easy calcula-

tion to determine the resources that will be needed

on each platform. (Kaminski, 2003)

The BMI Modifier Category is not a modifier in

the same way as the other modifier categories. No-

tice in Figure 1 that the BMI entity is connected to

both the Application Component entity and to the

Product entity. While the Application entity con-

nects the Product entity to the Application Compo-

nent entity (and through it to the Workload entity) in

a functional or procedural sense, the BMI Modifier

Category connects them in a behavioral sense. The

BMI modifier is a more formalized than the tradi-

tional workload driver because of this connection to

products.

USING A WORKLOAD INFORMATION REPOSITORY - Mapping Businesses and Applications to Servers and

Processes

407

5 WIRAM IMPLEMENTATION

WIRAM is currently implemented as a Microsoft

Access database because that was the tool the author

had. There is no requirement that Access be used but

it was an obvious choice because of the relatively

small size of the WIRAM database, the flexibility of

using Access with an IIS web server and the fact that

Access is standard in the company’s desktop soft-

ware installation.

6 CONCLUSION

This conceptual description of WIRAM (Workload

Information Repository for Analysis and Modeling)

shows the preliminary implementation of a database

repository of workload definitions and relationships.

The objective of WIRAM is to provide workload

consistency from business products to computer sys-

tems by defining each of the workloads, what about

the business changes resource usage and what met-

rics can be used to measures the workloads. The

WIRAM is designed in layers from Businesses at the

top to Workloads at the bottom. Modifiers Catego-

ries allow views of the relationships for specific

purposes. This database design provides a starting

point for customization specific to a company’s

needs and objectives. Once implemented, a WIRAM

will provide a consistent set of definitions for per-

formance and capacity planning studies. Presenta-

tions can simply refer to the WIRAM without hav-

ing to spend time on workload explanations and ar-

guments. Studies can be meaningfully compared.

Using WIRAM to map businesses and applications

to servers and processes improves the efficiency and

effectiveness of application analysis and system

modeling.

REFERENCES

American Heritage Dictionary, Third Edition, (Software)

Version 3.6p, 1994, SoftKey International Inc.

Boyd, Linda; Norton, Tim R., 1996. Application Informa-

tion Tracking System (AITS), 1996, MCI Resource

Modeling Group, Internal Presentation.

Baldwin, Ian C.E., 2002. UNIX Capacity Planning for

Mainframe Capacity Planners, A Rapid Development,

Low Cost, Case Study, Proceedings of the Computer

Measurement Group, CMG2002, Reno, NV, Decem-

ber 8-13, 2002.

Domanski, Bernard, 2002. System Performance Manage-

ment and Capacity Planning Tutorial, Proceedings of

the Computer Measurement Group, CMG2002, Reno,

NV, December 8-13, 2002.

Johnson, Adrian; Spellmann, Amy; Gimarc, Richard,

2002. How do you eat an elephant? or How to digest

application performance in bite-size chunks, Proceed-

ings of the Computer Measurement Group, CMG2002,

Reno, NV, December 8-13, 2002.

Kaminski, Ron; Ding, Yiping, 2003. Business Metrics and

Capacity Planning, Proceedings of the Computer

Measurement Group, CMG2003, Dallas, TX, Decem-

ber 7-12, 2003.

Lebsack, Rick, 2002. The Value Of It: A Strategic Per-

spective, Proceedings of the Computer Measurement

Group, CMG2002, Reno, NV, December 8-13, 2002.

Norton, Tim R., 2002. The Effect of Workload Groupings

on Distributed Transaction Capacity Models, Proceed-

ings of the Computer Measurement Group, CMG2002,

Reno, NV, December 8-13, 2002.

OGC, 2003. Proprietary commercial electronic re-

publication of the ITIL (Information Technology In-

frastructure Library) documentation (www.itil.co.uk)

by HMSO, St Clements House, 2-16 Colegate, Nor-

wich, United Kingdom, in consultation with the Office

of Government Commerce (OGC), Rosebery Court, St

Andrews Business Park, Norwich, United Kingdom

(www.ogc.gov.uk).

Smith, Connie; 2003. Best Practices for Software Per-

formance Engineering, Proceedings of the Computer

Measurement Group, CMG2003, Dallas, TX, Decem-

ber 7-12, 2003.

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

408