The Enterprise Architect of Hamelyn

Stakeholder Concern	Enterprise Focus	Project Focus
The city of Hamelyn is plagued with rats.	This indicates a serious problem with the “Public Health and Hygiene” capability.	We just need a quick project to eliminate the rats. So we buy some “Eliminate Creature” capability from an external vendor.
The Pied Piper gets rid of the rats.	Real business problem has not been addressed. Let’s now push on with the next phase of solving the problem.	Project successful.
The Pied Piper is too expensive.	We need a careful transition plan while we build an in-house capability.	Let us immediately renegotiate our contract with the vendor.
The Pied Piper gets rid of the children.	It turns out that the Pied Piper can reuse his “Eliminate Creature” capability for other purposes.	!*!?**!
Which Role?	Enterprise Architect? Strategic Procurement?	Solution Architect? Tactical Procurement?

See also my article “Requirements Engineering as if Stakeholders Mattered” (Requirenautics Quarterly, Issue 29, August 2003, pdf)

Architecture-Led Procurement

#entarch #procurement #acquisition Here are my slides from the EA Forum on Thursday.

I am planning to run some workshops on the subject for Unicom in the UK, with a pilot provisionally scheduled for June 2012. I've very keen to talk to anyone who has practical experience or strong opinions in this area, and I should also be grateful for references to case studies and other material.

Architecture led procurement

View more presentations from Richard Veryard

A Twin-Track Approach to Government IT

#ukgovit @instituteforgov has just published a report called System Error: Fixing the Flaws in Government IT.

The report recommends a twin-track approach to government IT, based on the two concepts of Agile and Platform.

"The platform must standardise and simplify core elements of government IT. For any elements of IT outside the platform, new opportunities should be explored using agile principles. These twin approaches should be mutually reinforcing: the platform frees up resource to focus on new opportunities while successful agile innovations are rapidly scaled up when incorporated into the platform."

The report acknowledges the tension between these two concepts ...

"Treating items as commodities reduces cost but can limit flexibility; coordinating elements of IT across departments frees up resources but may move them further from frontline users; common standards support interoperability but also restrict the freedoms to innovate."

... and offers some general ideas for managing this tension.

• To act fully in the interests of government, an agile approach requires a light touch form of coordination at a system level. 

• To minimise duplication of effort in solving the same problems, there needs to be system-wide transparency of agile initiatives. 

• Existing elements of the platform also need periodic challenge. ... Transparency, publishing feedback and the results of experiments openly, will help to keep the pressure on the platform for continual improvement as well as short-term cost savings.

Trouble is, some of this stuff is really hard. The report talks glibly about "a less than intelligent customer", referring first to business users having an inadequate conception of the possible, and then to the public sector as a whole lacking the collective knowledge and skills to negotiate effectively with suppliers. This lack of intelligence is apparently blamed on the V-model development process, which creates the impression that the adoption of Agile methods would solve this problem. But the idea of Agile as a silver bullet is a dangerous one, as many people have already pointed out on the Linked-In discussion group.

One way of understanding the twin track approach is to think of the different kinds of economics involved.

• 'Platform' means delivering economies of scale and economics of scope.
• 'Agile' means delivering economies of alignment.

Combining the two introduces some complex architectural challenges, as I've written about here and elsewhere before. We call this Asymmetric Design. For an example of this approach applied to public sector IT, see an analysis of the CSA Case by Philip Boxer and myself. See also The Impact of Governance Approaches on SoS Environments (pdf) by Philip Boxer and others.


In the current economic situation, the public sector as a whole is charged with making massive cost savings, and it is crazy to imagine that cost savings of this scale would not be associated with significant structural change, including IT systems. This kind of disruptive innovation goes way beyond the economies of scale and scope, and introduces some serious questions about the economics of alignment.

The word "architecture" is mentioned a few times in the Institute for Government report, but only in passing as something that the Government CIO will look after. (Mostly technology or solution architecture, I only found one single reference to business architecture.) So there is an implicit idea of central thinking and hierarchical governance. But there are some architectural challenges here that are some way beyond the current practices of enterprise architecture.

Governance is also a significant problem. The report comments on the pendulum swings between centralized and decentralized provision, which is something we noted in the CSA case, and was also present in the case of ContactPoint (which we were in the middle of writing up when it was cancelled). Such pendulum swings are often a characteristic symptom of weak or unsustained governance.

