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
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
EA Principles, Policy, Standards & Guidelines
tags
principles,
tea.net
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.
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
> "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!?!
tags
ofcom
< 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.
This is hot, and is going to be a catalyst in causing a strategic shift in IT's CAPEX leviathan.
Gartner's new approach for EA
tags
gartner
Gartner Identifies New Approach for Enterprise Architecture
Gartner is calling EA as Emergent Architecture, rather than Enterprise Architecture.
Interesting! Gartner talks about how EA was practised in the past, and contrasts those practices to how it should be in future. I don't know, how far back is past... But, I have been leading Architecture for the past 5yrs, and been involved in Architecture for 10yrs+. I totally agree with Gartner's 7 approaches, but would also add that they are not new. We have been practising this all along. Not doing so would lead to Architecture living in Ivory Tower, and out of touch with ground realities! Any basic book on management could tell you this... You don't need to be an Architect to understand human dynamics or organisational behaviour.
[1] http://gartner.com/it/page.jsp?id=1124112
[2] http://eapblog.burtongroup.com/executive_advisory_progra/2009/08/gartner-wakes-out-of-an-ea-induced-coma.html
Gartner is calling EA as Emergent Architecture, rather than Enterprise Architecture.
Interesting! Gartner talks about how EA was practised in the past, and contrasts those practices to how it should be in future. I don't know, how far back is past... But, I have been leading Architecture for the past 5yrs, and been involved in Architecture for 10yrs+. I totally agree with Gartner's 7 approaches, but would also add that they are not new. We have been practising this all along. Not doing so would lead to Architecture living in Ivory Tower, and out of touch with ground realities! Any basic book on management could tell you this... You don't need to be an Architect to understand human dynamics or organisational behaviour.
[1] http://gartner.com/it/page.jsp?id=1124112
[2] http://eapblog.burtongroup.com/executive_advisory_progra/2009/08/gartner-wakes-out-of-an-ea-induced-coma.html
EA value measures ? who cares?
tags
principles,
strategy,
views
And on that note, I have just received the draft ISO/IEEE 1471. I quite like what it says (quoted below), and fits in nicely into this discussion.
< snip >
An architecture description includes one or more architecture views (3.9). Each architecture view (or simply, view) addresses some of the architecture-related concerns held by the stakeholders of the system.
NOTE 3 This International Standard does not use phrases such as “business architecture”, “physical architecture”, and “technical architecture”. In the terms of this International Standard, equivalents of these phrases are “business view”, “physical view”, and “technical view”, respectively.
< /snip >
There can be only ONE architecture!!!
Kind regards,
Joseph
PS: Why... :-(
On 25 June, 15:44, Rheinlander Kirk wrote:
> Kewl! I agree completely! Awesome!
> Now if everyone else would get it :-(
> On Jun 25, 2009, at 7:20 AM, Joseph George wrote:
> > Kirk,
> > Yes, EA is about strategy. And I am not talking about a separate
> > technology strategy. There is only one strategy - and that is about
> > the business! Any technology (or other disciplines of) strategies are
> > part of the core business strategy, and firmly integrated together
> > within the enterprise. Any other way of doing this creates a white
> > elephant, for the sake of itself. A few years down the line, no one
> > understands why we are spending £££s of some black boxes... So, the
> > organisation continues to waste precious resources hoping nothing
> > breaks!?! The only winners are the Vendor$$$, and it is in their best
> > interests to keep the decision-makers in the dark, hoping they will
> > keep coughing up money for whatever sh.t they keep dumping on
> > customers.
> > As per the above, I don't believe in having a separate ETA as you say
> > below. There is only one EA, and everything fits in there. Or the
> > enterprise ends up being disconnected... as we perhaps see it now.
> > Best regards,
> > Joseph
> > On 24 June, 20:00, Rheinlander Kirk wrote:
> >> I think I might suggest modifying your comment slightly.
> >> EA, as COMMONLY (not currently) practiced, does not have much input
> >> into strategy.
> >> AND I strongly disagree .......
> >> From my experience, the EA is the prime protagonist of strategy. In
> >> nearly 100% of my EA engagements, the strategic planning process was
> >> delivering a 3-5 year financial plan; nothing that I would construe
> >> to
> >> be vaguely related to strategy. In every case, we revamped the
> >> strategic planning process to produce true strategic initiatives
> >> using
> >> a seeded topic list, and going through the SWOT (internal strengths
> >> and weaknesses, and external opportunities and threats) to extract a
> >> set of strategic initiatives, derive a set of supporting business
> >> initiatives, and develop a balanced scorecard set of metrics against
> >> each strategy.
> >> THIS was the marching orders for the EA effort - communicating this
> >> strategy, and coordinating the business initiatives across all
> >> functional organizations, in order to effectively deliver against
> >> strategy.
> >> EA without strategy, is the blind leading the blind.
> >> However, if you practice enterprise TECHNOLOGY architecture, then
> >> sure, ETA does not have much to do with strategy input.
> >> --Kirk
> >> On Jun 24, 2009, at 8:02 AM, Joseph George wrote:
> >>> Graham,
> >>>> I am not convinced that EA has much input to strategy as currently
> >>>> deployed by most companies , the savings come frequently from IT,
> >>>> such as server or applications consolidation , none of which is
> >>>> actually business strategy. Business is comprised of several
> >>>> disciplines such as Strategy, Planning , Operational execution ,
> >>>> Resource management , finance and more latterly Information
> >>>> technology . EA rarely addresses any of these , its simply an
> >>>> enabler in one or more of them.
> >>> As currently practised, EA does not have much input into strategy.
> >>> In
> >>> a ideal world, strategy would be formulated based on EA
> >>> recommendations. But, EA needs to mature and move up the food-chain
> >>> for that to happen. As I see it, EA seems to be getting dragged into
> >>> creating lower and lower level details, possibly because it is
> >>> trying
> >>> to be everything for everyone.
> >>> One of the goals of EA is to increase the Operational Efficiencies,
> >>> and for that EA needs to focus on where the bulk of the expenditure
> >>> (CAPEX, OPEX,...) is spent on. Guess where that might be? That is
> >>> probably what needs to be sorted and where massive savings could be
> >>> gained.
> >>> From what I have seen, EA would always be an enabler! If I could
> >>> *tell* my CEO to do something, then I become more than an enabler...
> >>> But, I guess, I am a long way off from there... Others might be in
> >>> much better positions?
> >>> Best regards,
> >>> Joseph
> >>> On 6 June, 20:12, Rheinlander Kirk wrote:
> >>>> As the organizations create the content of the enterprise
> >>>> architecture, by default, they agree to it.
> >>>> EA just allows communication and coordination across the
> >>>> boundaries,
> >>>> so they know the right things to do.
> >>>> Yes, I cut and pasted a relevant paragraph, rather than retyping
> >>>> the
> >>>> text again, as it had meaning in both contexts.
> >>>> On Jun 6, 2009, at 3:43 AM, C Johnson wrote:
> >>>>> I know where you are coming from, however for this context, if one
> >>>>> does not have a view (or baseline) of the organisations
> >>>>> architecture, then one cannot govern it... where the EA team owns
> >>>>> the process or references it, the business still need to
> >>>>> understand
> >>>>> and agree that the architecture follows what they have and what
> >>>>> they
> >>>>> see for the future (i.e. objectives, goals)
< snip >
An architecture description includes one or more architecture views (3.9). Each architecture view (or simply, view) addresses some of the architecture-related concerns held by the stakeholders of the system.
NOTE 3 This International Standard does not use phrases such as “business architecture”, “physical architecture”, and “technical architecture”. In the terms of this International Standard, equivalents of these phrases are “business view”, “physical view”, and “technical view”, respectively.
< /snip >
There can be only ONE architecture!!!
Kind regards,
Joseph
PS: Why... :-(
On 25 June, 15:44, Rheinlander Kirk
> Kewl! I agree completely! Awesome!
> Now if everyone else would get it :-(
> On Jun 25, 2009, at 7:20 AM, Joseph George wrote:
> > Kirk,
> > Yes, EA is about strategy. And I am not talking about a separate
> > technology strategy. There is only one strategy - and that is about
> > the business! Any technology (or other disciplines of) strategies are
> > part of the core business strategy, and firmly integrated together
> > within the enterprise. Any other way of doing this creates a white
> > elephant, for the sake of itself. A few years down the line, no one
> > understands why we are spending £££s of some black boxes... So, the
> > organisation continues to waste precious resources hoping nothing
> > breaks!?! The only winners are the Vendor$$$, and it is in their best
> > interests to keep the decision-makers in the dark, hoping they will
> > keep coughing up money for whatever sh.t they keep dumping on
> > customers.
> > As per the above, I don't believe in having a separate ETA as you say
> > below. There is only one EA, and everything fits in there. Or the
> > enterprise ends up being disconnected... as we perhaps see it now.
> > Best regards,
> > Joseph
> > On 24 June, 20:00, Rheinlander Kirk
> >> I think I might suggest modifying your comment slightly.
> >> EA, as COMMONLY (not currently) practiced, does not have much input
> >> into strategy.
> >> AND I strongly disagree .......
> >> From my experience, the EA is the prime protagonist of strategy. In
> >> nearly 100% of my EA engagements, the strategic planning process was
> >> delivering a 3-5 year financial plan; nothing that I would construe
> >> to
> >> be vaguely related to strategy. In every case, we revamped the
> >> strategic planning process to produce true strategic initiatives
> >> using
> >> a seeded topic list, and going through the SWOT (internal strengths
> >> and weaknesses, and external opportunities and threats) to extract a
> >> set of strategic initiatives, derive a set of supporting business
> >> initiatives, and develop a balanced scorecard set of metrics against
> >> each strategy.
> >> THIS was the marching orders for the EA effort - communicating this
> >> strategy, and coordinating the business initiatives across all
> >> functional organizations, in order to effectively deliver against
> >> strategy.
> >> EA without strategy, is the blind leading the blind.
> >> However, if you practice enterprise TECHNOLOGY architecture, then
> >> sure, ETA does not have much to do with strategy input.
> >> --Kirk
> >> On Jun 24, 2009, at 8:02 AM, Joseph George wrote:
> >>> Graham,
> >>>> I am not convinced that EA has much input to strategy as currently
> >>>> deployed by most companies , the savings come frequently from IT,
> >>>> such as server or applications consolidation , none of which is
> >>>> actually business strategy. Business is comprised of several
> >>>> disciplines such as Strategy, Planning , Operational execution ,
> >>>> Resource management , finance and more latterly Information
> >>>> technology . EA rarely addresses any of these , its simply an
> >>>> enabler in one or more of them.
> >>> As currently practised, EA does not have much input into strategy.
> >>> In
> >>> a ideal world, strategy would be formulated based on EA
> >>> recommendations. But, EA needs to mature and move up the food-chain
> >>> for that to happen. As I see it, EA seems to be getting dragged into
> >>> creating lower and lower level details, possibly because it is
> >>> trying
> >>> to be everything for everyone.
> >>> One of the goals of EA is to increase the Operational Efficiencies,
> >>> and for that EA needs to focus on where the bulk of the expenditure
> >>> (CAPEX, OPEX,...) is spent on. Guess where that might be? That is
> >>> probably what needs to be sorted and where massive savings could be
> >>> gained.
> >>> From what I have seen, EA would always be an enabler! If I could
> >>> *tell* my CEO to do something, then I become more than an enabler...
> >>> But, I guess, I am a long way off from there... Others might be in
> >>> much better positions?
> >>> Best regards,
> >>> Joseph
> >>> On 6 June, 20:12, Rheinlander Kirk
> >>>> As the organizations create the content of the enterprise
> >>>> architecture, by default, they agree to it.
> >>>> EA just allows communication and coordination across the
> >>>> boundaries,
> >>>> so they know the right things to do.
> >>>> Yes, I cut and pasted a relevant paragraph, rather than retyping
> >>>> the
> >>>> text again, as it had meaning in both contexts.
> >>>> On Jun 6, 2009, at 3:43 AM, C Johnson wrote:
> >>>>> I know where you are coming from, however for this context, if one
> >>>>> does not have a view (or baseline) of the organisations
> >>>>> architecture, then one cannot govern it... where the EA team owns
> >>>>> the process or references it, the business still need to
> >>>>> understand
> >>>>> and agree that the architecture follows what they have and what
> >>>>> they
> >>>>> see for the future (i.e. objectives, goals)
EA value measures ? who cares?
tags
principles,
strategy
Kirk,
Yes, EA is about strategy. And I am not talking about a separate technology strategy. There is only one strategy - and that is about the business! Any technology (or other disciplines of) strategies are part of the core business strategy, and firmly integrated together within the enterprise. Any other way of doing this creates a white elephant, for the sake of itself. A few years down the line, no one understands why we are spending £££s of some black boxes... So, the organisation continues to waste precious resources hoping nothing breaks!?! The only winners are the Vendor$$$, and it is in their best interests to keep the decision-makers in the dark, hoping they will keep coughing up money for whatever sh.t they keep dumping on customers.
As per the above, I don't believe in having a separate ETA as you say below. There is only one EA, and everything fits in there. Or the enterprise ends up being disconnected... as we perhaps see it now.
Best regards,
Joseph
On 24 June, 20:00, Rheinlander Kirk wrote:
> I think I might suggest modifying your comment slightly.
> EA, as COMMONLY (not currently) practiced, does not have much input
> into strategy.
> AND I strongly disagree .......
> From my experience, the EA is the prime protagonist of strategy. In
> nearly 100% of my EA engagements, the strategic planning process was
> delivering a 3-5 year financial plan; nothing that I would construe to
> be vaguely related to strategy. In every case, we revamped the
> strategic planning process to produce true strategic initiatives using
> a seeded topic list, and going through the SWOT (internal strengths
> and weaknesses, and external opportunities and threats) to extract a
> set of strategic initiatives, derive a set of supporting business
> initiatives, and develop a balanced scorecard set of metrics against
> each strategy.
> THIS was the marching orders for the EA effort - communicating this
> strategy, and coordinating the business initiatives across all
> functional organizations, in order to effectively deliver against
> strategy.
> EA without strategy, is the blind leading the blind.
> However, if you practice enterprise TECHNOLOGY architecture, then
> sure, ETA does not have much to do with strategy input.
> --Kirk
> On Jun 24, 2009, at 8:02 AM, Joseph George wrote:
> > Graham,
> >> I am not convinced that EA has much input to strategy as currently
> >> deployed by most companies , the savings come frequently from IT,
> >> such as server or applications consolidation , none of which is
> >> actually business strategy. Business is comprised of several
> >> disciplines such as Strategy, Planning , Operational execution ,
> >> Resource management , finance and more latterly Information
> >> technology . EA rarely addresses any of these , its simply an
> >> enabler in one or more of them.
> > As currently practised, EA does not have much input into strategy. In
> > a ideal world, strategy would be formulated based on EA
> > recommendations. But, EA needs to mature and move up the food-chain
> > for that to happen. As I see it, EA seems to be getting dragged into
> > creating lower and lower level details, possibly because it is trying
> > to be everything for everyone.
> > One of the goals of EA is to increase the Operational Efficiencies,
> > and for that EA needs to focus on where the bulk of the expenditure
> > (CAPEX, OPEX,...) is spent on. Guess where that might be? That is
> > probably what needs to be sorted and where massive savings could be
> > gained.
> > From what I have seen, EA would always be an enabler! If I could
> > *tell* my CEO to do something, then I become more than an enabler...
> > But, I guess, I am a long way off from there... Others might be in
> > much better positions?
> > Best regards,
> > Joseph
> > On 6 June, 20:12, Rheinlander Kirk wrote:
> >> As the organizations create the content of the enterprise
> >> architecture, by default, they agree to it.
> >> EA just allows communication and coordination across the boundaries,
> >> so they know the right things to do.
> >> Yes, I cut and pasted a relevant paragraph, rather than retyping the
> >> text again, as it had meaning in both contexts.
> >> On Jun 6, 2009, at 3:43 AM, C Johnson wrote:
> >>> I know where you are coming from, however for this context, if one
> >>> does not have a view (or baseline) of the organisations
> >>> architecture, then one cannot govern it... where the EA team owns
> >>> the process or references it, the business still need to understand
> >>> and agree that the architecture follows what they have and what they
> >>> see for the future (i.e. objectives, goals)
Yes, EA is about strategy. And I am not talking about a separate technology strategy. There is only one strategy - and that is about the business! Any technology (or other disciplines of) strategies are part of the core business strategy, and firmly integrated together within the enterprise. Any other way of doing this creates a white elephant, for the sake of itself. A few years down the line, no one understands why we are spending £££s of some black boxes... So, the organisation continues to waste precious resources hoping nothing breaks!?! The only winners are the Vendor$$$, and it is in their best interests to keep the decision-makers in the dark, hoping they will keep coughing up money for whatever sh.t they keep dumping on customers.
As per the above, I don't believe in having a separate ETA as you say below. There is only one EA, and everything fits in there. Or the enterprise ends up being disconnected... as we perhaps see it now.
Best regards,
Joseph
On 24 June, 20:00, Rheinlander Kirk
> I think I might suggest modifying your comment slightly.
> EA, as COMMONLY (not currently) practiced, does not have much input
> into strategy.
> AND I strongly disagree .......
> From my experience, the EA is the prime protagonist of strategy. In
> nearly 100% of my EA engagements, the strategic planning process was
> delivering a 3-5 year financial plan; nothing that I would construe to
> be vaguely related to strategy. In every case, we revamped the
> strategic planning process to produce true strategic initiatives using
> a seeded topic list, and going through the SWOT (internal strengths
> and weaknesses, and external opportunities and threats) to extract a
> set of strategic initiatives, derive a set of supporting business
> initiatives, and develop a balanced scorecard set of metrics against
> each strategy.
> THIS was the marching orders for the EA effort - communicating this
> strategy, and coordinating the business initiatives across all
> functional organizations, in order to effectively deliver against
> strategy.
> EA without strategy, is the blind leading the blind.
> However, if you practice enterprise TECHNOLOGY architecture, then
> sure, ETA does not have much to do with strategy input.
> --Kirk
> On Jun 24, 2009, at 8:02 AM, Joseph George wrote:
> > Graham,
> >> I am not convinced that EA has much input to strategy as currently
> >> deployed by most companies , the savings come frequently from IT,
> >> such as server or applications consolidation , none of which is
> >> actually business strategy. Business is comprised of several
> >> disciplines such as Strategy, Planning , Operational execution ,
> >> Resource management , finance and more latterly Information
> >> technology . EA rarely addresses any of these , its simply an
> >> enabler in one or more of them.
> > As currently practised, EA does not have much input into strategy. In
> > a ideal world, strategy would be formulated based on EA
> > recommendations. But, EA needs to mature and move up the food-chain
> > for that to happen. As I see it, EA seems to be getting dragged into
> > creating lower and lower level details, possibly because it is trying
> > to be everything for everyone.
> > One of the goals of EA is to increase the Operational Efficiencies,
> > and for that EA needs to focus on where the bulk of the expenditure
> > (CAPEX, OPEX,...) is spent on. Guess where that might be? That is
> > probably what needs to be sorted and where massive savings could be
> > gained.
> > From what I have seen, EA would always be an enabler! If I could
> > *tell* my CEO to do something, then I become more than an enabler...
> > But, I guess, I am a long way off from there... Others might be in
> > much better positions?
> > Best regards,
> > Joseph
> > On 6 June, 20:12, Rheinlander Kirk
> >> As the organizations create the content of the enterprise
> >> architecture, by default, they agree to it.
> >> EA just allows communication and coordination across the boundaries,
> >> so they know the right things to do.
> >> Yes, I cut and pasted a relevant paragraph, rather than retyping the
> >> text again, as it had meaning in both contexts.
> >> On Jun 6, 2009, at 3:43 AM, C Johnson wrote:
> >>> I know where you are coming from, however for this context, if one
> >>> does not have a view (or baseline) of the organisations
> >>> architecture, then one cannot govern it... where the EA team owns
> >>> the process or references it, the business still need to understand
> >>> and agree that the architecture follows what they have and what they
> >>> see for the future (i.e. objectives, goals)
EA value measures ? who cares?
tags
business.architecture,
tea.net
Graham,
> I am not convinced that EA has much input to strategy as currently
> deployed by most companies , the savings come frequently from IT,
> such as server or applications consolidation , none of which is
> actually business strategy. Business is comprised of several
> disciplines such as Strategy, Planning , Operational execution ,
> Resource management , finance and more latterly Information
> technology . EA rarely addresses any of these , its simply an
> enabler in one or more of them.
As currently practised, EA does not have much input into strategy. In a ideal world, strategy would be formulated based on EA recommendations. But, EA needs to mature and move up the food-chain for that to happen. As I see it, EA seems to be getting dragged into creating lower and lower level details, possibly because it is trying to be everything for everyone.
One of the goals of EA is to increase the Operational Efficiencies, and for that EA needs to focus on where the bulk of the expenditure (CAPEX, OPEX,...) is spent on. Guess where that might be? That is probably what needs to be sorted and where massive savings could be gained.
From what I have seen, EA would always be an enabler! If I could *tell* my CEO to do something, then I become more than an enabler... But, I guess, I am a long way off from there... Others might be in much better positions?
Best regards,
Joseph
On 6 June, 20:12, Rheinlander Kirk wrote:
> As the organizations create the content of the enterprise
> architecture, by default, they agree to it.
> EA just allows communication and coordination across the boundaries,
> so they know the right things to do.
> Yes, I cut and pasted a relevant paragraph, rather than retyping the
> text again, as it had meaning in both contexts.
> On Jun 6, 2009, at 3:43 AM, C Johnson wrote:
> > I know where you are coming from, however for this context, if one
> > does not have a view (or baseline) of the organisations
> > architecture, then one cannot govern it... where the EA team owns
> > the process or references it, the business still need to understand
> > and agree that the architecture follows what they have and what they
> > see for the future (i.e. objectives, goals)
> I am not convinced that EA has much input to strategy as currently
> deployed by most companies , the savings come frequently from IT,
> such as server or applications consolidation , none of which is
> actually business strategy. Business is comprised of several
> disciplines such as Strategy, Planning , Operational execution ,
> Resource management , finance and more latterly Information
> technology . EA rarely addresses any of these , its simply an
> enabler in one or more of them.
As currently practised, EA does not have much input into strategy. In a ideal world, strategy would be formulated based on EA recommendations. But, EA needs to mature and move up the food-chain for that to happen. As I see it, EA seems to be getting dragged into creating lower and lower level details, possibly because it is trying to be everything for everyone.
One of the goals of EA is to increase the Operational Efficiencies, and for that EA needs to focus on where the bulk of the expenditure (CAPEX, OPEX,...) is spent on. Guess where that might be? That is probably what needs to be sorted and where massive savings could be gained.
From what I have seen, EA would always be an enabler! If I could *tell* my CEO to do something, then I become more than an enabler... But, I guess, I am a long way off from there... Others might be in much better positions?
Best regards,
Joseph
On 6 June, 20:12, Rheinlander Kirk
> As the organizations create the content of the enterprise
> architecture, by default, they agree to it.
> EA just allows communication and coordination across the boundaries,
> so they know the right things to do.
> Yes, I cut and pasted a relevant paragraph, rather than retyping the
> text again, as it had meaning in both contexts.
> On Jun 6, 2009, at 3:43 AM, C Johnson wrote:
> > I know where you are coming from, however for this context, if one
> > does not have a view (or baseline) of the organisations
> > architecture, then one cannot govern it... where the EA team owns
> > the process or references it, the business still need to understand
> > and agree that the architecture follows what they have and what they
> > see for the future (i.e. objectives, goals)
Who is a business architect?
tags
business.architecture,
tea.net
Eswar,
> But, what is then the role of business architect - if his role is to
> just help by creating or understanding 'business' information, does
> he/she really involved in business decision making?
I think you query is relevant to all disciplines of Architecture and not just Business Architects. Everywhere I have been and seen, the Architects are not usually the decision makers, although they get deeply involved in the decision making process. The final decision (and responsibility) lies with the domain owners. If you are talking business, the business owners *are* the decision makers. Same applies to technology and other domains. The architect might make decisions, but that would always be on behalf of the domain owners. The architect recommends, along with his justifications based on their understanding. Note that the architect's understanding might not be complete, and they might not be privy to everything.
Also, the architect is not responsible for creating (or implementing) the organisation or any of its systems, and as such is further removed from the responsibility of ownership.
Best regards,
Joseph
On 17 June, 10:44, Eswar Ganesan wrote:
> The reason I have asked this question has an direct impact on the
> 'role of business architect'. The answer seems to be that all these
> combinations of roles I have provided are kind of 'yes' for the role
> of business architect.
> But, what is then the role of business architect - if his role is to
> just help by creating or understanding 'business' information, does
> he/she really involved in business decision making?
> If one is to be involved in business decision making, then there is a
> need to appreciate the business motivation - the row 1 of Zachmann.
> How can a business architect be able to model or identify business
> strategy has he not participated in strategy formulation or corporate
> planning and be able to drive business needs?
> Is business architect, just a consultant who cannot make decisions and
> is there only to provide the information the business management and
> operating team would like to have leading them to create informed
> decision making? This question might answer who can be a good business
> architect.
> Regards,
> Eswar
> On Wed, Jun 17, 2009 at 7:39 AM, Douglas Erickson wrote:
> > Wrong! Enterprise Architecture is the discipline of defining, designing,
> > and constructing the infrastructure for an enterprise. This includes the
> > the data, business processes to be performed, the geographic and
> > organizational structure of the enterprise, etc. An Enterprise Architect is
> > a person who is knowledgeable, skilled, and has expertise indefining,
> > designing, and developing and Enterprise. ENTERPRISE ARCHITECTURE HAS NEVER
> > BEEN ABOUT JUST THE TECHNOLOGY INFRASTUCTURE OF AN ENTERPRISE. That would
> > be, at best, an Information Technology Architect, or just a Technology
> > Architect which would only deal with Rows 3-5, of Column 3 of the Zachman
> > Enterprise Framework.
> > A Business Architect, if there is such a thing is the operating management
> > of the enterprise, the decision-makers, planners, etc.
> > ----- Original Message -----
> > From: Steve Cohen
> > To: the-enterprise-architecture-network@googlegroups.com
> > Sent: Tuesday, June 16, 2009 7:15 PM
> > Subject: Re: Who is a business architect?
> > In my opinion a Business Architect is someone who helps structure the
> > business (operating model, organizational structure, sizing, etc) to best
> > meet the already defined corporate / SBU / BU strategy - including making
> > best use of the software tools available.
> > An Enterprise Architect structures the technology to best enable the
> > business architecture.
> > Their background can come from multiple places
> > Eswar Ganesan said the following on 6/16/2009 9:08 AM:
> > Hi,
> > I have the following questions:
> > 1) Is BA is a person who has considerable amount of experience (more
> > than 10 years) in business decision making - have been part of
> > strategy development and corporate planning and finally turned out to
> > be architect advising/consulting EA initiatives of organizations?
> > 2) Is BA is Business Analyst turned Architect (more like technical
> > analyst/system analyst turned IT Architect) over a standard amount of
> > experience (5 + years) in business analysis, requirements engineering
> > and process modeling?
> > 3) Is BA is a "management consultant" who has knowledge/capabilities
> > on helping organizations/business units decide their strategic
> > objectives; a person with considerable amount (5+ years) of experience
> > in appreciating business motivation (goal/objective/strategy/tactics),
> > business situation (market trends, economic conditions etc) and
> > business project management?
> > 4) Is he a IT project manager turned BA over a considerable amount of
> > experience (12+years) in handling multiple IT projects/application
> > releases? A person who can appreciate business needs and IT delivery?
> > 5) An EA who has performed business architecture, application
> > architecture, information architecture and technology architecture for
> > a considerable amount of time (10 + years) and currently consults for
> > BA?
> > 6) Or simply a BA is an internal resource of the organization who is
> > groomed by the EA program or participated heavily on business decision
> > making and corporate planning as well financial planning functions?
> > Who is Business Architect..........
> > Regards,
> > Eswar
> But, what is then the role of business architect - if his role is to
> just help by creating or understanding 'business' information, does
> he/she really involved in business decision making?
I think you query is relevant to all disciplines of Architecture and not just Business Architects. Everywhere I have been and seen, the Architects are not usually the decision makers, although they get deeply involved in the decision making process. The final decision (and responsibility) lies with the domain owners. If you are talking business, the business owners *are* the decision makers. Same applies to technology and other domains. The architect might make decisions, but that would always be on behalf of the domain owners. The architect recommends, along with his justifications based on their understanding. Note that the architect's understanding might not be complete, and they might not be privy to everything.
Also, the architect is not responsible for creating (or implementing) the organisation or any of its systems, and as such is further removed from the responsibility of ownership.
Best regards,
Joseph
On 17 June, 10:44, Eswar Ganesan
> The reason I have asked this question has an direct impact on the
> 'role of business architect'. The answer seems to be that all these
> combinations of roles I have provided are kind of 'yes' for the role
> of business architect.
> But, what is then the role of business architect - if his role is to
> just help by creating or understanding 'business' information, does
> he/she really involved in business decision making?
> If one is to be involved in business decision making, then there is a
> need to appreciate the business motivation - the row 1 of Zachmann.
> How can a business architect be able to model or identify business
> strategy has he not participated in strategy formulation or corporate
> planning and be able to drive business needs?
> Is business architect, just a consultant who cannot make decisions and
> is there only to provide the information the business management and
> operating team would like to have leading them to create informed
> decision making? This question might answer who can be a good business
> architect.
> Regards,
> Eswar
> On Wed, Jun 17, 2009 at 7:39 AM, Douglas Erickson
> > Wrong! Enterprise Architecture is the discipline of defining, designing,
> > and constructing the infrastructure for an enterprise. This includes the
> > the data, business processes to be performed, the geographic and
> > organizational structure of the enterprise, etc. An Enterprise Architect is
> > a person who is knowledgeable, skilled, and has expertise indefining,
> > designing, and developing and Enterprise. ENTERPRISE ARCHITECTURE HAS NEVER
> > BEEN ABOUT JUST THE TECHNOLOGY INFRASTUCTURE OF AN ENTERPRISE. That would
> > be, at best, an Information Technology Architect, or just a Technology
> > Architect which would only deal with Rows 3-5, of Column 3 of the Zachman
> > Enterprise Framework.
> > A Business Architect, if there is such a thing is the operating management
> > of the enterprise, the decision-makers, planners, etc.
> > ----- Original Message -----
> > From: Steve Cohen
> > To: the-enterprise-architecture-network@googlegroups.com
> > Sent: Tuesday, June 16, 2009 7:15 PM
> > Subject: Re: Who is a business architect?
> > In my opinion a Business Architect is someone who helps structure the
> > business (operating model, organizational structure, sizing, etc) to best
> > meet the already defined corporate / SBU / BU strategy - including making
> > best use of the software tools available.
> > An Enterprise Architect structures the technology to best enable the
> > business architecture.
> > Their background can come from multiple places
> > Eswar Ganesan said the following on 6/16/2009 9:08 AM:
> > Hi,
> > I have the following questions:
> > 1) Is BA is a person who has considerable amount of experience (more
> > than 10 years) in business decision making - have been part of
> > strategy development and corporate planning and finally turned out to
> > be architect advising/consulting EA initiatives of organizations?
> > 2) Is BA is Business Analyst turned Architect (more like technical
> > analyst/system analyst turned IT Architect) over a standard amount of
> > experience (5 + years) in business analysis, requirements engineering
> > and process modeling?
> > 3) Is BA is a "management consultant" who has knowledge/capabilities
> > on helping organizations/business units decide their strategic
> > objectives; a person with considerable amount (5+ years) of experience
> > in appreciating business motivation (goal/objective/strategy/tactics),
> > business situation (market trends, economic conditions etc) and
> > business project management?
> > 4) Is he a IT project manager turned BA over a considerable amount of
> > experience (12+years) in handling multiple IT projects/application
> > releases? A person who can appreciate business needs and IT delivery?
> > 5) An EA who has performed business architecture, application
> > architecture, information architecture and technology architecture for
> > a considerable amount of time (10 + years) and currently consults for
> > BA?
> > 6) Or simply a BA is an internal resource of the organization who is
> > groomed by the EA program or participated heavily on business decision
> > making and corporate planning as well financial planning functions?
> > Who is Business Architect..........
> > Regards,
> > Eswar
Response: Culture Board paper
tags
culture,
leadership,
marchant
Culture Board paper, Ian Marchant blog post dt 09/06/2009
...
Feedback in response to Ian's Blog
Post Title - Culture Board paper
Date Posted - 09/06/2009
Name: Joseph George
Department: Technical Solutions
Location: Havant
Comments:
Ian,
"This paper seeks to update the Board... and provide some answers"
Undoubtedly, this is a step in the right direction. You say, this is what we want to project to the Board or (perhaps, more importantly) to our customers. But, I feel that would be an end result of proper implementation of what our company projects to our own employees and how we seek to ingrain the right values and culture within our company. Your statement, "This represents if you like, a view from the top...", tells me that this is probably what you are being told. I appreciate you being frank, but I have come to the sad conclusion that this view is not completely true! I hear many conflicting and very opposing views.
How do we truly find out for ourselves what our key employees (ones that are our hands and feet) feel of our company walking this talk? If you, sitting at the very top, ask someone, how would you know that you are not being fed with spin? Being surrounded with "yes" men (almost inevitable) is the beginning of the end for most great leaders.
May I refer you to a blog (not mine) post below:
<snip>
</snip>
Leadership as ‘Intentional Influence’
by George Ambler on Monday, June 15, 2009
The article “Leadership: Intentional Influence” from BusinessWeek provide an interesting discussion on the topic of leadership. Research by the company VitalSmarts uncovered the following key insights that help to understand why few leaders are able to exert influence.
1. Leaders act as if it’s not their job to address entrenched habits.
“Most leaders put a great deal of time into crafting strategy, selecting winning products, and engaging with analysts, shareholders, and major customers. But few realize the success or failure of their grand schemes lies in influencing the behavior of the hundreds or thousands of people who will have to execute the big ideas — their employees.
2. Leaders lack a theory of influence.
“Very few leaders can even answer the question, "How do you change the
behavior of a large group of people?" And yet, this is what they’re
ultimately paid to do. It isn’t just about making a decision; it’s about
getting people aligned to execute the decision. And this means
influence….”
3. Leaders confuse talking with influencing.
“Many leaders think influence consists of little more than talking people into doing things… Anyone who’s ever tried to talk a smoker into quitting knows there’s a lot more to behavior change than words…”
4. Leaders believe in silver bullets.
“When leaders actually attempt to influence new behavior, it’s common for them to look for quick fixes—to fall into the trap of thinking that deeply ingrained bad habits can be changed with a single technique. The failure mode is to rely on any single approach…”
PS: I sincerely hope that I come across as sounding positively hopeful, rather than negatively critical. We have managers at all rungs across our corporate hierarchy, and my comments are not a reflection of my perception of you. Personally, I find you to be one of the most open and receptive CEOs that I have worked with, which encourages me to continue posting my challenging thoughts to you.
Kind regards,
Joseph
Response: What's your policy idea?
tags
business.architecture,
change,
marchant,
policy
What's your policy idea?, Ian Marchant blog post dt 15/06/2009
...
Feedback in response to Ian's Blog
Post Title - What's your policy idea?
Date Posted - 15/06/2009
Name: Joseph George
Department: Technical Solutions
Location: Havant
Comments:
Ian,
I would propose a tiered tariff, much like the tax bands, but more. The lowest band would have the least cost per unit, and the upper bands would have progressively higher unit costs. This would mean that someone would pay much more for the 1000th unit than what he would pay for the 1st unit.
Currently, we (the industry) penalise low users with a standing charge load.
Kind regards,
Joseph
From: Ian Marchant
To: Joseph George
Date: 25/06/2009 16:50
Subject: Re: What's your policy idea?
Sent by: Eilidh Marshall
Joseph
We have been discussing this concept - so called rising block tariff with Ofgem and Government for some time now and one day I expect we will be successful.
Ian
Response: Why SSE exists
Why SSE exists, Ian Marchant blog post dt 09/06/2009
...
Feedback in response to Ian's Blog
Post Title - Why SSE exists
Date Posted - 30/04/2009
Name: Joseph George
Department: Technical Solutions
Location: Havant
Comments:
Ian,
Thank you so much for letting us have your speech. Your 10 Commandments (sorry Recommendations) touched a chord, particularly the (1st Commandment) statement: "We are not interested in getting people to use more of our product. It’s about selling them what they need – not what they can be persuaded they want." This reminded me of one of my enterprise architecture (internet peer group) forum conversations in Jan this year. I will reproduce some snippets of my comments from that conversation below:
<snip>
</snip>
I don't agree that "business is about making money" only. A few months ago, I would have been hard pressed to explain this. Look at the financial hotch-potch around you. If making money is the sole reason for a business, that will eventually destroy the economy.
Business is about providing a service and realising a value for it, not all in monetary terms either, but much of it so. Making money is tangential. A business justifies its existence in the Food-Chain by value-adding, and not by removing some existing ones. I would challenge even those people who say that their only reason for living is to make money. They perhaps do not realise that they might want to be happy too, as also to want to safely spend that money they have made not by losing it on some other greedy (criminal?) money making business, destroying the economy, society and associated eco-systems.
<snip>
</snip>
I do stand by my previous statement, as I have explained, and will happily explain again. However, I was not talking about a "green" company or a charity or some sort of voluntary organisation. If we look at the values or the mission statement of any commercial company worth its salt, we might notice that none of them put making money at the top of their list.
I would be happy to be proven wrong. Please don't get me wrong... I am not against making money, or have that as an objective. Money is important!
What am against is making money the sole objective or mission, as that leads to overiding any values or morals, which would otherwise be a decision making factor. It is not sustainable...
For this reason, I don't consider working for some industries... Perhaps that is my wishful thinking. But I don't wish to contribute to any nefarious business actively (overtly or covertly) going about destroying what people live for.
I believe your speech should be released to all our employees via their manager's team-brief, and let everyone digest these. I don't think every employee is able to read your blog.
Kind regards,
Joseph
Response: Green tea flavoured kit kats...
Green tea flavoured kit kats..., Ian Marchant blog post dt 08/04/2009
...
Feedback in response to Ian's Blog
Post Title - Green tea flavoured kit kats...
Date Posted - 08/04/2009
Name: Joseph George
Department: Technical Solutions
Location: Havant
Comments:
Ian,
Interesting to hear you talk about Japan just been 'open' and its global phenomenal brands. Most large Japanese brands are loosely defined group holding concerns, something probably like our SSE, with many independent businesses in their fold. About 7 years ago, I used to work for NTT (Nippon Telegraph and Telephone), which was 'the largest company' in the world in early 90s. NTT is still the largest telecoms company in the world. Many of its clients were (most still are) some of the largest companies in their industry. And Japan being one of the smallest countries in the world, totally destroyed after the War, says something...
Bowing is culturally akin to our shaking hands, and they do it so much, that I was almost doing the same, with friends and family when I would come back home. Did you happen to see the food-range served by McDonalds? :-)
Thanks for keeping us updated with your experiences.
Kind regards,
Joseph
From: Ian Marchant
To: Joseph George
Date: 15/04/2009 15:05
Subject: Re: Green tea flavoured kit kats...
Sent by: Moira Kerr
Joseph
I'm afraid I dined in Macdonalds which was largely traditional Mac fare.
Ian
From: Joseph George
To: Ian Marchant
Date: 15/04/2009 15:53
Subject: Re: Green tea flavoured kit kats...
Ian,
McDonald's Japan (a few years ago at least) also served Mega Teriyaki, an extra large (four beef!) Big Mac, Mega Tomato Mac, McPork, Ebi Filet-O (shrimp burgers), Koroke Burger (mashed potato, cabbage and katsu sauce, all in a sandwich), Ebi-Chiki (shrimp nuggets) and (your favourite) Green Tea-flavored milkshake! :-)
Kind regards,
Joseph
Can the principles of enterprise architecture be inherited from a Saas solution?
tags
cloud,
principles,
tea.net
> There
> are lots of "theories" and even some packaged solutions that basically
> ignore some principles of Computer Science, to consider them as a
> possible solution to any enterprise level problem would be
> irresponsible at best.
I agree. The vendors sure do try very hard.
> However, if you're looking at specific
> implementations then you are asking the wrong question; at that level
> you are asking if one can design a building by looking at how the
> plumbing has been done in other buildings.
At that level, I don't consider it to be Enterprise Architecture. Though, it is helpful to understand the details at lower levels, to consider how this might impact upon your upstream solution.
Kind regards,
Joseph
On 13 Feb, 15:34, Peter Hunsberger wrote:
> On Fri, Feb 13, 2009 at 4:44 AM, Joseph George
> wrote:
> > IMHO, architecture is just common sense. Consequently, any principle
> > which is open, makes business sense and aligns with corporate
> > objectives, even if based on some other theory is worth considering.
> Sorry, I'm going to have to some what disagree with you here.
> Architecture is a lot more than common sense. You cannot design a sky
> scraper using common sense, you need to know something about real
> engineering principles. Similarly, you cannot design enterprise
> solutions without knowing some basic IS engineering principles. There
> are lots of "theories" and even some packaged solutions that basically
> ignore some principles of Computer Science, to consider them as a
> possible solution to any enterprise level problem would be
> irresponsible at best.
> One can debate to what degree SAAS is general set of principles vs. a
> particular mode of systems implementation. To the extent that you
> lean towards general principles then sure, consider it part of the
> architecture tool kit. However, if you're looking at specific
> implementations then you are asking the wrong question; at that level
> you are asking if one can design a building by looking at how the
> plumbing has been done in other buildings.
> --
> Peter Hunsberger
> are lots of "theories" and even some packaged solutions that basically
> ignore some principles of Computer Science, to consider them as a
> possible solution to any enterprise level problem would be
> irresponsible at best.
I agree. The vendors sure do try very hard.
> However, if you're looking at specific
> implementations then you are asking the wrong question; at that level
> you are asking if one can design a building by looking at how the
> plumbing has been done in other buildings.
At that level, I don't consider it to be Enterprise Architecture. Though, it is helpful to understand the details at lower levels, to consider how this might impact upon your upstream solution.
Kind regards,
Joseph
On 13 Feb, 15:34, Peter Hunsberger
> On Fri, Feb 13, 2009 at 4:44 AM, Joseph George
>
> > IMHO, architecture is just common sense. Consequently, any principle
> > which is open, makes business sense and aligns with corporate
> > objectives, even if based on some other theory is worth considering.
> Sorry, I'm going to have to some what disagree with you here.
> Architecture is a lot more than common sense. You cannot design a sky
> scraper using common sense, you need to know something about real
> engineering principles. Similarly, you cannot design enterprise
> solutions without knowing some basic IS engineering principles. There
> are lots of "theories" and even some packaged solutions that basically
> ignore some principles of Computer Science, to consider them as a
> possible solution to any enterprise level problem would be
> irresponsible at best.
> One can debate to what degree SAAS is general set of principles vs. a
> particular mode of systems implementation. To the extent that you
> lean towards general principles then sure, consider it part of the
> architecture tool kit. However, if you're looking at specific
> implementations then you are asking the wrong question; at that level
> you are asking if one can design a building by looking at how the
> plumbing has been done in other buildings.
> --
> Peter Hunsberger
Can the principles of enterprise architecture be inherited from a Saas solution?
tags
cloud,
principles,
tea.net
IMHO, architecture is just common sense. Consequently, any principle which is open, makes business sense and aligns with corporate objectives, even if based on some other theory is worth considering.
Architecture needs to consider all stacks and layers of the company in defining and maintaining the Architecture Principles. We would need to consider the ground realities in conjunction with the people who are actually doing the work, as much as, if not more than, those sit in their ivory towers. If not, our architecture wouldn't be realistic.
Continuing further, I don't expect the Achitecture Principles to be cast in stone. More so, in these days, when the ground realities are changing faster than many businesses can adapt or even cope with. The principles need to be driven by both upstream and downstream.
For example, if SaaS is acceptable to your company, then there should be some architecture principle which accepts this solution. In fact, you should already have had this principle on your list, or accept that as a gap to be rectified. If not, SaaS should not be acceptable to your company, as it would potentialy conflict with one of your principles.
Hope this makes sense...
Kind regards,
Joseph
On Feb 11, 10:28 pm, Mark Cowan wrote:
> Is it possible or even desirable to gap fill EA principles by choosing
> a solution that aligns it. For example - in looking at a particular
> Saas solution that was based on the principle of "loose
> coupling" (insert the principle of your choice here) could its
> adoption force the desired design pattern?
> The solution doesn't have to be Saas or technology - it could be
> process based as well.
> All the best,
> Mark
> First Spike
> Information Management Simplified
>http://www.firstspike.com
Architecture needs to consider all stacks and layers of the company in defining and maintaining the Architecture Principles. We would need to consider the ground realities in conjunction with the people who are actually doing the work, as much as, if not more than, those sit in their ivory towers. If not, our architecture wouldn't be realistic.
Continuing further, I don't expect the Achitecture Principles to be cast in stone. More so, in these days, when the ground realities are changing faster than many businesses can adapt or even cope with. The principles need to be driven by both upstream and downstream.
For example, if SaaS is acceptable to your company, then there should be some architecture principle which accepts this solution. In fact, you should already have had this principle on your list, or accept that as a gap to be rectified. If not, SaaS should not be acceptable to your company, as it would potentialy conflict with one of your principles.
Hope this makes sense...
Kind regards,
Joseph
On Feb 11, 10:28 pm, Mark Cowan
> Is it possible or even desirable to gap fill EA principles by choosing
> a solution that aligns it. For example - in looking at a particular
> Saas solution that was based on the principle of "loose
> coupling" (insert the principle of your choice here) could its
> adoption force the desired design pattern?
> The solution doesn't have to be Saas or technology - it could be
> process based as well.
> All the best,
> Mark
> First Spike
> Information Management Simplified
>http://www.firstspike.com
Response: Exam over
tags
gov,
marchant,
policy,
principles,
strategy
Exam over, Ian Marchant blog post dt 11/02/2009
...
Feedback in response to Ian's Blog
Post Title - Exam over
Date Posted - 11/02/2009
Name: Joseph George
Department: Technical Solutions
Location: Havant
Comments:
Ian,
"My answer was that I would rather employ an extra person in Customer Service than in the Press Office."
Highly commendable, Ian! I feel this is one of the things ailing our government and consequently the country today. Too many spin doctors, and not enough constructive work!
There was a time (possibly my father's generation), when people looked to the media to form their opinion. Now, most people can see right through the media reports and analysis, which more often seem to be driving politically motivated corrupt agendas.
With the advent of the internet, peer groups are highly effective in dispersing personal feedback, and no amount of spin can kill that, other than actual constructive work to remedy the situation.
Kind regards,
Joseph
From: Ian Marchant
Date: 12/02/2009 16:25
Subject: Re: Exam over
To: Joseph George
Joseph
I couldn't agree more newspapers feel they are more important than they
really are.
Ian
Subscribe to:
Posts (Atom)