Bounded Solution Spaces
As a result of an interesting e-conversation with my friend Charlie Alfred, I concocted this bogus graphic:
Given a set of requirements, the problem space is a bounded (perhaps wrongly, incompletely, or ambiguously) starting point for a solution search. I think an architect’s job is to conjure up one or more solutions that ideally engulf the entire problem space. However, the world being as messy as it is, different candidates will solve different parts of the problem – each with its own benefits and detriments. Either way, each solution candidate bounds a solution space, no?
Categories: technical
linkedin, software architecture, software design, systems engineering, thinking
Leave a Reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
Agree. The interesting challenge becomes how to decide between Solutions 1, 2, and 4. It could be based on how *many* requirements are satisfied by each. This doesn’t account for relative importance of requirements, or how much the size of a missed requirement matters.
SEI’s CBAM (Cost Benefit Analysis Method) has an interesting take on this. My question is if it is possible to evaluate the cost/benefit of an architecture, why not approach the problem that way in the first place.
Charlie
Sorry Charlie, but I don’t think I understand your last sentence. Sounds like the cart before the horse? How can one evaluate an architecture without an architecture to evaluate?