The GRAAL project (is.cs.utwente.nl/GRAAL)
University of Twente, the Netherlands
14 November 2004
Infrastructure is the set of systems that should be available for use by all users whenever they need it. In GRAAL, we are interested in the software infrastructure of a business, but a large part of infrastructure is physical. It consists of the electricity network, telecommunication networks, the water provision network, the sewage disposal network, the central heating network, the network of roads, the rail network, broadcasting networks and other widely available service networks that provide services for the general public. Most of these networks have been introduced in the 20th century. Software infrastructures are just the latest addition to this set of infrastructures.
Because infrastructures provide services to a large heterogeneous set of user groups, they often have a network nature that allow users to use the services wherever they are in physical space. The software infrastructures that we found are no exception to this. They are usually partitioned into domains that have a roughly layered structure. The following diagram gives a typical structure. It also includes some of the physical infrastructure domains relevant for ICT.
Each domain is a knowledge area; it is not a system, but a type of systems. Experts in one domain are expert in this kind of system. They follow the trade press, follow trends in the technology market of that domain, and understand the offers made by technology vendors in that domain.
The hierarchy of domains in the above diagram represents a hierarchy of service provisioning levels to the user of the infrastructure. Software at higher levels uses services of software of lower levels, and so for higher-level software, the lower levels jointly form an implementation platform. At the same time, each higher level of software offers services with a semantics closer to the business concerns of the end user. At the highest level, personal productivity software (e.g., word processors, email client) and business intelligence software (e.g., decision support tools) offer services that can be defined in terms of the concerns of the end user.
Infrastructure components can be classified according to the size of the set of processes that they support and the speed at which their services change. From our observations, we make the following generalization.
The reason is that slow change allows a larger set of users to learn to use the infrastructure component, and the larger its user base, the more difficult it is to change anything in the component. Weill and Vitale classify infrastructure components according to scope and speed of change. At the lowest level of change, and the largest scope of users, we find commodities such as operating systems and certain user interface hardware such as credit card swipers. On top of that, we find stable services such as database management systems and workflow management systems. On the next higher level we find standardized applications such as HRM applications, accounting applications, and other components that might be included in an ERP system. We see this hierarchy roughly illustrated in the example infrastructure domains given above.
An infrastructure architecture consists of
A standard might be a de jure or de facto standard, or a selection of one or two vendors for software in one domain, company-specific agreements, branch-specific agreements, agreements with customers or suppliers, etc. In the companies we investigated, the infrastructure software is never built but bought.
Procurement decisions for infrastructure software are driven by four sources. Business goals may lead to certain infrastructure decisions. For example, the business goal to facilitate location-independent work can be supported by the installation of wireless network, groupware infrastructure, and standard browser interfaces accessible from anywhere. Business problems may lead to yet other decisions, such as the installation of more storage servers to solve performance problems, or the move to another network software supplier to solve problems with maintenance. Against these business drivers act forces coming from already existing software (legacy) and new software (technology trends). All organizations must deal with legacy systems. In fact, our six case studies lead us to formulate this tentative generalization:
Organizations differ widely in the relative priority given to these forces. We encountered organizations where the attention to business goals and business problems was merely symbolic and technology trends where the driving force. In other organizations, all four forces where given due weight in procurement decisions.