We left the Analyst in front of the white board, drawing circles and arrows. She was engaged in the primal act – Creation. Out of the formless Requirements Void was emerging the Light of a Solution, an Architecture. Or at least the Components of a Solution.

Well, we don’t need to code this system; we are going to buy it (most of it, anyway). But we need more than a formless functions and features list. Why?

Well – I’m a confirmed believer in Structure-Function; that is, the critical relationship between a system’s structure and its function. We want to buy the solution that supplies most of our needed functionality. We also want to buy the Solution that makes sense Architecturally – has Components that perform the high level functions that map to our high-level needs.

The best way to get a fit architecturally is to be able to articulate to the prospective Vendors what components we want to buy, and what they must do. A mis-match between the shape of the solution we think we need and the shape of the solution a Vendor proposes is a warning Flag. Plus, if you can articulate an Architecture you have a better way to look at what the Vendor is offering; what you are buying is Modules, not Use Cases or Features.

If you were looking for a solution for transportation, would you by a machine that had a seat, pedals, handlebars, a light, but no wheels? What if the vendor promised that a modification of the pedals supported the transportation function, and the seat was much superior to the competition?

Because of the immense flexibility of software, a vendor with a mis-match to your requirements can represent that the Package can support this or that requirement. We have all worked on software that has been patched beyond its original design, and beyond recognition. To minimize problems and customization, I want a solution that maps pretty well architecturally to my list of Components. If I can't find a Product like that, that’s a warning sign that I may have left out some critical pieces, or that I am describing a need that is best met by two (or more) packages.