Not only is this stuff structurally complicated, but there are some commercial stakeholders that have every incentive to maintain the complicated status quo, thanks to a grossly dysfunctional procurement process.

And there is an even bigger problem with the report, which is that it looks at government IT exclusively from within government - in other words, from the perspective of civil servants. For example, the report adopts a supply-side notion of "joined-up government", understood largely in terms of internal linkages and efficiencies between systems, and fails to mention the demand-side notion of "joined-up government" that involves a coherent experience for the citizen. (See my post on Joined-Up Government from December 2005.)

Meanwhile the notion of "user" appears to refer mainly to civil servants and other public sector workers. Surely the purpose of government IT is not to provide direct value to civil servants but to provide various forms of indirect value to individual citizens and socioeconomic communities.

The report regrets that "government IT [is] falling further and further behind the fast-paced and exciting technological environment that citizens interact with daily" and indicates "the potential for IT ... fundamentally changing the relationship between citizen and state". "Around the world governments are using technology to help them deliver better services, be more transparent and accountable, and connect more directly with their citizens." (Examples are cited from Canada, USA and Malaysia.)

And yet the report fails to explain how "agile" can adequately represent the demand side requirements of citizens, interacting with a broad range of government services while going about their public business. There is a completely different notion of "platform" required here - government as a platform, which Tim O'Reilly and others have been talking about for a couple of years. And a different notion of agility, which goes a lot further than agile software development.

---

Other commentary

See Linked-In discussion group

Harry Metcalfe (2 March 2011) observed that many of the recommendations in the report were really hard, and was one of the first to complain about the insufficient attention to procurement in the report.

Zero-Based Requirements

Brown-Field Requirements

One view of requirements engineering is that its purpose is to produce a complete and coherent statement of what some system-of-systems is required to do - in other words, its behaviour in the broadest sense, including "functional", "non-functional" and "commercial" requirements.

In a "Green-Field" scenario, we might imagine that this statement of requirements would result in the procurement and installation of a system of systems meeting the stated requirement. Requirements engineering is focused on understanding exactly what is required, and specifying it in an unambiguous and testable form.

But in almost all engineering projects, some system of systems - technical or sociotechnical - already exists, and the practical purpose is to make some planned changes to it. So people in the RE community are starting to talk more about "Brown-Field" requirements.

(RESG Event: Managing Brownfield Project Requirements, London, October 12th 2010)

Gap Analysis

An obvious starting point for brownfield requirements analysis would seem to be the identification of a gap between desire and reality. People often produce two models - an AS-IS model that describes the existing system, and a TO-BE model that describes its future replacement. The engineering requirements are then derived from the differences between the AS-IS model and the TO-BE model. This will typically result in a solution, possibly involving rebuilding some of the subsystems, replacing or upgrading some of the component parts, adding some new stuff or stripping out old stuff, rewiring the network, retraining the people, resetting system policies and parameters, and so on. In addition to a solution blueprint, showing how all these elements are to be configured, there will also be a transition strategy, indicating how (and in what sequence) all these changes will be installed. There are usually operational constraints - for example, a requirement to keep critical business processes running at an acceptable level during the transition period.

Imagine you want to rebuild your kitchen. You have to think about fitting new units into the existing space, or possibly moving a wall to give yourself more space. You have to decide whether you are going to keep the existing fridge (which you only bought last year) or buy a new one. And you have to think about how long you can manage without being able to cook. Moving the wall, or deciding to keep the old fridge, belong to the solution domain. But if you are going to do requirements analysis properly, there needs to be something in the statement of requirements that helps you determine these aspects of the solution.

