Home >

Political Agendas in Integration/SOA

A number of principles that apply whenever an Integration/SOA project abides to a political agenda as opposed to genuine business and technical benefit.

Posted on April 1, 2013 by Ernesto Garbarino

Overview

Political alignment is of the many reasons as to why departments within organisations—rather than organisations at large—pursue an integration transformation. When a political alignment need exists, the use of an economic model may not only be skipped, it may be forbidden.

A political alignment scenario encompasses a political entity and executors. The first may be as small as a single individual and as large as an entire company (for example, a vendor). The executors are those who carry out the biddings of the political entity. The business share holders are seldom members of the political entity, since political alignment scenarios are always detrimental to the health of the sponsoring organisation’s balance sheet.

Political alignment scenarios may be summarised in seven principles:

  1. The Cleopatra Principle: the political entity converts unsuspecting individuals into executors.
  2. The IBM Principle (“Nobody ever got fired for buying IBM”): the political entity demands the perceived safest choice irrespective of its business benefit.
  3. The Bernanke Principle: the political entity needs to be seen to be doing something “positive”, even though doing nothing (or very little) is the best course of action.
  4. The Gandhi Principle: the political entity needs to be seen to be abiding to the latest outsourcing trends.
  5. The Sheep Principle: some other branch within the organisation has already started an integration effort and the political entity must prove alignment irrespective of business benefit.
  6. The Booby Trap Principle: a licence for a particular integration product exists and the political entity feels that it must be exploited.
  7. The Funnel Principle: all information has to go through the political entity.

Principles

The Cleopatra Principle

Cleopatra’s charm and sexual appeal allowed her to conquer some of the ancient world’s most powerful men—Julius Caesar being the canonical example.

The Cleopatra principle applies when the political entity is represented by a similar charming character whose aim is that of obtaining political gain for the ultimate goal of reaping concrete business benefits.

This principle is only effective once a victim has fallen prey to the political entity’s charms. The victim then becomes an executor and will carry out the biddings of the political entity without objection. For example, the products pertaining to a specific vendor will be promoted without a cost–benefit analysis.

Alternatively, in the case of bribery, the victim is no longer an executor; they become a full member of the political entity.

The IBM Principle

The “Nobody ever got fired for buying IBM” principle equally applies to any sufficiently large vendor such as Oracle, SAP and TIBCO.

Under the IBM Principle, the political entity seeks safety and/or brand association. In the first case, the political entity is simply afraid of opting for a choice that—if it backfires—could damage their standing within the organisation. In the second case, the political entity seeks the experience of working with high-profile names. Such experience serves as a career-progression device both within the organisation and in future roles.

Vendors understand the IBM principle very well and their slogans are very helpful to the cause: “The best businesses run Vendor X”, “Best of breed”, “World class” and so on.

The problem is that the CFO does not work with brands; they work with numbers that may be in the red. In our experience, it takes less than 3 years for CFOs to come back with the following question:

“Dear CIO, what is this fat amount next to SOA that we have been paying for in the last three years? Please bring it down to half for the next year.”

This is not a statement favouring open source or small vendors. Most large businesses will indeed buy most of their technology and services from established vendors. The point is that the procurement choices need to follow an economic/capability-centric approach rather than a brand-driven one.

The Bernanke Principle

This principle is named after Ben Bernanke (Chairman of the U.S. Federal Reserve) who is famous for engaging in ineffective monetarist policies in the face of the 2008 financial crisis. Under this principle, the political entity wants to be seen doing something positive for the organisation; typically launching a big-bang integration programme.

The problem here is that not all of an organisation’s IT ills may be addressed from an integration perspective. Therefore, excessive resources may be squandered in the integration domain without ultimately producing visible results in the wider IT context. For example, in our experience, many organisations have severe weaknesses in aspects such as requirements gathering, release management and operations. These must be addressed first since they will be inherited by the integration programme as well.

The Gandhi Principle

The Gandhi principle applies when there is the widespread belief that outsourcing (typically, but not necessarily, to India) represents the next level in business maturity. The Gandhi principle prevails when the central theme is that the organisation should focus on its “core business” and outsource everything else.

Typical mantras heard in organisations that have fallen prey to the Gandhi principle are “We use IT but we are not an IT business”, and the apocryphal “We do not write code in this company”. We believe that organisations should be profitable; if an aspect—such as Business Integration—is not their core business, then cost and time-to-market may be aspects that probably sit outside their core business too.

The Ghandi principle is generally based on one assumption which is parroted as a self-evident truth:

All IT activities are always cheaper in India.

The political entity is often unaware of the following considerations:

India is becoming a leader in IT services in the same way that Switzerland is today a leader in the production of luxury watches. Outsourcing today is no longer a cost reduction measure based on the hypothesis of higher local costs. Outsourcing takes places as a mechanism of division of labour in which the outsourcing supplier provides domain-expertise and domain-services that are impossible to match by the customer on their own.

As we can see, the problem in regards to the Gandhi principle is not that of opting for outsourcing to India—or any other developing country. The issue is that of ignoring basic economic principles and holding onto untrue beliefs. In our experience, successful outsourcing engagements require a much greater amount of on-site coordination than what it is usually estimated. Such work adds up to the effective cost of transformation initiatives and resultant operating models.

