The Role of Architectures in Modern IT
Dr Bernard Robertson-Dunn

The Role of Architectures in Modern IT
Contents
1.	Introduction	2
2.	Benefits of the Architectural Approach.	6
3.	The Architectural Approach	8
4.	Architectures and Models	11
5.	Architectural Principles	16
6.	Infrastructure	18
7.	The Role of Standards in Architectures	19
8.	Change and Migration	21
9.	Conclusion	23

This paper was first published by MIS in December 1994.

The Role of Architectures in Modern IT
1.	Introduction
What have butterflies got to do with Information Systems? Very little. What has the butterfly effect got to do with Information Systems? Everything.
The butterfly effect is where a very small disturbance at one location can multiply and spread to cause dramatic changes at another location. The effect is named after the hypothetical situation where the flap of a butterfly’s wings in Brazil might set off a tornado in Texas. The butterfly effect is often associated with chaos, which is a term used to describe complex systems whose behaviour is non-predictable under some specific conditions of operation.
The reason that the butterfly effect is of relevance to information systems is because the Business and Information Systems that many organisations are trying to build today are so complex that there are often very small issues that, if not addressed appropriately, could cause dramatic and catastrophic effects within the system or organisation.
There are many Business Process Re-engineering and IT projects that have failed to meet expectations or which have never been completed. A frequent reason for this failure is that issues that should have been addressed were not addressed. The reasons why they did not get addressed are many and various but the result is the same - failure.
A way of managing this problem is to fully explore, to an appropriate depth, all the issues that may impact the behaviour of the system. The “appropriate depth” is related to the degree of complexity of the system and to the familiarity that the developers have with the technology of the solution. A consequence of this approach is that many of the decisions that are made during this “whole of system” examination can be incorporated into Architectural Principles and an infrastructure. The infrastructure can encompass both the delivery platforms as well as the development environment and process. This way of managing the development of complex Business and Information Systems will be referred to as the Architectural Approach.
The Architectural Approach attempts to solve the problem of developing complex Business and Information Systems in such a way that the costs and risks are minimised and the benefits, effectiveness and efficiencies of the systems are maximised.

