IT service management: towards a contingency theory of performance measurement

Information Technology Service Management (ITSM) focuses on IT service creation, design, delivery and maintenance. Measurement is one of the basic underlying elements of service science and this paper contributes to service science by focussing on the selection of performance metrics for ITSM. Contingency theory is used to provide a theoretical foundation for the study. Content analysis of interviews of ITSM managers at six organisations revealed that selection of metrics is influenced by a discrete set of factors. Three categories of factors were identified: external environment, parent organisationand IS organisation. For individual cases, selection of metrics was contingent on factors such as organisation culture, management philosophy and perspectives, legislation, industry sector, and customers, although a common set of four factors influenced selection of metrics across all organisations. A strong link was identified between the use of a corporate performance framework and clearly articulated ITSM metrics

Root Cause Analysis in Business Processes

Conceptual modeling is an important tool for understanding and revealing weaknesses of business processes. Yet, the current practice in reengineering projects often considers simply the as-is control flow and uses the respective model barely as a reference for brain-storming about improvement opportunities. This approach heavily relies on the intuition of the participants and misses a clear description of steps to identify root causes of problems. In contrast to that, this paper introduces a systematic methodology to detect and document the quality dimension of a business process. It builds on the definition of softgoals for each process activity, of correlations between softgoals, and metrics to measure the occurrence of quality issues. In this regard our contribution is a foundation of root-cause analysis in business process modeling, and a conceptual integration of goal-based and activity-based approaches to capturing processes

TANGO: Transparent heterogeneous hardware Architecture deployment for eNergy Gain in Operation

The paper is concerned with the issue of how software systems actually use Heterogeneous Parallel Architectures (HPAs), with the goal of optimizing power consumption on these resources. It argues the need for novel methods and tools to support software developers aiming to optimise power consumption resulting from designing, developing, deploying and running software on HPAs, while maintaining other quality aspects of software to adequate and agreed levels. To do so, a reference architecture to support energy efficiency at application construction, deployment, and operation is discussed, as well as its implementation and evaluation plans.Comment: Part of the Program Transformation for Programmability in Heterogeneous Architectures (PROHA) workshop, Barcelona, Spain, 12th March 2016, 7 pages, LaTeX, 3 PNG figure

Management issues in systems engineering

When applied to a system, the doctrine of successive refinement is a divide-and-conquer strategy. Complex systems are sucessively divided into pieces that are less complex, until they are simple enough to be conquered. This decomposition results in several structures for describing the product system and the producing system. These structures play important roles in systems engineering and project management. Many of the remaining sections in this chapter are devoted to describing some of these key structures. Structures that describe the product system include, but are not limited to, the requirements tree, system architecture and certain symbolic information such as system drawings, schematics, and data bases. The structures that describe the producing system include the project's work breakdown, schedules, cost accounts and organization

Towards a software profession

An increasing number of programmers have attempted to change their image. They have made it plain that they wish not only to be taken seriously, but they also wish to be regarded as professionals. Many programmers now wish to referred to as software engineers. If programmers wish to be considered professionals in every sense of the word, two obstacles must be overcome: the inability to think of software as a product, and the idea that little or no skill is required to create and handle software throughout its life cycle. The steps to be taken toward professionalization are outlined along with recommendations

Past and Future Operations Concepts of NASA's Earth Science Data and Information System

NASA committed to support the collection and distribution of Earth science data to study global change in the 1990's. A series of Earth science remote sensing satellites, the Earth Observing System (EOS), was to be the centerpiece. The concept for the science data system, the EOS Data and Information System (EOSDIS), created new challenges in the data processing of multiple satellite instrument observations for climate research and in the distribution of global-coverage remote sensor products to a large and growing science research community. EOSDIS was conceived to facilitate easy access to EOS science data for a wide heterogeneous national and international community of users. EOSDIS was to provide a spectrum of services designed for research scientists working on NASA focus areas but open to the general public and international science community. EOSDIS would give researchers tools and assistance in searching, selecting and acquiring data, allowing them to focus on Earth science climate research rather than complex product generation. Goals were to promote exchange of data and research results and expedite development of new geophysical algorithms. The system architecture had to accommodate a diversity of data types, data acquisition and product generation operations, data access requirements and different centers of science discipline expertise. Steps were taken early to make EOSDIS flexible by distributing responsibility for basic services. Many of the system operations concept decisions made in the 90s continued to this day. Once implemented, concepts such as the EOSDIS data model played a critical role developing effective data services, now a hallmark of EOSDIS. In other cases, EOSDIS architecture has evolved to enable more efficient operations, taking advantage of new technology and thereby shifting more resources on data services and less on operating and maintaining infrastructure. In looking to the future, EOSDIS may be able to take advantage of commercial compute environments for infrastructure and further enable large scale climate research. In this presentation, we will discuss key EOSDIS operations concepts from the 1990's, how they were implemented and evolved in the architecture, and look at concepts and architectural challenges for EOSDIS operations utilizing commercial cloud services