|Research, training, consultancy and software to reduce IT costs|
Universal business computer 2: Architecture
Systems benefit from a simple external architecture and a consistent internal architecture.
The universal business computer is a pragmatic quest for standardised IT architecture that is responsive, versatile, meets long-term management objectives, and is an order-of-magnitude simpler and cheaper than traditional approaches.
To get close to this ideal, we need to consider a number of different aspects. This week I want to share some ideas on overall architecture. In later weeks, I want to cover information representation, adding meaning to information, and user interaction.
I want to cover two aspects of architecture: what it looks like from the outside, and what it looks like on the inside.
The main requirement for architecture is that it should be easy to manage. To achieve this, each system should be self-contained. It should manage user interactions, store data, and perform its own housekeeping. There may be interactions between systems, but each system must have enough intelligence to cope when other systems are not available. Although a system may be implemented on multiple physical servers, it should be accessed through a single network address.
The outside view of the universal business computer is therefore very simple. It is a peer on a network of similar computers, with no layers and no dependencies.
Externally, all computers are self-contained, equivalent peers.
The universal business computer needs to support all types of interaction. It needs to interact with the user, typically to a web browser, and interact with other systems. It needs to support its own internal processing, connecting different components, initialization, housekeeping, and so on. Rather than thinking of these as separate types of processing, in my vision of the universal business computer, these are all carried out in the same way.
Our Metrici Advisor software provides an example. We encapsulate all processing and data access in services. These are implemented in Java and communicate with each other using XML messages. The services support all types of processing: they support a web-based user interface, provide access to components such as email, and perform initialization and housekeeping. The user interface is not service-based, but all significant processing is carried out by services called from the user interface layer.
The services are self-contained, for example performing all necessary authorisation checks. This means that anything a user can do can be automated. Services can be called from the UI layer, or from another system using a web service, or by pasting XML directly into a UI utility. Internally, services can be called by writing XML files into specific directories, or specified in startup files, or run from the command line, or run from Java programs, or embedded in user-defined scripts. Standardising all internal integration around services provides a common mechanism for building the application, which works for all types of processing.
Internally, common services encapsulate access to data and other components.
To summarise, the key points of my vision of the architecture of the universal business computer are:
Next week I will share some ideas on how information can be represented in a universal business computer.Next: Universal business computer 3: Data graphs
Minimal IT: research, training, consultancy and software to reduce IT costs.