Charlie Alfred’s Weblog

March 24, 2015

Architecture of the Problem 2

Architecture of the Problem 2

Architecture of the Problem is a term that was concocted to describe the nature of a problem and its formulation which enabled an effective architecture

The outline that was in this post has been subsumed by: Architecture of the Problem which discussess this topic.



  1. Hi CA,

    You’re outline seems to cover a very wide scope. Instead of a blog post, maybe you want to write a book that weaves/connects all of your ideas together? I’d surely buy it.

    A couple of comments/observations
    1) Abstraction is a key tool for simplifying complexity? IMO, it’s a tool for managing, and reasoning about, essential complexity. Essential complexity can’t be simplified; hopefully it can be understood and managed.
    2) Scrum stories are better than requirements? That’s arguable, and context-dependent πŸ™‚
    3) IMO, requirements are a tool for specifying what an impending candidate solution (regardless of the form the solution takes or what technologies it employs) must do, and how well it must do it, to ameliorate the “perceived” problematique (i.e. Ackoff’s “mess”).

    I look forward to reading your post. Thanks for the invite to comment!

    Comment by bulldozer00 — March 24, 2015 @ 4:43 pm | Reply

  2. Hi BD00. No chance of a book any time soon. It was exhausting enough writing a book chapter a couple of years ago. Couldn’t imagine doing that at the same time as chemo!

    1. You refer to essential and accidental complexity like Frederick Brooks would. What I meant (damn outline) is that if I refer to a dog and a cat as mammals, I am simplifying things by ignoring their essential differences. I do this at some risk, because I’m likely to get a negative reaction feeding dog food to a cat. The essential differences between a dog and a cat remain. All I do to “simplify” is reduce the categories and relationships. We both have valid takes here.

    2. This is a just a personal preference. IMHO, requirements are great for describing the list of outcomes that MUST be satisfied, using a set of simple declarative statements. I don’t like that the format of requirements makes it difficult (if not impossible, depending on the software process) to specify context, conditionals, and utility curves. What I like about stories is that the format permits all of these.

    3. I think that stories are good on the front end as input into architecture and prototyping. Requirements are better to capture the back-end, as input to development and verification. Too bad there is not enough time to do both. Maybe we’ll get a natural language tool to extract requirements from stories πŸ™‚

    Comment by charliealfred — March 24, 2015 @ 6:21 pm | Reply

    • Agree re: stories vs. requirements – requirements are distilled from reconciling the overlapping stories from different contexts

      Comment by Gene Hughson — March 25, 2015 @ 9:07 am | Reply

      • In my world, it’s the other way around. We develop specific user stories from higher-level, more encompassing, requirements that we’ve committed to deliver to our customers under contract. As Bertrand Meyer says in “Agile!”, if all you do is develop a system to implement specific user stories, your system will only provide a bunch of (perhaps fragmented) user stories. You’re out of luck if you’re a user who wants to do something that slightly deviates from the sequence of a specific story. Requirements are intended to cover the deviations. They might not do this 100% in practice, but that is one of the intents of using them over and above user stories. I think the best thing is, as Charlie hinted above, is to use both of them: Requirements->user stories->design->code/test/integrate/test.

        Comment by bulldozer00 — March 25, 2015 @ 10:51 am

      • Here’s my hangup (and it’s a terminology thing, but hey…) – requirements, in my opinion, have to be the result of some prior problem definition (because they state what’s “required”). If they’re a first-order thing, then I can “require” something that violates the laws of physics and kill the project – it cannot succeed because it cannot deliver what’s required. While most products won’t have such a blatant stumbling thrown in, I’d say there will be conflicting desires on the part of the stakeholders more often than not. If stories are a bad choice (due to the Agile connotations), then perhaps capabilities is a better choice. Either way, IMHO, requirements need to proceed out of some problem-definition process that captures all (to the extent possible) contexts that need to be covered.

        Comment by Gene Hughson — March 25, 2015 @ 11:50 am

      • I think the question comes down to semantics more than process. What is a requirement, really? Are they well-formed (clear, atomic, testable, consistent, and complete?) Bread can be made from dough, but bread is not the same as dough. My guess (and it’s just a guess) it that BD00’s “requirements” are more like value expectations than requirements.

        I certainly agree that you need to have *something* to frame user stories. I just don’t think they meet the acid test for requirements, no matter how many times the executive pounds his shoe on the table. The root of the word requirement is “require”, which implies that said requirement is known to be feasible!

        So, if you morph BD00’s “Requirements->user stories->design->code/test/integrate/test” into “Contexts=>Value Expectations =>Challenges=>Prototype =>Architecture/Design => Implement/Unit Test”=>System Test” then I’m on board!

        Comment by charliealfred — March 25, 2015 @ 12:15 pm

      • I agree, Gene. For requirements to be useful, they have to be feasible. The other issue is that 2 requirements can conflict (i.e. force tradeoffs). For example, suppose requirement A said that a plane had to be safe, and requirement B said that the passenger windows needed to open? Both requirements are clear, testable and feasible at face value. But safety goes out the window (literally and figuratively) if you open the passenger window at 35,000′

        Comment by charliealfred — March 25, 2015 @ 12:19 pm

      • “But safety goes out the window (literally and figuratively) if you open the passenger window at 35,000β€²”

        Dang! There goes my design for a submarine convertible πŸ™‚

        Comment by Gene Hughson — March 25, 2015 @ 12:39 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at

%d bloggers like this: