Category: Enterprise Architecture

What’s good for Obama is good for General Motors

There is something particularly exciting about Barack Obama’s plan to appoint a government chief technology officer.  Not only is this good for government, but it’s also good for the IT industry.  Like Ron Tolio of Cap Gemini has said

No half measures. And quite a strong message to many corporations that struggle with the role of IT in business. This is far from the marginalised position of an IT manager who apathetically reports to the CFO about cost cutting and risk management. This is a boardroom position, one that is supposed to create strong impulses for change and growth.

There is a real difference between a CIO that is charged with ‘serving the business’ and one that is charged with ‘getting value from IT’.  You can serve the business by saying ‘it’s the business’s money therefore they get to decide how to spend it’.  But to commit to delivering value out of IT you have to commit to business benifits and a business return of technology spend.  You need to actually contribute to the strategy and deliver growth through technology spend.

It doesn’t matter what type of CIO you are.  As long as you know what is expected you can be successful.  But if you are successful purely because you have moved investement decisions to business units, who is ensuring that you are getting the most value out of IT?  Is IT actually contributing to the organisations strategy and growth?

Anyway, it’s also good to see a few of these sites popping up too.  ObamaCTO.org allows anybody to suggest ideas for the CTO role, which are then voted on and ranked.  Now this sort of system is still susceptible to manipulation by special interests.  But it’s transparent – and that’s all you can do.

The Enterprise Architecture Network Google Group

The Enterprise Architecture Network Google Group has soon good disucssions.  Though it sometimes goes beyond what I would strictly call ‘enterprise architecture’; but most EA discussion do.  I would recommend joining it to connect with other architects.  You also have to be a member of the related LinkedIn group.

More for my own reference, here is a contribution I made to a recent discussion on the difficulty in determing an ROI for an enterprise architecture practice:

Hi  

I think it’s unfortunate when we are asked for an ROI for developing a EA practice.  This is like asking for the ROI of having a project manager.  It’s probably a good question, and I’ve asked it myself, but some things need to be sacred so we can just get on with the job.
I’d never ask for the ROI to set up an EA practice – to me this is sacred – because I’m sold on the idea already, as long as it’s small.  I think we need to sell EA more so less people ask for an ROI. But I also think that means changing slightly how we currently define EA.  It also means we need a response when people ask for an ROI…

This is why I’m so interested in how we define what EA actually is.  I think we should define EA solely as what some on this group might call Enterprise Business Architecture (EBA).  The other deliverables, work products, initiates, etc should be traced to that EBA but we shouldn’t call that the EA.  We also shouldn’t say the EA is complete only when all of the IT components properly align to it.  We should simple do the EBA – showing value streams, key customers, service strategies for the enterprise, etc – and trace to the minimum asset types required to get calculate baseline alignment to the EA.

The reason I say this is because you can’t define a return on investment for developing an EA practice except in terms of improving decision making relating to IT investment.  You are looking to improve alignment to the EBA over time, but you can’t do that from the EA practice itself.  You can only do that by influencing IT investment decisions.  Unfortunately, a more general tool already exists for improving decision making relating to investments.  And that’s the ROI calculation.

The problem is nobody ever asks ‘What is the ROI of determining the ROI?’, nobody ever asks the question ‘What is the quality of the ROI calculation?’, and nobody ever asks ‘How is the ROI process performing?’.  There is a bunch of IT effort being spent which roles up into the ROI calculation and unless you think your IT systems couldn’t be any better at this point in time, it’s not working.

Whether it’s formal or informal, organisations already think they are making decisions to maximize return on investment.  The problem is, in the area of IT investment there is no formal method of determing the inputs which go into the calculation of return on investment.  Also, the inputs must take into account the value streams of the business, IT costs, changes in IT cost structure, and changes in business cost structure.  IT initiatives move costs into IT while creating activities/costs to be performed by users outside IT.  As such, IT can’t determine ROI itself because the initiatives transform more than just the IT organisation.

An EA practice should formalise that process of determining the inputs into ROI calculations. It should also allow the performance of that process to be managed over time.  By the way, within the phase ‘IT initiatives’ I am also including that particular type of project I like which is technology-enabled business transformation.

Other initiatives – business initiatives – simply need to include the costs of IT in their ROI calculation.  IT cannot, by itself, commit to all ‘returns’ which are outcomes of IT initiatives.  This doesn’t mean IT can’t run business transformation programmes.  It simply means that any initative of this type requires communication, traceability, and modeling across multiple disiplines.  And it needs this even to calculate the ROI.

EA, in the strict sense of Enterprise Business Architecture, is the basis for not only IT strategy, but also for IT investment decisions.  EA, in this sense, is the baseline level of knowledge and process required to make ROI calculations for other IT initiatives.  So asking for an ROI for and EA practice which analyses the value streams of an enterprise and traces these to technical and organisational components is like asking for the ROI of developing high quality ROI calculations.

By the way, it’s possible that a particular CIO doesn’t have the responsibility for delivering value from IT investments.  In some instances the IT function doesn’t technically run even IT projects.  Instead these projects are ‘business projects’ relying on IT only to deliver a defined set of IT services.  However, this is a dangerous position for a CIO to be in.  It also just means that the EA practice should be sponsored by somebody else who does have that responsibility.  It doesn’t mean that (a small) EA practice shouldn’t exist.

Regards,
Matthew De George

Enterprise Architecture: ‘New’ to MWT

The MWT/TEBT Collaboration Architecture recognises that when technologies successfully transform businesses they often do so through sharing and/or standardisation of business processes and data.  It is this standardisation which allows greater transparency of operations (and operational risk) as well as ultimately enabling the implementation of the market-based approach at the heart of the MWT Model.

However, when it comes to defining and selecting which technology-enabled business transformation (TEBT) initiatives to perform, there is an overlap between the MWT Model and the most useful parts of what is called Enterprise Architecture.

Where enterprise architecture relates is in developing the collaboration architecture (to use the MWT term) to enable the senior executive team to have discussions on organisational value – and ultimately what processes and data should be standardised and/or shared via technology implementations.

Many enterprise architecture treatments focus only on optimising the platform architecture of the enterprise.  This makes many enterprise architecture discussions far too technical.  Also, from an implementation perspective, standardisation on platforms may actually be too expensive to ever implement; while at the same time it may provide less value to the enterprise than other initiatives could have.  Discussions on enterprise architecture that fall into this category may in fact reduce IT spend while losing focus on the knowledge and related IT capabilities which could increase the value of IT.

One book that doesn’t fall into this trap is Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.  I strongly recommend it as an introduction to this topic.  I have also added an Enterprise Architecture blog category to tag future posts on this topic.

Page 3 of 3

Powered by WordPress & Theme by Anders Norén