EA Principles, Policy, Standards & Guidelines

Derek,

Just to add my £0.02, on your two conditions:

I don't think a principle gives us a choice whether to use it or not. A principle is where we (as the organisation) have already decided our boundaries, on what we will or will not do. These might be over-ridden under exceptional circumstances with explicit agreement. The architecture principles document is not a discussion on whether the organisation should/could/would do something or not!

So, from your example in a previous post, if you have two principles like:
- SHOULD buy, don't build
- SHOULD be SOA compliant

I would say that neither of them form a principle. "SHOULD" means nothing, as it is treated more akin to a suggestion. And a principle is anything but that. Even without the "should", the two statements above are only expressing preferences, and not principles!

There is no place for any ambigious terms like "should" or "could" or "would" or "may" in any principle. The implications might contain these words, but I am uncomfortable if that be the case. Every statement is written in present tense. TOGAF provides an excellent refernce set of principles:
http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html#tag_30_06

It would be very helpful to refer to the dictionary meaning of the word "principle", as I find it very apt!

I guess (and I agree with Adrian Miley on this), all this probably makes sense depending on where you are, as in Architecture Principles vs Design Guidelines.

Kind regards,
Joseph

On Sep 15, 3:57 pm, 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