The Architectural Approach is based on four fundamental premises:
1.	Business Systems and Information Systems cannot be treated separately.
2.	It is better to identify and address the “whole of organisation” issues first and then develop individual systems within an overall framework of decisions, principles, guidelines and products.
3.	Architectural Principles and a comprehensive infrastructure are the mechanisms for encapsulating this framework
4.	Information and Information Systems are too important to be left to the IT Department
Traditionally, architectures are most often associated with buildings. However, there is a major difference between traditional architecture and System Architecture. Traditional architects know how to build a building, the technology is well understood and the steps are relatively well determined. In a modern Information System there is often a problem that stems from the fact that the system will be unique, not only in its operation but in its development and in its components. It may also be unique to the extent that new and unproven technology forms a fundamental part of the system.
Furthermore, architects rarely have to design a building that must meet changing user requirements that impact its fundamental structure. The changes in use of an IT system are analogous to changing the size of some or all of the rooms in the house (system enhancements) increasing the size of the house (scalability), moving the house from one block to another or building exactly the same house on different sized blocks (portability)
Even traditional architects can experience difficulties. The Sydney Opera House was a radically new style of building based on technologies that were not established or proven. The building of the Sydney Opera House has much in common with many of today’s Information Systems. It is claimed by many users of the facilities of the Opera House that they are too cramped and crowded and that it does not meet their requirements. However, it does look good from the outside and it enhances Sydney’s world-wide reputation.
Information Systems are an integral and vital part of many organisations. Even if an organisation is not primarily based on information, access to data regarding such things as orders, suppliers, schedules, payroll and finance, is critical to the smooth running of the business. Without access to their corporate data, many organisations could not survive. Some might not recover if they were denied access to their Information Systems for a few days, others might fail after hours or even minutes. This reliance on information means that the provision of robust, reliable, flexible systems needs to be properly planned, implemented and maintained.
In spite of the critical role that information systems play in these organisations, many business managers treat IT purely as a support service. What they do not realise is that their Information Systems are a critical and integral component of their business systems.
It may appear to be only a difference in terminology but to call critical information a resource, like finance, is to fail to understand the close coupling between business systems and information systems. It is rather like claiming that the blood in our bodies is just a vehicle for transporting oxygen to muscles and waste away from muscles. The circulatory system is an integral component of the human body, the body cannot exist without it and it cannot exist outside the body. This situation is the same with regard to information systems. The organisation would die without them and the systems could not exist without the organisation.
The point is that Business Systems and Information Systems should be seen as different perspectives of the same thing - the organisation as a whole. Business and Information Systems are the organisation whereas Information Technology just enables the systems. It is easy to concentrate on the technology. Many managers are now computer literate. Unfortunately they are not system literate. By focusing on the technology, that is, the delivery of the function, the purpose and reason for the function gets ignored. Under these circumstances, it is no wonder that an organisation does not get the systems that it needs, just what it deserves.
There is a need for wide ranging planning that encompasses both Business and Information System issues. Information Technology has become far more complex, it has been segmented to the extent that there is no single point of responsibility for the whole system, the same information must be used in different ways and by different parts of the organisation. Client Server and other forms of distributed computing technology require considerably more planning, control and administration than that required by the traditional mainframe. There has always been a need for planning, now it is much more critical and must address the organisation to a broader and deeper extent.
There is a difference between centralised planning and centralised control. Planning does not require or imply centralised control, rather it means establishing and adopting a consistent method in order to improve the benefits from a particular system. The Architectural Approach is one of centralised principles and infrastructure within which individual systems can work consistently and co‑operatively.
Centralised planning is not new. In the middle ages communications across countries and continents was difficult and involved considerable delays. The Roman Catholic Church had the problem of how to ensure that all the many churches spread throughout Europe adopted the same practices and presented a consistent message to its congregations. The way the Church solved the problem was to take members of the local church hierarchy to Rome where they would be educated in the ways and teaching of the Roman Catholic Church. They were then returned to their local church where they administered, taught and made decisions in ways that were consistent with the Church’s requirements. The Church had achieved centralised thinking and planning without centralised control.
The big gulf today does not stem from any difficulty with communications but from the way organisations devolve business responsibility and autonomy. Centralised control of Information Technology and Systems is out of favour. However the need for consistency, standardisation and economies of scale remain. The Architectural Approach provides a method by which centralised thinking and planning can be applied to those areas where it is required and the responsibility for individual systems can remain with the appropriate organisational unit.
Many of today’s systems have evolved by stealth. Without planning, the organisation finds itself with many LAN’s, each with a different configuration, with personal computers that are capable of running office automation but not corporate transaction systems, They may be too slow or of too limited a capacity to permit the IT department to implement enterprise systems. What choice does the organisation have - replace its existing systems? retrain its users? develop parallel systems? Whatever it does is has wasted time and money.
The design and implementation of complex business systems is an important aspect of business development involving both technology specialists and those responsible for the business. Information systems have become more complex, there are more choices to be made and the business needs to be more responsible for its own systems to a greater degree than in the past.
In this paper the term Architectural Approach will be used to describe the way that all aspects of system development can be addressed to reduce the risks and maximise the benefits that an organisation can get from its business and IT systems.
It should be pointed out that “Architectural Approach” is not a widely accepted term that describes this process. In fact there is no term that would be recognised by the IT community as describing an overall view of system development.
The Architectural Approach is one that makes sure that all relevant issues are dealt with at the appropriate time. It is one of resolving conflicting aspects at an appropriate time within the development process. It is best considered as a particular form of planning. However, it is more than what is traditionally thought of as IT planning. Planning has always been necessary, what has changed is the focus. IT strategic plans used to revolve around the technology. Now it needs to concentrate on the needs, the infrastructure and flexibility. If you do not plan for flexibility you get lock-in.
The technology available today is very seductive - so are the marketing messages. It all comes down to trust. Who do you trust? The market research gurus? Consultants? The vendor’s sales staff? Your own IT department or business managers? You have got to trust someone, just make sure it is the one who can substantiate their claims with evidence. Architectures are about evidence, knowledge and understanding followed by decisions and commitment.
2.	
Benefits of the Architectural Approach.
There are a number of characteristics of modern Information Systems that indicate that an Architectural Approach to their development is not only necessary but essential. These include:
1.	The critical nature of Information Systems to the survival of the organisation
2.	The widespread use of Information Systems across the organisation and the need for their integration.
3.	The business risks associated with many of the aspects of Information System development and implementation. These include the way in which an organisation may be critically dependant on particular vendors or technologies, the availability of development and maintenance skills in the market place and the integrity and security of corporate data.
4.	The complex nature of modern Information Technology, especially the introduction of distributed systems. Distribution can occur both physically and conceptually in that the data may be the responsibility of one group and the business rules the responsibility of another or even of several other groups.
5.	The requirement in many organisations for users to be more involved in the development of their own areas of the corporate Information Systems
6.	The need for old and new technologies and systems to co-exist and migrate over time.
Some of the benefits of using the Architectural Approach are:
Alignment of business needs and IT: By treating Business and Information Systems as aspects of a single system, the problem of alignment is greatly reduced.
Visibility of Organisational Values and Priorities: The development of Architectural Principles acts as a communications aid both horizontally and vertically within the organisation. Architectural Principles act as a guide to the designers and developers of systems so that the broader aims and goals of the organisation are reflected in the construction of the systems. They also convey to the business managers the problems and constraints of the IT development and delivery processes.
Infrastructure Many of the standards that an organisation wishes to adopt can be incorporated within the organisation’s infrastructure. By developing a comprehensive and consistent set of enabling technologies, individual systems can more easily achieve the required degree of flexibility, connectivity and interoperability.
Integration of IT systems: Client Server and other forms of distributed systems require a significant amount of planning. The Architectural Approach provides a structured way of addressing the issues of integration as well as providing a vehicle for achieving the required integration.
Flexibility of Systems Flexibility is not something that can be added to a system once it has been built. It is relatively easy to build a system with a single, fixed purpose. Taking a more general view of the use of the system and building in the flexibility from the start takes a considerable degree of skill, experience and knowledge. The Architectural Approach provides a structured method by which this can more easily be achieved.
Scalability of Systems Many systems have failed because what looked like a very useful prototype or personal productivity tool has been implemented across an organisation. The problems of maintenance, administration, security, backup etc. can grow explosively when a system is adopted by many users. Unless these issues are addressed at the in the design then they can quite easily turn a project into a potential point of failure for the organisation.
Ownership of Architectures By taking an Architectural Approach, an organisation makes a clear commitment to its individual architectures. The implicit and uncoordinated architectures that may exist within an organisation are identified and any inconsistencies or missing segments can be identified and addressed.
Risk Management By taking the approach of examining the whole system to an appropriate level of detail, the risks associated with the technology and implemented systems can be more easily assessed and managed. Architectural Principles regarding risk can be developed and adopted so that system developers can recognise and manage the exposures.
Appropriate Decision Making Processes The process of gathering information and analysing all the various requirements and options should lead to a better engineered system. All the major system decisions should be based on valid and well researched needs and benefits appropriately balanced against cost and risk.
3.	
The Architectural Approach
Architectural work in the domain of Business and Information Systems has often been likened to traditional architectural. J A Zackman of IBM has published a number of papers where he describes Information Systems architecture in terms of the construction of buildings. This type of architectural work may be appropriate when addressing issues relevant to the development of certain types of IT system, however it is not a good metaphor when applied to enterprise wide Information Systems or modern, dynamic, flexible distributed systems. This is because the construction of enterprise wide systems differs from that of a building in the several ways including:
1.	A building is a single object which exists within the wider context of a town plan, surrounded by many forms of infrastructure such as roads, water and sewerage systems, electricity, phone, gas, transport, education and health systems. The development of modern IT systems includes the infrastructure. Traditional architecture focuses on the needs of the single building.
2.	A building is a relatively static object whereas Information Systems are often required to migrate and evolve, run on different platforms and interact with other systems (the often stated benefits of Open Systems - scalability, portability, connectivity and interoperability)
3.	A building usually has one owner or type of owner with a single set of requirements. Information Systems have many owners and the requirements cover various viewpoints such as security, administration, different business users (e.g. transaction users and decision support users)
In its broadest sense, the Architectural Approach is one of breadth not depth first and that it is best to consider whole of organisation or whole of system issues together before anything is developed.
One of the conflicts that must be resolved is that of requirements against constraints. The business requirements must be balanced against the constraints and capabilities of the technology. If the balance is not achieved then either the technology will fail to deliver the required functionality or the business may be at a disadvantage compared with competitors who make better use of technology.

