Subject: [sfc] On architecture constraining solutions (or not)

From: Thomas Narten <[email-masked]>
Date: Sun, 20 Jul 2014 14:32:41 -0400

At Fri, 18 Jul 2014 20:38:12 +0000, Lucy yong wrote:
> > I suspect that there are two separate but related issues.
> > 
> > The architecture we proposed, and probably any useful archtiecture,
> > does constrain solutions.  In adopting an archtiecture, the working
> > group makes some choices.

> [Lucy] not so sure. We should adopt an architecture without making
> solution choices ahead. The architecture leads solution development,
> not the other way.

> At the same time, those constraints should general, not specific, and
> certainly not aimed at the NSH solution in particular.

> [Lucy] Yes and Agree.

<Not wearing chair hat>

I want to call out this point, because it is important. IMO, the
architecture absolutely can and should make choices that constrain
solutions. An architecture that doesn't constrain solutions, seems to
me to not be an architecture at all -- it suggests anything is allowed
and nothing is disallowed. (I'm exaggerating a bit to make the point.)

That said, the architecuture shouldn't exclude or prevent things that
that the WG deems important to support. But it is neither the job of
the WG (nor helpful) to try to support any/all hypothetical
possibilities. We are supposed to be solving real problems with real
requirements with a goal of developing real solutions. The
architecture needs to support that. But no more.

An important point of an architecture it to outline at a high level
what will be supported and what won't be supported -- and to make
choices at a high level about solution directions. By definition, that
means solutions will be constrained.

So yes, making architectural decisions that constrain solutions is
OK. Of course, the WG should be aware it is making such choices and
should be in agreement with making any such constraints.

Thomas

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Mon, 21 Jul 2014 12:50:28 +0000

What some people are probably asking for is a functional design doc. But the WG didn't decide for that, although in systems design you typically have the chain 

requirements spec -> functional spec -> system architecture -> design specs ......

The functional spec does not describe the internal machinery of a system but its behavior and interaction with the outside. Like ingoing flow -> blackbox action -> outgoing flow, where outgoing flow may mean specific modified transport behavior, modified payload, something else.

Architecture describes the information flow and information processing in some more detail. Therefore an architecture doc is the first step towards one of probably multiple solutions. 

Having this in mind Joel's merged architecture exactly does what an architecture doc should do.

What do you think?

Kind regards, 
Walter

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Thomas Narten
Gesendet: Sonntag, 20. Juli 2014 20:33
An: [email-masked]
Betreff: [sfc] On architecture constraining solutions (or not)

<Not wearing chair hat>

I want to call out this point, because it is important. IMO, the architecture absolutely can and should make choices that constrain solutions. An architecture that doesn't constrain solutions, seems to me to not be an architecture at all -- it suggests anything is allowed and nothing is disallowed. (I'm exaggerating a bit to make the point.)

That said, the architecuture shouldn't exclude or prevent things that that the WG deems important to support. But it is neither the job of the WG (nor helpful) to try to support any/all hypothetical possibilities. We are supposed to be solving real problems with real requirements with a goal of developing real solutions. The architecture needs to support that. But no more.

An important point of an architecture it to outline at a high level what will be supported and what won't be supported -- and to make choices at a high level about solution directions. By definition, that means solutions will be constrained.

So yes, making architectural decisions that constrain solutions is OK. Of course, the WG should be aware it is making such choices and should be in agreement with making any such constraints.

Thomas

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc