Improving Productivity in Design and Development of Information Technology (IT) Service Delivery Simulation Models

Service Delivery System Workflow

Having introduced the main components of the service system model, we can now describe a typical service delivery system workflow shown in Figure 1. For this example, we assume that there is only one instance of each service OS process. However, depending on a specific scenario, it is possible to have multiple instances of dispatchers, process managers, resource managers, and so on. Moreover, the number of instances can be dynamically adjusted according to the policy of the service OS management system. All the service OS components are connected through queues that can be priority-based or can enforce any other policy. Another purpose of the queues is to distribute SRs among multiple instances of service OS processes.

OPEN IN VIEWER

Figure 1.

The service delivery system workflow.

Service delivery starts when a client submits an SR to the service delivery system. Once submitted to the system, the SR gets into the dispatcher’s queue. The dispatcher processes SRs sequentially fetching them one by one from the queue. It analyzes the SR’s characteristics and selects the appropriate process type to serve the request. The dispatcher forwards the SR along with the selected process type to the process manager’s queue.

The purpose of the process manager is to manage the process life cycle: (1) instantiation of the process; (2) scheduling of the process tasks; (3) management of the process preemption; and (4) destruction of the process on completion. Once the SR is received by the process manager, it creates a new instance of the process according to the process type assigned to the SR by the dispatcher. The process manager schedules the process tasks by organizing the control flow around them. The resource allocation is done on a per task basis. Thus, prior to the actual execution of a task, the process manager submits a request for resource allocation for this task to the resource manager. During the resource allocation phase, the process is suspended.

When the request for resource allocation is received, the resource manager fetches the resource availability (RA) data from the RA database to determine the set of resources that are currently available. The RA data reflect the state of resources and can represent the information about busy resources, shifts of the workers, weekends, resource downtimes, and so on. Once a set of available resources is determined, the resource manager applies a resource allocation algorithm to find a subset of resources that correspond to the SR characteristics and the resource capabilities required by the process task.

As an example, sophisticated resource allocation algorithms may also initiate preemption of processes with a lower priority, or apply statistical analysis of the request arrival distribution, and possibly keep resources in reserve to manage the overall performance of the system over time. If some of the resource requirements cannot be satisfied, the request is queued until the resources are available. According to its resource allocation policy, the resource manager selects the actual resources to be allocated to the process task out of the set of suitable and available resources. Then, the resource manager updates the availability data of the allocated resources by setting their state to “busy.” It is also possible that the resource manager for various reasons allocates multiple independent tasks at the same time to a single resource. In that case, the resource multitasks by either switching between the tasks in a time-shared manner, such as round-robin, or processing the tasks sequentially in the order of their priorities, while the inactive tasks become suspended.

Once the resources are allocated, the process manager resumes the suspended process task and initiates its actual execution. Upon the completion of the task execution, the resources are released, and the control flow is passed to the next process task if it is required. The results of the process execution and the statistical data are passed to the system monitor, which stores the data and, if necessary, checks whether the performance requirements have been satisfied. The service execution result and statistical data are then sent back to the client as a result of the service invocation.

The contract negotiator handles the process of negotiating the service contract terms with the client and altering them when needed. If the contract terms have been violated during or as a result of the service delivery, the client may lodge a complaint, which is then processed by the complaint resolver. The role of the failure manager is to monitor and handle any failures that occur in the system. If a failure occurs, the failure manager requests suspension of the involved processes and release of the resources, and marks the resources experiencing the problem as “unavailable.” Once the problem is eliminated, it sets the state of the resources to “available” and sends a request for resumption of the suspended processes.

Dispatching SRs

Clients submit SRs to a service delivery system from a set of SRs R = { r i i = 1 , 2 , . . . , R } . Each SR is described by a set of characteristics and contains data that can later be passed to a process task. The characteristics are used by the dispatcher and resource manager to select the appropriate process type and allocate the required resources. A service system contains a set of n SR characteristics, with each of them containing a set of possible values. In other words, there are n sets C_j of SR characteristic values, where j = 1, 2,…, n. An SR is assigned a value for each characteristic. That is, each SR r_i is described by an n-tuple of the values of n SR characteristics (c ₁, c ₂,…,c_n ), where c 1 ∈ C 1 , c 2 ∈ C 2 , . . . , c n ∈ C n . The set C of all possible n-tuples of n SR characteristic values is defined in (1).