In all but the smallest and most simple projects, there will be many solution variants. The decision to retain or replace a particular component may be based on a technical calculation of its likely performance and capacity within the new configuration, or may be based on a political calculation as to the most convenient budget from which to fund the replacement (in other words, preferably someone else's budget, if we can get away with not replacing it now).

Ten years ago this month, I wrote a piece about this in relation to Component-Based Software Engineering. Supply and Fit (CBDI Journal, September 2000).

But there is a more fundamental reason why there are many possible solutions - because making sustainable changes to complex systems is a tough challenge. Large and complicated change programmes aren't always the most effective; a small intelligent fix is often far better (and less risky) than any amount of optimistic meddle.

So before we can get to a solution blueprint and a transition strategy, we need an intervention strategy. This takes us out of the comfort zone of requirements engineering into general systems thinking.

Leverage Points

Donella Meadows identified twelve leverage points for making changes in complex systems, and suggested that these could be ranked according to their power. See original paper by Donella Meadows. A version is included in her posthumously published book Thinking in Systems (2008).


If the intervention strategy can be expressed as a combination of leverage points, then this raises the question for requirements engineering - how do we work through the requirements of changing a complex adaptive system in a way that could produce this kind of intervention strategy?

Zero Based Procurement

Finally, I wanted to make a comment about one of the (many) dysfunctional aspects of prevailing procurement practices. In his blogpost Was this NHS IT tender a stitch-up? (Computer World, September 2010), Tony Collins talks about the difficulties of referencing a specific product or system in a tender document. "If a user organisation has a system it’s happy with, and wants to keep and enhance, why would it want to go through the needless expense of an EC tendering, rather than simply renew the contract?"

Procurement rules may have been designed to prevent cosy and uncompetitive relationships between public sector organizations and their suppliers. They appear to have the effect of forcing each procurement to be treated as a separate exercise, starting each time from a blank sheet of paper, so that there is at least the theoretical possibility of giving new suppliers a chance. (This is similar to the principle of Zero-Based Budgeting.) Many people doubt that these mechanisms actually have any real effect on competition or value-for-money; but meanwhile, these mechanisms appear to have a strongly negative impact on through-life capability management. How can brownfield requirements engineering be done properly under these constraints?

Asymmetric Demand for Defence Equipment

An independent review into the way the MOD buys equipment for Britain's Armed Forces has been published today, Thursday 15 October 2009. [Report, MoD News Article, BBC News]. Key finding.

"The Ministry of Defence has a substantially overheated equipment programme, with too many types of equipment being ordered for too large a range of tasks at too high a specification. This programme is unaffordable on any likely projection of future budgets."

That situation might sound familiar to a lot of managers, not just in the defence sector.

The report makes some favourable comments about the Through Life Capability Management (TLCM) programme, but indicates a lack of hard financial data that would be required to make quantitative decisions. There has been some discussion along these lines published in the RUSI Journal, including Agility and Innovation in Acquistion (Feb 2008) and The Meaning of Value-for-Money (Feb 2009).

The explanation for the current crisis can be found in the essential multi-sidedness of the defence acquisition ecosystem. Traditional cost accounting approaches (such as activity-based costing) fail to address the complexity of this multi-sidedness, and researchers are urgently seeking alternative cost accounting methods appropriate for complex systems-of-systems.

One of the key issues for Through Life Capability Management is that any errors or omissions in the long-term equipment programme must be repaired through what are known as Urgent Operational Requirements (UOR), which over the long haul can prove far more expensive and inflexible than the planned equipment.

The report also praises the Smart Acquisition programme, and expresses regret that the disciplines of Smart Acquisition have been somewhat diluted by recent reorganization.

---

Is this report only relevant to the defence sector, or can other sectors glean anything useful? My view is that the complexities of multi-sided markets and asymmetric demand can be found in many, perhaps most sectors. And the question of coordinating effectively between short-term and longer-term spending can be found in many domains, notably IT. I have little doubt that whatever management tools and techniques are developed by the MoD and its partners to address this problem will eventually trickle into civilian management.

Economics of agility 2

In my previous post on the Economics of Agility, I noted how little material has been published on this topic.

As Nicholas Whittall and Philip Boxer point out in their contribution to the recent debate on The Meaning of Value-for-Money in Defence Acquisition (RUSI, February 2009), there is an important link between agility and alignment. See also their earlier piece on Agility and Innovation in Acquisition (RUSI, February 2008).

The first observation is that defence acquisition - just like systems acquisition most anywhere - operates on a much slower tempo than the requirements of the business. The "business" of a military organization is running military campaigns; thus when writing for the defence community, Whittall and Boxer refer to the Campaign Tempo and the Acquisition Tempo.

The second observation is that there is a complex set of activities (such as orchestration, customization, and improvisation) involved in bridging between Demand (the demands of the campaign or business) and Supply (the procurement of specific systems and devices). These activities operate on an intermediate tempo, which Whittall and Boxer call the Alignment Tempo.

"Meeting the campaign tempo then depends on the alignment tempo possible, which in turn depends on the acquisition tempo at which gaps can be filled. Any slowness in acquisition tempo leads to increased bricolage and process short cuts to enable the alignment tempo to keep up with the campaign tempo. Thus, ‘agility’ finds its richest expression in the ability of the alignment tempo to meet the required campaign tempo at the lowest cost – i.e. to maximise the value-for-defence."

The challenge is then to produce just enough variety within the acquisition to optimize the economics of alignment. Boxer has developed a technique of Cohesion-Based Costing (not yet published), which "offers a means to attach a value to the cost of introducing flexibility". This kind of technique will clearly be of enormous benefit within the SOA world.

 

Related post Enterprise Tempo (October 2010)

Credit Crunch SOA - Outsourcing

One of a series of posts exploring how the current economic conditions are affecting the SOA world. What are the implications for organizations and individuals?

---

Outsourcing

At the level of the individual deal/firm, there are clearly going to be some casualties. Obviously the organizations that are in meltdown, or whose funds are currently frozen in some Icelandic bank account, are not going to be spending money they haven't got and can't borrow. And some emergency take-overs in the banking sector are going to reduce the number of banking systems that need to be built and maintained.

But overall, the situation for the outsourcing might not look too bad. Business-as-usual requires systems-as-usual. Indeed, some people in the outsourcing world (for example Phil Morris of EquaTerra via ZDNet) are arguing that outsourcing is countercyclic - in other words, it goes up when the economy as a whole goes down - because it is cheaper and lower-risk than employing people yourself. (I don't remember anyone saying outsourcing was counter-cyclic when the economy was going up, but I must have missed it.)

But what kind of outsourcing is it going to be? Following Archilochus (via Isaiah Berlin and Jim Collins) we can identify two styles of outsourcing: the Fox makes lots of small outsourcing deals and the Hedgehog makes one big outsourcing deal.

Som Sarma of Satyam Computer Services is on the side of the Hedgehogs when he writes "As organisations are driven to focus on IT cost having a single supplier can minimise management, due diligence and supplier selection expenses." [ComputerWorldUK, 2 October 2008] He repeats (in almost identical words) a point made by Martyn Hart back in January who, while acknowledging that the past couple of years has seen a swing away from 'mega deal' towards multi-shoring and choosing separate suppliers for each process, predicted a swing back to the single supplier, arguing that this would provide better cost management. [ComputerWorldUK, 22 January 2008]

However, Som Sarma's colleague Deepak Kataria, speaking at the New Services Environment Summit in Dallas TX (February 2008), warned against over dependency on single vendor. He recommends defining and implementing a conceptual abstract framework for mapping the technology roadmap to multiple vendor platforms and future versions [see Deepak's presentation on SOA Transformation (ppt)].

I'm with Deepak on this point. If you have a first-class architecture (and I admit that is a big IF) you can get the best of both worlds - better governance and risk management, as well as better cost management. With SOA, organizations can choose to manage outsourcing at a finer level of granularity, in order to squeeze extra value from the network, as well as keeping closer control over their suppliers. As organizations develop more sophisticated service management capability, they can move from being a simple hedgehog (hand everything over to XYZ Global Services and hope for the best) to being a clever fox.

One data point here - reported anxiety at General Motors over the merger between HP and EDS, which means GM is now spending a third of its massive technology budget with a single supplier. [HP-EDS Combo makes General Motors uncomfortable].

Meanwhile, both Som and Martyn identify another critical benefit from outsourcing - a shift towards Pay-As-You-Go models. See my previous post on Service-Oriented CashFlow.

Enhanced Services

One of the governance mechanisms described in recent paper on the Acquisition of Information Services and SOA Systems by the SOA Acquisition Working Group (described in my earlier post on Defense Procurement) is a so-called Enhanced Services Model, which aims to improve responsiveness.

'In the current model contractor’s incentives are to provide the minimal solution that meets the requirements. As the requirements grow and change, Engineering Change Proposals (ECPs) are required, resulting in real or perceived “scope creep”, and always in cost growth. This results in delays in deployment and fielded capability.

Under the enhanced services model, the contractor will be able to exceed the requirements by providing expanded or additional services. These could be “sold” to other users as a common reusable service that others do not have to develop. The additional services could also provide the basis for further development as the system matures.'

The paper signals an intention of the DoD to apply the concept of Enhanced Services in the defence domain. However, at present much of the discussion about enhanced services around the internet is not in the defence domain but in the healthcare domain. (Even if you search for DoD Enhanced Services you just seem to get stuff about healthcare for soldiers and veterans.)

In healthcare, the enhanced services model is used to allow and encourage service providers (e.g. healthcare system suppliers) to offer additional functionality, while allowing service consumers (e.g. clinics) to use these enhanced services in enhanced or specialized processes. In a complex ecosystem, this model allows scope for innovation and improvement.

The challenge with this approach is that it is not always possible to anticipate the value of enhancements. It also potentially increases the complexity of governance. However, there seems to be a strong opportunity to use the enhanced service model to provide added-value in complex situations where the service environment is not centrally controlled.

Defense Procurement

Let me start with a couple of quotes from a speech by US Secretary of Defense Robert M. Gates, Washington, D.C., Monday, September 29, 2008.

"When it comes to procurement, for the better part of five decades, the trend has gone towards lower numbers as technology gains made each system more capable. In recent years these platforms have grown ever more baroque, ever more costly, are taking longer to build, and are being fielded in ever dwindling quantities."

"The issue then becomes how we build this kind of innovative thinking and flexibility into our rigid procurement processes here at home. The key is to make sure that the strategy and risk assessment drives the procurement, rather than the other way around."

The US Department of Defense appears to have a very clear understanding of the opportunities for Service-Oriented Architecture in enhancing the procurement process and improving the economics of governance. In July 2008, the SOA Acquisition Working Group of the AFEI produced a useful set of Industry Recommendations for DoD Acquisition of Information Services and SOA Systems.

One point that comes across very clearly from this paper is the opportunity to separate the provision of different layers within a layered architecture. So we may have one set of suppliers providing the underlying layers, and a different set of suppliers providing the upper layers.

The AFEI paper identifies three roles - Platform Providers and Commodity Infrastructure, Component Developers and Enterprise Managers - with what it calls Firewalls between them. (See Figure 3 in the AFEI paper.) These firewalls roughly correspond to the first two of what Philip Boxer calls the three asymmetries of demand. The third asymmetry (not explicitly shown in the AFEI paper) is between the Enterprise Managers and the Customers. (Including customers in the schema is essential if you want to move towards a risk-reward model of procurement, as the DoD evidently does, because it is the customers who ultimately generate the effects.)

Managing all this complexity almost certainly results in higher management cost than if you simply outsource the whole lot to a large system integrator, but it also shifts the management control (architectural governance) back to the acquiring organization.

So which kind of organizations would want to do this then? It's a question of complexity - the greater the level of complexity and volatility in your requirements, the greater the potential benefits from having finer-grained and stratified control over your procurement.

And what kind of organizations are capable of this fine-grained stratified control? Perhaps not too many at the moment, which is why we need a capability maturity model for SOA that provides a roadmap for organizations to develop an appropriate level of SOA capability.

Sources

AFEI SOA Acquisition Working Group, "Industry Recommendations for DoD Acquisition of Information Services and SOA Systems", July 2008 (register on the AFEI website for free download)

For explanation of the three asymmetries, see Richard Veryard & Philip Boxer, Metropolis and SOA Governance, Microsoft Architecture Journal, July 2005.

Business Case for SOA 3

ZDnet blogger Joe McKendrick has uncovered an interesting difference of opinion between stakeholders in the US Government and Defense space about the viability of SOA, as described in the following posts:

• Defense doesn't rest with SOA (Nov 10)
• Study: the public sector ‘gets’ SOA, or at least ’shared services’ (Nov 15)

The US Defense Information Systems Agency (DISA) seems pretty committed to SOA. The problem apparently lies with some large US contractors, who seem to think that this threatens a profitable line of business selling software to the Department of Defense. David Bryan, a retired general who is now a vice-president at Northrop Grumman Defense Group, says that "Industry is struggling to determine a sound business case for the SOA approach". [source: FCW.com, Nov 8]

There are four things I want to say in response to this, which relate to the business case for SOA.

1. The Department of Defense evidently appreciates the potential of strategic-level or Enterprise SOA to reduce their IT costs and to improve the efficiencies and flexibility of their business. And if SOA enables the Department of Defense to get better value-for-money from its contractors, then this strengthens the business case for SOA within the Department of Defense. (DISA is clearly doing something right.)

2. If the Department of Defense insists on the SOA approach, then this will create a very strong business case for SOA within the ecosystem of defense contractors. (If you don't want the work, there's plenty others that do.)

3. SOA is not just a technological initiative, but carries significant changes to organization and governance, including procurement arrangements. Enterprise SOA is, in part, about commodity services - buying pre-existent capability - and minimizing the custom development.

4. There is a learning curve for defense contractors. To be successful in the enterprise SOA market, traditional integrators will have to change their business models from being dependent on big custom software development projects. But some are still loading their bids with software costs, according to DISA Procurement Director Evelyn Palma. IBM has already won a major supply contract under the new regime, and we might expect future contracts to go to the most SOA-literate contractors.

Open Sauce 2

Following my earlier post on Open Sauce, Sandy Kemsley points out the link between SaaS and shared services:

"your older brother owns all the bottles of hot sauce, and your mom makes you buy from him rather than the kid in the next block ... if you don't like his taste and choose not to have hot sauce, then he still justifies his existence because he's still the household standard"

So why does your mom grant a monopoly to your brother?

• Because it improves your brother's supply-side economics. (He needs a critical mass of customers to be economically viable. She doesn't think he is ready for the harsh realities of the open market.)
  

