This is interesting, and I can empathise with you. I find myself more powerful(?) being involved in high-level Solutions Architecture than being purely in the Enterprise layer. I can influence Business and Technology decisions and have the budget to throw behind these initiatives.
My moto: Architecting the Enterprise: Solution by Solution!
Possibly deserves a whole blog post to expand on it. But I'll let you all ponder on this thought.
Architecture Archetypes?
Where are we? And where do we want to go?
http://blogs.forrester.com/ea/2009/12/the-archetypes-of-ea.html
I liked this post by Alex Cullen, about the role and context of architects and their organisations. I particularly the diagram, showing the pulls in the four directions. I can see those pulls in this very group here too, i.e. everyone thinking what they do is more important than anything anyone else might be doing as an Architect!
What are your thoughts?
Kind regards,
Joseph
http://blogs.forrester.com/ea/2009/12/the-archetypes-of-ea.html
I liked this post by Alex Cullen, about the role and context of architects and their organisations. I particularly the diagram, showing the pulls in the four directions. I can see those pulls in this very group here too, i.e. everyone thinking what they do is more important than anything anyone else might be doing as an Architect!
What are your thoughts?
Kind regards,
Joseph
Licensure for IT Architects
tags
certification,
tea.net
Some excellent discussions but in the wrong thread! I agree with Adrian below, and assert that Architecture can only enable a Business Owner to make key decisions, and avoid potentially expensive costs in the long run. No EA or anyone else is going to replace the CEO or the MD and take away the BoD roles or ownership. If they did, they would become the CEO. There are stories of proxy CEOs or dummies sitting on the top chair with no power or knowledge to make decisions.
Coming back to the topic of this thread... Licensing can only be imposed on a legal basis for certain professions. A doctor can't practice medicine without a license. There are advantages to certification, but only a full university degree (not some two weeks course) probably grounds a student in hard academics. Not all doctors t work in the same field and/or have the same expertise. They have a basic qualification which makes them a licensed doctor, but they gain their expertise with training/certification. My GP could not perform brain surgery, and one who could would not do a heart op. You can see the diversity of architects within our group here too...
Anyone causing a business to lose money is not a public disaster! The company just winds down. Hence, a CEO/CIO not requiring a license to practice. The same applies to an Architect too! A business owner makes a decision, if it makes financial sense to him. If he chooses to employ a CEO without an (ivy league) MBA, it should be entirely his prerogative and he alone takes the risk.
Best regards,
Joseph
On 3 Oct, 21:00, Adrian Miley wrote:
> Brian,
> On 2 Oct, 17:58, "briankseitz" wrote:
> > EA if it is to be truly EA, EA needs to see, speak, and
> > integrate these discipline frameworks and architectures into a great whole.
> > [The value of the car to the owner is not the parts, it’s the utility the
> > whole provides when assembled and operating]
> I agree that the value of the business to its shareholders is the sum
> of the parts and I don't think anyone is on any doubt that all the
> parts have to work in unison in order to maximise the benefit of the
> business activities to the shareholders.
> But, to use your analoguy, when it comes to maintaining the car I
> don't think many people would argue that a specialist is normally
> better than a generalist - employing someone who specialises in
> bodywork to rebuild the engine when the cambelt goes will be expense
> and it's anyones guess what quality of work you will get.
> I'd make the same assertion about maintaining the business and it is
> for this reason that the Finance Director is normally a Finance
> Professional - he might know enough about Sales or Human Resources to
> recognise that they are important parts of the overall business but
> also they he isn't expert enough to take on those functions himself.
> (Knowing the limitations of ones own ability and knowledge is an
> important aspect of social politics.)
> > I'm about to start a new position. After discussing with the CEO the role
> > the "informal internal title" tentatively will be Chief Business Architect.
> > ... The role and responsibilities
> > will cover developing processes, management systems, client relationships,
> > employee development, value accounting systems, and information technology
> > to support all of the prior.
> > ....
> > Am I the boss --no
> > Am I the expert in each discipline or function --no
> > Will I be running the company --no that's what the CEO and management staff
> > do
> > Will I set the vision for the company --no again, the CEO, BoD, and
> > Executives do that
> Now this is probably closer to my idea of Enterprise Architecture as
> the function that stitches it all together but doesn't claim expertise
> for anything other than developing processes that enable other areas
> of expertise to carry out their activities. (Or at least that's how I
> understand your description.)
> This is a hell of a lot more palatable than the others who are
> claiming much more wideranging responsibility for the
> business itself and the task much more closely aligned with what IT
> used to label an Analyst / Designer who specified and designed things
> but didn't get involved in mere implementation detail.
> I'm one of those unusual people in IT in that I have no interest in
> computers or software and put them in the same category as hammers and
> screwdrivers - I always try to select the appropriate tool after I've
> decided what I'm going to build - so this description of Enterprise
> Architect chimes well with me.
> Just my opinion...
> Adrian
Coming back to the topic of this thread... Licensing can only be imposed on a legal basis for certain professions. A doctor can't practice medicine without a license. There are advantages to certification, but only a full university degree (not some two weeks course) probably grounds a student in hard academics. Not all doctors t work in the same field and/or have the same expertise. They have a basic qualification which makes them a licensed doctor, but they gain their expertise with training/certification. My GP could not perform brain surgery, and one who could would not do a heart op. You can see the diversity of architects within our group here too...
Anyone causing a business to lose money is not a public disaster! The company just winds down. Hence, a CEO/CIO not requiring a license to practice. The same applies to an Architect too! A business owner makes a decision, if it makes financial sense to him. If he chooses to employ a CEO without an (ivy league) MBA, it should be entirely his prerogative and he alone takes the risk.
Best regards,
Joseph
On 3 Oct, 21:00, Adrian Miley
> Brian,
> On 2 Oct, 17:58, "briankseitz"
> > EA if it is to be truly EA, EA needs to see, speak, and
> > integrate these discipline frameworks and architectures into a great whole.
> > [The value of the car to the owner is not the parts, it’s the utility the
> > whole provides when assembled and operating]
> I agree that the value of the business to its shareholders is the sum
> of the parts and I don't think anyone is on any doubt that all the
> parts have to work in unison in order to maximise the benefit of the
> business activities to the shareholders.
> But, to use your analoguy, when it comes to maintaining the car I
> don't think many people would argue that a specialist is normally
> better than a generalist - employing someone who specialises in
> bodywork to rebuild the engine when the cambelt goes will be expense
> and it's anyones guess what quality of work you will get.
> I'd make the same assertion about maintaining the business and it is
> for this reason that the Finance Director is normally a Finance
> Professional - he might know enough about Sales or Human Resources to
> recognise that they are important parts of the overall business but
> also they he isn't expert enough to take on those functions himself.
> (Knowing the limitations of ones own ability and knowledge is an
> important aspect of social politics.)
> > I'm about to start a new position. After discussing with the CEO the role
> > the "informal internal title" tentatively will be Chief Business Architect.
> > ... The role and responsibilities
> > will cover developing processes, management systems, client relationships,
> > employee development, value accounting systems, and information technology
> > to support all of the prior.
> > ....
> > Am I the boss --no
> > Am I the expert in each discipline or function --no
> > Will I be running the company --no that's what the CEO and management staff
> > do
> > Will I set the vision for the company --no again, the CEO, BoD, and
> > Executives do that
> Now this is probably closer to my idea of Enterprise Architecture as
> the function that stitches it all together but doesn't claim expertise
> for anything other than developing processes that enable other areas
> of expertise to carry out their activities. (Or at least that's how I
> understand your description.)
> This is a hell of a lot more palatable than the others who are
> claiming much more wideranging responsibility for the
> business itself and the task much more closely aligned with what IT
> used to label an Analyst / Designer who specified and designed things
> but didn't get involved in mere implementation detail.
> I'm one of those unusual people in IT in that I have no interest in
> computers or software and put them in the same category as hammers and
> screwdrivers - I always try to select the appropriate tool after I've
> decided what I'm going to build - so this description of Enterprise
> Architect chimes well with me.
> Just my opinion...
> Adrian
EA Principles, Policy, Standards & Guidelines
tags
principles,
tea.net
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-
On Sep 15, 7:18 pm, Adrian Miley
> 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
> > 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
> >
> > > 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
tags
principles,
tea.net
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
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
> 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
>
> > 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
Subscribe to:
Posts (Atom)