Department of Information Systems

Subject: Enterprise IS/IT Architecture

Chaos and Control

Arif Wibisono
wibisono@is.its.ac.id

Main references:
Col Perks, Tony Beveridge, Guide to Enterprise IT
Architecture, Springer, 2003
Kalani Hausman, Susan L Cook, IT Architecture for Dummies,
Wiley Publishing, 2011

Page 2

Outline
Introduction
Real-World IT Problems
Influencing Factors
Problem Matrix
o
o
o
o
o
o
o
o

The Business / Technical Strategy Gulf

The Information Inaccuracy and Integrity Problem
Infrastructure Hell
The Security Problem
The Problem of Incompatible Technologies
The Cost Problem
Technology Anarchy
The Problem with the Ongoing Systems
Management of IT

Exacerbating ChaosThe Advent of E-Enablement

Control Through Architecture
Summary
Page 3

Summary
All IT groups will experience problems with IT. These may be
related to a lack of integration between business strategy
and technical implementation, problems with an ailing
infrastructure, problems trying to integrate incompatible
technologies, major security issues, or the perennial issue of
controlling IT costs.
An holistic issue is that the rise of the Internet channel has
worsen the problems.
We believe that all of the problems described here are
symptomatic of the lack of an (or an ineffective) architectural
approach to technology.
In the rest of this book, we present a framework for
architecting an organizations IT environment. Our goal
is to demonstrate how the approach presented here can
actively aid the resolution of the problems described in this
chapter.
We begin this journey by positioning technology architecture
Page 4
with respect to other strategic-planning processes.

Introduction
In no organization is the operation of IT perfect.
Although not all problems are solvable using architectural
disciplines, a pragmatic approach is to isolate key issues and
concentrate effort on their solution
Organizational IT problems are products of a number of key
factors:
Technology environment
IT organizational structure
Capability
Industry
Management philosophy

Page 5

Problem Matrix
This sections summarize ten real-world IT problems that
can be mitigated by adopting an architectural approach.
The aim here is to provide the reader with a list of actual
problems we have experienced within IT organizations (with
names changed to protect the innocent, of course)
1. The Business / Technical Strategy Gulf
2. The Information Inaccuracy and Integrity Problem
3. Security Problems
4. Infrastructure Hell
5. The Problem of Incompatible Technologies
6. The Cost Problem
7. Technology Anarchy
8. The Problem with the Ongoing Systems Management of
IT
9. The Problem with Procurement
10. The Collapsing Event Horizon
Page 6

The Business / Technical Strategy Gulf

Problem summary: The failure of IT environment and
planning to be driven by business strategy.
Technical architecture to the rescue: Technical architecture
development and maintenance methods demand business
requirements traceability in the planning and
development of the technical environment.

Example of Requirements Matrix

Page 7

The Information Inaccuracy and Integrity

Problem
Problem summary: The inability of core systems to
support information accuracy due to tactically planned
business systems.
Technical architecture to the rescue: The resolution of
functional, information, and technology overlap and
intersystem integration issues is the focus of the
architectural development methods.
Example:
Customers complain that their details are not being
updated correctly.
Reconciliation of information (such as financial
information) in one system shows different figures than in
another system.
Management information does not appear to represent
the actual state of the business.
Information from external sources (such as order
information) results in an incorrect output generated from
Page 8
that information.

The Information Inaccuracy and Integrity

Problem

There are a number of reasons why intersystem duplication

can occur.
Legacy bespoke applications are replaced by package
solutions whose function overlaps existing systems..
Legacy systems are traditionally difficult to learn use,
modify, and integrate with. For instance, how many HR or
financial databases exist in your organization?
Corners of the organizationfor instance, international
officesmay have alternate methods of operation
(possibly due to internal or external political forces or
judicial or geographic reasons) that dictate different
solutions to business requirements.
Determining how function and information should be split
between systems can be difficult, so they appear in each.
Technical differences in system architectures have a direct
influence on this problem. The greater the degree of
technical difference the more likely that duplication will
occur. This is especially true with package software; the Page 9

