 | Level: Intermediate Danielle Ruest (architectures@reso-net.com), Senior IT Enterprise Architect (EITA), Resolutions Enterprises
Nelson Ruest (architectures@reso-net.com), Senior IT Enterprise Architect (EITA), Resolutions Enterprises
11 Jul 2006 Organizations rely on enterprise architecture (EA) to fulfill their business requirements with IT tools and services. Through these architectures, an organization can better understand its needs as they interact with others in the market and gain more flexibility to adapt to changing market trends. In this first article in a series, you discover what makes up an EA and learn how your organization can create an EA of its own.
The purpose of any organization is to efficiently run its business and provide services or products to its customers and clients.
In the execution of this goal, organizations rely on information technology (IT) tools and services. The only way the
relationship between business and IT can succeed is when the organization is fully aware of its technological infrastructure
and of all the processes that support it. Enter enterprise architecture (EA), which WhatIs.com defines as "A
conceptual blueprint that defines the structure and operation of an organization."
To achieve their purpose, organizations must fully understand the nature of their business, both present and future.
In fact, EA is designed to support and facilitate the achievement of the organization's objectives through
the use of technology. As a result, there's a close relationship between EA and the business architecture. Indeed,
the first step in the implementation of an EA is to fully analyze the business and understand its objectives. Next,
you must map out these objectives to the different technological components that make up your IT services. To do so,
organizations can rely on EA frameworks -- or relationship models that facilitate the definition of an EA (see
Resources).
The resulting EA consists of several subarchitectures. Traditionally, there are four such subarchitectures: business,
information, solution, and technology. Each architecture requires a definition in its own right, but it's
arguable that building an EA on only four pillars lacks precision and that more architectures are required. Let's
begin by looking at the relationships involved among these architectures.
The pillars of EA
There is no doubt that the most important aspect of an EA is the business architecture, the official
definition of business objectives, rules, and processes. This architecture must define relationships with
clients, suppliers, and other providers as well as the interactions with any other organism that may affect how
business runs in the organization. Therefore, for the foundation of EA, the business architecture forms the first building block
and trickles down to influence all other architectural components.
The components most affected and influenced by the business architecture deal with three core architectural pillars:
information, infrastructure, and development. The first pillar helps identify which data components
you must work with and how those data components are rated within your organization. Prioritizing data is one of
the most important aspects of the architecture. Knowing which information is vital to your organization and building
in proper safeguards for it allows you to move forward more easily.
When you have detailed the information architecture, you can move to the others. When you have a good understanding
of the data you must keep, you'll be able to identify which infrastructure you require. This process is similar
to the traditional technology architecture, but in fact, the infrastructure architecture is an agnostic description
of the components that make up your IT assets.
The third architecture that the business architecture affects relates to the traditional solutions architecture.
Because solutions require development, however, this architecture should actually be called the development
architecture. Although it's better to buy than to build, you must still perform customizations, and organizations
always require particular solutions that are simply not available on the market. But, to make your business
architecture successful, you must have a detailed architecture ripe with standards, policies, and processes to help
reduce costs and also to help ensure that the products that your development architecture delivers meets each
requirement.
The three pillar architectures -- information, infrastructure, and development -- require a high degree of interaction
to properly fulfill their goal. Therefore, you need an integration architecture -- that is, an architecture
that spans the three pillars to ensure that they interact properly and have specific junction points that will be
used for integration of any new business need.
Finally, the base that supports each aspect of an EA is the operations architecture, or the base strategy
used to make everything hum. In a recent poll during the Spring Interop conference in Las Vegas, Nevada, more than
95 percent of 150 systems administrators indicated that they work overtime. Yet, of the remaining five percent,
those who implemented a proper operations architecture never needed to or were never required to work overtime.
In today's agile world of business, if you don't have a proper operations architecture, you won't be able to deal
with any new requirement reactively, let alone proactively, because you'll be too busy catching up to existing problems.
It is almost impossible to believe that organizations running several thousand computers don't have integrated
directory services, are not deploying managed computers, and don't have a systems configuration and change-management
technology in place -- and yet there are organizations like this today. These organizations are so far behind that they
lack any sign of agility. Imagine the impact on their bottom line!
The seven layers of architecture are illustrated in Figure 1. Each architecture you see here will be the subject of
subsequent articles in this series.
Figure 1. The make-up of an EA
Standardize your architectures
Much of the work you do in preparing your EA is in the form of inventories. Inventories are the most
important aspect of any system description. If you don't know what you have, you can't manage it or expect it to
behave in any predictable manner. During the elaboration of these inventories, think about three key terms: standardization,
rationalization, and certification.
Standardization is at the core of any cost-driven delivery of IT services and means that everything is the same.
Of course, this definition cannot be taken literally. In IT, standardization means that at the core of all IT services,
you find a single and unique approach. If everything is the same at a given level of the IT Infrastructure, you can
ensure a consistent service delivery. For example, simply ensuring that all computers use the same operating system
with the same level of updates facilitates the repair process for support personnel, because they will always know
and understand the starting point of any problem-solving situation. In fact, they can also devise and prepare standard
responses to the most common problems, thus reducing problem-resolution time and cost. When creating inventories, keep
this term close to heart and look for any opportunities for standardization.
Rationalization, or a reduction of diversity within IT, helps support the standardization concept within IT. This
reduction primarily focuses on the tools in use within the IT structure. So, instead of selecting a tool because of
familiarity or personal preference, you choose it because of function. For example, if you need a word processor, you
select a single and unique word processor throughout the organization, thereby ensuring that all information produced
with this tool is reusable throughout the entire organization. Clearly, most organizations today understand this
concept in terms of office automation. What is less clear is why organizations have not extended this principle to
all other software products in use within their IT Infrastructure. When performing your inventories, look at the
opportunity for rationalization at every level.
Finally, certification deals with the methods put in place to prepare tools and services for deployment. By
introducing a certification process before deploying hardware, software, or services, organizations can take proactive
measures to ensure the stability of the offering. When you have your inventories in hand, try to identify areas where
certification can help.
These three key terms stand out today partly in light of the previous experience organizations have had with IT. At first
in the 1980s, organizations moved to information systems on a piecemeal basis. Business units developed their own
systems and put in place the infrastructures required to support them. IT was in charge of segregated environments.
Then, in the 1990s, organizations started to rationalize their infrastructures. However, business units continued to
use different technologies to develop and support the systems they required. IT was in charge of semi-integrated
environments.
Today, organizations are beginning to realize that they require complete integration if they want to control costs. As
such, the goal of your EA should be to offer one unique infrastructure that integrates all the aspects of IT and treats
it as a strategic corporate asset (see Figure 2). Business units become customers and IT becomes a service. IT as a
service: What a novel idea!
Figure 2. The evolution to an EA
IT as a service
If IT is a service, it must act as a service. People don't return to a restaurant where the service wasn't good.
When you go to the restaurant, it's for a quality experience. You want good service, and you expect good food.
When the experience isn't as you expect, you do the only thing you can in this situation: Your tip is equal
to the level of service, and you don't come back. The problem with IT as a service is that you don't have a
choice: You must use the services IT provides, regardless of whether they're good. Because IT has a service
monopoly, its level of service must be high. Standardization, rationalization, and certification go hand in hand
in the definition of IT quality of service. If these principles are not implemented, the organization is likely
to face some serious problems -- problems that should simply not be part of the picture if the organization
is to fulfill its objectives. Do any of the following sound familiar?
- Difficulty maintaining and updating the corporate network: Too many products mean multiple zones and
levels of expertise within IT. Some products will be well known and will thus be well supported; others will
not because of a lack of knowledge or support resources. Think long and hard before you decide to support
diversity in your network.
- Support situations require "one-on-one" relationships: Too much diversity means that each problematic
situation requires individual diagnostics. Problems cannot be related to other situations occurring in the
network, because nothing is the same.
- Information sources are disparate: If every person chooses the way he or she stores and produces information,
each person will be the only one who has access to it. Corporate-wide integration of information sources will
be impossible.
- Network evolution is impaired: If diversity is a factor, it's extremely difficult for the network to
evolve and change when new business needs arise or revolutionary technologies are introduced in the marketplace.
The cost of tracking the evolution of diverse products will limit the productivity of the organization.
- Development is hampered: If there's too much diversity in the network, it's impossible to aim for
information sharing through internal, corporate development. Developers follow their own personal guidelines,
and each internal application is an island of its own.
- Reliability is simply not present: Stability and reliability are difficult to achieve when there are too
many system components to integrate. Staff cannot have all the skills to maintain all the systems, so system
failures are commonplace and not unexpected.
 |