C = { ( c 1 , c 2 , . . . , c n ) | c 1 ∈ C 1 , c 2 ∈ C 2 , . . . , c n ∈ C n }

1

The relation between the set of SRs and the set of all possible n-tuples of SR characteristic values is defined as a function f : R → C .

SRs are assigned the appropriate process types by a dispatcher. The dispatcher analyzes the characteristics of an SR and according to its dispatching algorithm assigns the corresponding process type. A service delivery system contains a set of process types P = { p k | k = 1 , 2 , . . . , P } . The relation between the set of all possible n-tuples of SR characteristic values and the set of process types is defined as a function g : C → P . Therefore, we can define a dispatching algorithm d as a composite of the functions f and g, d = g°f. The domain of d is R; the range of d is P.

Example

Let SRs of a service delivery system focused on IT infrastructure support be described by three characteristics: SR type C ₁ = {hardwareProblem, softwareProblem}, SR priority C ₂ = {lowPriority, highPriority}, and SR complexity C ₃ = {simple, moderate, complex}. In this case, an SR reporting a low-priority complex software problem is described by a triple (softwareProblem, lowPriority, complex). For this example, the set X of all possible triples of SR characteristic values in the system is defined as shown in equation (2).

X = { ( c 1 , c 2 , c 3 ) | c 1 ∈ C 1 , c 2 ∈ C 2 , c 3 ∈ C 3 } .

2

Resource Allocation

The purpose of a resource is to provide one or more capabilities that can be employed during a service process execution in order to deliver the service. A capability is defined by a totally ordered or unordered set of its levels. An example of a capability can be the level of Java development skills X = { x l | l = 1 , 2 , . . . , X } , which is totally ordered under the ≤ relation. Another example of a totally ordered set of capability levels is the central processing unit (CPU) speed of a server Y = { y p | p = 1 , 2 , . . . , Y } . An example of a capability with an unordered set of its levels is the tools that a person can work with Z = { z q | q = 1 , 2 , . . . , Z } . A resource can have multiple capabilities, which are defined by the maximum level of each capability provided by the resource if the capability levels are ordered, or by an enumeration of the capability levels if they are unordered. It is assumed that a resource can provide a capability at all levels lower than its maximum if the capability levels are ordered.

Let A_i be one of the m available resource capabilities described by a set of its levels. Then, the resources of a service delivery system are described by m sets of capability levels for each capability A_i , where I = 1,2,…, m. The set A of all possible m-tuples of resource capabilities is defined in (3).

A = { ( B 1 , B 2 , . . . , B μ ) | B 1 ⊂ A 1 , B 2 ⊂ A 2 , . . . , B μ ⊂ A μ }

3

The capabilities of each resource are described by an m-tuple from A. There can be several resources with the same capabilities. Let the system contain a set of resources E = { e i | i = 1 , 2 , . . . , E } . Then, there is a relation between the resources and their capabilities q : E → A . At any point in time t, a resource e_i is characterized by its state s t ( e i ) ∈ S , which shows, for example, whether the resource is occupied or can accept further SRs. Since several resources can have the same capabilities and taking into account the time-dependent states of resources, the inverse relation of q is defined as q^–1 : A,S → ℘ (E), where ℘(E) is the power set of E.

Each process type contains a set of tasks T = { t u | u = 1 , 2 , . . . , T } . Resources are allocated on a per task basis. The relation between process tasks and their minimum required resource capabilities is defined by a function h : T → A l , where l is the number of resources required by the process task.

Based on the given definitions, a set of l sets of resources satisfying the capability requirements of a task t u ∈ T  can be determined as follows: (1) applying h to the task t_u to obtain a set of required capabilities and (2) applying q ⁻¹ to each of the l required capabilities and a state from S to obtain a set of suitable resources for each capability. Once a task is mapped on a set of suitable resources, the selection of a particular resource or subset of the suitable resources is done by a resource allocation algorithm of the resource manager. The resource mapping function and resource allocation algorithm can be arbitrarily complex and can accept extra parameters as required by the modeler.

According to the defined resource allocation algorithm, the resource manager evaluates the SR characteristics, required and available resources, required performance characteristics, and possibly other factors, and then allocates the appropriate resources to the process task. For example, for a particular process task, the resource manager is able to map the specified priority and complexity of an SR to the Java development skills and CPU performance of a server required to meet the priority and complexity requirements.

There are multiple possible scenarios of resource allocation, which depend on the system requirements. Some examples of resource allocation scenarios are listed subsequently:

