Managing Market Chaos
Managing Market Chaos
by: Tom
Anderson
Over the
last decade, we have seen the technology market move through several continuous
cycles
of growth. As Moore's
law continues to unfold, hardware price-performance points improve.
As they do,
the capability and capacity for software systems grows. The increase in
processing power fuels the
software industry and sets the foundation for increased change.
As technology
improves, business software systems must remain adaptable, flexible and
extensible. Even in
relatively static technology stacks, such as legacy Cobol applications,
adaptability, flexibility and extensibility
are all vital characteristics of systems that retain long life spans.
Little is
certain, but life dictates, "the only constant is change". If
the technology doesn't change, the
business elements of our software certainly will. We can take certain
proactive steps that will help insulate
us from changes and also help us manage those same changes. Two things
are certain: 1) we can not predict
change 2) we can not prevent change. Managing change may be best accomplished
by first understanding
what causes those changes.
Market
Chaos
Through out recent technology history, we've seen fantastic innovations.
We've come from running the CP/M
operating system on a TRS-80
in 16kb of RAM to a spanking new Pentium 4, running at 1.6 Ghz on a motherboard
capable of hosting 1 GB of RAM. Talk about an order of magnitude! Give
some thought to the following program...
5 Rem Sample Program
10 print "Hello World"
20 goto 10
30 end
It will run
the same on either of those pieces of hardware. Despite all the new horsepower,
simple constructs
like this will still work the same, right? So why do business software
systems seem to change so frequently?
Obvisouly, there is a level of complexity in business that is not present
in "Hello World". If we assume the business
complexity is a constant, then we are left with the technology itself.
Changes in our hardware and software platform
are responsible for driving much of the constant change in our systems.
Vendors are constantly changing their
products to offer us new capabilities and extending their platforms to
take advantage of all those available CPU
cycles. We want more, better and faster software ---- constantly.
The key to
managing change is to contain changing dimensions of you system behind
well defined, managed
interfaces. By isolating the elements in your software interfaces that
MAY change or are out of your direct
control, you can better manage the impact and scope that vendor changes
will have on your systems.
By layering
your system functions and creating well defined API's that you control,
you can control not only
what happens when a vendor changes their software, but you can also minimize
the impact to your systems
when you decide to change vendors. Historically, the software community
has called this type of approach reuse.
A good reuse policy can help to effectively
manage change We are suggesting that changing elements be
encapsulated even if they are not candidates for reuse.
Layering
Insulating yourself from changes in technology can be accomplished primarily
by using healthy amounts of
abstraction and encapsulation to layer your business software systems.
Applications
have followed multi-tier design concepts for several years now. This approach
implies
that you have several layers in your application design. Even in legacy
systems, data services and
application services have been separated from the presentation layer.
At each touch-point
in an application structure, consider creating a well-defined layer that
insulates your
application functions from the vendor software functions. The diagram
below shows an example:
Within each
layer, there may be additional layering to wrap vendor specific functions
and applications within
your own API. Once vendor functions are encapsulated within an API you
control, you've protected yourself
in a small way against changes by the vendor to their code libraries and
provisioned for changing to a new
vendor in the future.
Managing
Changes
The concept of creating well defined interfaces which wrap vendor specific
code can also be laid overtop of
dynamic business elements. Your business units will have constantly changing
requirements which need to be
managed. Creating an abstract interface into the software which defines
those rules will protecet the consumers
of that interface from changes underneath. Additionally, you may represent
the essence of the business
rules
in the data repository. By doing this, they become far more manageable.
Very little business data should ever
be hard-coded within an application structure. Storing business data elements
in the data repository means
that they are by nature dynamic and can change as the business changes.
In the model
above, the business rules layer simply becomes an evaluation engine or
API into the data repository.
Design
Patterns
Abstraction, encapsulation and the creation well defined API's are hallmarks
of good system design. Another way
of protecting against change is to fall back on a good design of the business,
data and process elements that
make up a system. For example, have an Object Model or ER-Diagram built
at a conceptual level, without a specific technology defined, allows system
builders to re-use those designs on completely different technology platforms.
Many data
engineering tools allow us to build data models using abstract data types,
whose actual DDL definition
is not decided upon until a Physical data implementation is chosen. This
allows us to define and solve the business
problems at hand and wait until fairly late in the design cycle to make
technology choices; again insulating us
from change in the marketplace.
A good object
oriented design, may be implemented over and over using various technology
platforms. A good OID
(object interaction diagram) and Object Model may be used to conduct an
implementation in Smalltalk, Eiffel or
Java. Without good abstract designs, you will be bound to the solution
as it is implemented with the technology
you have chosen. Abstract designs permit people to understand the elements
and solution to the business problems
without being encumbered by the technology.
J2EE
A very specific model of this architecture can be drawn using Sun's
J2EE architecture. The diagram below shows
one
possible example of this architecture:
 
You will
notice several things in this diagram.
- Data is
never directly accessed by any application layer functions. It is always
accessed either through a
view or by a stored procedure
- Data is
never directly accessed from the presentation layer. It is always accessed
through the data access
and business rules layer. The business rules and data access provide
a well defined API, behind which you
can hide the specifics of technical implementation details. This can
be easily implemented by using object
oriented design patterns and creating a set of abstract java classes.
- Presentation
data should be malleable and be able to be reformatted to the appropriate
client. XML using
XSL transformations gives us this capability
Summary
The inevitability
of change will force to either spend time and money to keep pace or will
inspire us to
innovate methods of protecting our substantial investments in software
systems. Isolate the changing
aspects of your systems and encapsulate them well. This will give you
the insulation you need to protect
your systems from "Market Chaos". Abstraction of business rules
and vendor functions into a clearly
defined API will help protect our substantial investments in business
software systems.
Here are some additional links to interesting articles on managing change
in the software environment:
|
