Information systems: types, layered architectures and availability

An information system is the set of data, procedures, people and technologies with which an organisation collects, stores, processes and distributes the information it needs: a company’s orders and invoices, a hospital’s medical records, a university’s exams. The automated part, the computer system, is its technical heart. In this lesson we look at the functions and types of information systems, layered architectures, the calculation of availability with the proof of the formulas for components in series and in parallel and an example, and the relation between systems and business processes.

What an information system does

Tasks are divided by level of decision:

• operational (transactional) systems record daily events: an order, a payment, an enrolment. They must be fast, reliable and consistent;
• management systems integrate the data of the departments: ERP systems (enterprise resource planning) manage accounting, purchasing, warehouse, production and staff in a single database; CRM systems manage customer relationships; SCM systems the supply chain;
• executive systems (business intelligence) analyse large amounts of historical data to support decisions, with dashboards and reports (lesson on distributed data and data warehouses).

At the centre of them all there is a database: the following lessons look at its design, its language, indexes and transaction management.

Layered architectures

A modern information system is divided into three logical tiers:

• presentation: the user interface, nowadays almost always a web or phone application;
• application logic: the organisation’s rules (how a discount is computed, when an order can be shipped), on one or more application servers;
• data: the database management system (DBMS), which guarantees persistence and integrity.

Separating the tiers makes it possible to change one without touching the others, to scale each independently by adding machines, and to protect the data, which is never directly exposed to users. Microservice architectures push the division further: many small independent applications, each with its own data, communicating over the network through documented interfaces (APIs). The cloud provides the tiers as pay-per-use services, from virtual machines to managed databases.

Availability

A system handling sales or a hospital’s emergencies must always work. Availability is the fraction of time the system works, related to the mean time between failures (MTBF) and the mean time to repair (MTTR) by . It is often expressed as a “number of nines”: 99.9 % means about 8.8 hours of downtime a year, 99.99 % about 53 minutes.

Theorem. For components failing independently, with availabilities :

• if the system works only when all of them work (components in series), ;
• if the system works when at least one works (components in parallel, redundant), .

Proof. Availability is the probability that the component works at any given instant. For independent events the probability that all occur is the product of the probabilities: this gives the series case. The parallel system is down only if all the components have failed, an event of probability ; availability is the complement. ∎

Example. An application server with availability 99.5 % and a database with 99.9 %, in series: , i.e. about 52 hours of downtime a year. Doubling both tiers, as in the figure: the application tier becomes , the data tier , and the system : about 14 minutes a year. A series is always worse than its weakest link; redundancy improves availability enormously, provided failures are really independent. Two servers in the same room, with the same power supply and the same faulty update, are not: that is why critical systems are spread over several data centres.

Systems and processes

An information system is not designed starting from technology, but from the organisation’s processes: the sequences of activities producing a result for a customer, internal or external (receiving an order, fulfilling it, invoicing it, collecting payment). They are described with graphical notations such as BPMN (Business Process Model and Notation), with activities, events, decisions and flows between roles. Process analysis shows where data originates, who uses it and which steps can be automated or eliminated. The experience of corporate IT projects is that failures rarely come from technology and much more often from misunderstood requirements and processes nobody rethought.