A scenario comes to mind -
A man wants to start a business. So, he goes downtown to the city centre and rents a shop in a prime location. He puts up a nice banner outside, and enters his shop... and starts thinking. What should his business be?
Next he goes outside and looks at some of the other shops. He finds some gadgets which take his fancy. He buys those from his friendly neighbouring shops, and brings those tools back to his shop. He starts thinking again... What should his business be?
Is this where an EA enters the scenario??
Best regards,
Joseph
SOA Best Practices @Gartner
I attended a Gartner briefing called "SOA Best Practices - How To Use It To Make A Difference" at their EMEA HQ in Egham.
Of the three presentations,
(1) was very useful
(2) was all about development, and not much to do with SOA
(3) was all about file transfers, and not relevant at all
Of the three presentations,
(1) was very useful
(2) was all about development, and not much to do with SOA
(3) was all about file transfers, and not relevant at all
Tool first or Purpose first for EA
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- level details more useful for support/operations rather
> than architecture. Not a wasted effort, IMHO. But, I wouldn't want to
> be spending all my architecture efforts in documenting the complete
> as- is. I would never hope to complete this task... :-)”
> Correct - which is why you don’t approach modelling that way.
> A lot of people do and they mostly fail because it’s the wrong
> process.
> 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- level details more useful for support/operations rather
> than architecture. Not a wasted effort, IMHO. But, I wouldn't want to
> be spending all my architecture efforts in documenting the complete
> as- is. I would never hope to complete this task... :-)”
> Correct - which is why you don’t approach modelling that way.
> A lot of people do and they mostly fail because it’s the wrong
> process.
Chancellor takes the axe to IT spending
tags
gov
And why not? The public sector is possibly best placed to gain benefits from Enterprise Architecture practised at the highest-levels. Just look at the plethora of services and assets scattered around the public estates funded by the same taxpayer and you can just about imagine the wasted (not just IT) expenditure behind the scenes.
Scope of Enterprise Architects in Cloud Computing World!
That entirely depends on where you, as an architect, are sitting - inside the cloud within the cloud operator or outside the cloud within the cloud user. Either way, the architecture principles remain the same, but the operations and business model are radically different.
Best regards,
Joseph
On May 24, 7:00 am, N Gowthaman wrote:
> Group,
> I am curious to understand the scope an Architect will be having in his
> profession with the advent of cloud computing space. Your thoughts pl
> N. Gowthaman
Best regards,
Joseph
On May 24, 7:00 am, N Gowthaman
> Group,
> I am curious to understand the scope an Architect will be having in his
> profession with the advent of cloud computing space. Your thoughts pl
> N. Gowthaman
Tool first or Purpose first for EA
Good post by Kevin! 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.
Also, EA (whatever framework you use) is an iterative process. You could start anywhere in this circle. As long as you complete a full iteration and preferably a second one, it shouldn't matter where you started out. But you would definitely have had an EA to start with. Most (or rather all) organisations have an EA. Whether they admit it or not, whether it is visible as an EA team or not, is a different matter.
What we are probably referring to, when we mention EA, is perhaps a formal EA team with a defined methodology using an accepted framework and documented fully. IMHO, that is an ideal state, and practically unfeasible and perhaps unrealistic. EA usually never completes. As EA is an iterative process, by the time you reach your goal, it probably might be time to start over again with the next iteration...!!!
Just because you have an EA team using an EA tool, doesn't mean you are actually performing EA.
I would think that having a tool is helpful for completing your EA. But, all your efforts would be towards populating the as-is with lower-level details more useful for support/operations rather than architecture. Not a wasted effort, IMHO. But, I wouldn't want to be spending all my architecture efforts in documenting the complete as-is. I would never hope to complete this task... :-)
Best regards,
Joseph
On May 19, 9:23 am, "Kevin (PragmaticEA.com) Smith" wrote:
> first and Tool second" or "Tool First and Architecture Strategy
> second".”
> Using and or starting with a tool is an eminently valid approach to
> start the adoption of EA and EA practises.
> It has been used successfully by many many organisations, for example,
> by Colin Birchenalls presentation at this weeks Gartner EA conference
> in London, where starting with a tool was the absolute best approach
> for Serco and Glasgow City Councils LLP and for the many successes
> they have achieved in growing up to the full EA level by delivering
> massive and real value to the business by modelling using a tool.
> There are many people who have completely failed by starting with a
> tool.
> The reason for this failure is NOT because starting with a tool is
> wrong or bad.
> The reason is (as with many many things that EA seeks to address) is
> process.
> Many people incorrectly start to use the tool (one example of bad
> process but there are many other ways of failing) by modelling the
> heck out of everything and after 6 months (or years for some failed
> attempts) the CEO asks what have we gained and the answer is nothing.
> Don't blame the tool is you use the tool incorrectly. Don't blame the
> screwdriver if you try to hammer nails in with it.
> The successful process for using a tool is actually very simple...
> Stage 1 – Determine the Question
> Identity a high level business question that the management wants an
> answer to, that they either: -
> a) Currently cannot answer, or
> b) Can get an answer but the quality and confidence in that answer is
> too low to be useful.
> Stage 2 – Determine Required Data
> Having understood what the question is, this stage identifies what
> information will be required to answer it. It should be noted that the
> temptation to try to answer the question should be resisted.
> Stage 3 – Populate the Model
> The third stage of the iteration is to find and populate the model
> with the information identified. This sub-process is described in
> detail in the next section
> Stage 4 – Integrate the Model
> This phase ensures that the work that has been done and the
> information loaded into the model is sustainable. For each of the
> Datasources there are two alternatives (which were identified in the
> Analysis Phase).
> a) The Datasource is removed – The processes and people using the
> original Datasource will stop using it and will use the information in
> the model.
> b) The Datasource is preserved – The necessary interfaces are built to
> enable the synchronisation and management of the data going forward.
> Stage 5 – Answer the question
> Having populated the model, it is now possible to use the mode in
> concert with the tools and analyses provided by the modelling tool the
> answer the business question. After this, another iteration is
> possible.
> fyi, I have just started a related discussion the EA Network Linked In
> discussion group (http://www.linkedin.com/groups?home=&gid=36781)
> entitled …
> GARTNER: "A FOOL WITH A TOOL IS STILL A FOOL"
> I was dismayed to hear this same staid, tired and, IMHO, damaging
> catchphrase at this weeks Gartner EA summit in London (May 2010).
>http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=3678...
Also, EA (whatever framework you use) is an iterative process. You could start anywhere in this circle. As long as you complete a full iteration and preferably a second one, it shouldn't matter where you started out. But you would definitely have had an EA to start with. Most (or rather all) organisations have an EA. Whether they admit it or not, whether it is visible as an EA team or not, is a different matter.
What we are probably referring to, when we mention EA, is perhaps a formal EA team with a defined methodology using an accepted framework and documented fully. IMHO, that is an ideal state, and practically unfeasible and perhaps unrealistic. EA usually never completes. As EA is an iterative process, by the time you reach your goal, it probably might be time to start over again with the next iteration...!!!
Just because you have an EA team using an EA tool, doesn't mean you are actually performing EA.
I would think that having a tool is helpful for completing your EA. But, all your efforts would be towards populating the as-is with lower-level details more useful for support/operations rather than architecture. Not a wasted effort, IMHO. But, I wouldn't want to be spending all my architecture efforts in documenting the complete as-is. I would never hope to complete this task... :-)
Best regards,
Joseph
On May 19, 9:23 am, "Kevin (PragmaticEA.com) Smith"
> first and Tool second" or "Tool First and Architecture Strategy
> second".”
> Using and or starting with a tool is an eminently valid approach to
> start the adoption of EA and EA practises.
> It has been used successfully by many many organisations, for example,
> by Colin Birchenalls presentation at this weeks Gartner EA conference
> in London, where starting with a tool was the absolute best approach
> for Serco and Glasgow City Councils LLP and for the many successes
> they have achieved in growing up to the full EA level by delivering
> massive and real value to the business by modelling using a tool.
> There are many people who have completely failed by starting with a
> tool.
> The reason for this failure is NOT because starting with a tool is
> wrong or bad.
> The reason is (as with many many things that EA seeks to address) is
> process.
> Many people incorrectly start to use the tool (one example of bad
> process but there are many other ways of failing) by modelling the
> heck out of everything and after 6 months (or years for some failed
> attempts) the CEO asks what have we gained and the answer is nothing.
> Don't blame the tool is you use the tool incorrectly. Don't blame the
> screwdriver if you try to hammer nails in with it.
> The successful process for using a tool is actually very simple...
> Stage 1 – Determine the Question
> Identity a high level business question that the management wants an
> answer to, that they either: -
> a) Currently cannot answer, or
> b) Can get an answer but the quality and confidence in that answer is
> too low to be useful.
> Stage 2 – Determine Required Data
> Having understood what the question is, this stage identifies what
> information will be required to answer it. It should be noted that the
> temptation to try to answer the question should be resisted.
> Stage 3 – Populate the Model
> The third stage of the iteration is to find and populate the model
> with the information identified. This sub-process is described in
> detail in the next section
> Stage 4 – Integrate the Model
> This phase ensures that the work that has been done and the
> information loaded into the model is sustainable. For each of the
> Datasources there are two alternatives (which were identified in the
> Analysis Phase).
> a) The Datasource is removed – The processes and people using the
> original Datasource will stop using it and will use the information in
> the model.
> b) The Datasource is preserved – The necessary interfaces are built to
> enable the synchronisation and management of the data going forward.
> Stage 5 – Answer the question
> Having populated the model, it is now possible to use the mode in
> concert with the tools and analyses provided by the modelling tool the
> answer the business question. After this, another iteration is
> possible.
> fyi, I have just started a related discussion the EA Network Linked In
> discussion group (http://www.linkedin.com/groups?home=&gid=36781)
> entitled …
> GARTNER: "A FOOL WITH A TOOL IS STILL A FOOL"
> I was dismayed to hear this same staid, tired and, IMHO, damaging
> catchphrase at this weeks Gartner EA summit in London (May 2010).
>http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=3678...
Doing Business without EA is like building a chain of “open” links
tags
philosophy,
tea.net
Lewis Caroll in Alice's Adventures in Wonderland:
Alice came to a fork in the road. "Which road do I take?" she asked.
"Where do you want to go?" responded the Cheshire cat.
"I don't know," Alice answered.
"Then," said the cat, "it doesn't matter."
Subscribe to:
Posts (Atom)