Showing posts with label principles. Show all posts
Showing posts with label principles. Show all posts
UKgov to "root out waste" with "zero-based" Budgeting
tags
brexit,
gov,
governance,
leadership,
legislation,
policy,
principles,
strategy
The new government is saying all the right things. Only time will tell whether they make a difference. The last few governments also started with lots of hope but lost their way somewhere down the road, and now their legacy lies in tatters. Let's hope this gov lives up to their promises!
New Year's Resolution: Investing Principles
tags
philosophy,
principles
Some questions to ponder.
Q: Do you have any principles?
I'm sure we all have principles. They might be in our conscious memory, or in our sub-conscious. Even criminals have their own principles as in how they deal with Joe public or others of their own ilk.
9 life lessons from Tim Minchin
tags
philosophy,
principles
Timothy David Minchin was born in England to Australian parents, but raised in Perth. He was awarded an honorary doctorate by the University of Western Australia and asked to give some guidance to the students on things he had learnt travelling the world, being himself and his ideas on being a successful person.
His UWA graduation speech bestowed "nine life lessons, to echo… the nine lessons of the carols of the traditional Christmas service."
His UWA graduation speech bestowed "nine life lessons, to echo… the nine lessons of the carols of the traditional Christmas service."
Cultural Lies
tags
culture,
integration,
leadership,
philosophy,
principles
"Our culture has accepted two huge lies. The first is that if you disagree with someone's lifestyle, you must fear or hate them. The second is that to love someone means you agree with everything they believe or do. Both are nonsense. You don't have to compromise convictions to be compassionate." Rick Warren
moral virtues
tags
capitalism,
culture,
principles
I agree with Philip Booth that capitalism does reward moral virtues and punishes the lack of it. You can see that reflected in the brand values, or assets listed in the balance sheet as goodwill. Lack of it destroys capital as demonstrated by the likes of Bernie Ebbers, and lately the Murdochs & quite a few others in the recent limelight.. Hard work in itself will not always be rewarded, unless it is channelled in the right direction... As far as poverty is concerned, I am not sure that we can completely eradicate it. But personally, I think what we really need is a fair, equitable & just society across continents, rather than a rich society locally where everyone is rich! I don't think we really understand poverty, living in a country where there isn't anyone dying from famine or hunger or thirst. NHS seems to be more worried about people eating too much.
Greg Smith's resignation letter
Greg Smith - Executive Director, Goldman Sachs
Today is my last day at Goldman Sachs. After almost 12 years at the firm — first as a summer intern while at Stanford, then in New York for 10 years, and now in London — I believe I have worked here long enough to understand the trajectory of its culture, its people and its identity. And I can honestly say that the environment now is as toxic and destructive as I have ever seen it.
To put the problem in the simplest terms, the interests of the client continue to be sidelined in the way the firm operates and thinks about making money. Goldman Sachs is one of the world’s largest and most important investment banks and it is too integral to global finance to continue to act this way. The firm has veered so far from the place I joined right out of college that I can no longer in good conscience say that I identify with what it stands for.
It might sound surprising to a skeptical public, but culture was always a vital part of Goldman Sachs’s success. It revolved around teamwork, integrity, a spirit of humility, and always doing right by our clients. The culture was the secret sauce that made this place great and allowed us to earn our clients’ trust for 143 years. It wasn’t just about making money; this alone will not sustain a firm for so long. It had something to do with pride and belief in the organization. I am sad to say that I look around today and see virtually no trace of the culture that made me love working for this firm for many years. I no longer have the pride, or the belief.
But this was not always the case. For more than a decade I recruited and mentored candidates through our grueling interview process. I was selected as one of 10 people (out of a firm of more than 30,000) to appear on our recruiting video, which is played on every college campus we visit around the world. In 2006 I managed the summer intern program in sales and trading in New York for the 80 college students who made the cut, out of the thousands who applied.
I knew it was time to leave when I realized I could no longer look students in the eye and tell them what a great place this was to work.
When the history books are written about Goldman Sachs, they may reflect that the current chief executive officer, Lloyd C. Blankfein, and the president, Gary D. Cohn, lost hold of the firm’s culture on their watch. I truly believe that this decline in the firm’s moral fiber represents the single most serious threat to its long-run survival.
Over the course of my career I have had the privilege of advising two of the largest hedge funds on the planet, five of the largest asset managers in the United States, and three of the most prominent sovereign wealth funds in the Middle East and Asia. My clients have a total asset base of more than a trillion dollars. I have always taken a lot of pride in advising my clients to do what I believe is right for them, even if it means less money for the firm. This view is becoming increasingly unpopular at Goldman Sachs. Another sign that it was time to leave.
How did we get here? The firm changed the way it thought about leadership. Leadership used to be about ideas, setting an example and doing the right thing. Today, if you make enough money for the firm (and are not currently an ax murderer) you will be promoted into a position of influence.
What are three quick ways to become a leader? a) Execute on the firm’s “axes,” which is Goldman-speak for persuading your clients to invest in the stocks or other products that we are trying to get rid of because they are not seen as having a lot of potential profit. b) “Hunt Elephants.” In English: get your clients — some of whom are sophisticated, and some of whom aren’t — to trade whatever will bring the biggest profit to Goldman. Call me old-fashioned, but I don’t like selling my clients a product that is wrong for them. c) Find yourself sitting in a seat where your job is to trade any illiquid, opaque product with a three-letter acronym.
Today, many of these leaders display a Goldman Sachs culture quotient of exactly zero percent. I attend derivatives sales meetings where not one single minute is spent asking questions about how we can help clients. It’s purely about how we can make the most possible money off of them. If you were an alien from Mars and sat in on one of these meetings, you would believe that a client’s success or progress was not part of the thought process at all.
It makes me ill how callously people talk about ripping their clients off. Over the last 12 months I have seen five different managing directors refer to their own clients as “muppets,” sometimes over internal e-mail. Even after the S.E.C., Fabulous Fab, Abacus, God’s work, Carl Levin, Vampire Squids? No humility? I mean, come on. Integrity? It is eroding. I don’t know of any illegal behavior, but will people push the envelope and pitch lucrative and complicated products to clients even if they are not the simplest investments or the ones most directly aligned with the client’s goals? Absolutely. Every day, in fact.
It astounds me how little senior management gets a basic truth: If clients don’t trust you they will eventually stop doing business with you. It doesn’t matter how smart you are.
These days, the most common question I get from junior analysts about derivatives is, “How much money did we make off the client?” It bothers me every time I hear it, because it is a clear reflection of what they are observing from their leaders about the way they should behave. Now project 10 years into the future: You don’t have to be a rocket scientist to figure out that the junior analyst sitting quietly in the corner of the room hearing about “muppets,” “ripping eyeballs out” and “getting paid” doesn’t exactly turn into a model citizen.
When I was a first-year analyst I didn’t know where the bathroom was, or how to tie my shoelaces. I was taught to be concerned with learning the ropes, finding out what a derivative was, understanding finance, getting to know our clients and what motivated them, learning how they defined success and what we could do to help them get there.
My proudest moments in life — getting a full scholarship to go from South Africa to Stanford University, being selected as a Rhodes Scholar national finalist, winning a bronze medal for table tennis at the Maccabiah Games in Israel, known as the Jewish Olympics — have all come through hard work, with no shortcuts. Goldman Sachs today has become too much about shortcuts and not enough about achievement. It just doesn’t feel right to me anymore.
I hope this can be a wake-up call to the board of directors. Make the client the focal point of your business again. Without clients you will not make money. In fact, you will not exist. Weed out the morally bankrupt people, no matter how much money they make for the firm. And get the culture right again, so people want to work here for the right reasons. People who care only about making money will not sustain this firm — or the trust of its clients — for very much longer.
Cultural Alignment of Business Systems
tags
culture,
integration,
leadership,
principles,
tea.net
Tim,
If you can slot your organisational culture into a rigid system, then by all means you can align or, at the very least, emulate your business sytems to reflect your culture. IMHO, from what I have seen in many organisations, culture has two aspects:
1. that which the leadership or the organisation wishes to inculcate down the heirarchy - the documented visible mission, vision, values, etc. which are formally available.
2. that which the leadership or the organisation is trying to get rid of - the invisible, undocumented, unstructured, unacknowledged behaviour exhibited by the heirarchy and emulated down the chain.
It is very easy to work with (1), and your could formulate and align architectural principles on a one-to-one basis. But, what is more important is tackling (2), and I think that is more value-add and more difficult. Particularly if you are an external entity, you might find (2) might be difficult to get a handle on.
I would suggest working with some experts on Organisational Behaviour, in order to achieve your goal. But, again IMHO, that is entirely the CEO's responsibility. You could take an architectural approach, but everything is not black and white, in this sense. :-)
In one of my discussions with our CEO, I referred him to an article (not mine, all credits to the original author), which I am happy to mention here, if it would be of any help re this context:
< snip >
Leadership as ‘Intentional Influence’, by George Ambler
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…”
< /snip >
Best regards,
Joseph
_______________
Joseph George
+44 (0)7951 499286 (please note change)
http://uk.linkedin.com/in/josephg
On Aug 6, 1:57 am, Tim Leigh wrote:
> Thanks for all the useful feedback re: cultural alignment of business
> systems, this forum is one of the best EA resources I’ve found.
> To answer a question, some high level examples of cultural values which we
> are trying to align with are:
> · Client centric
> · Empowered people and teams
> I’d like to take these high level culture/objective statements and expand on
> them within a framework, as the aim of the review is to assess how our
> systems reinforce or compete with the envisioned culture.
> Thanks for the suggestion of VSM, as this appears to be a good approach
> which I wasn’t aware of and seems to be a good way for us to go.
If you can slot your organisational culture into a rigid system, then by all means you can align or, at the very least, emulate your business sytems to reflect your culture. IMHO, from what I have seen in many organisations, culture has two aspects:
1. that which the leadership or the organisation wishes to inculcate down the heirarchy - the documented visible mission, vision, values, etc. which are formally available.
2. that which the leadership or the organisation is trying to get rid of - the invisible, undocumented, unstructured, unacknowledged behaviour exhibited by the heirarchy and emulated down the chain.
It is very easy to work with (1), and your could formulate and align architectural principles on a one-to-one basis. But, what is more important is tackling (2), and I think that is more value-add and more difficult. Particularly if you are an external entity, you might find (2) might be difficult to get a handle on.
I would suggest working with some experts on Organisational Behaviour, in order to achieve your goal. But, again IMHO, that is entirely the CEO's responsibility. You could take an architectural approach, but everything is not black and white, in this sense. :-)
In one of my discussions with our CEO, I referred him to an article (not mine, all credits to the original author), which I am happy to mention here, if it would be of any help re this context:
< snip >
Leadership as ‘Intentional Influence’, by George Ambler
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…”
< /snip >
Best regards,
Joseph
_______________
Joseph George
+44 (0)7951 499286 (please note change)
http://uk.linkedin.com/in/josephg
On Aug 6, 1:57 am, Tim Leigh
> Thanks for all the useful feedback re: cultural alignment of business
> systems, this forum is one of the best EA resources I’ve found.
> To answer a question, some high level examples of cultural values which we
> are trying to align with are:
> · Client centric
> · Empowered people and teams
> I’d like to take these high level culture/objective statements and expand on
> them within a framework, as the aim of the review is to assess how our
> systems reinforce or compete with the envisioned culture.
> Thanks for the suggestion of VSM, as this appears to be a good approach
> which I wasn’t aware of and seems to be a good way for us to go.
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.
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)
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
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)