2/4/2018 1.

The Problem - IT Architectures and Middleware: Strategies for Building Large, Integrated Systems, Second Edition

IT Architectures and Middleware: Strategies for Building Large, Integrated Systems, Second Edition

PREV NEXT
Acknowledgments 2. The Emergence of Standard Middleware
   🔎

1. The Problem
This book makes the link between business problems and IT solutions. It
is about turning functional requirements into an implementation design,
deciding how to spread the functionality across programs, and choosing
the technology to make it happen. But any set of functional requirements
is accompanied by what may be called nonfunctional requirements, which
have to do with ensuring that the system not only does what is expected,
but does it with the required performance, reliability, scalability,
manageability, and security. We therefore address these issues as well.

We believe that a key ingredient for success in all of the above is taking an
IT architectural approach. What does this mean? Architecture in IT
normally means high-level design. There is application architecture,
infrastructure architecture (network, system management, etc.), security
architecture, and many other architectures. IT architecture is the
overarching high-level design of all of these. Our view is that caring about
the high-level design, trying to get it right, and ensuring that all the
technical aspects (application, infrastructure, security, etc.) fit together
are important and are much neglected in IT design.

As an aside, architecture is unfortunately one of those words in the ITer’s

lexicon that has been severely mangled by overuse. Architecture
sometimes means a generic design pattern, for example, an “n-tier
architecture.” Sometimes it is vaguer than that, like “RISC architecture”
(meaning some generic properties like a small instruction set). Then there
are the “markitectures” such as IBM’s SAA (Systems Application
Architecture, which was much promoted around 1990) and Microsoft’s
DNA (Distributed interNet applications Architecture). When we talk
about architecture, we usually mean high-level design. When we mean
something vaguer and more generic, we hope that is obvious from the
context.

So why is high-level design so important? In a word—integration.

Integration turns many small applications into one large application.
Whole sections of the IT industry are built on the premise that small
applications can be easily assembled into larger ones; it’s just a relatively
straightforward technology problem. Well, you can create a large boat by
lashing together many small boats, and on a flat calm sea it will work just
fine. So how about lashing together IT applications?

To answer this question, we use an example of an imaginary but realistic

company to illustrate the things many organizations are trying to do.

1.1 EXAMPLE: MOVING TO E-

BUSINESS
Our example concerns a company that markets and sells, but does not
manufacture, a range of products. It now wants to sell over the Internet.
This represents a significant departure because the only Internet presence
up to this time is a Web server with static information pages about the
company and its products.

The IT applications of the sample company are illustrated in Figure 1-1.

Figure 1-1 IT applications before marketing via the Internet ⬆

Find answers on the fly, or master something new. Subscribe today. See pricing options.
File failed to load: /extensions/MathZoom.js

file:///C:/Users/RON/Documents/EGDownloads/IT%20Architectures%20and%20Middleware/1.%20The%20Problem%20-%20IT%20Architectures%2… 1/10
2/4/2018 1. The Problem - IT Architectures and Middleware: Strategies for Building Large, Integrated Systems, Second Edition

The original idea is to get an expert in Web development, build an

interface to the Order Entry system and then launch it on the world. A
moment’s thought, however, and it’s obvious that more is necessary. To
start, we need a number of additional interfaces, which are shown in
Figure 1-2.

Figure 1-2 IT applications after adding a Web commerce server

But building the interfaces is only part of the problem. The Web interface
has now exposed to the outside world all the inconsistencies and
complexities of the system that until now only the internal users had to
contend with. Even if the Web interface is a good one, some fundamental
issues go much deeper, for instance:

• When the order information is being sent from the Order Entry to the
Delivery system, there comes a time when it has been completed on one
system but is still unknown on the other. The order has gone into limbo.
The online user is left wondering what happened to it.

• Previously, payment was received after delivery. On the Internet there

probably will be a need to take credit card details and process the
payment before delivery. This means changes to the Order Entry,
Delivery, and Billing applications.

• Product information is dispersed via the Order Entry, Warehouse,

Delivery, Billing, Static Web Server, and Marketing applications. There is
great potential for inconsistencies of information and therefore a danger
that an online customer will order an unavailable product or be unable to
order an available product.

• Customer information is dispersed via the Order Entry, Delivery, Billing,

