SYSTEM ORGANISATION reflects the basic strategy used to structure a system. Three organisational styles are widely used. THE REPOSITORY MODEL Subsystems must exchange data. This may be done in two ways: (a) all shared data is held in a CENTRAL DATABASE or REPOSITORY, accessible to all subsystems — the repository model (b) each subsystem maintains its own database, and data is passed explicitly between subsystems When large amounts of data are to be shared, the repository model is most commonly used, because it is an efficient way of sharing large volumes of data — there is no need to transmit data explicitly from one subsystem to another. ADVANTAGES · EFFICIENT for sharing large amounts of data — no transmission needed · subsystems producing data NEED NOT KNOW how that data is used by other subsystems · CENTRALISED MANAGEMENT — backup, security, access control and recovery are handled in one place; new tools are easy to integrate if they are compatible with the agreed data model · SHARING MODEL IS PUBLISHED as the repository schema, so integrating new tools is straightforward DISADVANTAGES · subsystems must AGREE ON A DATA MODEL — inevitably a compromise, and the compromise may make each subsystem's job harder · EVOLUTION IS DIFFICULT — a new data model means converting the whole repository, at high cost · different subsystems have different requirements for security, recovery and backup policy, but the repository model forces the SAME POLICY on all · DISTRIBUTION IS HARD — even where logically possible, keeping a distributed repository consistent is expensive CLASSIC EXAMPLES: a CASE toolset sharing a design repository; a compiler whose phases share a symbol table and AST; a database-centred enterprise application; a blackboard system in AI. THE ONE-LINE SUMMARY: the repository model trades COUPLING FOR CONVENIENCE. Everything is easy to reach, and everything therefore depends on one schema — which is why "the shared database" is the hardest architectural decision to reverse.

THE CLIENT–SERVER MODEL A distributed system model showing how data and processing are distributed across a range of components. It has three parts: · a set of STAND-ALONE SERVERS offering services (a print server, a file server, a name server) · a set of CLIENTS that call on these services · a NETWORK allowing clients to access servers Clients may have to know the names of the available servers and the services they provide; servers need not know the identity of clients or how many there are. Clients access services provided by a server through REMOTE PROCEDURE CALLS. ADVANTAGES · DISTRIBUTION OF DATA IS STRAIGHTFORWARD · makes EFFECTIVE USE of networked systems; may allow cheaper hardware · EASY TO ADD a new server or upgrade an existing one transparently DISADVANTAGES · NO SHARED DATA MODEL, so subsystems use different data organisation, and data interchange may be inefficient · REDUNDANT MANAGEMENT in each server · NO CENTRAL REGISTER of names and services — it may be hard to find out what services and servers are available THE LAYERED (ABSTRACT MACHINE) MODEL Used to model the interfacing of subsystems. Organises the system into a set of layers (or abstract machines), each providing a set of services. · supports the INCREMENTAL DEVELOPMENT of subsystems in different layers — when a layer interface changes, only the adjacent layer is affected · CHANGEABLE and PORTABLE — the layered structure means each layer can be replaced by an equivalent one without affecting the rest, provided the interface holds DISADVANTAGE · STRUCTURING THE SYSTEM IN LAYERS CAN BE DIFFICULT. An inner layer may provide facilities required by an outer layer that is not immediately adjacent, forcing either a layer-skipping call (breaking the model) or a pass-through (adding no value). · PERFORMANCE can suffer: a service request may have to be interpreted at each layer, so multiple levels of interpretation add latency. This is the cost the layered model pays for its portability. THE STRICT vs RELAXED LAYERING QUESTION: STRICT a layer may call ONLY the layer immediately below. Maximum isolation, maximum pass-through boilerplate. RELAXED a layer may call ANY lower layer. Less boilerplate, but now a change to layer 1 can affect layer 4 directly, which is the property layering was bought to prevent. Real systems mostly use relaxed layering and then regret it selectively. CLASSIC EXAMPLES: the OSI/TCP-IP protocol stack; an operating system (hardware → kernel → system calls → libraries → applications); a version-management system layered over an object-management system over a database system over an operating system.

THE SAME requirement — "the licence system must produce monthly revenue reports" — organised three ways. REPOSITORY ┌──────────┬──────────┬──────────┬──────────┐ │ Intake │ Review │ Payment │ Reporting│ └────┬─────┴────┬─────┴────┬─────┴────┬─────┘ └──────────┴────┬─────┴──────────┘ ┌──────▼──────┐ │ REPOSITORY │ one schema └─────────────┘ Reporting simply queries the shared tables. Adding a report costs a SELECT and nothing else — the model's great strength. BUT: Payment cannot change its fee table shape without breaking Reporting, and nobody knows who reads what, so in practice NOTHING can be changed safely. Evolution cost is the price of the query convenience. LAYERED ┌────────────────────────────────┐ presentation ├────────────────────────────────┤ application services ├────────────────────────────────┤ domain logic ├────────────────────────────────┤ data access └────────────────────────────────┘ database Reporting is a domain service; presentation never touches SQL. Swapping PostgreSQL for another store means rewriting ONE layer. BUT: a report needing a bulk aggregate must either go through the per-entity data-access layer (slow — the N+1 query problem) or skip a layer (breaking the model). This is the layering pain in its most common real form. CLIENT–SERVER Intake service Review service Payment service │ │ │ └─────────────────┴─────────────────┘ network │ Reporting client Each service owns its data and exposes an API. Payment can change its internals freely. BUT: a revenue report now needs data from three services, so Reporting must make three network calls and JOIN IN APPLICATION CODE — and if Payment is down, the report fails. There is no consistent point-in-time snapshot across three independent stores. THE HONEST SCORECARD ─────────────────────────────────────────────────────────── criterion repository layered client–server ─────────────────────────────────────────────────────────── ad-hoc reporting excellent good poor independent change poor good excellent scaling out poor moderate excellent consistency excellent excellent poor operational effort low low high ─────────────────────────────────────────────────────────── NOTE THE PATTERN: reporting ease and independent change are ANTI-CORRELATED across all three rows. That is not a coincidence — easy cross-cutting queries require shared structure, and shared structure is exactly what prevents independent change. Every "which architecture?" argument in industry is a rediscovery of this one trade-off.