• Because it improves your own demand-side transaction costs. (Your mom doesn't want you traipsing around the neighbourhood trying out alternative sauces when you should be getting on with your homework. Your mom thinks - argue with her if you dare - that homework is a core activity whereas sauce-procurement is non-core.)

• Because it reduces the overall complexity of the household, reduces risk and increases accountability. (If you get sick, she knows exactly who to blame.)

All these arguments can be used to justify standard shared services in an enterprise. But they always have to be balanced against the loss of opportunity and choice.

• Who gets to choose the flavour of sauce? Does the casting vote always go to the loudest or most awkward member of the family?

• Do some members of the family go without sauce altogether, rather than use the majority choice?

• Does trading sauce with the neighbours have any positive side-effects - for example relationship-building (trust) or learning new recipes (innovation)?

• And shouldn't your brother be getting on with his homework as well, instead of wasting his time on a venture that is only viable with Mom's intervention?
  

Sandy spells out some of the enterprise implications of this in a comment to James Governor's post on Shared Services and SOA. One of her main concerns is captivity versus choice - a factor where external services seem to have the advantage over internal services. I think this is generally correct. However, as I argued in my post on Service Competition, external services aren't always going to give you a decent choice either.

Supplier Abuse

Bill Waddell is very critical of the way Ford manages its supply chain, and praises Microsoft in comparison.

• Henry And Harvey Would Be Ashamed
• Henry and Harvey Would Like Microsoft

That's Henry Ford and Harvey Firestone, founders of the auto and tyre companies respectively. Two generations later, the Ford and Firestone families were joined in marriage, so Bill Ford is descended from both Henry and Harvey. Despite this, the partnership between the two companies has been very troubled, with especially bitter and public recriminations over the SUV disaster, which (if I've got the dates right) took place while Bill Ford was Chairman.

