The role of the Budget is to provide an update on the state of the economy and the public finances and to present new forecasts for each, to set out the Government's economic and fiscal objectives, to report on the progress the Government has made toward achieving its objectives, and to set out the further steps the Government is taking to meet them.
The Budget is the major financial and economic statement made each year by the Chancellor of the Exchequer to the Parliament. A guide to the Budget, including a list of all Chancellors since World War II is available on this website:
http://hm-treasury.gov.uk/budget.htm.
I'll try to update this post with my perspective of the budget.
The African Runner
tags
philosophy
Every morning, a gazelle wakes up knowing that it must run faster than the fastest lion, or die.
Every morning, a lion wakes up knowing that it must run faster than the slowest gazelle, or starve.
- excerpt from an African Proverb
Every morning, a lion wakes up knowing that it must run faster than the slowest gazelle, or starve.
- excerpt from an African Proverb
Tool first or Purpose first for EA
Quite possibly... Should I have bought a (flat-pack?) shed first, and then go shopping for the tools required? Or, should I buy the tools first, and then go shopping for my d-i-y shed?
Note: We are not discussing whether tools are useful or should we use tools? Tools are *definitely* useful and we *should* use appropriate tools, when required.
Best regards,
Joseph
On Jun 15, 7:15 am, "alan lloyd" wrote:
> Great one Ken .. sounds like we are of the same vintage..
> I remember when my dad used to build garden sheds with a hand saw and a
> hammer..
> The last shed I put up was 1000 times more sophisticated than that i.e had
> electric roller doors.. and the tools were different too - a lot of them for
> some reason had wires with mains plugs on them :-)
> Could one say - that without an understanding of the tools available -
> there would similar lack of understanding of the material at hand and the
> processes to use them?
> -----Original Message-----
> From: the-enterprise-architecture-network@googlegroups.com
> [mailto:the-enterprise-architecture-network@googlegroups.com] On Behalf Of
> Ken Orr
> Sent: Monday, 14 June 2010 5:09 AM
> To: The Enterprise Architecture Network
> Subject: Re: Tool first or Purpose first for EA
> I can also remember doing EA before tools. Indeed, I remember doing
> programming
> when the only tools were assemblers and core dumps, but I can't
> imagine going
> back to that point even though I saw some marvelous programs developed
> using
> only primitive tools, blackboards, paper and pencil and brain power.
> The point about tools is that there are certain problems dealing with
> scale that cannot
> really be attacked without tools, tools that those of us "doing EA"
> invented for
> the express purpose of "doing EA better".
> Ken Orr
> On Jun 12, 10:53 am, Glen wrote:
> > Amazingly enough, we created and implemented EAs before there were any
> > "tools". I created my first EA in the mid 80's and there were many
> > people earlier than I. We had word processing and some rudimentary
> > drawing capabilities plus pencil and paper. This didn't stop us from
> > being effective and I'm not sure it was really all that inefficient.
> > It certainly didn't line the pockets of the tool vendors. Most of
> > the work was and still is getting the EA adopted and the systems
> > (business and technical) compliant.
> > On May 18, 11:06 am, Eswar Ganesan wrote:
> > > Hi All,
> > > What is the best practice of developing an Enterprise Architecture -
> > > "Architecture Strategy first and Tool second" or "Tool First and
> > > Architecture Strategy second".
> > > I have seen a situation wherein the tool has been bought first and then
> few
> > > people are sitting around with the tool and identify that the tool can
> do
> > > process modeling, data modeling, application landscaping and technology
> > > collaboration diagram etc - so the approach for EA has taken shape such
> that
> > > - okay, these are the 15 templates that are available in the tool and
> lets
> > > make it a mandate across the company so that if someone has to model
> some
> > > diagram around this 15 template then they have to come to this team
> which
> > > can help doing this. Is this EA?
> > > In my opinion, EA design and strategy - the motivation element comes
> first -
> > > make it a case that the purpose, framework and approach for EA defined
> and
> > > then decide on tool and approaches to deliver architectural
> deliverables.
> > > What do you fellow architects comment on this, thanks,
> > > Regards,
> > > Eswar
Note: We are not discussing whether tools are useful or should we use tools? Tools are *definitely* useful and we *should* use appropriate tools, when required.
Best regards,
Joseph
On Jun 15, 7:15 am, "alan lloyd"
> Great one Ken .. sounds like we are of the same vintage..
> I remember when my dad used to build garden sheds with a hand saw and a
> hammer..
> The last shed I put up was 1000 times more sophisticated than that i.e had
> electric roller doors.. and the tools were different too - a lot of them for
> some reason had wires with mains plugs on them :-)
> Could one say - that without an understanding of the tools available -
> there would similar lack of understanding of the material at hand and the
> processes to use them?
> -----Original Message-----
> From: the-enterprise-architecture-network@googlegroups.com
> [mailto:the-enterprise-architecture-network@googlegroups.com] On Behalf Of
> Ken Orr
> Sent: Monday, 14 June 2010 5:09 AM
> To: The Enterprise Architecture Network
> Subject: Re: Tool first or Purpose first for EA
> I can also remember doing EA before tools. Indeed, I remember doing
> programming
> when the only tools were assemblers and core dumps, but I can't
> imagine going
> back to that point even though I saw some marvelous programs developed
> using
> only primitive tools, blackboards, paper and pencil and brain power.
> The point about tools is that there are certain problems dealing with
> scale that cannot
> really be attacked without tools, tools that those of us "doing EA"
> invented for
> the express purpose of "doing EA better".
> Ken Orr
> On Jun 12, 10:53 am, Glen
> > Amazingly enough, we created and implemented EAs before there were any
> > "tools". I created my first EA in the mid 80's and there were many
> > people earlier than I. We had word processing and some rudimentary
> > drawing capabilities plus pencil and paper. This didn't stop us from
> > being effective and I'm not sure it was really all that inefficient.
> > It certainly didn't line the pockets of the tool vendors. Most of
> > the work was and still is getting the EA adopted and the systems
> > (business and technical) compliant.
> > On May 18, 11:06 am, Eswar Ganesan
> > > Hi All,
> > > What is the best practice of developing an Enterprise Architecture -
> > > "Architecture Strategy first and Tool second" or "Tool First and
> > > Architecture Strategy second".
> > > I have seen a situation wherein the tool has been bought first and then
> few
> > > people are sitting around with the tool and identify that the tool can
> do
> > > process modeling, data modeling, application landscaping and technology
> > > collaboration diagram etc - so the approach for EA has taken shape such
> that
> > > - okay, these are the 15 templates that are available in the tool and
> lets
> > > make it a mandate across the company so that if someone has to model
> some
> > > diagram around this 15 template then they have to come to this team
> which
> > > can help doing this. Is this EA?
> > > In my opinion, EA design and strategy - the motivation element comes
> first -
> > > make it a case that the purpose, framework and approach for EA defined
> and
> > > then decide on tool and approaches to deliver architectural
> deliverables.
> > > What do you fellow architects comment on this, thanks,
> > > Regards,
> > > Eswar
The Power of One
tags
virtual
Integrated End-to-End Virtualisation
Virtualisation gives you the power of one. One instance of each desktop OS. One copy of each application. One image of each server workload. Managed centrally and assembled dynamically at runtime. Delivered as a secure, personalised, on-demand service.
Less is more...
http://simplicityispower.citrix.com/
Virtualisation gives you the power of one. One instance of each desktop OS. One copy of each application. One image of each server workload. Managed centrally and assembled dynamically at runtime. Delivered as a secure, personalised, on-demand service.
Less is more...
http://simplicityispower.citrix.com/
The 5 Ws and 1 H
tags
tea.net
The courage of thinking about the 5Ws and 1H
What When Where Who Why
How
We don't start with "The How"!
What When Where Who Why
How
We don't start with "The How"!
Integrating EA Mgmt and Technical Frameworks
AOGEA Ottawa-Gatineau Chapter
EA Seminar - 29 Mar 1010
Integrating Enterprise Architecture Management and Technical Frameworks
Presented by:
Lynn Wallace, Sr Information Architect, Canada Revenue Agency
Robert (Bob) Weisman, CEO, Build The Vision Inc.
EA Seminar - 29 Mar 1010
Integrating Enterprise Architecture Management and Technical Frameworks
Presented by:
Lynn Wallace, Sr Information Architect, Canada Revenue Agency
Robert (Bob) Weisman, CEO, Build The Vision Inc.
Tool first or Purpose first for EA
Ken,
> EA tools are not a question of whether but when, and the when is when
> you know enough to use them.
I don't think we are debating whether a tool is needed or what that tool should be. We are specifically discussing only "the when" aspect.
You do say
> First you need a dynamic methodology, then you
> need training, tools and expertise to
> support it.
I kind of agree with you above about the first. But I would suggest, first you need an EA Vision to start. This delivers some goals to target, i.e. reduce cost, increase agility, or increase capability, etc. All the other steps follow later, perhaps in different orders depending on the organisation maturity and its readiness. I completely agree with Peter Hunsberger on his last posts.
> YOU SIMPLY CAN'T DO "REAL EA" WITHOUT TOOLS, INDUSTRIAL
> GRADE TOOLS!
Hmmm... What is "REAL EA"? Even EAs can't seem to agree... :-)
And, I see no point in buying "INDUSTRIAL GRADE TOOLS", if the organisation simply cannot afford it, or the people to use it, i.e. does not have capable EAs or other personnel to support this amazing tool. An EA tool is only good enough if everyone who are supposed to populate it, are diligent and skilled enough with this tool. Else, the TCO would result in a white elephant and another shelfware.
If the organisation can afford a good tool, has trained EAs and all other relevant analysts in this particular tool, then it is probably ready to use this tool. If this is the case, it better have supportive management ready to drive forward the resultant EA delivery and targets. Otherwise, all these efforts would just generate another business process and red-tapes hampering business agility.
To end my £0.02, I would say, have capable people in place, before you get capable tools. Who would identify which tool is capable? When/How would this capable tool become beneficial?
Best regards,
Joseph
On May 29, 5:40 pm, Ken Orr wrote:
> Every once in while people get heated about the wrong question. The
> statement that some organization
> “started EA before they started with the tools” is kind of
> meaningless. What's missing is the idea of a
> workable methodology. First you need a dynamic methodology, then you
> need training, tools and expertise to
> support it. YOU SIMPLY CAN'T DO "REAL EA" WITHOUT TOOLS, INDUSTRIAL
> GRADE TOOLS!" Sure you
> can use Visio to draw pictures, but and EA database is not just a set
> of pictures done one time,it is a set
> of pictures that support an EA Roadmap that are constantly updated.
> One of the core problems with REAL EA is that the problems are so
> complex that you need special tools to
> address just the interactions between systems or the numbers of
> individual data tables. If you select tools too
> early, however, there is a good chance that the organization will not
> really understand what the requirements
> are and end up trying to get the cheapest solution...bad idea.
> EA tools are not a question of whether but when, and the when is when
> you know enough to use them.
> Ken
> On May 26, 3:05 am, Joseph George southern.co.uk> wrote:
> > Kevin,
> > > Not sure what “started EA before they started with the tools.” means -
> > > but as I understood it (after sitting through the presentation) they
> > > only way they started was to buy a tool, figure out a good question
> > > they wanted to answer that would give a big return (application
> > > portfolio rationalisation), populated the tool with the data required,
> > > made some changes, save d a lot of money, modelled some more, etc,
> > > etc.
> > Hmmm... that sounds like a fool with a tool approach. We could apply
> > this same principle to any (not necessarily EA) tool and start a
> > business model around that tool, viz. "buy a tool, figure out a good
> > question they wanted to answer that would give a big return, populated
> > the tool with the data required, made some changes, save d a lot of
> > money, modelled some more, etc, etc." Et Voila, I've got a new
> > business case. Let us buy a hammer (or whatever the latest jazzy thing
> > the advertising industry is throwing at us), figure out a good
> > question... that would give a big return,... etc etc.
> > But further down your post, you answer exactly what I meant. You
> > probably figured that yourself
> > > Which is why I asked Colin Birchenall after the presentation.
> > And the answer contains the EA approach and the tool was part of their
> > solution. Purrfect!
> > > to start modelling stuff, so we can
> > > understand stuff, so we can kill stuff where we don’t need it, and
> > > strengthen stuff where we do”
> > And what a brilliant way to gain buy-in from the business owners:
> > > the only way we can work with you and
> > > generate a return for all is to
> > I like this approach. Either we agree on a clear approach and work
> > together and generate a return for all. Or we can't generate a return
> > and won't work with you! Any waffling rhetoric about fluffy stuff just
> > muddies the water for the sponsors and disengage them.
> > Kind regards,
> > Joseph
> > On May 24, 4:01 pm, "Kevin (PragmaticEA.com) Smith"
> > wrote:
> > > @Joseph: “However, I would venture to say from the example he gives
> > > that they started EA before they started with the tools. All it means
> > > is that they started using the tool, before they had a complete EA
> > > vision populated.”
> > > Not sure what “started EA before they started with the tools.” means -
> > > but as I understood it (after sitting through the presentation) they
> > > only way they started was to buy a tool, figure out a good question
> > > they wanted to answer that would give a big return (application
> > > portfolio rationalisation), populated the tool with the data required,
> > > made some changes, save d a lot of money, modelled some more, etc,
> > > etc.
> > > They started at the application /infrastructure level then moved up
> > > into solution architecture, then project portfolio then strategy.
> > > The point being they did stuff that saved money.
> > > The question, of course is…
> > > “OK - but you needed a mandate/money etc to buy the tool, have some
> > > training, and the people to do some modelling etc right? So how did
> > > you get the mandate/money ?”
> > > Which is why I asked Colin Birchenall after the presentation.
> > > Hi answer was - “Yes, exactly right - the catalyst was the formation
> > > of the LLP between Serco and Glasgow City Council. Serco had basically
> > > said, OK - you want us to be in partnership with you in terms of
> > > provision of IT? = no problem - the only way we can work with you and
> > > generate a return for all is to start modelling stuff, so we can
> > > understand stuff, so we can kill stuff where we don’t need it, and
> > > strengthen stuff where we do”
> > > Colin also agreed that what they had done was not rocket science and
> > > simply common sense and that many many organisations have many people
> > > who already know what should be done and how it should be done but
> > > they don’t get the remit/budget/mandate to do anything.
> > > Which is why I have started thinking that the best way to get
> > > organisations to adopt EA is to marry the education and awareness
> > > approach with a catalyst approach. There are many…
> > > - Mergers & Acquisitions
> > > - Business Unit Consolidation
> > > - Introduction of New Products, Services or Lines of Business
> > > - Outsourcing a Business Function
> > > - Divesting a line of Business
> > > - Operational Cost Reduction
> > > - Business Transformation
> > > - Building Relocation
> > > - Strategic Planning
> > > - Increase Business Agility, Efficiency and Effectiveness
> > > - Streamlining Business Processes
> > > - Consolidation of Suppliers, Technologies or Applications
> > > - Business Process Management
> > > - Business Process Re-engineering
> > > - Off shoring
> > > - Market/Shareholder Pressure
> > > @Joseph: “, EA …..is an iterative process. You could start anywhere in
> > > this circle”
> > > Sort of. some things you can some things you cant; For example, you
> > > can just start modelling stuff before buying a proper tool, however
> > > you can’t start doing governance using principles (operate) until you
> > > a) have agreed what they are and b) made the changes in the
> > > organisation required to operate them (Implement)
> > > @Joseph: “Just because you have an EA team using an EA tool, doesn't
> > > mean you are actually performing EA.”
> > > I would say yes and no.
> > > My higher level view is that EA is generally about strategic planning,
> > > modeeling and governance.
> > > Based on this, I would say that 99.9999% of organisations are already
> > > “doing” EA. They already do strategic planning (it may be terrible),
> > > they already do modelling (it may be terrible) they already do
> > > governance (it may be terrible).
> > > They may do everything terribly, but they still have an EA and they
> > > still do EA.
> > > If you don’t use a project management methodology (e.g. Prince2, MSP)
> > > does this mean you don’t do project management? No.
> > > Frameworks help people to do what they are doing in a more efficient,
> > > better, structured way.
> > > EA is no different to Prince, MSP, Six Sigma, LEAN, ITIL, COBIT, etc
> > > etc etc.
> > > They are all frameworks/.methodologies/methods for improving thngs.
> > > They just scratch different itches.
> > > @Joseph: “But, all your efforts would be towards populating the as-is
> > > with lower-
...
read more »
> EA tools are not a question of whether but when, and the when is when
> you know enough to use them.
I don't think we are debating whether a tool is needed or what that tool should be. We are specifically discussing only "the when" aspect.
You do say
> First you need a dynamic methodology, then you
> need training, tools and expertise to
> support it.
I kind of agree with you above about the first. But I would suggest, first you need an EA Vision to start. This delivers some goals to target, i.e. reduce cost, increase agility, or increase capability, etc. All the other steps follow later, perhaps in different orders depending on the organisation maturity and its readiness. I completely agree with Peter Hunsberger on his last posts.
> YOU SIMPLY CAN'T DO "REAL EA" WITHOUT TOOLS, INDUSTRIAL
> GRADE TOOLS!
Hmmm... What is "REAL EA"? Even EAs can't seem to agree... :-)
And, I see no point in buying "INDUSTRIAL GRADE TOOLS", if the organisation simply cannot afford it, or the people to use it, i.e. does not have capable EAs or other personnel to support this amazing tool. An EA tool is only good enough if everyone who are supposed to populate it, are diligent and skilled enough with this tool. Else, the TCO would result in a white elephant and another shelfware.
If the organisation can afford a good tool, has trained EAs and all other relevant analysts in this particular tool, then it is probably ready to use this tool. If this is the case, it better have supportive management ready to drive forward the resultant EA delivery and targets. Otherwise, all these efforts would just generate another business process and red-tapes hampering business agility.
To end my £0.02, I would say, have capable people in place, before you get capable tools. Who would identify which tool is capable? When/How would this capable tool become beneficial?
Best regards,
Joseph
On May 29, 5:40 pm, Ken Orr
> Every once in while people get heated about the wrong question. The
> statement that some organization
> “started EA before they started with the tools” is kind of
> meaningless. What's missing is the idea of a
> workable methodology. First you need a dynamic methodology, then you
> need training, tools and expertise to
> support it. YOU SIMPLY CAN'T DO "REAL EA" WITHOUT TOOLS, INDUSTRIAL
> GRADE TOOLS!" Sure you
> can use Visio to draw pictures, but and EA database is not just a set
> of pictures done one time,it is a set
> of pictures that support an EA Roadmap that are constantly updated.
> One of the core problems with REAL EA is that the problems are so
> complex that you need special tools to
> address just the interactions between systems or the numbers of
> individual data tables. If you select tools too
> early, however, there is a good chance that the organization will not
> really understand what the requirements
> are and end up trying to get the cheapest solution...bad idea.
> EA tools are not a question of whether but when, and the when is when
> you know enough to use them.
> Ken
> On May 26, 3:05 am, Joseph George
> > Kevin,
> > > Not sure what “started EA before they started with the tools.” means -
> > > but as I understood it (after sitting through the presentation) they
> > > only way they started was to buy a tool, figure out a good question
> > > they wanted to answer that would give a big return (application
> > > portfolio rationalisation), populated the tool with the data required,
> > > made some changes, save d a lot of money, modelled some more, etc,
> > > etc.
> > Hmmm... that sounds like a fool with a tool approach. We could apply
> > this same principle to any (not necessarily EA) tool and start a
> > business model around that tool, viz. "buy a tool, figure out a good
> > question they wanted to answer that would give a big return, populated
> > the tool with the data required, made some changes, save d a lot of
> > money, modelled some more, etc, etc." Et Voila, I've got a new
> > business case. Let us buy a hammer (or whatever the latest jazzy thing
> > the advertising industry is throwing at us), figure out a good
> > question... that would give a big return,... etc etc.
> > But further down your post, you answer exactly what I meant. You
> > probably figured that yourself
> > > Which is why I asked Colin Birchenall after the presentation.
> > And the answer contains the EA approach and the tool was part of their
> > solution. Purrfect!
> > > to start modelling stuff, so we can
> > > understand stuff, so we can kill stuff where we don’t need it, and
> > > strengthen stuff where we do”
> > And what a brilliant way to gain buy-in from the business owners:
> > > the only way we can work with you and
> > > generate a return for all is to
> > I like this approach. Either we agree on a clear approach and work
> > together and generate a return for all. Or we can't generate a return
> > and won't work with you! Any waffling rhetoric about fluffy stuff just
> > muddies the water for the sponsors and disengage them.
> > Kind regards,
> > Joseph
> > On May 24, 4:01 pm, "Kevin (PragmaticEA.com) Smith"
> >
> > > @Joseph: “However, I would venture to say from the example he gives
> > > that they started EA before they started with the tools. All it means
> > > is that they started using the tool, before they had a complete EA
> > > vision populated.”
> > > Not sure what “started EA before they started with the tools.” means -
> > > but as I understood it (after sitting through the presentation) they
> > > only way they started was to buy a tool, figure out a good question
> > > they wanted to answer that would give a big return (application
> > > portfolio rationalisation), populated the tool with the data required,
> > > made some changes, save d a lot of money, modelled some more, etc,
> > > etc.
> > > They started at the application /infrastructure level then moved up
> > > into solution architecture, then project portfolio then strategy.
> > > The point being they did stuff that saved money.
> > > The question, of course is…
> > > “OK - but you needed a mandate/money etc to buy the tool, have some
> > > training, and the people to do some modelling etc right? So how did
> > > you get the mandate/money ?”
> > > Which is why I asked Colin Birchenall after the presentation.
> > > Hi answer was - “Yes, exactly right - the catalyst was the formation
> > > of the LLP between Serco and Glasgow City Council. Serco had basically
> > > said, OK - you want us to be in partnership with you in terms of
> > > provision of IT? = no problem - the only way we can work with you and
> > > generate a return for all is to start modelling stuff, so we can
> > > understand stuff, so we can kill stuff where we don’t need it, and
> > > strengthen stuff where we do”
> > > Colin also agreed that what they had done was not rocket science and
> > > simply common sense and that many many organisations have many people
> > > who already know what should be done and how it should be done but
> > > they don’t get the remit/budget/mandate to do anything.
> > > Which is why I have started thinking that the best way to get
> > > organisations to adopt EA is to marry the education and awareness
> > > approach with a catalyst approach. There are many…
> > > - Mergers & Acquisitions
> > > - Business Unit Consolidation
> > > - Introduction of New Products, Services or Lines of Business
> > > - Outsourcing a Business Function
> > > - Divesting a line of Business
> > > - Operational Cost Reduction
> > > - Business Transformation
> > > - Building Relocation
> > > - Strategic Planning
> > > - Increase Business Agility, Efficiency and Effectiveness
> > > - Streamlining Business Processes
> > > - Consolidation of Suppliers, Technologies or Applications
> > > - Business Process Management
> > > - Business Process Re-engineering
> > > - Off shoring
> > > - Market/Shareholder Pressure
> > > @Joseph: “, EA …..is an iterative process. You could start anywhere in
> > > this circle”
> > > Sort of. some things you can some things you cant; For example, you
> > > can just start modelling stuff before buying a proper tool, however
> > > you can’t start doing governance using principles (operate) until you
> > > a) have agreed what they are and b) made the changes in the
> > > organisation required to operate them (Implement)
> > > @Joseph: “Just because you have an EA team using an EA tool, doesn't
> > > mean you are actually performing EA.”
> > > I would say yes and no.
> > > My higher level view is that EA is generally about strategic planning,
> > > modeeling and governance.
> > > Based on this, I would say that 99.9999% of organisations are already
> > > “doing” EA. They already do strategic planning (it may be terrible),
> > > they already do modelling (it may be terrible) they already do
> > > governance (it may be terrible).
> > > They may do everything terribly, but they still have an EA and they
> > > still do EA.
> > > If you don’t use a project management methodology (e.g. Prince2, MSP)
> > > does this mean you don’t do project management? No.
> > > Frameworks help people to do what they are doing in a more efficient,
> > > better, structured way.
> > > EA is no different to Prince, MSP, Six Sigma, LEAN, ITIL, COBIT, etc
> > > etc etc.
> > > They are all frameworks/.methodologies/methods for improving thngs.
> > > They just scratch different itches.
> > > @Joseph: “But, all your efforts would be towards populating the as-is
> > > with lower-
...
read more »
Subscribe to:
Posts (Atom)