Infrastructure Hell
Problem summary: The tactical manner in which some
infrastructure technologies are provided inhibit the ability of
the IT environment to cooperate as a whole.
Technical architecture to the rescue: The technical
architecture focuses directly on ensuring the
effectiveness of the technology environment and
supports its continuing health through governance
processes.
Example:
Real time ERP application will be very difficult to
implement at places with internet low bandwidth
capabilities

Page 10

The security problem

Problem summary: Many organizations cannot confidently
state that their IT environments are secure.
Technical architecture to the rescue: A major service area
in the technical architectures jurisdiction is security.
The development of a technical architecture mandates the
organization understand its current and future panapplication security needs.
Example:
The emergence of computer virus, trojan, denial of service
attack are potentially harm business operations

Page 11

The security problems

There are many symptoms that may be recognized. Here are
some that we have uncovered
A number of, usually unrelated, mechanisms with which
users will identify themselves to the many information
systems they need to access. The general complaint from
users typically is, Why do we have to remember so many
passwords?
Management paranoia over connecting systems to the
Internet (or even to other partners over private networks).
Generally, this paranoia is an artifact of uncertainty over
how information assets will be protected.
Inability to determine whether attacks have even
occurred. This points to issues with the way systems are
audited and the processes for review.

Page 12

The security problems

There are many symptoms that may be recognized. Here are
some that we have uncovered
Individuals who have limited understanding of their
responsibilities surrounding information security. Many
may not know who to contact about security issues.
Association of the cost of security measures to the value
of the information being protected is seldom understood
and rarely taken into account during the design of security
systems. Organizations are not sure how much to spend
on security measures.

Page 13

The Problem of Incompatible Technologies

Problem summary: The IT environment does not
interoperate effectively to provide support for business
processes.
Technical architecture to the rescue: The technical
architecture deals directly with the effectiveness of the IT
environment.
There are many symptoms that may be recognized. Here are
some that we have uncovered
Users adopt manual workarounds to conduct a business
process which scans incompatible systems.
Users cannot collaborate effectively with the entire
organization. Typically, users within small groups have no
difficulty conducting business. However, incompatible
collaboration systems thrown about the network can make
the task of interacting outside the immediate workgroup
difficult
Page 14

Problem of Incompatible Technology

There are many symptoms that may be recognized. Here are
some that we have uncovered
The sharing of documents and other information (such as
reports, business utilities, or marketing material) is ad hoc
and ineffective. Incompatible document-sharing
architectures and document-editing applications, and ad
hoc methods of distribution, reduce the effectiveness of
information transfer.
The use of new or upgraded corporate applications is
problematic due to incompatible operating systems and
hardware specifications. This tends to lead to islands of
application usage.

Page 15

The Cost Problem

Problem summary: The cost of IT in organizations is
ineffectively controlled or understood.
Technical architecture to the rescue: The technical
architecture mandates an understanding of the
organizational type and takes a reasoned approach to the
building of the technical environment that reflects cost
drivers.
Remember that :
Investment is NOT made in technology for technologys
sake but rather as a driver to meet the business
strategy and needs
Most organizations have conflict over their IT spending.
There is no magic formula

Page 16

The Cost Problem

Gartner Group classifies organizations into three types in
terms of technology adoption, as follows :
Type A, Type B, Type C

Page 17

The Cost Problem

Gartner Group classifies organizations into three types in
terms of technology adoption, as follows :
Type A organizations are always:
Considering the risk of adopting new technology against
the rewards of competitive advantage.
Adopt technology long before it is considered stable or
commodity and aggressively exploit technology for
business critical processes.
Only a small number of organizations fit into this
classification

Page 18

The Cost Problem

Type B. organizations :
Focus on the overall value of adopting technology.
They may be innovative in some areas and conservative
in others.
They tend to adopt technology as it becomes mainstream.
They are by far the largest group and use IT to improve
productivity, product quality, and customer service
Type C organization
Focus on cost-effectiveness as the major driver for IT.
They will wait until technology is commodity, proven, and
cost-effective before investing.

Page 19

Technology Anarchy
Problem summary: Individuals hold the technology
vision for the organizationwhen they leave, everything
changes.
Technical architecture to the rescue: The technical
architecture comprises a governance process to ensures
that the IT environment is owned and championed by
the organization, not the individual.

Page 20

Technology Anarchy
Things that introduced anarchy:
Technical advocates leave the organization, resulting in a
feeding frenzy as new roles and responsibilities are fought
for. This results in dramatic technology changes as
advocates in new areas are established.
Common IT processes, such as tendering, can be enacted
a random nature to technology selection.
Technology vendors can continually remodel their
products and services causing confusion, tactical decisionmaking, and a reliance on technology du jour by
organizations.
Autonomous business units make purchasing decisions
that make sense for them but not for the IT environment
in general.

Page 21

The Problem with the Ongoing Systems

Management of IT
Problem summary: IT systems are becoming
increasingly less managed.
Technical architecture to the rescue: The technical
architecture treats systems management as a key
service. Management aspectsknown as service qualities
are a fundamental part of the environment.
It is even more critical today that application have a
considered approach for providing :
Availability, including performance, survivability,
serviceability, and reliability
Assurance, including security, integrity, and
credibility
Adaptability, including scalability, interoperability,
extensibility, and portability
The overall quality of applications is dependent on their:
Functional requirements
Nonfunctional requirements
Page 22

The Problem with Procurement

Problem summary: Procurement processes for IT
systems are reinvented for each project.
Technical architecture to the rescue: The technical
architecture puts in place a set of standards for
procurement.
Example of the problem :
The initial part of a projectthe execution of a buy
processsends people scattering throughout the
organization looking for tender processes and other
collateral required to make product selections. Inevitably
there is limited retained knowledge in this area
It is critical that the procurement of technology be aligned
with the technical vision and strategy, thus ensuring a robust
and maintainable environment.
The architecture provides artifacts and processes that input
directly into the procurement process to ensure that this
occurs.
Page 23

The Collapsing Event Horizon

Problem summary: Equating rapid delivery with tactical IT
decision making.
Technical architecture to the rescue: The technical
architecture provides a set of reasoned artifacts that
guide all e-business tactical decisions.
As new electronic delivery channels become a key
component of a businesss selling proposition, most
organizations are facing the reduction in time needed to
deliver into these new channels.
The problem is the lack of a consistent approach for
determining how e-business systems should be built and how
they should fit into the overall IT environment

Page 24

Exacerbating ChaosThe Advent of EEnablement

As always, the problem with chaos is that the organization
is far too busy dealing with the tactical problems
firefightingto step back and deal with the symptoms.
There tends to be a feeling of treading water. There are
never enough resources to deal with the day-to-day
problems, let alone for management to find the capacity to
consider a strategic cure.
If IT delivery is chaotic now, then the Internet has just added
a new dimension to the problem. The tendency to focus
purely tactically seems to be encouraged. As the Internet
style extends into the organization, is firefighting to become
the norm?

Page 25

Control Through Architecture

Management must focus on immediate problems as they
arise
Planning is important
A stable and architectured IT environment can turn to chaos
in no more than a year unless architectural disciplines
continue to be applied.
The enterprise architecture is the organizations strategy for
information, business systems, and technology.
In each of these areas, key direction is provided to individual
IT projects to ensure that divergence is minimized or
eliminated.

Page 26

Control Through Archictecture

Organizations must understand the concept of architectural governancethe ongoing quality management of the technical environment.

Page 27

Outline
Introduction
Real-World IT Problems
Influencing Factors
Problem Matrix
o
o
o
o
o
o
o
o

The Business / Technical Strategy Gulf

The Information Inaccuracy and Integrity Problem
Infrastructure Hell
The Security Problem
The Problem of Incompatible Technologies
The Cost Problem
Technology Anarchy
The Problem with the Ongoing Systems
Management of IT

Exacerbating ChaosThe Advent of E-Enablement

Control Through Architecture
Summary
Page 28