The Architectural Approach is based on four fundamental premises:
1.	Business Systems and Information Systems cannot be treated separately.
It is a fallacy to believe that Business Systems can be re-engineered in isolation of the Information Systems that deliver the required functionality. Business Systems are critically dependant on information. Information Systems manage information but they do more than just manage. They also automate many of the business processes. The human procedures and the automated processes must work together in a mutually co-operative manner if the complete processes are to be any where near optimal.
Reportedly, one reason for many of the failures of Business Process Re-Engineering is because the scope was wide enough. New processes were engineered but the technology to deliver them was not available or would take too long to develop In other cases, processes were re-engineered within the constraints of old technology, whereas the competition used modern technology to drastically improve their processes.
Much of the drive for Business Process Re-engineering and better alignment of IT and the Business has come out of the IT department. For years, the IT department has been accused of letting IT drive the business. There is a simple reason for that. Business managers do not understand IT. Therefore IT people have had to try and understand the business in order to develop appropriate systems. It is not surprising that many Information Systems have failed to meet requirements - no-one could tell the developers what the requirements were and the guesses were wrong.
The result? IT gets a bad name and the business continues to complain about the lack of good Information Systems.
The Architectural Approach addresses this problem by intimately involving both parties to the system - the business and the IT department.
2.	It is better to identify and address the “whole of organisation” issues first and then develop individual systems within an overall framework
Complex enterprise wide systems have many inter-relationships both vertically (e.g. lower level components such as the communications network and operating systems impact the applications) and horizontally (e.g. multiple applications needing to interoperate). The only way by which these relationships can be identified and managed properly is by a thorough analysis of the environment and the requirements. The cost of resolving conflicts and fixing problems is orders of magnitude less expensive at the initial planning stage than when purchasing decisions have been made, programs have been written and implementation is under way.
Many business managers seem to believe that developing complex Information Systems is simply a matter of identifying user requirements, purchasing technology and writing code. This simplistic view is dangerous in the extreme, both for the organisation and the Information System developers. These managers, being unaware of the real problem - their lack of understanding, are unable to solve it. In fact, they make the problem far worse because the additional constraints they impose on the development process can make a solution impossible.
Unfortunately this seems to be a global problem. There are software engineering newsgroups on the Internet where professional software developers figuratively tear their hair out with frustration because of the no-win situations they find themselves in. They either attempt an impossible job, or they do not have a job. The most common complaint concerns user requirements - they are either incomplete or they keep changing during system development. The Architectural Approach identifies all the major issues up-front and forces decision making at the appropriate time. This results in a progression of granularity - big, wide reaching decisions first, details later.
3.	Architectural Principles and Infrastructure are the mechanisms for encapsulating this framework.
The development of Architectural Principles requires a broad understanding of important issues, agreement as to the appropriate decisions and commitment to those decisions.
The infrastructure that an organisation puts in place should reflect those Architectural Principles. Furthermore, it should be possible to identify each component within the infrastructure with at least one Architectural Principle.
The process of developing Architectural Principles should guarantee the participation and co-operation of business management and Information Systems developers. Each side has the opportunity to learn about the other side’s concerns, priorities and major issues and to contribute in a meaningful manner towards the growth and development of the organisation through its core systems.
If the development of Architectural Principles fails then this should be an indication of some basic management flaws within the organisation. The only option then is for senior executives to address the problem at a management level. If the problems do not get resolved then the Information System developers may as well start looking for jobs in organisations which at least give them a fighting chance of success, they certainly do not have any where they are.
4.	Information and Information Systems are too important to be left to the IT Department
Information is the life blood of an organisation. Information Systems are a necessary but not sufficient component of an organisation’s structure. Chief Executives and other senior managers are not equipped to make critical design or procurement decisions regarding their Information Systems, nor should they. Information Systems developers are not equipped to make decisions on behalf of the whole organisations, neither to they have the responsibility.
The System Architects, by having a foot in both camps, act as translators and interpreters for each side. They, on their own, make very few decisions; rather they educate, facilitate, document and enforce. The enforcement of the Architectural Principles and the various architectures is essential for the success of the systems. The IT department, without guidance from the remainder of the organisation will make its own decisions, to the best of its ability. They have been doing this for years and have suffered the consequences - and so has the organisation.
The power of modern technology and the systems that can be built utilising that technology is a two edged sword. The power can be used for success or it can destroy an organisation. The concentration of business rules into a few places can be an advantage in that a rule can be easily changed. If it is an incorrect or invalid rule, then the impact of that rule may be felt throughout the whole organisation, maybe within seconds, potentially leading to a major disruption to the organisation when it discovers the error and tries to recover.
In the days of manual procedures with supporting technology, if a worker had a bad day or was unable to attend the workplace, the impact was local and contained. Today, when the balance has changed so that the worker tends to support the technology, an incorrectly configured piece of that technology can affect the whole business.
The dependence of an organisation on its technology is probably not fully recognised by senior management. They might have a gut feeling that if they lost their computers, life would be very difficult, but they tend to be unaware of the really critical dependencies. These are things like components of their systems that can only be maintained by a single programmer who may fall under a bus or retire. An other example is the dependency on old technology which cannot be replaced or upgraded because the vendor is no longer in business.
The Architectural Approach is very much a case of developing a complete understanding of an organisation and its systems through analysis and synthesis. This understanding is facilitated through the development of architectures and models.
4.	Architectures and Models
Question - Why is the human brain so much better than the computer on your desk? Answer - because the performance and behaviour of a system is determined more by the relationships between the components than the components itself. The components of the brain, neurones, have a response time measured in tens of milliseconds. The components of a computer have response times measured in microseconds, thousands of times faster than the human brain. It is the structure, or architecture, of the human brain that enables humans to perform amazing feats of pattern recognition and creativity of which computer systems are totally incapable.
Architectures are of crucial importance in distributed, open computing systems. In the same way that the structure of the human brain is vital to its performance, it is the organisation of distributed systems that largely determine their operational characteristics. In some respects, the distributed systems that are possible today are both an advantage and a disadvantage. About ten years ago, just before the personal computer began to be utilised by business organisations, the Information Technology industry had come to terms with the issues related to the design and implementation of major, complex on‑line applications. The realisation that the structure of the data changes slowly but the requirements of processes change rapidly led to the separation of information from process. Applications were built within a purchased environment consisting of compilers, operating systems, development tools, on‑line transaction processing monitors, and database management tools, etc. running on a centralised hardware platform. To develop its applications, an organisation could source everything that it needed from a single vendor. The organisation made use of the implied architectures that came with the products and services it bought.
Today, large organisations are demanding more complex information systems which are being implemented on multiple hardware platforms from different vendors. These systems are running a distributed infrastructure across multiple operating systems. At the same time, many of these organisations are looking for independence from any particular vendor's proprietary product set and are demanding adherence and compliance with Open Systems standards. One consequence of these trends is that organisations are having to take responsibility for their own architectures. Unfortunately, it is not always realised by senior managers, both IT and business, what a key part architectures play in the specification and delivery of business systems.
Architectures
An architecture is a way of establishing relationships between similar conceptual components. It can identify components and show the structural relationships between them.
The terms architecture, model and design are sometimes used interchangeably. In this document they will be used in the following manner:
An architecture is a set of documents that describes the structure and relationships between various specific components of a complete system.
An architecture is developed by modelling various aspects of the organisation and its systems. The output of a modelling exercise is one or more models which contribute to the appropriate architecture.
An architecture contains models but it may also contain other things such as migration plans, product selections, cost benefit analyses etc.
The term architecture is usually used in the conceptual and logical stages of system development. The term “design” tends to be used when the physical aspects of the systems are being addressed. A program or a database may have a design but the general principles of architecture i.e. structure and relationship still apply.
System Architecture
In this paper the term System Architecture is used to describe the architecture of the total system. A System Architecture is made up of a set of sub-architectures and other documents, each focusing on a particular view of the overall system. The set of architectures that are presented in this section are not intended to be definitive. Each organisation needs to examine its need for architectures, its capacity to support the Architectural Approach and its relationships with vendors and suppliers of Information Technology.
The following diagram shows the components of a System Architecture.