If there is one or more available resources for each required set of capabilities, the resource allocation algorithm selects one resource out of the available set of resources for each required set of capabilities.

In addition, a process task may contain information on its performance characteristics depending on the number of allocated resources (if multiple resources with the same capability are supported by the process task) and different levels of the resource capabilities.

Use Case Modeling

The first phase of the Product Line UML-based Software Engineering (PLUS) approach proposed by Gomaa (2004) is use case modeling. During this phase, functional requirements for the product line are specified and modeled as UML use case diagrams. During the use case modeling, functional requirements are defined as sequences of interactions between actors (users of the system) and the system, which is considered to be a black box. In other words, use cases define the external functional requirements of the system. Functional requirements and the associated use case diagrams are divided into three categories: kernel, optional, and alternative. Kernel use cases capture functional requirements that must be met by all members of the product line. Optional use cases are needed only by some members of the product line. Alternative use cases describe functional requirements that are different for different members of the product line. Apart from the categorization of use cases, there are other mechanisms of incorporating variability into a use case model. Small variations can be expressed as conditional alternative branches in a use case. Use cases can extend each other through extension points using the “extends” relationship and conditions. The “includes” relationship can be used to include an abstract use case into several independent use cases.

The main use case of an IT service delivery system is when a client requests service from the system by submitting an SR. Therefore, we define the “Request Service” use case as a kernel use case (Figure 2). During use case modeling, the system is considered to be a black box; therefore, the “Request Service” use case contains two basic actions: A client submits an SR and the system returns the SR processing results. To provide flexibility in the design of future systems, the use case definition includes four extension points: <before request>, <after request>, <before results>, and <after results>. These extension points can be used by other use cases to extend the basic functionality of the system.

OPEN IN VIEWER

Figure 2.

The use case diagram.

Another kernel use case is “Sign Service Contract,” which represents the necessity to establish a service contract agreement between a client and the provider prior to the actual service delivery. Often, service providers offer default service contract terms that are implicitly accepted by clients by submitting SRs. However, this is not always the case; therefore, the use case includes two extension points: <before signing> and <after signing> the contract. An example of a use case extension is an optional use case “Negotiate Contract Terms” that extends “Sign Service Contract” at the <before signing> extension point. This use case is enabled if the “Contract Negotiation” feature is supported by the system. This use case represents the ability of a client to negotiate and adjust the service contract terms before requesting the service from the service provider.

“Lodge a Complaint” is a kernel use case that extends the “Request Service” use case at the “after results” extension point. This use case is invoked when a client disputes the results of the service delivery due to, for example, a violation of the SLAs. The “Return Process Metadata” use case is an optional extension of the kernel “Request Service” use case at the <after results> extension point. This use case is enabled if the system supports the “Process Metadata” feature. If it is enabled, the data describing the process of the service execution, such as performance characteristics or any required intermediate results, are collected and returned to the client along with the service process execution results.

Feature Modeling

Once the functional requirements of a system are captured in a use case model, the next step is to derive features from the use cases. A feature is a requirement or characteristic that is provisioned by one or more members of the product line. Features are used to differentiate members of the product line and determine common and optional functionality. Features can be kernel, optional, alternative, or parameterized. Features may depend on each other using the “requires” or “mutually includes” relationships.

According to the PLUS approach, all features are derived from the use case model. However, based on the idea of internal variability proposed by Pohl, Böckle, and Linden (2005), we extend this by dividing features into external and internal. External features capture the external functional requirements of the system and are derived from the use cases. On the other hand, internal features are invisible to the users of the system and are determined by its internal architecture. Internal features are architectural features in the sense that they define variations of the internal system architecture without affecting the external functional requirements. Therefore, internal features usually define lower level variability and depend on a subset of the external features. A combination of the external and internal feature models provides a single view of the product line’s variability, as all variations are defined using feature conditions.

Since external features are derived from use cases, we define three kernel features: “SR Processing,” “Contract Signing,” and “Complaint Resolution.” We also define two optional features: “Process Metadata” and “Contract Negotiation.” The relationships between these features are depicted in Figure 3. According to the use case model, the “Process Metadata” feature depends on the kernel “SR Processing” feature, whereas the “Contract Negotiation” feature depends on the “Contract Signing” feature. Therefore, in the feature model, we define that the “Process Metadata” and “Contract Negotiation” features require the kernel “SR Processing” and “Contract Negotiation” features, respectively, via the “requires” relationship. We define five optional internal features that depend on the kernel “SR Processing” feature: “System Monitoring,” “Service OS Management,” “Process Suspension,” “Failure Management,” and “Process Preemption.” The relationships between the internal features are depicted in Figure 4.

