Service Management and Information Systems – IT Service ...iss.uni-saarland.de/workspace/documents/dlm-13_it-service... · business processes by IT organization Management concept

Service Management and Information Systems – IT Service Infrastructures Univ.-Prof. Dr.-Ing. Wolfgang Maass Chair in Economics – Information and Service Systems (ISS) Saarland University, Saarbrücken, Germany WS 2011/2012 Thursdays, 8:00 – 10:00 a.m. Room HS 024, B4 1

Univ.-Prof. Dr.-Ing. Wolfgang Maass

01.02.12 Slide 2

General Agenda

1.  Introduction 2.  Service Strategy 3.  New Service Development (NSD) 4.  Service Quality 5.  Supporting Facility 6.  Forecasting Demand for Services 7.  Managing Demand 8.  Managing Capacity 9.  Managing Queues 10. Capacity Planning and Queuing Models 11.  Services and Information Systems 12.  ITIL Service Design 13.  IT Service Infrastructures 14.  Summary and Outlook


01.02.12 Slide 3

IT Service Infrastructures

Business processes

to be supported by IT

Coordination of business and IT

Required methods to achieve optimal support of business processes by IT

organization

Management concept for service-oriented architecture of information and communication technology SOA

Business Process Management

Business Service Management

IT Service Management (de-facto standard ITIL)

•  ITIL recommendation: business processes and solutions should be designed and developed using a service-oriented architecture (SOA) approach

•  SOA considered best practice for improving effectiveness and efficiency in the provision of IT services

•  Defined by OASIS (Organization for the Advancement of Structured Information Standards)

“SOA is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.”

(OCG, 2011)


01.02.12 Slide 4

Service-Oriented Architecture – the Thing from Another World…

SOA is… •  a software architecture that modularizes services •  a flexible and modular approach to develop shared

services for usage in different areas of business •  a descendant of logical evolution of software

modularization techniques SOA intends… •  to bring agility into organizations by encouraging

development of self-contained, reusable services

SOA enables … •  recombining of services in various forms for

implementing new or improved business processes •  linking business and computational resources on demand •  flexibility in choosing (1) technologies for software

implementation, and (2) locations of service providers and consumers

(OCG, 2011; Valipour et al., 2009)


01.02.12 Slide 5

Retrospection

•  SOA = evolution of component-based architecture, interface-based design (object-oriented) and distributed system architectures in 1990s and Internet in general, e.g., CORBA, J2EE

(Valipour et al., 2009; Garlan & Shaw, 1993)

Software architecture – a young idea.

•  1950s: software written in machine language; later it became clear that certain patterns of execution were commonly useful

•  1960s: design level of certain elements of software systems, namely abstract data types, was raised above level of programming language statements or individual algorithms

•  1970s: recognition of useful system organizations; development of software architecture styles

“Camelot is based on the client-server model and uses remote procedure calls both locally and remotely to provide communication among applications and servers.” (Spector et al., 1987) “We have chosen a distributed, object-oriented approach to managing information.” (Linton, 1987)

Extracts of literature in

1980s


01.02.12 Slide 6

Software Architecture -- Clarifications

Reducing complexity through abstraction and separation of concerns

“Software architecture involves the structure and organization by which modern system components and subsystems interact to form systems, and the properties of systems that can best be designed and ana lyzed a t the sys tem level.” (Kruchten et al., 2006, p. 23)

“Software architecture is the study of the large-scale structure and performance of software systems.” (Lane, 1990, p. 1)

“An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization […].” (Kruchten, 2003, p. 84).

“Architecture is defined […] as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.” (ANSI/IEEE 1471-2000 Standard, [1])

(Valipour et al., 2009, p. 3)


01.02.12 Slide 7

Software Architecture -- Clarifications

Reducing complexity through abstraction and separation of concerns

“Software architecture is the study of the large-scale structure and performance of software systems.” (Lane, 1990)

“An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization […].” (Kruchten, 2003).

“Architecture is defined […] as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment , and the pr inc ip les governing its design and evolution.” (ANSI/IEEE 1471-2000 Standard)

“Software architecture involves the structure and organization by which modern system components and subsystems interact to form systems, and the properties of systems that can best be designed and a n a l y z e d a t t h e s y s t e m level.” (Kruchten et al., 2006, p. 23)

(Valipour et al., 2009, p. 3)


01.02.12 Slide 8

Some Common Architectural Styles