Business Model
The Business Model describes the major operations that are performed by the organisation in support of its business functions. The Business Model identifies the Business Processes that the organisation needs to perform in order to achieve its business goals and objectives. It then relates the Business processes to the organisational structure.
The Business Model defines groups of workers in terms of the type of work they perform, their relationships with each other and their locations.
In broad terms, the business model must cover the full extent of the system that is being automated.
Application Architecture
This is a catalogue of the business functions that can be supported by automated processes. It describes the connections, relationships and dependencies between the processes.
It will also include a catalogue and assessment of existing application, their importance to the organisation and any issues regarding their maintenance or enhancements.
Data Architecture
This is a model of the information used by the organisation and the relationships between logical groupings of information. This model should include all forms of information, not only that which may be stored in automated systems. The relationships between the various major information subjects should be identified as well as the major processes that transform the information.
Technology Architecture
This is a description of the delivery mechanisms by which the application and information architectures, when suitably implemented, will be delivered. It may also include the development environment which is required to implement the business systems.
There are many issues that can seem to be solely the responsibility of the IT department but which can have a dramatic impact on the business, especially if the wrong decision has been made. An example of this is the method by which an organisation develops client/server applications. An organisation may decide that it wishes to integrate its existing mainframe systems but also make use of the presentation facilities available on personal desktop machines. If the IT department elects to implement a two tier technology then that will restrict the partitioning of the application to two layers.
This decision can have a major impact on the subsequent development of the business systems. This configuration can lead to a problem of achieving data and transaction integrity across the two platforms. This can mean that either very little functionality is put on to the desktop machine or that the system displays a lack of reliability and robustness. Furthermore, the choice of two platforms, each with their own development environment can lead to major problems of consistency and application development team management.
Business functionality may result in being distributed across different delivery platforms, development environments and application developers. When the business decides that it wishes to change functionality, or the need to relocate the functionality becomes apparent, the IT department will not be able to react very quickly, possibly drastically disadvantaging the organisation.
It is highly unlikely that business managers would have been involved in a comprehensive decision making process to select the most appropriate technology architecture or development environment. What usually happens is that someone makes a gut feeling decision based on a superficial examination of technical issues. Asking the business is too difficult as they do not have the technical background that enables them to contribute significantly. The business managers are not able to establish the consequences of the technical decisions and so product or architectural selections are made based on limited information.
The technology often receives the most attention from business managers because they can see it, touch it and have a limited knowledge of technology based on personal use. However, the decisions to select technology is often not based on sound, comprehensive business reasons, balanced with the requirements of the system or the IT department.
Business Issues
As outlined in the previous section, business issues should be included in the development of architectures, especially those which could involve major risk, cost and dependencies.
Business related issues include such issues as:
1.	Risk, cost, benefit, of the system
2.	Capacity of the organisation to accept, implement and manage change
3.	Vendor relationships,
4.	The need and costs of standardisation
5.	The methods of establishment of standards
6.	IT responsibilities
7.	Architectural Responsibilities
8.	Development and maintenance Skills
It must also address such human issues as staff skill requirements, training, industrial relations, implementation strategies, workloads, and it might even extend to the importance of ergonomics and health.
The Architectural Principles and Infrastructure components are covered in the following sections
5.	Architectural Principles
In an article in the Harvard Business Review in March 1989, “How Executives can Shape their Company’s Information Systems”, Thomas Davenport, Michael Hammer and Tauno Metsisto reported how they had studied more than 50 large organisations. They discovered that a few companies were using their technology more effectively than most. The more successful companies had expressed their basic philosophies about IT through a set of management principles. These principles are simple, direct statements of an organisation’s basic beliefs about how it wants to use IT.
In the Harvard Business Review article, this “principles” approach to IT development focused on the requirements of IT and it was recommended that the head of information systems drive the process whereby senior managers in the company would become involved in formulating the basic principles.
Architectural Principles are very similar to the IT management principles described in the Harvard Business Review article but their role is expanded and they should be owned by the business rather than the IT department.
It is essential that Architectural Principles cover more than just IT. They should encompass the basic business processes and systems as well as other issues such as the relative priorities of business management such as risks, vendor relationships, personnel management and empowerment (or otherwise).
A framework of business principles can act as an excellent vehicle for management communication and decision ,making. It also forces managers to think in broader terms than day-to-day survival as well as identifying and clarifying implicit any contradictions in management philosophy or goals. The development of Architectural Principles is not a simple statement of desires. It is a process of communication and compromise between two different parts of the organisation each trying to achieve its own set of goals. Often these goals can be in conflict. It is essential that this conflict be resolved in a manner that is appropriate for the whole organisation, not either part of the organisation.

