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.
© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 28 October 2008
Tuesday, 21 October 2008
System-oriented architecture principles
If we want our IT to consist only of strictly independent systems, what would our design principles be?
Last week I introduced the idea of a system-oriented architecture (SYSOA), in which the basic unit of IT is a strictly independent system.
To consider this further, we need some definitions and some principles.
First, definitions. IT is made up of three types of entity: systems, appliances and network.
The distinction between an appliance and a component of a system is subjective, and reflects its usage and how it is managed. If it supports only one system and is managed as part of that system, then it is a component of the system. If it supports many systems, or it is managed as a generic capability, then it is an appliance.
Although these principles may seem simple, they challenge commonly held views of IT. They do not support the view of IT as a library of reusable components, or the idea of IT as layered architecture. However, I think that these principles could achieve the same aims, but in a simpler and better-controlled way. Next week, I will cover how data management would need to change to conform to a system-oriented architecture.
© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Last week I introduced the idea of a system-oriented architecture (SYSOA), in which the basic unit of IT is a strictly independent system.
To consider this further, we need some definitions and some principles.
First, definitions. IT is made up of three types of entity: systems, appliances and network.
- A system is a purposeful and independent collection of application software, the system software and hardware on which it runs, and all the support services required for its operation.
- An appliance is a generic hardware and software capability that may provide a service to a system or systems, but which is not otherwise purposeful.
- The network is the means of communication between systems.
- Every system has a defined purpose, usage and owner.
- Every system is independent from all others. It can run independently from all others (though it may not be able to do useful work). It does not share data or runtime components with any others. It does not assume the state of data in any others.
- Every system is an instance of a system definition. Many system definitions have only one instance but, for example, a branch-based system is likely to be an instance of a common definition.
- There are no special relationships between systems. There is no special relationship between client and server systems, between instances of the same system definition, or between systems that co-operate to support a meaningful business activity. Systems can not be broken down into systems, and systems are not assembled from systems.
- Systems only communicate with each other through pairs of defined request-response messages.
- Every system has a physical existence. It is located somewhere, and it is clear where this system ends and the next system starts.
- Technical functionality can be defined as a system provided that it is a purposeful and independent piece of functionality.
The distinction between an appliance and a component of a system is subjective, and reflects its usage and how it is managed. If it supports only one system and is managed as part of that system, then it is a component of the system. If it supports many systems, or it is managed as a generic capability, then it is an appliance.
Although these principles may seem simple, they challenge commonly held views of IT. They do not support the view of IT as a library of reusable components, or the idea of IT as layered architecture. However, I think that these principles could achieve the same aims, but in a simpler and better-controlled way. Next week, I will cover how data management would need to change to conform to a system-oriented architecture.
© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 14 October 2008
System-oriented architecture (SYSOA)
Should we design IT so that every system is entirely independent of every other system?
I often write about the idea of thinking of IT as just a set of systems. (See Systems orientation: understand your IT and Systemhood.) The general idea is that we currently think of IT as a complex of processes, organisational structure and technology, but that we can simplify this by superimposing a view that divides IT into a set of notionally independent systems.
This system view has many benefits. It makes IT much easier to understand, especially to a non-technical audience. It provides a unifying principle that lets us bring together a lot of technology management under a single umbrella. It is the basis for easy and powerful IT improvement techniques like system quality management.
Mostly, I think of a system view as just that - a view superimposed on the reality of IT to give an effective handle for management. The real, physical stuff of IT - servers, networks, software, databases, support groups - is not really separated out so cleanly. But for the next few weeks, I want to explore what would happen if we did clearly separate each system through the entire IT stack. To give it a name, we could call this approach system-oriented architecture, or SYSOA (not to be confused with a service-oriented architecture, SOA).
In IT we are often apologetic about having independent systems within our architecture. The fashionable view is that independent systems should be broken down into a sea of reusable services. I want to explore the opposite direction, and consider what would happen if we used independent systems as the basic building block of the whole architecture.
I want to start next week by suggesting some principles for SYSOA. What is a system, and what isn't a system? How do we classify things like email services and PCs? What design rules do we need to ensure that systems are truly independent?
I then want to consider the application of SYSOA in four areas, which are architecturally the most challenging:
This is an exploration of an idea. This is not necessarily the right thing to do, but by considering it we can learn a lot about architecture and IT management. But I wouldn't completely dismiss the idea, either. Despite being unfashionable, I want to show that there is a lot of common-sense in a system-oriented architecture, and that, perhaps, it is something that we should take very seriously.
© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
I often write about the idea of thinking of IT as just a set of systems. (See Systems orientation: understand your IT and Systemhood.) The general idea is that we currently think of IT as a complex of processes, organisational structure and technology, but that we can simplify this by superimposing a view that divides IT into a set of notionally independent systems.
This system view has many benefits. It makes IT much easier to understand, especially to a non-technical audience. It provides a unifying principle that lets us bring together a lot of technology management under a single umbrella. It is the basis for easy and powerful IT improvement techniques like system quality management.
Mostly, I think of a system view as just that - a view superimposed on the reality of IT to give an effective handle for management. The real, physical stuff of IT - servers, networks, software, databases, support groups - is not really separated out so cleanly. But for the next few weeks, I want to explore what would happen if we did clearly separate each system through the entire IT stack. To give it a name, we could call this approach system-oriented architecture, or SYSOA (not to be confused with a service-oriented architecture, SOA).
In IT we are often apologetic about having independent systems within our architecture. The fashionable view is that independent systems should be broken down into a sea of reusable services. I want to explore the opposite direction, and consider what would happen if we used independent systems as the basic building block of the whole architecture.
I want to start next week by suggesting some principles for SYSOA. What is a system, and what isn't a system? How do we classify things like email services and PCs? What design rules do we need to ensure that systems are truly independent?
I then want to consider the application of SYSOA in four areas, which are architecturally the most challenging:
- Data management. Shared databases can be a valuable corporate assets, and yet they seriously undermine the separation of systems.
- Integration. Although strong system boundaries are critical to system integration, advanced middleware takes functionality out of systems and appears to break system boundary rules.
- User interfaces. Browsers and client/server systems are hard to classify.
- Infrastructure. To be cost-effective, infrastructure has to be shared between multiple systems, which undermines their separation.
This is an exploration of an idea. This is not necessarily the right thing to do, but by considering it we can learn a lot about architecture and IT management. But I wouldn't completely dismiss the idea, either. Despite being unfashionable, I want to show that there is a lot of common-sense in a system-oriented architecture, and that, perhaps, it is something that we should take very seriously.
© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 7 October 2008
Why you should use XSLT
The XML processing language XSLT is a powerful and flexible solution to many development needs.
In the development work we do at my company, I am surprised to find one programming language is taking an ever-increasing proportion of the work. And it isn't Java, it's XSLT.
XSLT is a specialised language for converting one data structure into another. Its inputs are always XML, but its output can be anything. It can be used for a wide variety of development work: for serving web pages; as a report writer; for integrating inside and between applications; for generating test data and data loads; and for generating code.
XSLT is useful, effective and flexible.
XSLT is useful because it deals with XML. XML is a very effective way of gathering a complicated collection of data into a single lump. It is used in a large and growing proportion of IT systems. It is fundamental to the web, to systems integration, and to reporting. It is used in big and small systems - from major enterprise systems down to the files used in office applications. Even things that don't use XML, like PDF, can be built using XML tools.
XSLT is effective because it understands XML. In other languages, you process XML by querying the data structure, like standing outside a shop and trying to pick what you want by poking through the windows with a big stick. XSLT understands the data structure it is working on, more like walking through the shop and picking up what you need from the shelves. It is fundamentally different from dealing with XML in a general-purpose language.
XSLT is also effective because it is based on functional programming and pattern matching. I do not fully grasp the underlying computer science, but what I find is that programs are much more specifications of what should be achieved, rather than detailed recipes for how they should work. When you start, XSLT can be daunting, but after a while it becomes easy, powerful and surprisingly error-free. A few lines of XSLT can replace hundreds of lines of code in another language.
XSLT is very flexible. It is standards-based and cross-platform. It is supported by plenty of free and commercial tools. It can be run from the command line, in a browser, on a server, or from inside another program. It is suitable for simple one-off scripts, right up to complicated enterprise-level processing. You can even plug in other functions to extend it beyond the standard.
There are some downsides. XML and the functional programming style can be difficult to get to grips with when you start. XSLT can be slow, though it is possible to compile it where performance is critical. Being a specialised language, XSLT isn't designed to meet every programming need, and you will always need to use it in conjunction with other languages.
XSLT should be part of the toolbox of every IT developer and every IT organisation. It you are not already using it, learn it (I recommend XSLT by Doug Tidwell, ISBN 0-596-00053-7). If you are like me, you will soon find that it is the right solution to an ever-growing proportion of your development needs.
© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
In the development work we do at my company, I am surprised to find one programming language is taking an ever-increasing proportion of the work. And it isn't Java, it's XSLT.
XSLT is a specialised language for converting one data structure into another. Its inputs are always XML, but its output can be anything. It can be used for a wide variety of development work: for serving web pages; as a report writer; for integrating inside and between applications; for generating test data and data loads; and for generating code.
XSLT is useful, effective and flexible.
XSLT is useful because it deals with XML. XML is a very effective way of gathering a complicated collection of data into a single lump. It is used in a large and growing proportion of IT systems. It is fundamental to the web, to systems integration, and to reporting. It is used in big and small systems - from major enterprise systems down to the files used in office applications. Even things that don't use XML, like PDF, can be built using XML tools.
XSLT is effective because it understands XML. In other languages, you process XML by querying the data structure, like standing outside a shop and trying to pick what you want by poking through the windows with a big stick. XSLT understands the data structure it is working on, more like walking through the shop and picking up what you need from the shelves. It is fundamentally different from dealing with XML in a general-purpose language.
XSLT is also effective because it is based on functional programming and pattern matching. I do not fully grasp the underlying computer science, but what I find is that programs are much more specifications of what should be achieved, rather than detailed recipes for how they should work. When you start, XSLT can be daunting, but after a while it becomes easy, powerful and surprisingly error-free. A few lines of XSLT can replace hundreds of lines of code in another language.
XSLT is very flexible. It is standards-based and cross-platform. It is supported by plenty of free and commercial tools. It can be run from the command line, in a browser, on a server, or from inside another program. It is suitable for simple one-off scripts, right up to complicated enterprise-level processing. You can even plug in other functions to extend it beyond the standard.
There are some downsides. XML and the functional programming style can be difficult to get to grips with when you start. XSLT can be slow, though it is possible to compile it where performance is critical. Being a specialised language, XSLT isn't designed to meet every programming need, and you will always need to use it in conjunction with other languages.
XSLT should be part of the toolbox of every IT developer and every IT organisation. It you are not already using it, learn it (I recommend XSLT by Doug Tidwell, ISBN 0-596-00053-7). If you are like me, you will soon find that it is the right solution to an ever-growing proportion of your development needs.
© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Subscribe to:
Posts (Atom)