and Marketing applications. There is a possibility that the customer’s
goods or invoice will be sent to the wrong address or the cost billed to the
wrong credit card account.

Looking further ahead, the company might want to implement a WAP

interface (Wireless Application Protocol for ordering over a mobile
phone), a call center, one-to-one marketing, business to business (B2B)
Internet communications, and a commerce portal. These interfaces are
illustrated in Figure 1-3.

Figure 1-3 IT applications after adding interfaces

File failed to load: /extensions/MathZoom.js

file:///C:/Users/RON/Documents/EGDownloads/IT%20Architectures%20and%20Middleware/1.%20The%20Problem%20-%20IT%20Architectures%2… 2/10
2/4/2018 1. The Problem - IT Architectures and Middleware: Strategies for Building Large, Integrated Systems, Second Edition

How can all these requirements be implemented? It’s clear that some kind
of structure is necessary to prevent chaos breaking out. Looking more
closely, we see three generic issues that need exploring.

First, the business process flow from order entry through distribution to
billing must be controlled. The primary reason is that the customer wants
to know what happened to his or her order. The solution could be an
order-tracking system linked to all the other systems. This solution could
provide the basis for many other improvements. For instance, it might be
possible to substantially improve the business process for order
cancellation and product returns. The business might also be able to get a
better handle on where the delays are in the system and improve its speed
of service, perhaps to the extent of being able to promise a delivery time
when the order is made.

Second, the quality of data needs improvement. The fundamental issue is

that there are many copies of one piece of information, for instance,
product or customer data, dispersed over many databases. There must be
a strategy to share the data or control data duplication or both.

Third, an existing application needs to be opened up to additional end-

user devices. Figure 1-3 shows the Order Entry application being called
from a Web Commerce server, from a WAP server, from the Call Center
workstations, and from a B2B server. Not only should the Order Entry
application be able to handle all these forms of access, it should also be
possible to start entering an order on a Web Commerce server and finish
entering the same order over the telephone.

These three challenges—improve cross-functional business process

control, provide accurate online information, and support multiple
presentation devices—are typical of many IT organizations. IT
architecture is a primary tool for solving all these problems.

Of course, these problems are not the only IT management concerns.

Three other issues that stand out are:

• Making applications more responsive to change—in other words,

building for the future

• Keeping costs down

• Finding skilled staff

IT Architecture has a direct impact on the first of these problems and an

indirect but considerable impact on the other two.

So what is IT architecture? Why is it different from what we did before?

And how does it help us tackle the issues just outlined?

1.2 WHAT IS IT ARCHITECTURE?

IT architecture is a solution to the problem “How do I structure my IT
applications to best suit the business?” Technically, an architecture
identifies the components of a problem space, shows the relationships
among them, and defines the terminology, rules, and constraints on the
relationships and components. This notion of architecture has been
widely and successfully used, starting in the 1970s with communications
architecture, first by vendors such as Burroughs, IBM, and Sperry Univac,
and then by various standards bodies.

The main purpose of defining an architecture is to try to impose order on

chaos, or potential chaos. Architecture is an essential first step to orderly
solutions to problems. It does this by establishing a framework within
which to solve both current and anticipated problems. Consider again the
sample company. The initial business requirement was to add an Internet
sales channel. This could be tackled as a one-off, by installing a Web
commerce server of some kind, without too many problems. However, the ⬆
initial requirement implies a need for a number of other connections,
which introduces more complexity. And the requirements are not likely to
stop there but will extend to new channels and services. If every
requirement is tackled as a one-off, the environment quickly becomes

File failed to load: /extensions/MathZoom.js

chaotic, as can be seen in Figure 1-3. It shows the connections among the
various parts of the system and how functions are implemented—file

file:///C:/Users/RON/Documents/EGDownloads/IT%20Architectures%20and%20Middleware/1.%20The%20Problem%20-%20IT%20Architectures%2… 3/10
2/4/2018 1. The Problem - IT Architectures and Middleware: Strategies for Building Large, Integrated Systems, Second Edition

transfer, Remote Procedure Call (RPC), and electronic data interchange

(EDI)—as well as the connections that would be required to introduce
various new channels. In many cases, these connections are implemented
ad hoc, leading in the extreme (a documented case) to several thousand
unique point-to-point connections.