The hallmark of a good Architectural Principle is that it makes a selection from a range of viable alternatives. A statement such as “Corporate Information is an Asset” has little value in terms of a decision. The alternative, “Corporate Information is not an Asset” is not really a option. However a statement like “the organisation will permit each operating division to select the Information Technology that best suits its business needs” is a valid principle. There are a number of alternative, equally valid statements that could define the way in which the organisation might allocate responsibility for Information Technology.
The golden rule when formulating Architectural Principles is that the reverse of a principle must make as much sense as the principle itself.
Architectural Principles can be grouped into various areas. The responsibility for each group of principles can be allocated to an appropriate senior manager. What is equally important however, is that the set of Architectural Principles be self consistent. It is no good having a business Architectural Principle that states “we will not be critically dependent on any single vendor” as well as an IT Architectural Principle that states “we will adopt the XYZ development methodology and toolset. The resolution of this conflict falls squarely in the domain of the Architectural Approach. It is also essential that such conflicts are both known and resolved openly before any subsequent decisions are made and which could have unfortunate side effects.
6.	
Infrastructure
Most organisations wish to acquire Information Systems that will deliver them a competitive business advantage. This will be reflected in style and nature of their applications. If they could go out to the market place and purchase a unique set of solutions that met their specific needs then that is what they would probably do. However, as this is usually (though not always) the case most will purchase or develop a set of applications and customise them to a greater or lesser extent. These organisations are prepared to employ business analysts who are able to translate business requirements into information systems. What they would prefer not to do is to employ Information Technology specialists to develop technology with no direct business benefit. The business risks associated with an organisation developing technology that will support business analysts is considerable. These risks include factors such as the need for special development skills, building components lacking in robustness or which are inferior to commercial products, the maintenance skills required to support the components etc.
There is a major difference between integrating a set of commercially supported system products into an infrastructure and an organisation developing such system products for itself. Most commercial organisations would accept the first option and should be very wary of attempting the second.
One of the main physical manifestations of the Architectural Approach is the creation of a robust, widespread, useful infrastructure. This can make system development and migration look deceptively simple - mainly because a lack of problems. The best way to overcome a difficulty or solve a problem is to avoid it in the first place.
As anyone who has worked for a well run business of any kind knows, everything seems so simple. Simplicity is an illusion. Simple things hide complexity, they do not remove it. It takes a major intellectual effort to predict and address problems before they occur. Because there is a lack of problems, those who do not see or understand what has really happened often arrive at the wrong conclusions. They do not appreciate the value of the up-front planning and the co-ordinated decision making process that has preceded the apparently simple results.
This effect is common in the IT business where the business managers do not have the experience or knowledge to realise the nature or the extent of the planning activities that need to be undertaken. In the days of proprietary architectures, IT development was deceptively simple. It was not easy even in those days but it was relatively straightforward. Today it is much harder but many managers, including some IT managers, do not fully understand the way the responsibility for architecture has shifted from the vendor to the user.
7.	
The Role of Standards in Architectures
Why standards?
Standards play a major part in the Architectural Approach. There are two types of standards, technology and other business standards.
Technology Standards: - i.e. those technical standards upon which guide the organisation in its selection of products. These may or may not be Open Systems standards but they do apply to the technology. In the past, vendors sold proprietary systems where the architectures which underpinned the technology were the property of the vendor. Today an organisation purchasing technology is more likely to ask for Open Systems which, utilise vendor independent architectures that are based on standards, both formal and informal.
The IT industry is adopting standard architectures, designs, interfaces and protocols because it makes excellent sense from a manufacturing and development perspective. As in all aspects of engineering, standards are defined and adopted when they bring benefit to the design and construction activities. They represent an acceptance that, within a particular product domain, the innovation phase at the interfaces has largely ceased and that the maturation phase has commenced. Innovation within the domain may continue within a known and agreed interface framework.
The availability of industry and international standards within certain domains means that the relationships between products has been defined and agreed. Vendors can now concentrate on construction in the knowledge that their products will work with other vendor’s products.
Vendors that do not adopt industry and international standards will find it harder to participate in the high volume market place than those that do. All major vendors have adopted, and will continue to adopt, industry and international standards where they bring benefit to both the vendor and the customer.
The push to Open Systems has meant that there are specified boundaries and interfaces between agreed layers and modules within an overall design framework. This leads on to the other benefits which are associated with Open Systems, those of interoperability, portability and scalability. These benefits are the result of common architectures, not the reason for them.
Architectures are not new. Information Technology product developers (e.g. hardware platforms, operating systems, application packages, infrastructure components such as DBMSs, compilers etc.) and large scale application developers have long understood the need for architectures when dealing with complex systems.
Information Technology product developers realise that, by grouping functionality into layers or modules, they can deal with each separately. They achieve this by providing interfaces which conform to agreed standards so that the layers and modules can happily co‑exist. This concept of layering and grouping is the main thrust behind such concepts as Open Systems, distributed computing, and Object Oriented Technologies.
However, the specification of layers and modules does not solve all the problems of dealing with complexity. It separates them into two types; what goes on inside a module or layer and what goes on between the modules or layers. The interactions and relationships between the modules and layers is where architectures come in.
Business and other standards which the organisation develops for its own use. An organisation may have many other standards which it wishes to adopt. These can include standard methodologies, standard or preferred vendors, standard letters or memos as well as standard procedures for conducting various business functions. Information Technology can both assist and hinder an organisations attempt to achieve standardisation. It is possible to incorporate standard business practices and rules into information systems so that their enforcement is guaranteed. Unfortunately this might also make changing the same business practices and rules very difficult, especially when the conditions under which they need to be applied may vary in ways that were not foreseen when the system was originally designed.
The problems associated with setting standards
Selecting between available standards, while not being easy, is not as difficult as setting standards. It takes a lot longer and requires more effort and a different skill set to establish and maintain useful and robust standards.
It takes a higher level of competence to fix a problem than to create it. How many non-IT organisations have the skill set, the will or the commitment to set complex IT standards? Even if they do, then the question may be fairly put - why? The answer may be that it gives them a competitive advantage, on the other hand it may not.
The downside of standards
There can be a certain robustness and strength in diversity. If there are a number of available different products, methods, services etc. and one fails there are alternatives available. Business flexibility can be enhanced by having a range of tools ready to meet a market need or change in business conditions. Standardising can remove this diversity to the detriment of the effectiveness of the organisation in times of change.
Setting standards can be likened to putting all your eggs in one basket. Some large corporations prevent more than a few senior executives from flying in the same plane in case of accidents. It would be interesting to learn if they have a similar concern about some of the IT decisions that have been made by more junior staff which could have a far more dramatic impact if the worst case should happen.
An organisation needs to take great care when setting standards of any type. They can be of significant benefit but they can also increase business risk and be an impediment to flexibility and change.
8.	
Change and Migration
The one issue that will affect all aspects of a business is change. Change can be accommodated in two ways tactically or strategically. The tactical method is based on immediate, short term decisions. The strategic method is based on planning and long term decisions and is where the Architectural Approach fits in.
The aim of the Architectural Approach is to address those issue that will impact all aspects of the business’ systems. Addressing change therefore is a major goal.
There are four things you need to know when you are planning change. Where you are now, where you want to be, migration, i.e. when and how are you going to get there and lastly, why you want to be there. These can be illustrated in the following diagram:

