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-

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

EA Principles, Policy, Standards & Guidelines

I'll third that Kirk, and completely agree with your caveat.

But I don't agree with your further trick:

> the range of principles, by their very
> nature, are in conflict.

If there are any conflicting EA principles, then those need to be reviewed and/or eliminated. We don't need to dot every i and cross every t! IMHO, if we have reached a situation where we have too many principles and some of them conflict, it is probably because we are going into too much detail, or we haven't got the correct top-down approach, i.e. flowing from the EA through to TA, IA, DA, BA, etc. I might have completely misunderstood you, and if so would like some examples, if you could elaborate...

As there should be no conflicting principles, I see no point in principles being prioritised either. Though, I have no issue if they are.

AspiringEA, we have had a few excellent discussions on Architecture Principles in this group before. I can refer you to two I remember, titled: "EA value measures ? who cares?" and "Can the principles of enterprise architecture be inherited from a Saas solution?". You might find some more, if you look back through the archives in this group.

Kind regards,
Joseph

On Sep 13, 8:37 pm, Rheinlander Kirk wrote:

> "Don't forget, EA is not about making decisions, it’s about providing
> the business and executives with information so thEy can make better
> and more informed decisions."

> I'll second that, with the further caveat, that EA, done right, will
> NOT require the executives to make decisions from the input - the
> process will empower the business to make decisions in line with the
> executive intent, as these core decision values (principles) are
> defined. This is the key to making EA scaleable to the enterprise as a
> whole - make it SOP.

> The further trick is that the range of principles, by their very
> nature, are in conflict. A method of prioritizing these core decision
> values against some logical and consistent view of a breakdown of the
> enterprise, is essential.

> Without this prioritization, you end up with what I call the "Bible
> Approach" - pick chapter and verse to support whatever decision you
> want to make.

> --Kirk

> On Sep 13, 2009, at 3:37 AM, kevin wrote:

> > Hi again Mr Aspiring EA,

> > I just thought I would also let you know that having a set of
> > principles is the easy part....

> > What is more difficult is getting us and value from those principles.

> > Firstly, documenting and understanding the implications of each
> > principle is very important.

> > Secondly, you need to make sure that the principles you adopt identify
> > what tasks need to be done and what needs to be put in place in order
> > to adopt them.

> > Thirdly you need, for each principle, a set of metrics so that you can
> > measure whether the principles are having the intended effect or not.

> > Fourthly, you need to make sure that the process of how change
> > evaluated against the principles is defined and can be operated.

> > So make sure whatever principles you use, they address these issues.

> > Don't forget, EA is not about making decisions, it’s about providing
> > the business and executives with information so thEy can make better
> > and more informed decisions.

> > Of course, the ones in PeaF do.

> > Cheers,
> > Kevin.

Ofcom - working for the Suppliers!?!

< quote >
Last year it went to the High Court to prevent the publication of the information the public needs in a form that's useful: a national database, even though it has the identity, location and strength of every cell tower. (As we can see in SiteFinder).

So market-friendly in the Ofcom dictionary translates as: "Cosy with a handful of suppliers, whose interests it guards jealously, preventing the market from working better."
< /quote >

In the interest of consumers: Abolish Ofcom!

Amazon's Virtual Private Cloud (VPC) solution

http://allthingsdistributed.com/2009/08/amazon_virtual_private_cloud.html
This is hot, and is going to be a catalyst in causing a strategic shift in IT's CAPEX leviathan.