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.

No comments:

Post a Comment

Popular Posts