So what does a typical architecture look like? Figure 1-4 shows such an
architecture as it might be defined, for example. Although variations are
possible, the structure in Figure 1-4 should serve as a useful starting point
for discussing the ideas behind architecture.

Figure 1-4 Typical IT architecture

Figure 1-4 identifies the various components of the architecture. The

environment is split into three parts, or tiers: presentation, application,
and data. The presentation tier manages the interface with the various
connections to the system—the access channels—and is responsible for
ensuring that information is delivered in the right way to whatever device
is being used. The application tier represents the business logic, operating
on the various databases in the data tier.

The key to tying the parts together is in the rectangle in Figure 1-4 labeled
Integration Infrastructure. It describes the hardware and software
required to make the desired connections—the presentation tier to the
applications and the applications to each other. What happens inside the
rectangle is crucial. The following paragraphs sketch the main elements,
which are discussed in detail throughout the book.

A critical part of the software content is called middleware. The IT

industry is a bit of a fashion industry. Some middleware vendors have
expunged the word middleware from their vocabularies because they
think it is associated too closely with now unfashionable approaches.
However, we’ll carry on using the word because it is helpful.

A simple definition of middleware is “software that is necessary in

practice to build distributed applications.” But why does the application
have to be distributed? It does not; the middleware could easily be used to
integrate applications in one machine. In fact, it is important that
middleware be able to integrate two applications in one machine; first, for
testing purposes, and second, because it is sometimes a convenient way to
implement an application that might be distributed later. However, we
don’t want to widen the definition to include every piece of integration
software that cannot operate over a network. An important characteristic
of middleware software is that it is capable of operating over a network.

Middleware is more complex than most IT people recognize (and certainly

a good deal more complex than most middleware vendors would have you
believe). For a complete solution, there are at least eight elements to
consider, although many of these elements are seen as part of the network
infrastructure and not middleware. (It is hard to draw a line between
networking software and middleware software, so we will consider it in its
totality.) The total picture is illustrated in the Figure 1-5.

Figure 1-5 Middleware and associated elements

File failed to load: /extensions/MathZoom.js

file:///C:/Users/RON/Documents/EGDownloads/IT%20Architectures%20and%20Middleware/1.%20The%20Problem%20-%20IT%20Architectures%2… 4/10
2/4/2018 1. The Problem - IT Architectures and Middleware: Strategies for Building Large, Integrated Systems, Second Edition

In the context of the example, A and B are two elements: either one from
the presentation tier and one from the application tier or two
applications. For the purpose of this discussion, suppose that the two are
in different physical systems. The box around both indicates a complete
environment. There are eight numbered elements in the diagram,
collectively providing the necessary facilities for effective collaboration.

The first two, the communication link and the protocol, enable A and B to
send data to each other through a physical communications link, either
local or wide area. There are two sets of protocols: a network protocol to
carry data over the link and a middleware protocol to handle the dialog
between A and B. The two sets of protocols are complementary and
together provide the required degree of reliability, performance, and so
on. Different middleware protocols provide a wide variety of connection
types, for example, in terms of response time and guarantee of delivery.

The programmatic interface and the common format for data together
define the way that A and B communicate with the middleware. The
common format for data describes how the data should be structured so
that both A and B understand it, and the programmatic interface specifies
the way the data are presented to the middleware.

These four elements together are sufficient to ensure the required

communication between A and B. The other four elements are technical
and are concerned with ensuring the required degree of performance,
reliability, and so on. Insufficient attention to these four items will result
in a system that functions but is unsuitable for production.

Server process control concerns the way that the operating system,
middleware, and other software manage the scheduling and execution of
the applications and is crucial to performance, particularly scalability. For
instance, a failure to use resource pooling for threads, database
connections, and application components can severely restrict system
capacity and performance.

Naming and Directory Services provide the means of locating the

communicating elements, for example, for A to find B. These services may
be rudimentary or very sophisticated, depending on the size of the
environment.

Security is concerned with ensuring that the communication between A

and B is safe enough to meet requirements; it includes encryption,
reliable identification of systems, and granting permission for access.

Finally, Systems Management is concerned with the configuration,

