Enterprise Architecture: Is there any such thing? 3

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.

Global Outsourcing Market

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.

CIOs as Storytellers? Reply

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.

Picture1

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.

Benefits-Led Contracting: no immediate future for outcome based agreements Reply

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.

Picture1

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.

 

 

INFOGRAPHICS: the worst form of risk management Reply

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. 

Competitive Advantage in IT 1

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.

Cloud research exposes gaps between CIOs and the business. . .again Reply

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?

  1. 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.
  2. 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.
  3. 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.
  4. 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 Reply

Sometimes the best defense is deletion – CSO Online – Security and Risk.

data mining. big dataThe 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

Picture1

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:

  1. 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.
  2. 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

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.

Will CIOs Really Focus on the Business in 2013? Reply

“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:

  1. 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.
  2. 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.

 

EA as Strategic Planning: I’m Still Not Convinced Reply

Business and TechnologyA recent blog entitled: “EA is Strategic Planning” highlights a sentiment by many enterprise architects (a widely abused moniker) that what they are doing is new, ingenious and necessary.  I’m still not convinced.  Whilst one cannot decry the skills, expertise, knowledge and ability of many enterprise architects I am yet to see a cogent argument that what they do is either cost effective or necessary.

Heresy?  Hardly.

The enterprise has done remarkably well since the Dutch East India Company was granted its royal license in 1600.  The rise of the  enterprise has not abated and diversified companies such as Du Pont and ITT have shown that complexity and size are no obstacle to good, valuable shareholder growth. 

IS EA JUST GOOD IT?

I am in two minds:  (i) EA has certainly helped the IT community with complexity by bringing a portfolio view ICT programs, but(ii) EA has added no significant value to a listed company (beyond just good sense, well delivered IT programs) or reduced its risk to such an extent that would warrant dedicated EA. 

EA has likely been the product of a traditional lack of the requisite skills to translate the social value of collaborative software into corporate monetary value.  It is worth noting that embedded systems (such as robotics) and operational systems (systems that a given corporation simply cannot perform its operations without) are not included in this assessment as their value to the business can be calculated in a simple NPV assessment of projects, i.e. the system will directly result in higher discounted cash flows.  That this should be the job of a programmer is nonsense.  That large commercial enterprises are only beginning to adopt social media systems (which people have been using for years) highlights the general inability of enterprises to grasp the financial value of subtle and complex ICT.

SO WHAT DOES EA OFFER?

Enterprise architecture is not strategic planning.  As much as I like David Robertson’s book “Enterprise Architecture as Strategy”, it is farcical to suggest that the structure of an organisation should either come first or drive (other than the broad parameters)  the functional design of the business model.  If EA is to deliver value to the organisation then it must reach beyond large, complex IT.  To add real value it must be the the function which is capable of reaching across the business siloes to solve the problems which the corporation does not even yet know it has.

ENTERPRISE ARCHITECTURE AS A SEPARATE DISCIPLINE

Enterprise architecture must grow out of its humble ICT beginnings if it is to have the boardroom caché and intellectual gravitas necessary to drive strategy.  EA must develop beyond it systems engineering fundamentals and extend its validity into the statistical relationships between technology structures, information performance and shareholder return.  Only in this way will EA be able to communicate the financial return which subtle and complex MIS systems can add to a company.  Whatever enterprise architects believe they can do they will not get the opportunity to display their value, beyond simple tenders, unless they can convince the finance function.

The Efficiency vs. Effectiveness – customer focus is the key | LinkedIn Reply

The Efficiency vs. Effectiveness Debate Continues | LinkedIn.

efficiency versus effectiveness. targetEfficiency is a key enabler of effectiveness.  Effectiveness goes towards value whereas efficiency goes towards cost.  Ask the question:  “if the enterprise was less efficient would it still be effective?’  The answer will give you an idea of just how important effectiveness is to the enterprise (i.e. government or corporate).

Efficiency is more critical depending on how far removed the task/issue is from the customer.  The customer does not care one jot how efficient your processes are.  The customer has not the slightest concern whether your systems are efficient.  Whether a corporate customer or recipient of government services, they want effectiveness.  Whether they will pay a premium for that will determine the price.

For back-office functions, however, efficiency is critical.  In the treasury-2-cash process the result should always be the same.  In procure-2-pay the result should always be the same.  Effectiveness is not an issue:  it must be effective and therefore efficiency is critical.

In a recent project with the good folk at Glentworth the team looked at Disaster Management and concluded that the key failing of disaster management was not the efficiency of the Emergency Services but rather the effectiveness of the function across the entire value chain.  Efficiency was the critical attribute of emergency response but that effectiveness was the missing ingredient in the current approach to Disaster Management.  In the 2010 floods in Queensland, the Interim Report by the Floods Commission Inquiry made (inadvertently) a good distinction between effectiveness and efficiency.  To paraphrase the Commission, they noted:

‘. . . of the 37 people who died, 22 of them would still be dead even if the Emergency Services had been as efficient as possible.’

VALUE CHAIN ANALYSIS

Efficiency is critical but as the above quote demonstrates it must work in tandem to deliver what Peter Drucker noted was the real purpose – Value.  Efficiency should be pursued where business units can be structured as modular units and deliver repeatable processes which are removed from the customer.  In customer facing activity it is vital, however, to ensure that effectiveness is the key.

ORGANISE INFORMATION FUNCTIONALLY NOT STRUCTURALLY

In order to achieve this businesses and government services need to manage activities right across their Value Chains (and possibly across their extended value nets as well).  Much like Disaster Management, it is good for businesses to achieve operational efficiency but fairly pointless if the product or service is ineffectively delivered or ineffective in the hands of the customer.   The structure of government highlights this point.  Government departments, like most businesses, act structurally not functionally.  Teams and departments are forced into ineffective outcomes through rigid structures which enforce inefficient workflows.

In days of yore this has not mattered but with the ubiquity of smart devices and with easier access to a more competitive array of services the need for a greater focus on effectiveness is becoming more apparent.  Recent articles on the move to a customer-centric focus highlights this.  In order to achieve the best possible blend of effectiveness and efficiency governments and businesses need to manage customer interactions functionally to achieve the best possible outcomes.  Both types of enterprise should structure their delivery business units modularly and manage workflows using experienced caseworkers.  This does not mean that work should be managed on a costly case-by-case basis but rather by exception.  

There should be no debate between effectiveness and efficiency.  Both are critical but to paraphrase Drucker it is only with the right blend that enterprises can achieve value.