The political entity’s failure is mainly in regards to the discrimination between the specific activities (such as Requirements Gathering) that are most cost effective and efficient on–site from those that are not.

If the political entity is rewarded for abiding to the Gandhi principle set by the executive board, irrespective of factual business advantage, then an integration transformation takes place entirely in terms of political alignment and all economic models are dismissed.

The Sheep Principle

In large organisations (especially those with branches in several countries) an integration effort could have already started in a different branch—“the shepherd”. When this is the case, the imitating branch—“the sheep”—is either explicitly told to follow the example set by the shepherd and/or the political entity’s intention is to show that the sheep will do at least as well as the shepherd.

In theory, an existing integration effort within the wider organisation should be positive because it helps understand where most of the wider organisation’s challenges lie. The issue arises when the shepherd’s business integration effort is actually poor and not worth imitating. This could be due to various reasons such as:

  1. The shepherd started out the integration programme as a pilot without the aid of experienced staff and/or consultants. As such, there may be many negative aspects that are best avoided by the sheep.
  2. The two branches share no common IT assets and business alignment is unrealistic. For example, branches in different countries may use different pricing models, product catalogues and so on.
  3. The shepherd’s programme is orientated towards political alignment rather than economic benefit.

Alternatively, the political entity may sit within the realm of the shepherd. In this case, the vested interest is to emphasise the shepherd’s leadership by forcing the sheep to replicate the same “success story”.

Political alignment under this scenario is risky if the sheep is self-funded and must prove business benefit independently. Should the sheep’s business integration programme be sponsored by the shepherd’s CFO (or a global one) then the risk of failure is at least shifted away from the sheep’s executors.

The Booby Trap Principle

The booby trap appears in the form of an Unlimited Licence Agreement (ULA), or a relatively cheap transition to a licence, that includes middleware products. The booby trap results in product entrenchment and eventual hike up of costs some years after the licences have expired. We will develop these risks further on.

If a member of the organisation inadvertently falls into this trap, then the political entity is only represented by the vendor. However, if an individual within the organisation sees in such a purchase, an opportunity to show that a massive discount has been achieved—in conflict with hypothetical inflated values—then we have a customer–vendor political alignment scenario.

For example, an offer “to pay £3,000,000 per year over an existing RDBMS licence, that permits having access to all of the vendor’s middleware products, which would have cost—supposedly—£8,000,000 on their own” is presented.

The issue is that a software licence is not “latent capital” is would be a brand new, yellow bulldozer sitting unused in the organisation’s parking lot. A software licence produces the following effects:

  1. It enables partial or total features: for example, without the licence, only one of the CPU’s cores may be active. In extreme cases, the software may not be operational at all without a licence.
  2. It prevents legal sanctions: in essence, it prevents the organisation from being sued should the organisation use the software without a licence.
  3. It provides support: in case the organisation finds problems and/or bugs.
  4. It saves labour: only in relationship to the alternative of not using the licensed software given an existing or planned activity for which no other alternatives exist.

Unless a specific software module within the licence agreement is used to reduce labour (in essence, to avoid bespoke development that would otherwise have been more expensive) for a specific activity (point 4), then points 1, 2 and 3 are immaterial. And here lies the root of the problem.

The risk of product entrenchment occurs when the Business Integration team is provided with a ULA and the use of all products is given equal weighting; since they have all been paid for and they are perceived as “free”.

Whenever a new requirement crops up in the Business Integration team, the first port of call will be one of the modules within the ULA. Overtime, services that could have been implemented in a much simpler fashion in the absence of a ULA turn out to require a plethora of discrete platforms: business rules engines, event processing engines, multiple BPM engines and so on.

Once the ULA deal is over and the products are entrenched, the vendor can ask any arbitrary figure for the discrete modules or for the renewal of the ULA itself.

Not all ULAs are bad; only mismanaged ULA negotiations become actual booby traps. If the political alignment factor is too strong to be opposed, then these are a few general strategies to minimise the impact of a ULA:

  1. Full depreciation assumption: The ROI must be rendered before the ULA expires and the default assumption should be that all the CAPEX invested in bespoke artefacts, namely services, on top of the ULA’s provided modules, will depreciate to zero.
  2. Long term fee locking: The ULA’s fees are locked for a long period—seven years or more—including reasonable inflation modifiers in the currency in which the purchasing organisation operates. Make sure that early End-of-Life (EOF) aspects are taken care of in the contract and that such aspects are linked to formal version numbers.
  3. Economically rational ULA Usage: In this case, all the required modules are identified in advance and the Business Integration team is forbidden from using any other additional modules. An inquiry should show pricing data from multiple sources that confirm that the identified modules come cheaper as part of a ULA than as separate acquisitions.

The Funnel Principle

Unlike other principles, the presence of the funnel principle makes it difficult to tell the real circumstances, since the political entity’s aim is to conceal information and only disclose points that are in line with their agenda—most likely one of the principles 1—6.

Symptoms:

Oddly enough, the funnel principle applies when the political entity is actually weak in the art of politics and insecurity is their dominant aspect.


  1. India struggles to cap wage inflation http://www.ft.com/intl/cms/s/0/37b742de-7cb4-11e0-994d-00144feabdc0.html#axzz2fji5FBPr