Information Technology Reference
In-Depth Information
Ashby gives another example of an aircraft. An aircraft can only move
in a constrained manner; it cannot jump to any portion of the sky instantly.
It is constrained by its speed, power, position, technology, etc. Only
because there is this constraint, another system — an air traffic control
system — can hope to manage or regulate the aircraft.
Software gets enhanced with new features when the variety in the
software system (the regulator) tries to match the increased variety in the
environment (the business). More variety in the regulator is good. A rigid
system will fail when it encounters a situation that it cannot “match.” In
software, design constraints are sometimes applied early in the life cycle
that drastically reduce the variety of the delivered system. For example,
one may decide that only IE (Internet Explorer) browsers will be sup-
ported. If the variety in the market is higher (i.e., many customers use
other browsers), then the early choice has reduced the variety of the
software delivered in a manner that may make it unacceptable later on.
Ashby's work provides an excellent and underutilized approach to
systems design. System designers should view information systems as
regulating systems, with the requisite variety designed to match the envi-
ronments in which the systems will be deployed. The Law of Requisite
Variety encourages one to take a total systems view. While simple models
can be powerful for the purposes of design, the underlying assumptions
should not be too simplistic. They must have the requisite variety in their
range of actions to match the variety required in real-world applications.
Most See, Very Few Observe
There is a vast difference between desires (wants) and requirements
(needs). Customers usually have desires. The observant business analyst
converts these desires into requirements. Architects and designers use the
most suitable technologies to satisfy these requirements. They should have
a keen sense of the prevailing trends in the surrounding environment,
while proposing a solution that meets the requirements. This sense is the
key to success in software, an effort that one must undertake keeping in
mind that the up-front investment is sizeable, development is complex,
time to market is long, and barrier to entry for competition is fairly low.
As a creator of software, one would like to look ahead and deliver solutions
that meet future, perhaps unanticipated needs. Architects and designers
need to recognize new trends that could be leading indicators of some
important changes that may become evident later. Radio waves and
cathode-ray oscilloscopes signaled the advent of television. Similar exam-
ples are strewn throughout the history of computing. Microsoft and Apple
were the first to observe the need for greater power and flexibility in the
