It’s important to remember when architecting a system that maintenance
will, in the long run, consume more resources than initial development
of the project. Short cuts taken during the initial development phase
of a project can result in significant maintenance costs later.
For example, you may have been informed that unit tests don't deliver
direct value and so you tell your developers to skip the rigorous
application of them. This makes the delivered system much more
difficult to change in the future, and decreases confidence when making
those changes. The system will require far more manual testing for a
smaller set of changes, leading to brittleness and increased
maintenance expenses as well as a design that's not as appropriate as a
fully-tested design (let alone a test-first design).
A serious architectural mistake that is sometimes made is to adapt an
existing system for a purpose that it is not fit for, on the basis that
using an existing system somehow reduces costs. For example, you might
find yourself utilizing BPEL architectural components coupled with
database triggers to deliver an asynchronous messaging system. This
might be done or insisted upon for reasons of convenience or because
that is the architecture is known to you or the client. But a
messaging architecture should have been selected in the first instance
after requirements made it clear it was a necessary component. Poor
decisions made at the inception of a project make it much more
expensive to re-architect the system to meet new requirements.
In addition to avoiding short cuts during the initial development
phase, it’s also important to correct poor design decisions as quickly
as they are discovered. Poorly designed features can become the
foundation for future features making corrective action later even more
costly.
For example, if you discover that inappropriate libraries were selected
for some underlying functionality they should be replaced as soon as
possible. Otherwise the effort to make them fit evolving requirements
will result in additional layers of abstractions, each designed to
hide the poor fit of the previous layer. You are building yourself a ball
of tangled twine, tack, and sticky tape and with every layer you add,
it is harder to unravel. This easily results in a system that is
resistant to change.
As an architect, when you encounter an architectural problem or design
flaw insist that it be rectified now, when it cheapest to fix it. The
longer you leave it to drag out, the higher the interest payment is.
by Scot Mcphee
This work is licensed under a
Creative Commons Attribution 3 licence

RSS