Larger Scale Systems Require Higher-Level Abstractions

Mary Shaw Computer Science Department and

Software Engineering Institute Carnegie Mellon University

Pittsburgh, Pennsylvania 15213, U. S. A. Abstract

Over the past thirty years, abstraction techniques such as high level programming languages and abstract data types have improved our ability to specify and develop software. However, the increasing size and complexity of software systems have introduced new problems that are not solved by the current techniques. These new problems involve the system-level design of software, in which the important decisions are con- cerned with the kinds of modules and subsystems to use and the way these modules and subsystems are organized. This level of organization, the software archirecrure level, requires new kinds of abstractions that capture essential properties of major subsystems and the ways they interact.

1. Introduction The development of abstraction techniques has been a major source of improvement in programming practice. It has provided programming language constructs, specification techniques, program structures such as algorithms and data types, strategies for modular decomposition, and more [8]. The essence of abstraction is recognizing a pattern, naming and defining it, analyzing it, finding ways to specify it, and providing some way to invoke the pattern by its name without error- prone manual intervention. This process suppresses the details of the pattern’s implementation, reduces the opportunity for clerical error, and simplifies understanding of the result. There are, of conrse, many kinds of detail associated with software. It is possible to identify abstractions of many kinds, specifying different sorts of detail-about functionality, implementation, performance, physical properties, and so on. At any given time, some of these details are significant and others ir- relevant. Consequently, different abstractions are appropriate at different points in the software design and development process. In other words, good abstraction is ignoring the tight detail at the right times.

This work was supported by Carnegie Mellon University and the Mobay Corporation.

Permission to copy without fee all or part of this material is granted provided that the co

hi ies are not made or distributed for direct commercial

advantage, the AC copyr$ht notice and the title of the publication and its date appear, and notice 15 given that copying is by permission of the Association for computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.

The development of individual abstractions often follows a common pattern. Fist, problems are solved ud hoc. As expe- rience accumulates, some solutions turn out to work better than others, and a sort of folklore is passed informally from person to person. Eventually the useful solutions are understood more systematically, and they are codified and analyzed. This enables the development of models that support automatic implementation and theories that allow the extension or generabza- tion of the solution. This in turn enables a more sophisticated level of practice and allows us to tackle harder problems--which we often approach ad hoc, starting the cycle over again. As time passes, the abstractions capture larger and larger amounts of detail with more and more precision. This allows increasingly complex programs to be described with a given amount of effort. This pattern can be seen, for example, in the development of higher-level programming languages and abstract data types.

2. The Software Architecture Level of Design

Just as higher-level languages and abstract data types emerged because good programmers recognized useful structures, good programmers now recognize useful system organizations. Some of the popular system organizations are

l Pipes and Filters: Each module accepts a stream of inputs and emits a stream of outputs; usually the output stream involves local transformation of the input stream, making the module a filter. As indicated in Figure 2-1, modules are strung together by connecting the output stream of one module to serve as the input stream of its successor (a pipe).

stream Filter strssm

Figure 2.1: Pipes and Filters

143 01999 ACM 0-89791~305-1/99/0500/0143$00.75

l Data abstraction: Abstract data types provide a useful way to organize a software system. With the addition of in- heritance of definitions, it is known as object-oriented programming [5]. Figure 2-2 suggests a typical system organization, in which a number of independent objects (obj) invoke each others’ operations (op).

obl op Is i an invocation

Figure 2.2: Data Abstraction

l Layered Systems: The system is organized hierarchically, with each layer providing service to the layer above it. In- ner layers am usually hidden from outer layers, e:xcept for certain functions carefully selected for export [6]. Figure 2-3 gives an example of such an architecture.

Useful Systems

Users

Figure 2.3: Layered System

l Rule-Based System: The computation is organized as an unordered collection of rules, each of which gives a con- dition under which the rule applies and an acticln to take when it does apply [3]. Figure 2-4 shows a typical system organization in which an inference engine interprets the rules that define the knowledge base for a particular application.

This level of system organization and design is the softwure architecture level. Software organizations like these are used informally, but they are not systematically understood. Nor are they taught systematically, with guidance about reasons for choosing one rather than another for a given application. Nev- ertheless, software designers sometimes describe the architectures of particular systems. Most commonly, such a description includes a block diagram of the major subsystems and la- bels the elements in terms that refer to their specific function in the system.

