Definition of IT Architecture
IT Architecture is a relatively new profession. Although the first use of the word architecture in IT systems is unclear, the term was used in Fred Brook's 1975 book "The mythical man month".
Fred Brooks was the project leader for the project leading to the IBM mainframe System/360 and the accompanying operating system OS/370. These were large projects (5,000 man years) where having an overall architectural of the systems were key to their success.
But the term architecture in IT systems only became popular many years later. In the 1990's software architecture became more widely used. Patterns were described for solving common programming issues, and languages were developed to describe architectures on a high abstraction level.
In 2000 the ANSI/IEEE 1471-2000: Recommended Practice for Architecture Description of Software- Intensive Systems became the first formal standard in the area of software architecture.
IT architecture describes the fundamental design decisions of an IT system and their rationale, usually at the beginning of a project or program. These are the things that are very hard and/or expensive to change later on in the project. An example could be the decision to use commercial products in a solution instead of in- house developed software. Another example is using a specific vendor for infrastructure components (for instance always using Hewlett-Packard as a supplier for servers).
Many definitions of architecture exists, many of which can be found on the site of the Software Engineering Institute (SEI) of the Carnegie Mellon University. However, the most accepted and well-known definition of IT architecture is the ANSI/IEEE Std 1471-2000, ISO 42010 “Recommended Practice for Architectural Description of Software- Intensive Systems” (also known as the IEEE1471):
Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
This definition has several components that are elaborated below.
The architecture must be fundamental to the system or infrastructure. For instance, the choice to use only Cisco equipment for network components is a fundamental choice (which cannot be changed easily later on), while the choice to use a certain version of the Cisco IOS operating system is something that can be changed at a later time or can be decided upon later.
Architecture describes a system that consists of components with their relationships. In principle everything can be seen as a system. An IT server infrastructure is a system, created from servers (components) that interact. However, the servers themselves are systems too, built of CPUs (Central Processing Unit), memory, power supplies, etc. - the components - that interact to behave as one server. CPUs can also be considered a system, with multiple cores, an Arithmetic Logic Unit (ALU), pipelines, caches, and so on.
The relationships between components of a system can also stretch beyond the system’s border. Systems can interact with other systems, outside of the architectural span of the system itself. For instance, the IT infrastructure of an organization (the system) is connected to the Internet, of which the organization has no control and which is considered to be out of scope of the system’s architecture.
Since architecture only describes the foundations of a system, principles are used to guide the design and evolution of the system. Architecture principles are the fundemantal rules the system is built upon.
Architecture principles limit the design freedom for the system's components. A typical architecture principle for IT infrastructures could be to limit the use of operating systems for servers to Windows only. This makes the resulting architecture better manageable, but limits the freedom of choice of components built upon the infrastructure: software only available on Linux cannot be used.
After the design and implemenaton, an IT system is maintained by system managers for many years. The architecture must be maintained and guarded during the complete life cycle of the system. Normally in its life cycle changes are made; the system unsergoes an evolution - it is enhanced or new interfaces are introduced. When the architecture is not properly governed the system could evolve from its original architecture into a more diffuse and disorganized architecture. Over the years, the systems appears to "fall apart".
This entry was posted on Friday 01 February 2013