operation, fault management, and performance of the environment—it
keeps the whole thing working properly.

The Integration Infrastructure (shown in Figure 1-4) is logical in the sense

that it makes no specific assumptions about its physical deployment.
Various structures are possible. One approach is to deploy the necessary
software in the presentation and application tiers, with just a network
connecting them. The infrastructure in this case may be thought of as a
bus connecting the different systems. Alternatively, a separate physical
system or systems could be deployed between the presentation and
application tiers. This could be called a hub approach. And the two can be
combined, with a hub handling some of the traffic and a bus structure
handling the other parts.

A critical point about the architecture discussed here, including its various
deployment strategies, is that the access channels are managed in the
presentation tier while the business logic resides in the applications. Their
role can be viewed as providing services to whoever requests them,
independently of the characteristics of any ultimate requester. It is up to
the presentation tier to manage device dependencies. The Integration
Infrastructure ties the presentation and applications together.
Applications can also request services of each other, again without regard
to characteristics of the requester. An architecture in this form is referred
to as a service-oriented architecture (SOA). Web services technology,
which is discussed in detail in Chapter 4, is a current approach to
standardization of SOA across multiple organizations on the Internet,
although it can be used within a single organization as well. We strongly
support the concept of service-oriented architecture with or without Web
services technology.

The architectural model is a framework for deciding which parts need to

communicate with which, how they do it, where any new logic should
reside, how existing applications are to be incorporated, how the
databases are to be handled, and how to deal with all the various technical
issues, such as performance. There are quite a few variations to juggle. It
is therefore essential to develop a number of alternatives, based on the

⬆
patterns just described. Each model has to be matched with the business
requirements, used as a framework for analyzing the kind of technology
required, and ultimately used to guide the choice of specific technologies
and products in those cases where there is a choice.

File failed to load: /extensions/MathZoom.js

file:///C:/Users/RON/Documents/EGDownloads/IT%20Architectures%20and%20Middleware/1.%20The%20Problem%20-%20IT%20Architectures%2… 5/10
2/4/2018 1. The Problem - IT Architectures and Middleware: Strategies for Building Large, Integrated Systems, Second Edition

1.3 WHY IS THIS DIFFERENT

FROM WHAT WE DID BEFORE?
If you look at the IT configurations of most organizations today, you will
see many standalone applications, each with its own presentation layer,
business processing logic, and database. We will call these silos. Silo
applications are represented in Figure 1-6.

Figure 1-6 Silo applications

The example company has six silos: Order Entry, Delivery, Warehouse,
Billing, Accounts, and Marketing. The problems described in this example
are typical: inconsistencies in the data, difficulties in creating a single user
view across multiple silos, and the lack of business process integration.
Sixty silos, not six, would be more typical of a large commercial
organization.

Silo applications were bought or built on behalf of departments in the

organization and were tuned to their requirements. Typically, those
requirements were to computerize paper-based systems and designed to
make that single department’s life easier. Now, several reorganizations
later, the departmental boundaries are different. What worked then does
not work now.

Observe that new tools and clever techniques such as reuse make it easier
to develop new silos even faster. In the past we might have developed a
few hundred applications using old tools; given the new tools, we could
have developed a few thousand more applications. Yes, the business
would have more functionality in its IT applications, but the problems of
fast response to business change and information accuracy would be just
as intractable.

Silo thinking is deeply embedded. Reasons include:

• Departments don’t want to lose power.

• Project management wants self-contained projects to control, often for

budgetary reasons.

• Development methodologies are silo based.

• There is a fear of large integrated systems.

• There is a fear of changing large existing applications.

Clearly, we think the fears are to some extent unjustified; otherwise, we

would not be writing this book. Nonetheless, there is genuine fear and
uncertainty.

Organizations are loathe to change their applications and are therefore

looking for ways to gain the benefits of integration without the pain of
touching the existing code. One alternative we call the “Surround
Architecture.” It is illustrated in Figure 1-7. The idea is to surround the
existing applications with a front end and a back end.

Figure 1-7 Surround architecture

Before going further, let us point out that in some cases this kind of
architecture is inevitable. If the application is bought from an external
software vendor and can be changed by only the vendor, then this kind of
File failed to load: /extensions/MathZoom.js
integration may be the only choice. If the application actually resides in a

