Hard problems [Re: Standards]

[James Kempf]

Hi John,

I think you've put your finger on the problem quite well.

            jak


----- Original Message -----
From: "John C Klensin" <john-ietf at jck.com>
To: "James Kempf" <kempf at docomolabs-usa.com>
Cc: "Brian E Carpenter" <brian at hursley.ibm.com>;
<problem-statement at alvestrand.no>
Sent: Wednesday, February 26, 2003 1:44 PM
Subject: Re: Hard problems [Re: Standards]


> James, Brian, and others,
>
> I think that there is a separate, but confounding problem
> here.  It isn't really "architecture", at least as I think we
> have been using that term.
>
> As many people have observed, a common, and often successful,
> engineering technique is to take a complex problem, divide it
> up into manageable pieces or modules, and then work on, and
> solve, the pieces one at a time (perhaps deferring those that
> are least important and/or least tractable forever).  But the
> pieces have to fit back together.  If they don't, it implies
> that the modularization was wrong.  That modularization is a
> major element of the architectural issue, and we too often
> ignore it when we start breaking up problems into little,
> easy-to-solve pieces.  Sometimes we get away with ignoring it,
> and sometimes we don't.
>
> But there is a separate issue that manifests itself in
> interactions and side-effects among modules.  When we are
> lucky about the large/hard problems we pick, we can modularize
> things in a way that eliminates such interactions.  But
> sometimes we aren't lucky.  In those cases, we really need to
> look at the overall problem space, or the whole set of
> modules, as a systems problem: everything potentially
> interacts with everything else, and everything either works
> well together or doesn't work well at all.  More important,
> design tradeoffs must be made with regard to the whole system,
> not what would work well for any particular module or
> component.   "90% solutions" may be satisfactory for these
> situations, or may be completely useless.  And, like it or
> not, economic factors and implementation and deployment issues
> are often part of the system.
>
> Ignoring the systems issues can easily get us to a solution
> that works perfectly well, but doesn't interwork well with
> things with which it needs to interwork and, consequently, is
> of no practical use to anyone.
>
> When the hard problems come along, we don't do as much
> architecture as we should.  But where we really seem to break
> down is in doing careful and comprehensive systems analysis.
>
>     regards,
>        john
>
>
>
> --On Wednesday, 26 February, 2003 09:43 -0800 James Kempf
> <kempf at docomolabs-usa.com> wrote:
>
> > Brian,
> >
> >> So, we have a problem about how to tackle hard problems
> >> (a.k.a. architectures in some circles). I think you'll find
> >> that is already covered in the draft, so I'm not sure we're
> >> advancing the charter here.
> >>
> >> I will comment, however, that the Global Grid Forum,
> >> although a beginner in this game, has already come up with
> >>...
> > This issue was discussed at the IESG/IAB retreat last fall,
> > and there were some objections noted. One was that such
> > working groups tend to attract people who have little, if
> > any, implemenation experience and therefore result in designs
> > that may have implementation problems or require the working
> > groups doing the protocol design to iterate with the
> > architecture group to get rid of such problems. Most of the
> >...
>
>