Chaos and Control

Department of Information SystemsSubject: Enterprise IS/IT Architecture

Arif [email protected]

Chaos and Control

Page 2

Col Perks, Tony Beveridge, Guide to Enterprise IT Architecture, Springer, 2003

Kalani Hausman, Susan L Cook, IT Architecture for Dummies, Wiley Publishing, 2011

Main references:

Page 3

Introduction

Real-World IT Problems

- Influencing Factors- Problem Matrix

o The Business / Technical Strategy Gulf o The Information Inaccuracy and Integrity Problem o Infrastructure Hell o The Security Problem o The Problem of Incompatible Technologies o The Cost Problemo Technology Anarchy o The Problem with the Ongoing Systems

• Management of IT

Exacerbating Chaos—The Advent of E-Enablement

Control Through Architecture

Summary

Outline

Page 4

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 organization’s 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 with respect to other strategic-planning processes.

Summary

Page 5

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

Introduction

Page 6

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

Problem Matrix

Page 7

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.

The Business / Technical Strategy Gulf

Example of Requirements Matrix

Page 8

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 that information.

The Information Inaccuracy and Integrity Problem

Page 9

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 organization—for instance, international offices—may 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 ability to integrate applications effectively is restricted by the vendor’s choice of technology

The Information Inaccuracy and Integrity Problem

Page 10

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

Infrastructure Hell

Page 11

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 architecture’s jurisdiction is security. The development of a technical architecture mandates the organization understand its current and future pan-application security needs.

Example:

- The emergence of computer virus, trojan, denial of service attack are potentially harm business operations

The security problem

Page 12

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.

The security problems

Page 13


- 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.

The security problems

Page 14

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.


- 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

The Problem of Incompatible Technologies

Page 15


- 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.

Problem of Incompatible Technology

Page 16

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 technology’s 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

The Cost Problem

Page 17

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

- Type A, Type B, Type C

The Cost Problem

Page 18

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

The Cost Problem

Page 19

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.

The Cost Problem

Page 20

Problem summary: Individuals hold the technology vision for the organization—when 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.

Technology Anarchy

Page 21

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 decision-making, 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.

Technology Anarchy

Page 22

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 aspects—known 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

The Problem with the Ongoing Systems Management of IT

Page 23

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 project—the execution of a buy process—sends 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.

The Problem with Procurement

Page 24

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 business’s 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

The Collapsing Event Horizon

Page 25

As always, the problem with chaos is that the organization is far too busy dealing with the tactical problems—firefighting—to 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 26

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 organization’s 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 27

Control Through Archictecture

Organizations must understand the concept of architectural governance—the on-going quality management of the technical environment.

Page 28

Introduction

Real-World IT Problems

- Influencing Factors- Problem Matrix

o The Business / Technical Strategy Gulf o The Information Inaccuracy and Integrity Problem o Infrastructure Hell o The Security Problem o The Problem of Incompatible Technologies o The Cost Problemo Technology Anarchy o The Problem with the Ongoing Systems

• Management of IT



Summary

Outline

Documents

Chaos and Control