file:///C:/Users/RON/Documents/EGDownloads/IT%20Architectures%20and%20Middleware/1.%20The%20Problem%20-%20IT%20Architectures%2… 6/10
2/4/2018 1. The Problem - IT Architectures and Middleware: Strategies for Building Large, Integrated Systems, Second Edition

different organization—in other words, the organization is part of an

alliance—this kind of architecture may also be inevitable. And silos are a
natural consequence of mergers and acquisitions.

But the surround technique should be kept to a minimum. A front-end

hub can be easily built to cope with 5 transaction types from one
application and 20 from another. But if you try to reshape the interface
for 200 transaction types in one application and 400 in another, the list of
rules will balloon to enormous proportions. Furthermore, recovery issues
make the front-end hub much, much more complex. For instance,
suppose your new presentation interface takes one input and processes 10
back-end transactions. What happens if the sixth in the set fails? You have
to programmatically reverse the transactions of the previous five.

Note, it is not that hubs are inherently wrong. The problems arise because
the applications being called by the hubs are not service oriented.

Turning to the back end, we are not against data warehouses, but a data
warehouse is much more effective if the data is clean. The notion of taking
data from multiple sources and reconstructing the correct form is
unrealistic. How can you take the name from one database, the address
from another, the phone number from a third, and reconstruct a correct
record? How do you know John Smith in one database is J. Smith in
another? If there are two phone numbers for a person, which is the
correct one? Of course, the last input data is the most likely to be correct,
but how do you know which one is the last by looking at the data? You
can’t!

An alternative strategy is to replace silos by packages. Many organizations

have a policy that they will use third-party application packages for IT
applications as much as is reasonably possible.

All the problems described with silo applications can exist with
applications packages and for exactly the same reason—they are
essentially stand-alone silo applications. Fortunately, many more
packages these days are taking a service-oriented approach and can be
integrated well with the rest of the organization’s IT. It is rare that an
organization can run using only one package, so some level of integration
is likely to be necessary.

Many of the techniques described in this book can be used on packages as

well as standalone applications. The big difference is that technology
choices are constrained. Since the architecture principles we describe do
not rely on a single technology or even a short list of technologies, most of
them apply for packages. For instance, in Chapter 14 on information we
describe the notion of achieving data accuracy by having a primary
database and controlled duplication of the data to one or more secondary
databases. This technique can often be implemented with packages. For
instance, let us suppose the data in question is the customer information.
You might have to write some code to create the flow of messages from
the primary database to the package applications, and you might have to
write code to process these messages as updates on the package database,
but it can be done. It is probably harder to make the package database the
primary, but of course, how much harder depends on the package.

1.4 REWRITE OR EVOLVE?

Given a decision to take an IT architectural approach, how can it be
implemented? There are two options: rewrite or evolve.

It is wise to be cautious about the notion of rewriting simply to keep up

with technology. If you had done so in the past, you would have first
rewritten the application into DCE, then again into CORBA, and again
into J2EE, and would now be looking to implement Web services. One
reason that IT architecture got a bad name is because many organizations
have had their IT architecture evaluated; the resulting studies are sitting
on a shelf gathering dust. A major problem with such exercises has been
their recommendation of technology-driven change.

What about occasional rewrites? There are again good reasons to be

cautious:

• The existing application works.

• All those concerns about scalability, resiliency, and security may have
been solved already.

• Rewriting is expensive and lengthy, during which time the business

cannot move forward.

• Rewriting is risky.

In the long term, rewriting can never be a strategy for success; at some ⬆
stage or other the organization will have to embrace evolutionary change.
To understand why, look at the graph in Figure 1-8.

Figure 1-8 The cost of rewriting

File failed to load: /extensions/MathZoom.js

file:///C:/Users/RON/Documents/EGDownloads/IT%20Architectures%20and%20Middleware/1.%20The%20Problem%20-%20IT%20Architectures%2… 7/10
2/4/2018 1. The Problem - IT Architectures and Middleware: Strategies for Building Large, Integrated Systems, Second Edition