Ten critical elements of EA
Problems of this type are expensive -- indeed, any problem is expensive. Fortunately, you don't have to live with them.
If you build an EA, you can avoid them all and improve your productivity at all levels. All your staff will be able to
focus on its own tasks and won't get sidetracked by issues that simply shouldn't exist in your network. To get there,
you must start documenting the different components or different architectures that will make up the EA. For each architecture,
you need:
- A vision statement
- Goals and strategies of the architecture
- Driving principles for the architecture
- Geographic distribution of the architecture
- Principle actors in the architecture.
- Information sources for the architecture
- Information flows for the architecture
- Architecture policies
- Architectural standards
- Implementation plans
If you concentrate on these 10 critical aspects of the architecture, you should be able to properly document the structure
of each. Keep it simple, and use language that is straightforward and easy to understand. This way, it will be much easier
to have the architecture accepted and, more importantly, adopted by the people in your organization. When you're armed with
a proper EA, you're ready to take on the world, because you know exactly where you stand.
Resources Learn
Get products and technologies
-
Build your next development project with
IBM
trial software, available for download directly from developerWorks.
Discuss
About the authors
| 
| | Nelson Ruest is a senior enterprise IT architect (EITA) with more than 20 years of experience in migration planning and network,
computer, server, and overall solution design (including MCSE, MCT, Microsoft MVP Windows Server). He has been a computer operator, a systems administrator, a trainer, a help
desk operator, a support engineer, an IT manager, a project manager, and now, an IT architect. He was recently named a
Microsoft Most Valuable Professional for the Windows Server product line. You can reach Nelson at
architectures@reso-net.com. |
Rate this page
| |