l Blackboard Systems: A central data structure represents In particular problem domains or user communities, a single the current state of the computation; a collection of inde- pattern may predominate. This pattern may be used because it pendent processes, each responsible for a certain kind of is familiar, or it may be used because other alternatives are not knowledge, check the current state and update it if they considered, even when some other organization might be bet- can. As indicated in Figure 2-5, processes, or knowledge ter. Consider, for example, the Unix community, in which

j=h lnpute

. Outputs Selected rule Selected dete

Figure 2.4: Rule-Based System

sources (ksi), are invoked when they are able to improve the current state; the progress made by each knowledge source should enable some other process to operate. This organization is useful for applications in which diverse kinds of knowledge must be brought to bear on interpretation of raw data; the current state represents the current state of the interpretation and the various processes aug- ment that interpretation using whatever expertise each one impIements [ 13.

( ks7 y 1 ‘data) 1 y ks4 )

Figure 2-5: Blackboard System

144

l Data abstraction: Abstract data types provide a useful way to organize a software system. With the addition of in- heritance of definitions, it is known as object-oriented programming [5]. Figure 2-2 suggests a typical system organization, in which a number of independent objects (obj) invoke each others’ operations (op).

obl op Is i an invocation

Figure 2.2: Data Abstraction

l Layered Systems: The system is organized hierarchically, with each layer providing service to the layer above it. In- ner layers am usually hidden from outer layers, e:xcept for certain functions carefully selected for export [6]. Figure 2-3 gives an example of such an architecture.

Useful Systems

Users

Figure 2.3: Layered System

l Rule-Based System: The computation is organized as an unordered collection of rules, each of which gives a con- dition under which the rule applies and an acticln to take when it does apply [3]. Figure 2-4 shows a typical system organization in which an inference engine interprets the rules that define the knowledge base for a particular application.

This level of system organization and design is the softwure architecture level. Software organizations like these are used informally, but they are not systematically understood. Nor are they taught systematically, with guidance about reasons for choosing one rather than another for a given application. Nev- ertheless, software designers sometimes describe the architectures of particular systems. Most commonly, such a description includes a block diagram of the major subsystems and la- bels the elements in terms that refer to their specific function in the system.

l Blackboard Systems: A central data structure represents In particular problem domains or user communities, a single the current state of the computation; a collection of inde- pattern may predominate. This pattern may be used because it pendent processes, each responsible for a certain kind of is familiar, or it may be used because other alternatives are not knowledge, check the current state and update it if they considered, even when some other organization might be bet- can. As indicated in Figure 2-5, processes, or knowledge ter. Consider, for example, the Unix community, in which

j=h lnpute

. Outputs Selected rule Selected dete

Figure 2.4: Rule-Based System

sources (ksi), are invoked when they are able to improve the current state; the progress made by each knowledge source should enable some other process to operate. This organization is useful for applications in which diverse kinds of knowledge must be brought to bear on interpretation of raw data; the current state represents the current state of the interpretation and the various processes aug- ment that interpretation using whatever expertise each one impIements [ 13.

( ks7 y 1 ‘data) 1 y ks4 )

Figure 2-5: Blackboard System

144

(Garlan & Shaw, 1993; Shaw, 1989)

Pipes and filters - each component (= filter) has set of input and outputs; pipes = connectors, e.g., traditional compilers

Data abstraction – independent objects (data abstraction)(= components) invoke each others’ operations (connectors), e.g., object-oriented programming

Layered systems -- o r g a n i z e d hierarchically, each layer (component) providing service to l a y e r a b o v e i t ; connectors defined by protocols, e.g., OSI model

Further styles: •  Event-based, implicit invocation, e.g.,

user interfaces •  Distributed processes, e.g., client-

server architectures

Roots of SOA


01.02.12 Slide 9

Describing Software Architecture

•  ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description = international standard for architecture descriptions of systems and software [2]

•  Presents conceptual foundation for expressing, communicating and reviewing architectures

Extract of standard terms: •  Stakeholder: having an interest in a system, e.g., organization

•  Concern: interest in a system of one or more of its stakeholders

•  Architecture view: architecture of a system from perspective of specific system concerns, e.g., technological, economic

•  Architecture framework: conventions and practices for the description of architectures established within a specific domain of application / stakeholders, e.g., Zachman’s IS architecture framework [3], Kruchten’s 4+1 view model (Kruchten, 1995) [4]

(IEEE 42010 [2])


01.02.12 Slide 10

Characteristics of SOA

