EA Principles, Policy, Standards & Guidelines

Ahhh... now I understand... We are discussing architecture requirements, rather than architecture principles! All those terms - must, should, could, would, may - suddenly start to make sense!

On Sep 15, 7:18 pm, Adrian Miley wrote:

> Derek,

> Yep, I agree – that article I referenced deals with all three points.

> However, to clarify the SHOULD bit, the “EXCEPT WHERE” clauses should
> explain the only circumstances where the principle doesn’t apply and
> if there is a conflict between two (or more) principles then it’s
> probably because the exceptions need updating. RFC-2119 mentions this
> by saying ““..mean that there may exist valid reasons in particular
> circumstances to ignore a particular item, but the full implications
> must be understood and carefully weighed before choosing a different
> course.” However rather than leave it to the individual to decide that
> a SHOULD statement didn’t apply to them I just reinterpreted that as
> meaning “MUST … EXCEPT WHERE”.

> This I think defining of exception when they are encountered is a
> natural part of the evolution of a set of principles.

> The approach I normally take whenever I’m building from scratch is
> adopt a set of “ivory tower” principles (the web is full of them on
> just about any subject you could mention so a start point is easy to
> find) and then violate them very carefully as the specific business
> requirements and resulting architecture takes shape.

> Even when working in an established environment I’ve seen this
> approach taken and do think it’s more robust than starting with
> nothing and then retro-fitting.

> The link for a copy of RFC-2119 ishttp://www.faqs.org/rfcs/rfc2119.html
> though lots of other copies around some with different wording!

> Regards,

> Adrian

> On 15 Sep, 15:57, Derek Vandivere wrote:

> > Adrian,

> > I suppose I'll buy it on two conditions:

> > - The must / should / could is an intrinsic part of the principle
> > - It's possible to have two conflicting 'shoulds'

> > While I totally agree that effective principles *should* match your
> > criteria below, I think the reality is that they're modelling, well,
> > reality, which isn't nearly as cut-and-dried.

> > On Tue, 15 Sep 2009 05:01:38 -0700 (PDT), Adrian Miley

> > wrote:
> > > Derek,

> > > I think Joseph George is right about principles being unambiguous, non-
> > > conflicting and consistent. I’d also add characteristics like robust,
> > > quantifiable, appropriate and unambiguous to the mix.

> > > If we don’t apply these sort of objective measures to defining &
> > > managing the Architectural Principles then we generally end up with a
> > > lot of arguments with different people having different agendas and
> > > the probable result of someone pulling rank and imposing their
> > > interpretation or preferences on the outcome. Another key
> > > characteristic is independence – if the principle doesn’t outlast the
> > > architect that formulated it then is it really a principle of just a
> > > design preference?

> > > Following on from that, I think an important step is the separation of
> > > “real” Architectural Principles from Design Guidelines – to me the
> > > separation is the distinction between MUST vs. SHOULD vs. MAY (as
> > > defined in the infamous RFC-2117) with only the MUST statements being
> > > Architectural Principles, MAY are just Design Guidelines and SHOULD
> > > isn’t allowed – they are transformed either to “MUST … EXCEPT
> > > WHERE”
> > > or “MAY” statements.

> > > In a recent article on Architectural Principles (see
> > >http://www.tdan.com/view-articles/8972) I discuss the “Principles Of
> > > Defining Principles” in more detail. Admittedly this is about
> > > Enterprise Data Architecture but I think most of the points can be
> > > applied to just about any type of architecture without too much
> > > tweaking.

> > > In the real-world of course there will be situations where the
> > > Architectural Principles may need to be broken in order to meet a
> > > desired end-state but that’s just a case of either (1) appending a
> > > necessary “EXCEPT WHERE” clause to the principle or (b) handing out a
> > > temporary “Architectural Waiver” (with appropriate divergence /
> > > convergence plan) until the offender can be brought into line.

> > > Just my opinion,

> > > Adrian-