What would be the impact on data and database management if we based IT architecture on the principles of strictly independent systems?
The fundamental feature of system-oriented architecture (SYSOA) is that IT is composed of strictly independent systems. All the supporting infrastructure of a system is considered part of the system.
This would seem to reduce the importance of data. Instead of being a significant part of the overall architecture, data and databases are relegated to be a mere component of systems. Would this undermine the role of data, and reverse the good data and database management disciplines that have grown up over the years?
Let's have a look at SYSOA's impact on data in more detail.
Simplistically, SYSOA suggests that every system that uses a database needs its own schema, running on its own database instance, on its own server. Although this is a simple and understandable approach, it could be a recipe for chaos as each system reinvents the basics of data storage.
SYSOA also allows for the idea of "appliances" - generic IT capability that is shared between systems. The requirements of SYSOA can be met by a shared database server, in which each system has a separate schema. The schema and data is owned by the system, but the database instance and underlying operating system and hardware is managed as a standard service, which would help control the databases. Large, important or difficult systems can still have their own fully-optimised instances. SYSOA shows that this is not inconsistent, but a realistic response within a rigorous architectural framework.
SYSOA also allows for "database only" systems such as a data warehouse or a shared corporate database. However, it forces some discipline on these, the most important being clear ownership and defined interfaces. SYSOA gives clarity to the database owner resist "tactical" requirements that threaten to wreck the overall design, and to control what accesses are made to the database.
SYSOA's requirement for system independence discourages cross-system database access. The need for separation prohibits different systems to update the same rows on the database, or participate in shared transaction control.
However, SYSOA does allow for cross-database access under controlled conditions. There must be clear ownership of the data - one system serves the data, another is the client. There must be a defined interface - there are specific tables or views that are made public. And the client systems must be able to run if the serving system is not available.
SYSOA has a lot to offer data and database management. It discourages ill-disciplined shared data over which the IT organisation has no authority, but is still expected to sort out somehow. It enforces clear ownership of data, and careful controls on cross-database access. Where common databases are required, SYSOA gives the owners of the database clearer authority - it is not just a dumping ground for whatever projects dream up. SYSOA builds the case for meaningful business ownership of data, and strengthens the IT organisation's case for managing data effectively.
Initially, SYSOA may seem to undermine data and database management. But a closer look shows that the principles of SYSOA make the case for the clarity, ownership and authority required to manage data and databases effectively.