I should preface this post by saying that I am a huge fan of enterprise architecture and have been for some time. However, I posit that there is simply no evidence that enterprise architecture actually exists or will ever exist.
If EA were working or was economically viable we could have expected a decline in the global outsourcing market as businesses sought to integrate and consolidate applications along an enterprise metamodel. However, this work predicates a level of control and ownership which is not consistent with applications/business process outsourcing.
Definitions of EA aside, it seems clear to me that the economic benefits of EA simply cannot compete with the economic benefits of outsourcing. In order to turn the tide, my personal opinion is that EAs need to be able to architect from the financial instead of the minutiae of the technical. Stop trying to solve technical problems and start trying to solve business problems. More importanlty – in line with the ‘E’ in enterprise – be able to cut through the petty bureaucracies and fiefdoms of middle management and begin to define business problems by calibrating financial statements with technical information. In other words, how can technical architects analyse adverse financial variances on the monthly balance sheet and turn them into changes in the technical development or delivery? What is the technical implication of a month-on-month 17.5% adverse variance on Indirect Labour? Until these figures become the mainstay of an Enterprise Architect’s work then EA will never be able to compete with the simple value proposition of outsourcing, i.e. “it’s not working! give it to an expert.”
More importantly, in virtually all businesses (i.e. non-tech businesses) the company is defined by accountants and sales people. Operations comes in close second and IT is so far at the back of the corporate parade that it can’t even hear the marching band play. In order for Enterprise Architecture to morph into something useful – and something closer to what I imagine Zachmann imagined – it will need to deal with enterprise engineering. This is the difference between systems engineering and Engineering Systems, i.e. the engineering of information between the various systems/functions in the business. What is the atomic meaning of a cost variance in IT terms?
Until EA/EE can truly grasp the complexities of the enterprise it will only ever be IT window-dressing. In the meantime, I hope I’m wrong.
In a recent article in online magazine CIO & Leader Chris Potts argues that technology has come so far that CIOs need to start to take the lead and help businesses move beyond the antiquated structures of yesterday. He says that CIOs need to tell a story of how the business could be, how it should be. He says that CIOs are uniquely equipped with the technological mindset to tell the story of the business of the future.
In recent tweet I was harsh on Chris but in hindsight I believe I need to be more brutal. The world does not go round for a lack of dreams. Businesses are not short on vision. What is lacking is execution. Projects do not fail for want of strategic intent, they fail for want of expert systems engineering and expertise in engineering systems. This means that an enterprise doesn’t only need good technical expertise in their horizontal functions but they need expertise in the methodology which carries that knowledge as it passes through the market verticals. This is to say that it is fine to be a good project manager but can you manage the project from market analysis through to business development? Can you manage the project through the architecture? Through to contract close out?
None of this relies on telling stories. These is deep technical expertise. Storytelling shouldn’t be ignored. One of my all-time favourite authors, Larry Prusak, is a huge believer in storytelling as a means for engagement and building up a common picture of knowledge. A sort of inherited reference point for change. As important as storytelling is, it is becoming a fad and a distraction for executives. By focusing on storytelling they are ignoring the real complexity hidden in projects.
Corporate storytelling is developing a huge following and it’s not just for CIOs. Larry Prusak loves it, Patrick Lencioni has elevated it into a fine art and everyone seems to be getting the storytelling bug. Stories are great because they help people from disparate backgrounds develop a common understanding of a problem or vision – one that sticks. Storytelling has the power to corral even the most difficult of us and motivate us to play our part in the corporate journey.
Executives love stories because they require almost no detail, no plan, no roles and responsibilities and no changes in remuneration. Done well, they can convince people into delivering more for less pay and when they don’t stories will shame those same underpaid workers into delivering the goods. What’s not to like about storytelling?
At large UK outsourcing establishment there was an underperforming account in the Midlands. Legend has it that the CEO of the local authority berated the account manager with the legendary phrase: I’ll buy more IT when you can solve teenage pregnancy!” The account manager duly skulked into the corner and got on about his job of providing outsourced IT services. What should he have done? He should have used that story to develop truly value adding services which would have (i) increased the profitability of the account, (ii) built trust between him and the CEO, and (iii) possibly helped try and solve the actual problem.
He didn’t, so I did. I went to India and spoke to our outsourcing partners. I tried to engineer an end-to-end process whereby we could harness the incredible intellectual latency of our outsourcing partners, Genpact and Patni, to develop an integrated process for analysing local authority data then identify and target girls at risk for tailored social services. In this way we could break the socially debilitating cycle of early teenage pregnancy whilst pushing account revenue into the stratosphere. We needed to do this in a way that enabled us to retain the confidence of our customers as well as created buy-in from internal management. So, we made sure the data security was right and that the project was aligned to the new corporate strategy of a greater push into outsourcing the middle-office.
I told the story. I told it again and again but I used it to tease out the detail of the development process, the customer engagement process, the revenue model and the customer benefits. Because, for every executive who smiled at the heart-warming vision there were 3 contrary developers, engineers and other middle managers who tried to shoot me down with the detail. My story explained the engineering process. My story was the glue which pulled all the systems engineering together and that is how I believe enterprise storytelling can help organisations.
The IACCM rightly points out that key supplier relationships underpinned by robust and comprehensible contracts are essential to the implementation of significant strategic change. Their research identifies a 9.2% impact on bottom line from contract weakness. Top 5 causes being:
- Disagreement over contract scope,
- Weaknesses in contract change management,
- Performance failures due to over commitment,
- Performance issues due to disagreement over what was committed,
- Inappropriate contract structures or responsibilities.
Two things are given in this mess: (i) Firstly, that contractual structures are weak and inappropriate to deal with high levels of operational complexity and technical risk, and (ii) secondly, that legal means of enforcement are cumbersome, expensive and ineffective.
That business is ready to solve this legal problem by contracting for outcomes is (a) nonsense and (b) missing the point. Business is already dealing with the operational and technical risk of large and complex contracts. Business is already structuring many of its agreements to deal with outcomes. Large prime contracts, alliance contracts and performance-based contracts are already commonplace in PFI/PPP and Defence sector deals. That neither are wholly efficient or effective is for another time. It is, however, for the legal community to devise more sophisticated ways of contracting in order to solve their side of the problem.
PEOPLE ARE THE KEY
The primary reason for not being able to contract for outcomes is that the vendor doesn’t own the people. This is critical because without the ability to control and intervene in the delivery of work the risk increases exponentially. Consequently, the risk premium paid for outcome-based contracts will either make them (a) prohibitively expensive, or (b) impossible to perform (within parameters). So, a business which offers you an outcome-based contract is either having you on or just about to charge you the earth.
The chart below only serves to prove Paul Strassman’s mantra that outsourcing is more an emetic than a cure. By and large the following is true:
- Outsourcing is a financial decision and not a business one.
- Companies engaging in heavy outsourcing activity are overall commercial losers.
- Financial gains from outsourcing are usually mythical as per user costs usually increase from declines in overall employment.
- The only financial gains from outsourcing are usually short term wins on the stock markets.
Large scale outsourcing of the IT function weakens corporate productivity by lessening flexibility at a time where the company must create additional agility in order to survive. The heavier the outsourcing activity the more likely the business is to lose its information management function, i.e. the ability access information (which now largely resides under vendor SLAs), package and use it quickly and effectively is now gone.
The secret to IT outsourcing is to (a) commoditised and (b) focus on capability. Firstly, businesses should not even have to think about infrastructure. There are very few arguments to retaining one’s own data centre. IT infrastructure and even network monitoring and optimisation are highly commoditised product offerings with very low risk. Just do it.
Secondly, focus on capability. Understand where technology creates value in your business. Focus on increasing the productivity (and reducing costs) of those areas of opportunity by packaging modular information offerings from high-end suppliers. For instance, some outsourcing companies specialise in data analytics and BI. Some specialise in risk analysis and some specialise in service-based client messaging. Start to build these services – all of which can be done better and cheaper by outsourcing firms – and begin to build them into a client narrative which allows your business to penetrate deeper into the middle and front offices. This is just an example but it highlights the fact that if your company has a modular information supply chain you have the agility to create great, differentiated service offering based on real customer value.
Be careful what you outsource. Get to grips with business complexity (it’s here to stay) and don’t derogate from your business responsibility to information management.
Aristotle wrote that “metaphor is the worst form of argument. He’s right. If you have something to show/prove, then do so precisely and in a way which is meaningful and useful to your target audience.
Recently the guys at Innovation of Risk posted an article on the use of infographics to analyse risk. I don’t know who coined the term “PowerPoint Engineering” but most infographics fit neatly into this category. Infographics can save presentation or they can sink it but mostly they are used to convey ill conceived and poorly thought out ideas which snowball into worse run projects. The best advice is to take these bath-tub moments (why do people think they have great ideas when they’re washing?) and run the analysis with an expert using an expert system. If you can’t do that then (a) you’re in the wrong department for having the idea in the first place, and (b) chances are that there is a tonne of minute but important detail you missed out.
Whilst I think that visual display of graphics is vital to achieve stakeholder buy-in, it is also clear that imprecise PPT-engineering masquerading as infographics is the worst form of management snake-oil there is. An erstwhile systems engineering mentor of mine used to say, “if you think they’re BS’ing you then ask them what the arrows mean”. 9 times out of 10 they won’t have a clue.
Although a recent article in SearchCIO alludes to competitive advantage by IT departments, arguments like this can take the CIO down a dangerous road. The holy grail of many CIOs is to run a department which is both profitable and also increases business capability. Mostly, however, IT departments are costly and the subject of constant complaint.
Can IT ever be a profit centre?
Economists have long argued that businesses should strip away overhead (i.e. not included in the cost of goods sold but pure overhead) cost chargebacks from business verticals and their processes in order to gain a clearer view of what is profitable and what is not. If they don’t then smaller, profitable processes are often in danger of being swamped with overhead. In this way, many businesses often outsource or cut the wrong activities.
It is notoriously difficult to cost IT chargebacks so that market verticals are charged just the right overhead. Should businesses charge their verticals for email? They often do but isn’t this just a cost of business that the centre should absorb? Isn’t the burden of communication and reporting largely placed onto verticals anyway? So if they could run their business units in a more entrepreneurial way wouldn’t the cost of IT be significantly reduced?
What if we extend that argument and let IT be a profit centre? Why don’t we let business units find cheaper ways of doing business and compete with the IT department? Security/integration/management time arguments aside – it is likely that if IT departments were able to charge for the thing they were really good at, this would be a source of competitive advantage within the business.
So, there is a good reason why IT departments aren’t profit centres but, of course, this doesn’t solve the problem of the high cost of IT inside business.
In a recent article for Beyond IT Failure Michael Krigsman highlights the colossal disconnect between IT and the business. Looking at the graph below has IT really spun off at a tangent? Is IT just pursuing its pet projects again?
IT is not wrong. IT is best placed to understand compliance requirements. IT should understand which applications delivery value for money and IT should be able to choose which apps support competitive advantage. Cloud is, by and large, a non-functional requirement as so does not need to be in the functional user spec.
“Business is not a toy shop and the argument “but I’ve got it on my phone” does not wash in a secure, structured enterprise environment.”
So why the disparity between what what the business thinks it needs and what IT choses?
- IT is a cost centre. IT is responsible for delivering functionality in the most cost effective way. Business is not a toy shop and the argument “but I’ve got it on my phone” does not wash in a secure, enterprise environment.
- Business Requirements. I have never met a business vertical which understood its requirements. Requirements engineering for the systematic design of accurate software is an entire segment of the tech industry. It is complex and (mostly) poorly done. Invest in getting it right if you want to deliver better systems.
- Engagement. There is no two ways about it – IT is appalling at business engagement and business are shockingly bad at letting IT in and then articulating their needs (in order to begin the requirements process.
- Productivity. Improved productivity is more of a human problem than a technological one. New software will not make people smarter. Unless the processes and collaboration structures already exist then new binary systems will only serve to compound the problem. In such cases, software procurement becomes a very, very expensive process of sandboxing and prototyping to elicit accurate business requirements.
In order to achieve better ROI on tech investments whilst still delivering great software which improves productivity, businesses need to (a) understand where tech enables business capability in their value chains, (b) understand the development of their business’ capabilities, and (c) create a ‘value ladder’ which supports the parallel propositions of architectural development and business productivity.
Sometimes the best defense is deletion – CSO Online – Security and Risk.
The point is prescient. In these early days of Big Data awareness the battle between information management v. store now/analyse later can obfuscate other issues: Cost and Necessity.
ONE BIG POT
Is there really the practical technology that an organisation can actually move away from structured databases and just stick all its information into one big ‘pot’, to be mined for gold nuggets at a later date?
Storing information (as opposed to just letting stuff pile up) is a costly business and the decision to store information usually comes from people on higher pay bands. The decision of where to locate is often a manual decision which not only has a significant management overhead of its own but also involves co-ordination from other high pay bands.
THE COMPLEXITY OF INFORMATION
Add to this dilemma the complexities of ‘legal hold’ on material and the identification of ‘discoverable’ items. Suddenly information management looks a lot harder and the siren song of Big Data seems a lot more alluring. The problem is that information that is not valuable to some is valuable to others. Who is qualified to make that decision? Should all information be held given that it will likely have some enterprise value? The battle is between cost and necessity:
- Cost: Deciding what to keep and what to get rid of takes management time and effort that costs money. The problem is that it is neither cost effective nor good policy to to push hold/delete decision making down to the lowest clerical level. The secret is to have those decisions made by more senior case-workers but only within their limited remit.
- Necessity: The secret is to categorise management information to determine necessity. Use a workflow to cascade and delegate (not to avoid) work. As it moves it accumulates metadata. No metadata means no necessity and therefore it should be disposed of automatically (eschewing arguments of regulatory compliance).
The answer is to automate the deletion of information (other than ‘Legal Hold’). Once a document/question has reached the end of the workflow without accumulating any metadata then the information should be disposed of automatically. Case-Workers make the decisions to act on the document/question and metadata is attached by more clerical staff (on lower pay bands) as the item moves through the workflow. If no metadata is attached it can be assumed that the item is not important and is therefore disposed of. Cost is minimised by letting case-workers make decisions of relevance within their own sphere of expertise without the additional management overhead for de-confliction/meetings etc. In this way, the enterprise makes a collective decision of importance and stores the information accordingly thus answering the issue of necessity.
“Whilst CIOs are predominantly drawn from the infrastructure segment of ICT there is unlikely to be a shift in focus towards proactive business initiatives.”
The CIO’s commercial prerogatives largely stem from CEO directives as they tally with other recent CEO surveys from McKinsey & Co etc. It is likely, however, that need to increase services to corporate clouds through a myriad of new/personal devices during these times of severe cost pressures will keep CIOs occupied for the next year, at least.
Looking to the future, until business schools focus their corporate decision making modules on information management and technology enablers the dearth of IM savvy senior executives will continue and thereby the pull-through into the CIO role. The solution is likely to come in one of two ways, namely:
- A cost/complexity inflection point will be reached. Medium sized businesses will begin to outsource not only their IT but also their IM. As better IM begins to solve business problems some people will naturally be pulled through into corporate CIO roles at FTE.
- Alternately, clever CEOs will shift the accounting of their IT departments towards Profit Centres. CIOs will be forced to come up with innovative chargeback models and new services in order to compete beyond storage for non-essential services. The good will survive and the bad will move back to being small, in-house IT departments.