Over time, a system’s functionality will increase and improve and the
rewrite will become larger and longer. The only escape occurs if the
rewrite can use new tools that are an order of magnitude better than their
predecessors. Suppose ten analysts and programmers have spent 10 years
extending an application; they have spent 100 staff years on the
application. For the same ten people to rewrite the system in 1 year would
require tools that deliver ten times the productivity of their old tools.

So when should you rewrite? First, rewrite when the technology is so old
that there are serious issues with support, such as a lack of skills. Second,
rewrite when the business functionality has changed so much that it’s
probably easier to rewrite than to modify.

It seems to be a fact of life that all of an organization’s important

applications need to change, and often organizations feel held back by
their inability to change their key applications fast enough. Changes run
along a continuum. At one end of the continuum there are changes with
the flow—changes that affect only a small, localized part of the existing
application, although they may add a large amount of new code. At the
other end of the continuum are changes against the flow—changes that
cause widespread alterations to the code. A simple example of changes
against the flow is increasing the size of an important field (e.g., product
code) where the field length has been hard coded in many places. During
the life of an application, changes against the flow are avoided, either by
not being done entirely or by developing a new module in the application
that overlaps in functionality and holds the same data. Sometimes a new
silo application is developed. Eventually, the cumulative effects of
avoiding hard changes are overwhelming; something has to be done.
There are two options:

1. A substantial change to the existing application

2. A rewrite

In our experience, the first option is often easier than many people
realize. For instance, in Chapter 15 we discuss putting a new end-user
interface on applications (e.g., a Web interface on an old screen-based
application). To do such a project requires substantial changes to the
existing application, but the changes often involve deleting rather than
rewriting code—paring the existing application to its core and then
rebuilding on the core. The way to assess the impact of major change is to
try it on a small part of the application. Perhaps give a programmer the
task of doing as much as possible in a set period of time (say, a few weeks)
and then see what progress has been made.

The skill in extending the life of an application is largely about making

against-the-flow changes earlier rather than later. Most important
applications have a backlog of change requests. Look at the changes and
assess whether they go with the flow or against the flow. Take the against-
the-flow changes and consider what needs to be done to the overall
architecture of the application to make them possible. Then decide
whether you need to rewrite.

If you do need to rewrite and the application is large, the rewrite will have
to be done in stages. Often a good preliminary to doing a rewrite is to
divide the existing application into chunks that are then replaced one at a
time. A huge advantage of such an approach is that if the project is
stopped for any reason, you will still have the benefit of a partial rewrite.

What does this have to do with architecture? Against-the-flow changes are

often changes to the architectural design. A key characteristic of a good
architecture is that it is designed for evolution. Applications today are not
islands; they are integrated. Against-the-flow changes can have
ramifications across many applications, especially, for instance, changes
to the database. We are looking therefore for an overall architecture that
is designed for evolution. The architecture itself is not implemented once
and then forgotten. It is something that should continually be kept up to
date.
⬆
From a technical point of view, design for evolution largely means that the
parts of the system have clearly defined functionality and work together in
the simplest way possible. A good starting point is following the principles

of a service-oriented architecture, which is discussed in Chapters 4, 5 ,

File failed to load: /extensions/MathZoom.js

file:///C:/Users/RON/Documents/EGDownloads/IT%20Architectures%20and%20Middleware/1.%20The%20Problem%20-%20IT%20Architectures%2… 8/10
2/4/2018 1. The Problem - IT Architectures and Middleware: Strategies for Building Large, Integrated Systems, Second Edition

and 6 . But this is only a start. Often the biggest stumbling block is

aligning the services with the business functionality and the business
information. We discuss this issue in detail in Chapters 11, 12, and 13.

1.5 WHO DEVELOPS THE

ARCHITECTURE?
As we work on architectures across the world, we often find that the
person nominally in charge of the IT architecture is (a) a technician
through and through and (b) somewhat detached from the rest of the
organization. Often that person or group is not really concerned with
architecture, but rather is the organization’s technology leader, the person
or group who searches out new stuff and tells the organization what might
be interesting. This job is important; it just isn’t architecture. Architecture
should not be described in a big document that is put on a shelf; It is the
high-level design that is developed during a project’s inception phase and
should be used throughout the project. The architecture is valuable only
when real problems are considered.

Trying to implement a design with knowledge only of the technology is

