On this page, Bobby Woolf explores the topic of IT architecture to help you
understand what it is, who does it, and its history. He offers an overview
of how IT architecture has evolved and defines the IBM architecture
disciplines. He also guides you to other resources on developerWorks that
can help you learn more about architecture.
What is IT architecture? Architecture is the important stuff. If you ask a
system's expert what is important, their response defines the architecture.
The architecture of a system is the highest level of shared understanding of
that system by the experts who create it. It is the main parts of the system
that need to be understood so that the system, the main components, and how
they relate and interact can be understood. An architecture is whatever the
expert designers find important at the top level; the architecture drills
down into important details while less important ones are determined at
lower levels of design.
As long as a system is in use, its architecture is never finished. The
architecture is first envisioned when the system is conceived. Continually
evolving insights about the requirements for a system and then realizing
those requirements inevitably change the architecture.
In the realm of information technology (IT), even for a single,
software-intensive system, there are many architectures. If the entire
system is considered the topmost level of interest, that's the enterprise
architecture. If you're focusing on the hardware and low-level
software the system runs on, you're concerned about the infrastructure
architecture. Even that may be high level for someone focused on the
network architecture, in which the network is considered the
highest level of interest. Others focus exclusively on the storage
architecture. Operations architecture involves keeping the
production system running smoothly even during challenges like load spikes
and outages.
There is no single architecture, but enterprise architecture is the highest
level of architecture. An enterprise is a collection of organizations with a
common set of goals and a common bottom line. An enterprise can be a
corporation or a government agency, or a division or department that
operates independently of others in the same organization. An enterprise can
even include business partners, suppliers, and customers, although
conflicting interests may make common goals difficult to pursue. An
enterprise architecture addresses all the concerns and needs of an
enterprise necessary to successfully produce, execute, and maintain the
software-intensive systems it requires.
Architecture is important because every system has one. Sometimes an
architecture is developed before any part of the system is implemented.
Other times, system implementation takes place without formal definition of
an architecture. Most cases fall between these two extremes. However, even
in the latter scenario, the system has an architecture, and in the software
world, more often than not, the system architecture becomes apparent only
after the system is built.
There are three general types of these non-architected architectures, each
with its own derogatory yet memorable name:
Big ball of mud (a.k.a. Shantytown) -- This kind of system
contains large segments that are unused. Yet the unused parts are so
enmeshed with everything else that they're impossible to identify, much
less remove.
Spaghetti -- This is a system with no logical flow, where any
part may be connected to any other part. In such a case, most of the parts
share some dependency on many or most of the other parts, even if such
dependencies make little difference to the overall functionality of the
system.
House of cards -- With this non-architecture, every part depends
on many others, so that a change to one part breaks several, and fixing
one problem introduces many more.
Many systems with the properties of one type tend to have the properties of
the other two types as well. Figure 1 shows an example architecture that has
characteristics of all three types.
Systems get built this way because they're not planned. They're built in a
hurry to meet immediate needs without considering qualities necessary for
long-term success, often by people lacking required skills and resources.
The team that builds such a system may have too few people, or it can have
too many people who dilute, rather than amplify, the effect of the most
talented team members.
One glance at the preceding figure should illustrate the need for
architectural design before the team starts building a system. When building
a system, a small number of visionaries, perhaps just one, needs to lead the
design team to avoid this kind of tangled mess. This visionary must have an
overarching plan in mind, not for every detail, but more of an overall idea
of what is needed and how to do it. This visionary is responsible for the
architecture. With such a visionary -- and with an architecture in place
before anyone starts to build the system--order can prevail and a
consistent, understandable, system can be built -- one that can be modified by
the team or by other teams when new needs arise.
An architect is the person responsible for developing the architecture and
ensuring that it is created. Although an individual architect could do all
of the work, the development usually involves a team approach. In this
sense, the architect is like the coach of a team, the conductor of an
orchestra, or the director of a film. The architect's vision of the system
to be created becomes the plan for the team to create it.
What skills are required of an IT architect? IT architects must see the big
picture, understand the main parts, and know how they fit together. IT
architects need to be able to balance conflicting needs, such as
requirements, budget, manpower, and timeframe. They need to look at what the
system must do. They must also anticipate future needs and the problems the
system may face and prepare for how to resolve those problems. Architects
must be able to develop a vision, then communicate that vision to the team
and motivate its members to enact it.
What an architect needs most is experience. No one should be an architect
the first day on the job. A would-be architect needs to gain mastery of the
main individual parts before attempting something bigger. He or she needs
experience managing a project, working with stakeholders, and leading a
team. Good architects are not born; they grow into the position.
The following are major milestones in IT architecture, listed in roughly
chronological order:
Mainframes. The first applications ran on one central computer.
Users connected through dumb terminals or teletype machines. Architecture
was simple: The application did everything beyond the operating system.
For persistence, there was no external database like IBM DB2® or
Oracle -- the application stored its data in files itself. There were no
messaging systems, no GUIs, no shared data, and no interaction between
applications.
Workstations. As desktop computers became common, so did
applications that ran on them. These are personal productivity
applications like VisiCalc, WordPerfect (now published by Corel
Corporation), and the Microsoft® Office applications. These were
personal applications; each user ran a locally installed copy and quit it
after its use. No data was shared; it was stored in files on local disk
and only distributed by sneaker-net.
Networking. Networks connected workstations to each other, to
shared server computers, and to mainframe-style central processing
computers. This enabled e-mail capability within an enterprise and sharing
files on a file server.
Client/server. Networking enabled client/server computing, where
the application no longer ran completely on a central computer or on a
workstation, but was split across the two. Original client/server
applications ran on the workstation but accessed centralized data from a
database server. Later architectures split the application itself into two
parts: a shared component for business logic that ran on the server and
local clients that implemented the user interface. The need to host this
central business logic led to the development of application servers for
running and managing the server part of the application.
N-tier. A client/server architecture is said to be a two-tier
architecture. When the database server runs on a different host computer
from the application server, that's a three-tier architecture. As
network-based applications became more sophisticated, designers divided
the application stack -- from the GUI to the database -- into more processes
on both the client and the server. Such a multiple-tier design became
generically known as an n-tier architecture.
Internet. The Internet is networking on steroids, a global
network. The Internet is actually older than the networks in most
enterprises, but it was impractical to access it in the business world
until an enterprise constructed an internal network that could connect to
the Internet. The Internet enabled communications and information sharing
not just between users in an enterprise, but between users anywhere in the
world.
World Wide Web. The Web made the Internet graphical. It enabled
authors to publish words and pictures -- using Hypertext Markup Language
(HTML) -- as a combined document that could be viewed by anyone anywhere in
the world. These HTML documents contained hyperlinks to other documents,
so any reference to another document became active and provided the reader
direct access to the referenced source. This was the beginning of
information on demand, to links being as important as nodes.
Browser GUIs. The Web introduced HTML browsers for viewing static
HTML documents. This paradigm was quickly adapted to provide interactive
GUIs for accessing remote applications. This was a return to the
centralized computing model. It wasn't actually a client/server model,
because practically none of the application ran on the client except for
HTML rendering and some simple scripting. Even the validation of input
values had to be performed on the server.
Web services. The Internet was created to connect applications,
but the Web connected people to static content and to server applications.
Web services use the Web to connect applications so that one application
can invoke behavior in another application through a Web connection.
Web 2.0. This is the application of Web services to Web sites.
The user of a Web site is no longer a person, it's another application.
Service-Oriented Architecture (SOA). Applications have tended to
be monolithic, running entirely either on a central computer or on a
workstation. Client/server and n-tier architectures distributed
application layers; browser GUIs moved the application back to the server.
Even with n-tier architectures, this architecture was still rather
monolithic because the run-time stack is self-contained; applications at
best interacted as peers. SOA divides an application into a service
coordinator (the top set of consumers in a composite application) that
represents user functionality and service providers that implement the
functionality. While the coordinator tends to be unique to a particular
application, a service can be reused and shared by multiple composite
applications.
Event-driven architecture. With SOA, the service coordinator
explicitly specifies and invokes the desired services. With event-driven
architecture (EDA), an application detects an event and emits a
notification; other applications have handlers that can receive the
notifications and react by invoking services. In this way, the detection
application doesn't have to know all the services it should invoke in
response to an event; it can simply announce the event and let the other
applications decide which services to invoke in response.
Information technology (IT) architecture is the fundamental organization of
a software-intensive system. A system is software-intensive because the most
prominent part of an IT architecture is its applications, the part that
enables the users perform their business tasks.
Besides applications, there are other aspects to IT architecture. The
applications in an IT architecture require infrastructure, a foundation to
run on. This foundation is made up of hardware-server computers, desktop
workstations, storage, and networking. It's also made up of server software,
including middleware-application servers, database servers, messaging
systems, workflow engines, and rules engines. Data is stored in this
foundation, managed as an asset, and made available by controlled access to
multiple applications. This foundation is also the host for integration
solutions to let applications communicate with each other.
Other aspects of IT architecture bring these elements together. All of them
must be managed at run time to ensure their proper operation. And an
architect must make sure all of these parts -- infrastructure, applications,
data, integration, and operations -- come together to form one smoothly
operating, software-intensive system that meets the needs of its users.
Thus, there are different kinds of IT architects. IBM defines the following
six architecture disciplines:
Enterprise architecture. An enterprise architect focuses on
mapping IT capabilities to business needs. The architect is responsible
for an enterprise's full range of software-intensive systems, including
the relationship between multiple applications, data shared between
applications, integration of the applications, and the infrastructure to
run applications.
Application architecture. An application architect focuses on the
design of applications to automate business processes and provide
functionality that helps users perform business tasks. The architect's
responsibilities include designing the application to meet user functional
and quality of service requirements including performance, availability,
scalability, security, and integrity. Responsibilities also include
evaluating and selecting the software and hardware necessary to run the
application, as well as the tools and methodologies to develop the
application.
Information architecture. An information architect focuses on the
data used by multiple applications, including the structure, integrity,
security, and accessibility of that data. The architect's responsibilities
include designing, building, testing, installing, operating, and
maintaining the systems for managing that data. Design of these systems
must account for data requirements such as source, location, integrity,
availability, performance, and age.
Infrastructure architecture. An infrastructure architect focuses
on the design of hardware and server software including server computers,
storage, workstations, middleware, non-application software, networks, and
the physical facilities that support the applications and business
processes required by the enterprise. The architect's responsibilities
include evaluation and selection of these components; modeling,
simulating, and testing to validate the designs and selected products; and
performance, availability and scalability of the resulting infrastructure.
Integration architecture. An integration architect focuses on the
design of solutions that enable existing applications, packaged software
offerings, networks, and systems to work together within an enterprise or
among enterprises. These solutions may use different technologies,
vendors, platforms, and styles of computing.
Operations architecture. An operations architect focuses on the
design of solutions to manage the infrastructure and applications used by
the enterprise. The architect's responsibilities include defining plans,
strategies, and architectures for the installation, operation, migration,
and management of complex information systems.
These architects do not work independently because their domains overlap.
The infrastructure architect designs the foundation the systems run on. The
application architect designs the programs for users, the integration
architect makes sure the programs can be integrated, and the information
architect makes sure they have data. The operations architect makes sure it
all runs properly, and the enterprise architect oversees all of these
aspects and ensures that they all come together. In Figure 2, you can see
the relationship between the six architectural disciplines, as identified by
IBM.
IBM developerWorks contains a wealth of resources for learning about
numerous technical topics, including architecture. The types of resources
available include:
Articles. Authored by some of IBM's most experienced technical
staff members and guest contributors. developerWorks articles cover all
levels of application development, both product-specific and
vendor-neutral, including architecture.
Tutorials and Training. Step-by-step guidance to teach specific
IT skills. Series are organized around products and technologies.
IBM Education Assistant. Tutorials that teach skills to help use
specific IBM products.
Podcasts. Listen to conversations with a broad range of technical
leaders, both inside and outside IBM, who offer expert insights and
discuss technology innovation and evolution.
Webcasts. Free technical presentations that provide you with the
latest information on products and technology.
Blogs. Authored by members of IBM's most knowledgeable and
articulate technical staff. Many of them focus or comment frequently on
architectural issues.
Sample IT projects. Examples of complete projects, from
requirements through implementation, presented as series of articles that
walk you through the process of developing systems.
You can find plenty of architecture topics worth learning about. The
preceding resources include materials about four of the most prominent
architectural topics and IBM product areas, including:
WebSphere Business Process Management provides a set of IBM products that
help with implementation and deployment of SOA applications. Learn more
about WebSphere Business Process Management from the following resources:
Virtualization makes resources logical, hiding their implementation
structure. Grid computing pools resources and distributes tasks optimally.
Autonomic computing enables a system to be self-healing, dynamically
adjusting in response to demand and problems. Get more information about:
WebSphere Extended Deployment is a WebSphere Application Server environment
that provides grid and autonomic features. To learn more, see the following:
developerWorks
Sample IT projects
combine architectures, technologies, and IBM products to help you understand
the process of developing IT systems. Projects that specifically focus on
architecture include:
"Architecting on demand solutions"
-- Develop an application using the 13 capabilities of the IBM On Demand
Operating Environment.
"Optimize resource usage and reduce costs"
-- Develop an intranet portal that aggregates many business-critical
applications using WebSphere Portal, WebSphere Extended Deployment,
Tivoli, and DB2 products.
Check out these additional resources to learn more about IT architecture.
"Who
Needs an Architect?"
-- Martin Fowler's excellent IEEE Computer Society article (PDF) discusses
the nature of software architecture and the people who do it. An e-mail
from Ralph Johnson in the article forms the basis for much of this
article's description of architecture.
The Open Group Architecture
Framework (TOGAF)
-- The Open Group has spent a lot of time thinking about architecture. The
organization's definition of an enterprise forms the basis of this
article.
"Introducing The Open Group Architecture Framework (TOGAF)" -- In this
series on
developerWorks
Architecture,
Jeff Egan explores TOGAF and how to use it to develop an enterprise
architecture. Titles include:
"Exploring IT architecture disciplines": This series of articles by
Danielle and Nelson Ruest on
developerWorks Architecture
reviews types of architecture, how they fit together, and how to apply them.
Read the following installments to find out more:
Insight and outlook. Enhance your knowledge about IT
architecture. Check out various installments of the
Insight and outlook column,
where IBM architecture experts discuss common topics and questions of
interest.