Current Model
This is an as-is view of the organisation, its systems and technology. Included in this view should be a complete description of all the various aspects of the current systems. It is essential that an organisation knows where it is starting from before it undergoes any significant change. It is very easy to focus on specific shortcomings associated with a system and attempt to correct those shortcomings without paying due regard to all the issues. It is rather like planning a holiday on a fixed budget. If you spend too much on the travel and holiday arrangements you may not have enough to spend once you get there.
This phase requires a comprehensive analysis of the current situation so that any changes that are considered can be measured against a base line understanding.
Future Model
This is where the organisation, its systems and technology should be or need to be. The future model should include new descriptions of all the items in the current model. If, by comparing the current model with the new model, it becomes apparent that there is no one-to-one correspondence which cannot be adequately explained, then there may well be a butterfly wing waiting to beat and cause unforeseen damage at a later stage in the development processes.
Both the Current and Future Models consist of architectures and other models. They are each particular perspectives of the same organisation, separated by time, effort and commitment.
Why
It is essential that the reasons for change are visible and agreed. It is very easy for business managers to make implicit Information System decisions because they confuse the “why” for the “how” or “what”. The many failed attempts to adopt client/server currently being reported in the media illustrate this confusion. Deciding that current applications and technology are no longer meeting requirements is a valid decision for a business manger to make. What is not, is deciding that a specific technology, user interface, product or design methodology should be adopted. These are all part of the “how” and “what”
The “why” should include the goals and objectives of the organisation. . These should be used in the migration phase to determine the weaknesses of the current environment in meeting the present business requirements.
Migration
This is the method by which the organisation will migrate from its current situation to the future model. It also encompasses the timeframe in which it will achieve the new model.
The development of the future model and the migration cannot be done in isolation. It is usually an iterative process, although often one issue may take precedence over others. Business issues such as government regulations or competitive drivers may require that the future model must be achieved within a certain time. In this case the cost of achieving the change will be correspondingly higher. On the other hand, minimising the cost of change may be the highest priority.
9.	
Conclusion
The Architectural Approach is very simple. If you wish to do several things, think about those issues that will impact all of them, make appropriate decisions and then do each separately within the knowledge, understanding that has been gained and the lessons that have been learned.
There are so many inter-related issues in today’s Business and Information Systems and the Systems are so critical to many organisations that planning is an essential activity. Vaguely specifying Open Systems in the vain hope that all the benefits of portability, scalability and interoperability will magically come flooding out of the PC on your desk is akin to life membership of the flat earth society - a little short on reality.
It has been reported recently in the media that many attempts at Business Process Re‑engineering have been somewhat less than successful. It is most likely that the reason is because the organisation did not consider all the aspects of the changes they were attempting. In any balancing act, progress can only be made by paying attention to both sides of the axis. It is the role of the architect to facilitate that balance. Good balance looks effortless and, to the uninitiated, the effort required to achieve it appears minimal. Like many things in life this is deceptive. Certainly, doing the right things in the right order can give the impression of simplicity.
It takes effort, commitment, trust and understanding to create modern business systems. The complexity of systems and the number of choices available to user organisations has dramatically increased especially with Open Systems and Client Server computing. Trusting to luck is not an option. Neither is letting the wrong people make the wrong decisions and then expecting the system developers to perform magic and make it work. This approach did not work in the past, it will work even less now.
The Architectural Approach is essential if an organisation wishes to maximise its return on its IT investment. If an organisation cannot afford to develop a System Architecture then it cannot afford to take the risk of building the system. There are only a few ways of developing a system successfully, there are many ways of failing. Without the understanding which is achieved by developing a System Architecture it is highly probable that the organisation will discover one of the many ways of failing.

References
Chaos,
Making a new science.
James Gleick
Paradigm Shift
The New Promise of Information Technology
Don Tapscott, Art Caston
How Executives can Shape their Company’s Information Systems
Harvard Business Review March-April 1989
Thomas H Davenport, Michael Hammer, Tauno J. Metsisto
A framework for Information Systems Architecture,
IBM Systems Journal, Vol 26, No 3, 1987 
J. A. Zackman.