fraught with danger. It’s a bit like making a decision whether to go to
work by train, car, or bicycle without knowing how far you have to travel.
If the technologists know little about the application, they will be forced to
overengineer, to build a Rolls Royce when a Mini would do.

Trying to design an application without concern about the technology is

also dangerous. Suppose you program your application and demonstrate
it on a portable PC. It may work wonderfully, but try to scale it to work
with 1,000 users and all kinds of problems arise. A specific example may
make this clear.

One of us attended a conference on architecture where one of the

presentations was a case study of an application to process sales figures
from a large number of retail outlets. A core part of the application was a
data-collection process, followed by a daily batch run to update the sales
database. An architecture was defined and a fashionable run-time
environment technology chosen. The development progressed, and a test
was set up to run a representative daily run against the database; it took
over 24 hours. After a lot of work, the figure was reduced, but it was still
not very good. The matter was made worse by the fact that the technology
had minimal batch facilities. If sufficient attention had been paid to the
technical aspects of the chosen environment at the architectural stage, a
lot of the problems could have been avoided.

These points are explored in Chapters 7 through 10 on resiliency,

performance, systems management, and security.

So during the inception phase both technologists and application

designers are required, as are, for much of the time, representatives of the
business. Looking again at the example, notice that a service-oriented
architecture solves only one of the problems—the need for channel
independence. Another problem was keeping track of a business process,
in this case the status of an order. There is no technological solution to
this; it is a high-level application design problem. It requires aligning the
services with the business processes. Another problem was the quality of
the data and the major question of whether we want one or multiple
copies of a piece of information. These are application architectural issues
and are discussed in detail in Chapter 12 on business processes level
design. Essentially the argument is about distributed versus centralized
applications and databases. Only by building up a picture of how
applications and databases support the business processes can we derive
or discern detailed performance and resiliency requirements. This in turn
influences technology decisions, which also relate to distribution
decisions. For example, a particular configuration may need a high-speed
network that is prohibitively expensive. Finding this out early allows the
opportunity to choose another architectural design and avoid spending
time and money that cannot be recouped.

One of the main aims of this book is to teach the application designers
enough about the technology and to teach the technologists enough about
application design so that they can all participate in these discussions.

1.6 SUMMARY
In this chapter, we set the scene for the rest of the book by explaining the
most important concepts concerning architecture and its implementation.

The key points are:

• When faced with implementing new requirements such as those in the ⬆

example, avoid one-off solutions. Instead, develop an architecture as a
framework for matching requirements against design and discussing
technology options. The architecture should address current requirements
and anticipate future needs. Expect a number of iterations at this stage
File failed to load: /extensions/MathZoom.js before arriving at a workable solution.

file:///C:/Users/RON/Documents/EGDownloads/IT%20Architectures%20and%20Middleware/1.%20The%20Problem%20-%20IT%20Architectures%2… 9/10
2/4/2018 1. The Problem - IT Architectures and Middleware: Strategies for Building Large, Integrated Systems, Second Edition

• The architecture separates the applications logic from any presentation

required by access channels. It is a service-oriented architecture, where
the applications deliver services regardless of the requester. This is the
goal.

• Follow an evolutionary approach when implementing the architecture,

avoiding large-scale rewriting unless there are extremely good reasons
(e.g., the business is now run on entirely different lines). Rewriting for the
sake of technology alone is a mistake. If a rewrite is absolutely necessary,
it is best to do it gradually, introducing new functionality in stages.

• Ensure that the technical issues are addressed up front to avoid

developing systems that work functionally but are operationally unusable.
Do this by making sure that architects work with people who understand
the technology and the applications, and who can refer to and consult
those who understand the business.

• Finally, do not finish the architecture and then leave it on a shelf to

gather dust. It should be regarded as a living document, updated and
revised as necessary so that it continues to be useful.

Recommended / Queue / History / Topics / Tutorials / Settings / Get the App / Sign Out
© 2018 Safari. Terms of Service / Privacy Policy
PREV NEXT
Acknowledgments 2. The Emergence of Standard Middleware

File failed to load: /extensions/MathZoom.js

file:///C:/Users/RON/Documents/EGDownloads/IT%20Architectures%20and%20Middleware/1.%20The%20Problem%20-%20IT%20Architectures%… 10/10