①  SOA != web services – web services are just an implementation of SOA and do not implement all aspects, e.g., no specification of service levels

②  Separates the “what” (interfaces) from the “how” (implementation)

③  Dynamic binding of modular components – loose coupling

④  Interoperability between platforms and languages

(Valipour et al., 2009)

SAP Enterprise Service Oriented Architecture (Enterprise SOA) •  SAP solutions currently using

Enterprise SOA: mySAP CRM, mySAP ERP, mySAP SRM [5]

IBM WebSphere software for SOA environments •  Application infrastructure,

application integration, business process management etc. [6]

Exemplary software products implementing the SOA idea:

SOA concepts, e.g., •  RPC protocol = remote procedure

call -- inter-process communication that allows an application to cause a procedure to execute in another address space, e.g., SOAP

•  Jini framework for development of distributed systems

•  REST architectural style •  WSDL = Web Services Description

Language – used for describing functionality offered by web service


01.02.12 Slide 11

How to? -- Service-Oriented Modeling

•  Different approaches for service modeling, e.g., SOMA (Service-Oriented Modeling and Architecture) by IBM and SOMF (Service-Oriented Modeling Framework) (Bell, 2008)

•  SOMF = SOA implementation framework = holistic modeling language for software development that employs disciplines and an universal language to provide tactical and strategic solutions to enterprise problems

(Bell, 2008)

5 SOMF modeling styles for linking services

SOMF modeling assets – 4 major software formations

(Source: wikipedia.de)


01.02.12 Slide 12

Example: Service-Oriented Modeling

(Methodologies Corporation Inc., 2008)


01.02.12 Slide 13

“Everything as a Service”

SaaS = Software as a service •  License-free software; usage of software as service, e.g.

Google Docs

PaaS = Platform as a service •  Integrated runtime / development environment as service,

e.g., Windows Azure (server infrastructure for cloud services), Google App Engine and Force.com (develop and deploy own applications on external infrastructure)

IaaS = Infrastucture as a service •  Leasing of hardware infrastructure as a service instead of

buying, e.g., Amazon EC2 (processing power) and S3 (storage)

SOMF Cloud Computing Model


01.02.12 Slide 14

Benefits of SOA

•  Facilitates manageable growth of large-scale enterprise systems

•  Facilitates internet-scale provisioning and use of services

•  Reduce costs in organization-to-organization cooperation

•  Simple paradigm for organizing large networks of systems that require interoperability

•  Functionality across ownership boundaries

(Valipour et al., 2009)


01.02.12 Slide 15

Critique

•  Most SOA deployments in large enterprises have not been successful or have not provided the expected ROI because SaaS elements in deployments are missing

•  SOA only survived by its offsprings – SaaS, cloud computing and all other architectural approaches that depend on “services”

•  Except in rare situations, SOA do not reduce costs or increase agility on a massive scale

•  IT systems are no better than before – costs are higher, projects take longer, systems are more fragile

•  People forgot what SOA stands for – they are too wrapped up in technology debates and miss the important stuff: architecture and services

•  Implementations of large number of services (chatty services) leads to degradation in performance

•  Access to data via multiple business services – unified view of data endangered

(Manes, 2009; Brodkin, 2007; Cherbakov et al., 2005; Singla, 2009)


01.02.12 Slide 16

“SOA is Dead, Long Live Services!”

•  Requirement for service-oriented architectures is stronger than ever

•  Successful SOA, i.e. application re-architecture requires disruption to status quo = redesign of application portfolio instead of deploying new technology and building service interfaces to existing applications

•  e.g., transformation of IT department of construction company Bechtel [7]

(Manes, 2009)


01.02.12 Slide 17

Example: Bechtel

•  Bechtel transformed its IT department and turned itself into a software-as-a-service (SaaS) provider for internal users, subcontractors and business partners

•  Scrapped all of its existing data centers and built three new facilities

•  Applied the SaaS computing model internally to provide IT services to 30,000 users, including 20,000 employees and eventually 10,000 subcontractors and other business partners

•  SaaS model allows "to bring in a different cost model that can afford us to have a high-capacity, global, collaborative work environment […]” (Geir Ramleth, CIO of Bechtel) [7]


01.02.12 Slide 18

“SOA is Dead, Long Live Services!”

•  Requirement for service-oriented architectures is stronger than ever

•  Successful SOA, i.e. application re-architecture requires disruption to status quo = redesign of application portfolio instead of deploying new technology and building service interfaces to existing applications