Bill Waddell writes

The fundamental problem with Detroit style purchasing - and Detroit hardly has a monopoly on it - is that each side thinks they are clever enough to avoid the fundamental economic principle of risk and return.

The net result of that supply chain was that all players - customers, us and our suppliers - viewed each other as the enemy - the competition. We devoted enormous time and mental energy at trying to skim a few cents from each other. We spent a lot of time looking for other suppliers and other customers. Nobody in the chain saw it as a cooperative effort to satisfy the end customer, with each of us entitled to reap a reward commensurate with our investment and risk in the supply chain. We took the end customers for granted, and saw getting the upper hand on each other as the key to becoming more profitable.

Bill Waddell contrasts this with the Microsoft's refusal to blame any of its suppliers for difficulties with the XBox 360.

That, to me, shows a level of class the execs in Detroit cannot imagine. And I think it has a lot to do with why Microsoft makes money, and Ford and Firestone do not.

I suspect some people within the software industry will dispute this analysis. And it's probably not fair to judge a company from a single incident, whether positive or negative. But if you are working on supply chain partnerships - or business partnerships in general - Waddell's analysis is worth reading.

Technorati Tags: SOA service-oriented supply-chain

Knowledge Coupling

According to reports in the Financial Times, the Inland Revenue wishes to find a new IT contractor. Government IT outsourcing has been dominated by a small number of firms, particularly EDS and Accenture.

Apparently, some major service companies (including, it is rumoured, IBM Global Services) do not consider it worth submitting bids against the incumbant. Bidding costs can run into tens of millions, with very low chances of success.

Principle One: If you want to maintain the right to choose, you have to exercise your choice from time to time – otherwise, the choice becomes void.

Principle Two: If contractors have exclusive (or privileged) access to complex knowledge required both to maintain the service, and to participate meaningfully in the bidding process, then the choice may become economically non-viable.