Choosing the "Right" Architecture
When presented with an application challenge, we often have to choose a
workable
approach from myriad alternatives to implement the design. As when building a new house, the choices you make determine how well it holds up and meets your customer's or your personal needs when it's used or abused, or when a
hurricane
blows through. Your design and implementation (the way you build your house) also determine how easily you can add a new wing or simply remodel the kitchen. Your design and implementation also determine whether or not the building inspector will approve your home for
occupancy
or force you to go back and add bathrooms. Yes, there are always constraints. Just as building codes, the homebuilder's budget, and the site
chosen
dictate
what kind of house you build, software
architects
and developers are limited as to budget, schedule, integration with existing applications, databases or operating systems, and what the boss's nephew thinks the program should do. Experience
tells
us that "people" issues often play a pivotal role in the choice of architecture. As architects, mentors, and
consultants
, we all must concern
ourselves
with training (or
retraining
), installation and deployment, and licensing costs (
assuming
your company actually pays for its software), as well as myriad development issues. We've all seen situations where the company was dead-set against one or more architectures long before we arrived and no amount of logic would shake them from this opinion. Perhaps, the company has built their system up over several decades and, due to its immensity, can't possibly change it. While these situations are not always dire, they can significantly impact the success of your working relationship and your ability to provide a "best practice" solution.
Sometimes (
fairly
often, in my experience), you'll be called on to modify, repair, or
resurrect
an existing applicationperhaps one you didn't design or write and all too often based on a design that you can't endorse. Perhaps the company is looking for validation for an architectural approach or some way to provide independent credibility for a decision made about the application.
Office politics is another factor that often plays a big role in application design. If I've learned anything over the last thirty-some-odd
years
it's that people are very sensitive about their creative ideas. Criticizing their design is tantamount to saying their kid's face resembles a pig's butt (even though it does). They also tend to be defensive about designs sold to upper management or suggested by someone they respect. If the design fails or is somehow flawed, someone's career might be in jeopardy. When you approach an existing design, consider who created it, its history, and the motivation behind that approach before you add your offhand or well-
considered
comments.
IMHO
Criticizing a customer's design is like telling them their kid's face resembles a pig's butt.
I lost count of the number of times someone has asked about a problem with their application only to tell us that they didn't really have a choice as to a better (best practice) alternativeit's not their design. I expect many of you have worked with customers who tell you how to design the system down to the finest detail but blame you when it does not work as they expected. Doctors have the same problem when a patient who's been watching the 6
PM
news decides that they have every disease the pill-pushers are advertising. It's hard to know what to do in these casesthere is no simple answer. Do we tell our customers that their design won't work, it's somewhat "challenged," or do we
carefully
outline specific problems and areas of concern? We could just walk away and lose the account to someone who needs the job or doesn't know better.
My approach has been to try to prevent these problems in the first place by mentoring the customer as the specification is written and work with their team to better understand the issues, challenges, and dependencies before the design is set in stone. If I
arrive
on the scene too late or they insist on a challenged design, I insist on documenting our concerns and either walk away or do the best I can given the constraints. Frankly, sometimes it's best for everyone if I
turn
down projects with a doomed design. It's like trying to repair an engine that melted down to a puddle trying to deliver 5 tons of
bricks
with a ¼-ton Toyota pickup. Sometimes, it's cheaper and easier (in the long run) to get a new truck that's better designed for the load. As we've all seen, even the most prestigious
leaders
have trouble knowing when they're in over their head and admitting they made a mistake in judgment.
On the other hand, perhaps our skills are not a good match for the project. Consider this: When surgeons approach a patient's problem, they try to solve it with a scalpel because that's the tool they know best. When chiropractors approach the same problem, they try to solve it with an "adjustment," just as a podiatrist would use a lift or an orthopedic shoe. In the same way, when a programmer that's worked exclusively with JET/Access databases approaches a problem, they're likely to design the solution with JETeven though it's rarely the best fit. In the same way, ASP developers tend to choose browser-based solutions just as Windows Forms developers tend to choose a client/server approach. Unfortunately, too many developers choose an approach because it's new or sexy or has "XML" in the
name
instead of the approach that best fits their customer's requirements. In our world of specialization, consultants and developers often have to know when their skills and specialties apply to the problem at hand and when they don't. If you encounter problems that can't be
solved
with your skillset, you need to get more training, do more research to add more skills and talents to your toolbox, refer the problem to a specialistor know when to back away. I assume that's why some of you are reading this book.
|