OPEN IN VIEWER

Figure 3.

The external features diagram.

OPEN IN VIEWER

Figure 4.

The internal features diagram.

The “System Monitoring” feature represents the capability of the service delivery system to continuously monitor the system operation and collect data describing the system state, such as metrics of the performance, cost, and so on. The “Service OS Management” feature describes an additional ability of the service delivery system to manage its service OS processes by real-time changes of their parameters, algorithms, number of instances, and so on, according to predetermined policies and data collected by the system monitoring component. The “Process Suspension” feature allows the system to suspend the execution of service processes and resume them later. The “Failure Management” feature applies the process suspension to interrupt the service processes that are using the resources affected by a failure. The processes are resumed when the failure is eliminated. The “Process Preemption” feature allows the resource manager to preempt service processes that are utilizing the resources, which must be allocated to SRs with higher priorities.

In our approach, the feature model plays the role of the variability model proposed by Pohl, Böckle, and Linden (2005). It is used to define the variability via feature conditions. We apply the defined feature model to specify feature conditions at the lower levels of the product line architecture, such as the static and dynamic models. The PLUS approach applies iterative development; therefore, all the variability introduced at the lower architectural levels is reflected in the feature model during the next iterations. The hierarchies of external and internal features can be further extended when necessary using the “extends” and “mutually includes” relationships and introducing additional optional or alternative features.

Static Modeling

In static modeling, the objects participating in the system’s operation are determined and categorized using stereotypes; relationships between them are established using UML class diagrams. At this stage, the variability is defined through interfaces, abstract classes, inheritance, and parameterization. Classes can be kernel, optional, and alternative, corresponding to the defined external and internal features. For our model, we use a convention that all the classes in the static model are represented by interfaces and, therefore, each of them can be extended to implement the variability.

According to the PLUS approach, we divide the objects into two main categories: state dependent objects and entities. State-dependent objects are the objects that implement the control flow of the system. These objects are active in the sense that apart from reacting to external events, they can initiate activities themselves independently of the external environment and other state dependent objects. On the other hand, entities are passive objects, they do not perform actions; rather these objects are acted on by state-dependent objects and are used to store data and states of other objects in the system.

Figure 5 shows the kernel and optional state dependent objects constituting our model as well as their relationships. According to the model, the service delivery system consists of four kernel state dependent objects: Dispatcher, Resource Manager, Process Manager, and Complaint Resolver; and four optional state-dependent objects: OS Manager, Failure Manager, System Monitor, and Contract Negotiator. The functionality of these objects corresponds to the service delivery system workflow introduced earlier.

OPEN IN VIEWER

Figure 5.

The static model diagram of state-dependent objects.

We split the entity model into three parts: SR, resource, and process type–related entities. An SR contains a single collection of SR characteristics, which in turn contains multiple SR characteristics. The model of resource-related entities divides the resources into two categories: OS resources and regular resources. OS resources are utilized by service OS processes, such as Dispatcher, Resources Manager, and so on. OS Manager’s decision on adding and removing instances of OS processes may rely on the availability of OS resources. In contrast, regular resources are allocated to service processes. All resources contain information on their availability using the resource availability data abstraction. Similar to SRs, each resource embodies a collection of resource capabilities containing a set of resource capability values.

Similar to the resource entity model, process types are split into OS process types and regular processes types. OS process types represent classes of service OS processes (e.g., Dispatcher and Resource Manager), whereas instances of service processes are created based on regular process types. Regular process types contain sets of process tasks that are executed in order to deliver the service. Each instance of a process contains the corresponding process type data abstraction and is stored in a process pool.

Dynamic Modeling

During the dynamic modeling phase, UML communication diagrams are developed to represent message passing, control, and sequencing between the objects comprising the system. Communication diagrams model different scenarios and are parameterized by internal and external features. Communication diagrams can be kernel, optional, and alternative. Variant diagrams show the impact of particular variation points in the original diagram and depict only the required modifications of the original diagram. Using UML state charts, state machine modeling describes the internal behavior of state-dependent objects defined during the static modeling phase. Due to the lack of space, we do not include the dynamic model and state machine model diagrams in this article; however, the interested reader may find them online. ¹

Implementation in AnyLogic