•  e.g., transformation of IT department of construction company Bechtel [7]

•  Massive shift -- “SOA needs to be part of something bigger.” – just shiny new technology will not make things better

•  “And that’s where we need to concentrate from this point forward: Services.” (Manes, 2009)

(Manes, 2009)


01.02.12 Slide 19

Outlook

1.  Introduction 2.  Service Strategy 3.  New Service Development (NSD) 4.  Service Quality 5.  Supporting Facility 6.  Forecasting Demand for Services 7.  Managing Demand 8.  Managing Capacity 9.  Managing Queues 10. Capacity Planning and Queuing Models 11.  Services and Information Systems 12.  ITIL Service Design 13.  IT Service Infrastructures 14.  Summary and Outlook


01.02.12 Slide 20

Literature

Books: •  Bell, M. Service-oriented Modeling: Service Analysis, Design and Architecture, Wiley, 2008. •  Kruchten, P. Rational Unified Process: An Introduction, Addison-Wesley Longman, 2003. •  Office of Government Commerce (OGC), ITIL Service Strategy, The Stationery Office (TSO), London, 2011.

Papers: •  Brodkin, J. "SOA's 6 burning questions", JavaWorld, Website, 2007. •  Cherbakov, L., Ibrahim, M. and Ang, J. "SOA Antipatterns", IBM, Website, 2005. •  Garlan, D. and Shaw, M. "An Introduction to Software Architecture", in Ambriola, V. and Tortora, G.,

ed.,'Advances in Software Engineering and Knowledge Engineering', World Scientific Publishing Company, Singapore, 1993, pp. 1-39.

•  Methodologies Corporation Inc., "SERVICE-ORIENTED MODELING FRAMEWORKTM (SOMF) VERSION 2.1 – SERVICE-ORIENTED DISCOVERY AND ANALYSIS MODEL LANGUAGE SPECIFICATIONS", Technical report, Methodologies Corporation Inc., 2008.

•  Kruchten, P. "Architectural Blueprints – The "4+1" View Model of Software Architecture," IEEE Software (12:6), 1995.

•  Kruchten, P., Obbink, H. and Stafford, J. "The Past, Present, and Future for Software Architecture," IEEE Software (23), 2006, pp. 22--30.

•  Lane, T. G. "Studying Software Architecture Through Design Spaces and Rules", Technical report, Software Engineering Institute -- Carnegie Mellon University, 1990.


01.02.12 Slide 21

Literature

•  Linton, M. A. "Distributed management of a software database," IEEE Software (4), 1987, pp. 70-76. •  Manes, A. T. "SOA is dead; Long live services", Application Platform Strategies Blog, Website, 2009. •  Shaw, M. "Larger scale systems require higher-level abstractions," SIGSOFT Softw. Eng. Notes (14), 1989,

pp. 143—146. •  Singla, V. "The Overlapping Worlds of SaaS and SOA - How SaaS and SOA will enable "IT as a Service"",

Cloud Computing Journal, Website, 2009. •  Spector, A. Z., Thompson, D., Pausch, R. F., Eppinger, J. L., Duchamp, D., Draves, R., Daniels, D. S. and

Bloch, J. J. "Camelot: A distributed transaction facility for Mach and the Internet - an interim report", Technical report, Tech. Rep. CMU-CS-87-129, Carnegie Mellon University, 1987.

•  Valipour, M. H., Amirzafari, B., Maleki, K. N. and Daneshpour, N. "A brief survey of software architecture concepts and service oriented architecture"'2nd IEEE International Conference on Computer Science and Information Technology, 2009', 2009, pp. 34—38.

Web: •  [1] http://standards.ieee.org/findstds/standard/1471-2000.html •  [2] http://www.iso-architecture.org/42010/cm/ •  [3] http://www.Zachman.com/ •  [4] http://www.iso-architecture.org/ieee-1471/afs/frameworks-table.html •  [5] http://www.sap.com/germany/solutions/business-suite/index.epx •  [6] http://www-01.ibm.com/software/solutions/soa/offerings.html •  [7] http://www.networkworld.com/news/2008/102908-bechtel.html?page=1


Univ.-Prof. Dr.-Ing. Wolfgang Maass Chair in Information and Service Systems Saarland University, Germany

Documents

Service Management and Information Systems – IT Service ...iss.uni-saarland.de/workspace/documents/dlm-13_it-service... · business processes by IT organization Management concept