Choosing the Right Architecture


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.




Hitchhiker's Guide to Visual Studio and SQL Server(c) Best Practice Architectures and Examples
Hitchhikers Guide to Visual Studio and SQL Server: Best Practice Architectures and Examples, 7th Edition (Microsoft Windows Server System Series)
ISBN: 0321243625
EAN: 2147483647
Year: 2006
Pages: 227

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net