We have implemented the proposed model of a product line of IT service delivery simulation models as a Java framework in the AnyLogic simulation environment (Borshchev and Filippov 2004). The AnyLogic simulation environment has been chosen for its approach to the model development, which is a combination of graphical interface-based modeling using an extensive library of components with the ability to program the behavior of custom components in Java. The implementation of our framework features generic interfaces and abstract classes with pre-implemented base functionality. The framework contains all the necessary components, which can be used directly, extended, or completely overridden if required. This adds to the flexibility in the design of simulation models, as the base architecture and components of the framework are reusable and customizable in accordance with the product line model.

Proof-of-Concept Validation

In order to validate the proposed approach, we implemented a proof-of-concept product line of simulation models of a family of real-world IT service delivery systems in the domain of data center management (Banerjee, Dasgupta, and Nirmit, 2011). The related IT service delivery systems were represented by a base simulation model of the product line and a set of related simulation models produced through major modifications of the base model. The simulation models have been implemented using the AnyLogic simulation environment and the framework described in the previous section. The validation consisted in showing the correctness and applicability of the proposed product line of IT service delivery simulation models to modeling real-world systems through a comparison of simulation results produced by a model implemented using the proposed framework with results produced by the corresponding custom simulation model that has been specifically designed and implemented to model the service delivery system.

In the domain of data center management, customer-owned IT infrastructures are supported and managed by specialized third-party service providers. Customers submit SRs that are remotely processed by Service Workers (SWs) of the service providers. The base IT service delivery system simulated in this case study is one of IBM’s IT service delivery systems, which is described in detail by Banerjee, Dasgupta, and Nirmit (2011).

The modeled service delivery system serves several customer accounts. SRs submitted by each account are characterized by their complexity and priority, which are mapped onto SR characteristics. There are two levels of complexity C ₁ = {lowComplexity, moderateComplexity}, and 4 priority levels C 2 = { 1 , 2 , 3 , 4 } . In our experiments, we used real workload traces and statistics collected from the modeled IBM’s service delivery system. Both the product line based and custom simulation models were supplied with the same input data. The workload traces used in the simulation have been obtained from six customer accounts, which are anonymized due to confidentiality concerns.

The complexity and priority of an SR follow probability distributions shown for each account in Table 1. The arrival times of SRs follow an exponential distribution with the arrival rate changing every hour on a 7-day cycle for each account independently. Due to the large number of arrival rates, we do not include them in this article. Each SR requires a period of time to be processed, which is referred to as the service time and is log-normally distributed with the mean and standard deviation defined separately for each combination of complexity and priority, as shown in Table 2. SRs waiting in the queue are ordered based on their priority: high priority SRs are served first. Moreover, if no resource is available for a just arrived high priority SR, a lower priority SR is preempted, and the released SW starts working on the high priority SR. The preempted SR waits in a queue for the SW to become available and resume the processing.

OPEN IN VIEWER

Table 1.

SR Parameter Probability Distributions.

	Account 1	Account 2	Account 3	Account 4	Account 5	Account 6
SR complexity probabilities
Low complexity	0.92	0.76	0.75	0.62	0.89	0.68
Medium complexity	0.08	0.24	0.25	0.38	0.11	0.32
SR priority probabilities
Priority 1	0.09	0.43	0.04	0.36	0.00	0.33
Priority 2	0.04	0.14	0.48	0.13	0.02	0.08
Priority 3	0.86	0.40	0.34	0.46	0.46	0.56
Priority 4	0.01	0.03	0.14	0.05	0.52	0.03

Note. SR = service requests.

OPEN IN VIEWER

Table 2.

Service Time Distribution Parameters.

	Priority 1	Priority 2	Priority 3	Priority 4
Low complexity SRs
Mean	42.02	53.20	32.73	42.52
SD	51.29	53.99	35.14	38.90
Moderate complexity SRs
Mean	56.83	68.13	50.74	55.50
SD	57.47	65.10	50.37	48.26

Note. SD = standard deviation; SR = service request.

At every point in time, there are a number of SWs each capable of serving SRs with some maximum level of complexity. The capabilities of SWs are mapped onto the corresponding resource capabilities from the set of available resource capabilities A ₁ = {low, medium, high}. An SW is available between the specified start and end times of his shift at specific days of week, which are modeled as resource availability changing depending on the time of the day and day of the week. Normally, a highly skilled SW works on SRs with the maximum complexity, which the SW is capable of serving. There is a policy, referred to as the swing policy, according to which highly skilled SWs start working on SRs with a lower complexity when a specified threshold on the number of pending SRs with the lower complexity is exceeded. For the purposes of this case study, a pull-based dispatching policy was applied (Banerjee, Dasgupta, and Nirmit, 2011). According to this policy, an SW that becomes available fetches the next SR from the global prioritized queue of SRs.

