Designing around an existing product
Been in a situation, wherein the design of an application occurs after the choice of a third party application has already been made? If you have, I am guessing you are sporting a wry smile right about now.The purist within every software architect yearns to have the requirements and design fleshed out before any purchasing decision can be made. Yet as many of us have found out the hard way, it does not always happen. So what is a poor software architect to do? One option is to throw ones hands up, update your resume and browse Dice(;-)). That is not a bad option, in my honest opinion, but for those who actually are foolhardy enough to persevere here is one general approach.
1. Understand your requirements in detail. This includes all the nitty gritty. Be humble, ask questions, gain context and proceed. If anything will make your job in the future easier it will be this one step. Oodles of big money has been spent in creating a unicorn to be worshipped when all the customer wanted was a horse to ride.
2. Understand the third party application. You may hate doing this, but you have to. If nothing else, this exercise will improve your character and at the end of the day is this not what matters? :-) I have found it helps immensely, if the off-the-shelf product that has been foisted on you actually comes with a manual or documentation - the more the better. If you are this fortunate then read away. Identify in detail the features of your new toy, its mannerisms, fancies, dislikes and shortcomings. Make sure you have a crystal clear picture of the API, configuration settings, and hardware/software needs. If you are one of those poor unfortunate souls who must fathom the ocean with nary a map, then accept my apologies and head out the nearest window. (just kididng) On a more serious note, you could befriend one of the developers or vendor contacts and ask them to enlighten you on the workings of their marvel. Believe me you a learn a lot more a lot faster when someone gives youa big picture overview and the key principles of an application.
3. Understand what the gaps are. Essentially at this juncture, you are trying to determine and list out the requirements that are needed that cannot be provided by your application. This includes functional and non-functional requirements. Having this list gives you an idea of the magnitude of the mess you are in.
4. Identify a set of options that you could use to bridge the gaps that exist. For example, you could build a wrapper, use an ancillary application, or some other option that fills in the missing functionality.
5. From this point on, if you are worth your salt, things should be straight forward. (Yeah right...) Your task in now simplified to designing for the gaps that exist using one of the options that you have come up with.
As any good architect should, make sure you document all of your decisions, assumptions and thinking. That will help the developer that takes up your design have an easier time than you did. Is that not why you are paid the big buscks!!
I have found that attaching a Notes to the developer section to my design helps a lot or if you feel really gracious about it walk them though it, step by step. ;-)
(c) 2005 Vivek Pinto For more details please visit us at Wonomi Technologies
posted by vivek pinto @ 7:11 PM
1 comments
