IT Architecture
Abstract
This document seeks to provide a clear and consistent definition of IT architecture as well as providing a consistent framework from within which to continue the discussion. There is currently quite a bit of noise within IT regarding architecture; however in the author's experience, the discussion is a difficult one due to the wide range of views and assumptions that limit the value of these discussions. This document seeks to eliminate this ambiguity and enable a more productive conversation regarding IT architecture and its role within the enterprise.
Table of Contents
“Architecture” has become the buzz word of the new millennium; however, there is a great deal of confusion, even within IT organizations as to what is “architecture”. This document will define one perspective on what architecture is and how the architecture roles should be leveraged within the organization to help ensure the success of IT.
The role of the architect seems to be a recent development within IT organizations. Why has this role developed? The obvious answer is that the complexity of solutions that are being developed has increased as IT has matured. This has naturally forced IT to demand more and more specialized roles as the complexity has increased. The role of the architect has developed out of a need to manage systems and solutions with greater and greater complexity.
The complexity within IT has increased as a result of the types of solutions that are being demanded by the business that they support, as well as the need for increased integration of systems. Additionally, the integration of IT into most every facet of business is increasing the complexity of IT systems.
The role of the architect has only become a requirement as these systems have increased in complexity and the role of the architect is to manage the most abstract portions of these projects. The architect works at the highest levels of abstraction in order to help simplify these complex solutions into manageable quanta of functionality that can then be logically developed by the designers and eventually the implementers.
When IT systems consisted mostly of a single computing platform (as a single Mainframe, for instance), the complexity of developing any solution was a function of the complexity of the functionality and the complexity of the source code that was developed on the platform. Additionally, most of these systems were developed in functional silos that provided hard boundaries that were never crossed.
Within the types of systems that were developed, it was important to have a database architect to develop data models and ensure the performance of the underlying data systems. It was also often important to have a software designer (at this point, usually not called a software architect) to manage the complexity of the software being developed; however, often this roles was left to the developer.
The role of the architect was mostly not required for these types of systems, mostly due to specific factors that limited the complexity of the solution, such as the lack of distributed systems, systems were largely monolithic and required little to no integration. Each system could be developed in a “vacuum”.
IT systems began to increase in complexity, as they started to “sprawl”. With the introduction of the midrange systems and eventually PCs, the complexity of the technology began to increase, mostly due to the need to distribute functionality across more than a single computing resource. Additionally, with the introduction of the PC, the number of users of IT solutions increased. Additionally, the creation of LANs and eventually WANs, greatly increased the complexity of the systems that needed to be developed.
Also during this time, IT systems began to mature so that integration between the sales and accounting systems began to become more visible. Traditionally, this information exchange was manual, requiring a user to copy the information, at the worst case. At the best case, the information was extracted and loaded from system to system on a scheduled basis, such as a nightly batch process. These were successful, when IT systems were not required to be available 24X7 (mostly because most business were not global organizations, or if they were global, each region maintained their own IT systems)
Today, IT is moving quickly to a model where there is a single data store for the entire enterprise and multiple systems interact through this common data store. Additionally, systems can no longer operate in silos as they have done traditionally. Also, the distributed nature of the applications has significantly increased. This has given rise to the need to have a single computing system across the globe. Also, the capabilities of networking has significantly increased, thus allowing for greater and larger distribution of processing and data.
This complexity in the evolution of IT within the enterprise is giving rise to a need to manage this complexity. No longer can a developer or a software designer manage the complexity of an entire solution or computing system. Additionally, the DBA can no longer be expected to work in a silo with only the data model.
The requirements of scalability, functional complexity, distributed processing, and availability must be actively managed at some level in order to develop and deliver a system that meets user and organizational requirements in the modern IT organization.
This section will try and provide a general definition of architecture in order to help frame the conversation for the remainder of the document. In simple terms an IT architect in comparable a traditional Architect. When seeking to construct a building, generally one takes the concept to the Architect to help create the overall building concept. The Architect takes the specifications, ideas, and requirements from the customer and works to create a structure that meets those needs. In addition to general best practices and principles, the architect is also responsible for the aesthetic qualities of the construction.
Similar to the Architect role from construction, the IT architect functions to work within the organization to undertake tasks to creat IT systems based on customer ideas, requirements, and specifications. The architect is generally responsible for making sense of the technology by breaking down the problem into components that can be delegated to other groups within IT. Additionally, the IT architect is responsible for technology decisions as relates to the overall construction of the system. However, much like the traditional Architect, while the Architect has the overall vision, relies on other specialists in order to facilitate completion of various activities required to complete the task/system.
While a traditional Architect relies on civil engineers, masons, carpenters, and other specialists, the IT architect also relies on specialists such as network specialists, developers, and operations analysts in the construction of IT systems. The following section will outline the IT roles generally required within a typical enterprise IT organization. Once these roles are well understood, then the author will outline the various architect roles within these various organizations and roles as well as demonstrating why these roles are necessary and defining the various responsibilities and collaboration points between these roles and the organizations in which they function.
Architecture is a very broad and encompassing term. As such, there are many different types or architecture and roles/activities that require architects. In order to understand architects and architecture, it is important to understand the broad roles found within the IT organization and to provide a framework from within which to frame the role(s) of the Architect.
Analysts generally provide the bridge between the purely business focused users, stakeholders, and subject matter experts. They are involved in requirements gathering and ensuring that the system(s) being implemented by the IT organization meet the needs of the business organizations for which they support.
The development organization is generally responsible for implementing custom solutions or providing solutions for integration of systems within IT.
The QA organization within IT is responsible for being the check valve between the development and operations organizations.
The operations organization is responsible for ensuring that the IT systems that have been implemented continue to function within the organization. They are responsible for managing the production systems and ensuring that these systems remain stable and functional.
The support organization is responsible for turning problems into solutions. When things "go bump" in the machine, support is the organization that puts on their capes and restore order back to the universe. Often overlooked and undervalued, they fill a crucial role within the modern IT organization.