The metric of interest in this case study is the response time. The response time is the time period from the moment when an SR enters the system to the moment when its processing is completed and it exits the system. We focus on this metric, as it describes the overall system operation encompassing the dispatching of SRs, resource allocation, preemption, and so on. We aim to obtain a nonstatistically significant difference in the response times produced by the model implemented using the proposed approach and the custom model.

We conducted a set of t-tests to compare the response times obtained from the two simulation models for all combinations of accounts, complexity, and priority. The resulting p values are listed in Table 3. All the t-tests resulted in p values > .05, which means that there are no statistically significant differences in the response times produced by the models. Therefore, we accept the null hypothesis that there is no difference in the response time produced by the two simulation models. This fact demonstrates the correctness of the proof-of-concept simulation model implemented based on the proposed framework and product line of IT service delivery simulation models.

OPEN IN VIEWER

Table 3.

p Values From the Conducted t-Tests for Comparing the Response Times Produced by the Simulation Models.

	Priority 1	Priority 2	Priority 3	Priority 4
Low complexity SRs
Account 1	0.948	0.870	0.194	0.627
Account 2	1.000	0.206	0.222	0.064
Account 3	0.982	0.806	0.964	0.991
Account 4	0.921	0.655	0.601	0.578
Account 5	0.993	0.845	0.923	0.875
Account 6	—	0.990	0.797	0.084
Moderate complexity SRs
Account 1	0.855	0.786	0.383	0.893
Account 2	0.886	0.589	0.518	0.240
Account 3	0.869	0.965	0.983	0.432
Account 4	0.513	0.831	0.701	0.777
Account 5	0.729	0.841	0.902	0.924
Account 6	—	0.850	0.476	0.793

Note. SR = service requests.

Comparison of Design and Development Time

In order to evaluate the productivity gains brought by the proposed approach, we implemented three major modifications in the initial service delivery simulation model described in the previous section to produce three new models with similar but different functionality. The aim of this experiment is to evaluate the time taken to implement new but related models compared with implementing the corresponding modifications in the custom simulation model. The first modification was the implementation of a push-based dispatching policy, in which the dispatcher assigns SRs to SWs as soon as they arrive (Banerjee, Dasgupta, and Nirmit, 2011). Each SW maintains his own queue of pending SRs prioritized by the deadline. If the shift of an SW ends before all of his SRs have been processed, the remaining SRs are reinserted into the dispatcher’s queue. This dispatching policy supports preemption: Each SW maintains his own queue of preempted SRs waiting for the SW to become available and resume the processing.

The second modification was the implementation of the swing policy similarly to the original model, but in addition to assigning low complexity SRs to medium skill SWs, moderate complexity SRs are assigned to high skill SWs. The third modification was the implementation of rest breaks during the shifts of SWs. Each SW can take three rest breaks during his shift, where the total duration of breaks is calculated from the specified efficiency parameter of SWs. The duration of each of the three breaks is calculated according to the 1:4:1 proportions, respectively. A break is scheduled randomly during every one third of the shift. SWs cannot accept new SRs during their breaks. If an SR is currently being served, its processing is suspended at the beginning of the SW’s break and resumed at the end of the break.

The development time taken for the implementation of the described modifications along with time estimates for the corresponding custom model modifications suggested by an experienced model designer are shown in Table 4. The results indicate that for these particular modifications, the application of the proposed framework and product line of IT service delivery simulation models has led to 5–8 times reductions in the development time compared with the time required to implement these modifications in the custom simulation model. This is explained by the fact that in contrast to the custom model, the proposed model takes advantage of the standard architecture provided by the product line of IT service delivery simulation models, its flexibility and extensibility leading to significant productivity gains, while providing correct simulation results as demonstrated by our case study presented in the previous section.

OPEN IN VIEWER

Table 4.

Design and Development Time Comparison.

Modification	Product Line	Custom Model
Push-based dispatch	5 hours	40 hours
High-medium swing	2 hours	12 hours
Rest breaks of SWs	3 hours	15 hours

Note. SWs = Service Workers.