Hard problems [Re: Standards]

John C Klensin john-ietf at jck.com
Wed Feb 26 16:44:29 CET 2003

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.


--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

More information about the Problem-statement mailing list