Globally Integrated Enterprise

IBM boss Sam Palmisano has written an article for the Financial Times saying that "Multinationals have been superseded". [news report, article (subscribers only)] and portraying "the emerging business model of the 21st century".

Firstly, he restates the vision of the component-based business. (See my post on Project Catalyst from November 2003.)

"Because new technology and business models are allowing companies to treat their functions and operations as component pieces, companies can pull those pieces apart and put them back together in new combinations, based on judgements about which operations the company wants to excel at and which are best suited to its partners."

And includes a plea for new models of trust.

"We need new ways of establishing trust based on shared values that cross borders and formal organizations."

Palmisano doesn't explicitly mention IBM's recent announcement of increased investment in India, but his denial that the new business model merely involves exploiting cheap labour will undoubtedly be linked to this deal.

"These decisions are not merely a matter of off-loading non-core activities, nor are they merely labour arbitrage - that is shifting work to low-wage regions. ... The consideration driving most business decisions will be securing a supply of high-value skills."

James Martin said something similar in his BBC radio interview last week, which I reported elsewhere.

"Sometimes the reinvention is going to work best in countries which are not rich countries today. So India for example is creating software which is measurably better than in the United States or Britain. ...

[Describing a company he was involved in] ... In the beginning we thought it was just better programmers, but then it turned out that the Indian CEO was better than the American CEO, so the finance people replaced the American CEO with the Indian CEO."

My interpretation of this model is that it leads a power-to-the-edge strategy. You don't reserve the high-skill jobs (such as R&D and product design) to the centre, or to the home country.

"The globally integrated enterprise ... fashions its strategy, management and operations to integrate production - and deliver value to clients - worldwide."

For further commentary, see Colin Barker at ZDnet.

Technorati Tags: IBM power-to-the-edge service-oriented

Data Provenance

In my previous post on Information Sharing, I discussed some of the problems of information sharing in a loosely-coupled world, with special reference to the security services. There is further discussion of the social and political aspects of this at IntoTheMachine and TrustBlog. In this blog, I am continuing to focus on the information management aspects.

On Friday, I had a briefing about an EU research project on data provenance, led by IBM. This project is currently focused on the creation and storage of provenance data (in other words data that describe the provenance of other data - what we used to call an audit trail). The initial problem they are addressing is the fact that provenance data (audit trails and logs) are all over the place - incomplete and application-specific - and this makes it extremely hard to trace provenance across complex enterprise systems. The proposed solution is the integration of provenance data from heterogeneous sources to create one or more provenance stores. These provenance stores may then be made available for interrogation and analysis in a federated network or grid, subject to important questions of trust and security.

In art history, provenance means being able to trace a continuous history of a painting back to the original artist - for example proving the version of the Mona Lisa currently in the Louvre is the authentic work of Leonardo da Vinci. As it happens, we don't have a completely watertight provenance for the Mona Lisa, as it was stolen by an Italian artist in 1911, and remained absent from the Louvre until 1913. Most art lovers assume that the painting that was returned to the Louvre is genuine, but there is a gap in the audit trail in which an excellent forgery might possibly have been committed. [See The Day The Mona Lisa was Stolen. I learned about this story from Darien Leader's book Stealing the Mona Lisa.] Provenance may also involve an audit trail of other events in the painting's history, such as details of any restoration or repair.

In information systems, provenance can be understood as a form of instrumentation of the business process - instrumentation and context that allows the source and reliability of information to be validated and verified. (Quality wonks will know that there is a subtle distinction between validation and verification: both are potentially important for data provenance; and I may come back to this point at a later date.) Context data are used for many purposes besides provenance, and so provenance may involve a repurposing of instrumentation (data collection) that is already carried out for some other purpose, such as business activity monitoring (BAM). Interrogation of provenance is at the level of the business process, and IBM is talking about possible future standards for provenance-aware business processes.

Provenance-awareness is an important enabler for compliance to various regulations and practices, including Basle2, Sarbanes-Oxley, and HIPPA. If a person or organization is to be held accountable for something, then this typically includes being accountable for the source and reliability of relevant information. Thus provenance must be seen as an aspect of governance.

Provenance is also an important issue in complex B2B environments, where organizations are collaborating under imperfect trust. From a service-oriented point of view, I think what is most interesting about data provenance is not the collection and storage of provenance data, but the interrogation and use. This means we don't just want provenance-aware business processes (supported by provenance-aware application systems) but also provenance-aware objects and services. Some objects (especially documents, but possibly also physical objects with suitable RFID encoding) may contain and deliver their own provenance data, in some untamperable form. Web services may carry some security coding that allows the consumer to trust the declared provenance of the service and its data content. There are some important questions about composition and decomposition - how do we reason architecturally about the relationship between provenance at the process/application level and provenance at the service/object level?

We also need an analysis and design methodology for provenance. How do you determine how much provenance data will be adequate to satisfy a given compliance requirement in a given context (surely standards cannot be expected to provide a complete answer to this) and how do you compose a suffiently provenance-aware business process either from provenance-aware services, or from normal services plus some additional provenancing services. Conversely, in the design of services to be consumed outside the enterprise, there are important analysis and design questions about the amount of provenance data you are prepared to expose to your service consumers. The EU project includes methodology as one of its deliverables, due sometime next year. In the meantime, IBM hopes that people will start to implement the provenance architecture, as described on the project website, and provide practical input.

SOA and Rational

See my Software Industry Analysis weblog for live reports from the IBM Rational User Conference in Las Vegas, including keynote by Grady Booch, and presentations by Alan Brown and others.

1	KeyNote 1: Born To Run (Software) Business-Driven Development disconnects from Business to Development and from Development to Operations	link
2	Business-Driven Development - Rational, WebSphere & Tivoli Service-Oriented Architecture	link
3	KeyNote 2: Grady Booch. Innovation and Software Engineering	link
4	Product Architecture & Brand Identity	link
5	KeyNote 3: Thomas Dolby. Innovation.	link
6	Summary	link

IBM DeveloperWorks contains links to a number of IBM and non-IBM blogs about the Rational Conference, including mine.

Post updated with permanent links after the series of reports was complete.

Technorati Tags: IBM Rational rsdc2005 SOA service-oriented

Business Unbundling

One of the key concepts of the component-based business or service-based business is that you can change the nature of the coupling or coordination between enterprise units. So we are seeing significant quantities of demerger, unbundling, outsourcing and so on.

Much of this unbundling is being pushed by regulators, especially in utilities (including telecom). See my previous note on Local Loop Unbundling. Think also of the structural changes that various regulators have threatened Microsoft with.

These are often formulated in terms of unbundling services, products or platforms. But they have obvious implications for organizational structure as well. (At one time it looked possible that Microsoft might be split into separate organizations, just as Standard Oil and ATT were previously broken up. And many years before that, IBM was also threatened.)

But the regulatory agenda should not make us think there is always a going to be a conflict of interest here. (Someone in a large telecom company once told me that the unbundling forced upon the company by the regulator had actually turned out to be beneficial for the company as well, because it had increased internal management visibility and innovation.) So sometimes unbundling is the right thing all round.

SAP has been making moves to support unbundling, and the SAP Roadmap includes guidance for unbundling (ECRM Guide, Feb 2005). There is also some standard IT support for inter-company collaboration and data exchange (SAP Press Release, Feb 2005).

John Hagel III and John Seely Brown have been writing about these issues for ages. John Hagel and Marc Singer had an article in Harvard Business Review called Unbundling in the Corporation (1999) (abstract only, purchase reprint). Hagel has been promoting a standard demerger pattern, which splits the enterprise into three standard chunks: infrastructure management, customer relationship or product innovation and commercialization. (This pattern has evolved in his writing, and his terminology has shifted somewhat.) In a recent blog posting (March 2005), he interprets recent developments at 7-Eleven as a successful implementation of this idea.

Hagel points out that these three activities operate with a different business logic on different timescales. Referring to Disney, HP and Morgan (April 2005), he comments: "Product innovation businesses and customer relationship businesses have completely different economics, skill set requirements and cultures. These are incompatible business types that cannot co-exist successfully within a single corporation. By trying to straddle both, these companies found that they could not be excellent in either."

Hagel has identified some of the relevant factors for determining the best way of unbundling the business - but this is not the whole story.

There are two contrasting approaches for unbundling. The approach favoured by Hagel assumes we can establish broad patterns and practices of demerger and subsequent collaboration. This has some advantages - among other things, it suggests that there will be multiple organizations offering broadly similar interfaces, yielding commercial flexibility. But we have some doubts about the generality of this approach. The alternative is to carry out specific analysis for each particular situation. More effort, but sometimes justified.

Component-Based Business

My book on the Component-Based Business was published in 2001. At that time, Component-Based Software Engineering (CBSE) was all the rage (kindof) and I wanted to demonstrate that the same principles could be applied to the design and construction of business as to the design and construction of software.

At that time, there was a fundamental tension in the CBSE world, which I can very crudely characterize as follows: On the one hand, there were OO people who, when they thought of components at all, saw them as glorified objects. On the other hand there were the ODP/CORBA people who thought of components as inherently distributed service packages, but who were often prevented from implementing interesting and viable solutions by the prevailing technological state-of-the-art. (I did say this was a crude characterization, I know there are loads of exceptions, but still ...)

My own alignment was always with the service-oriented rather than the object-oriented. (Historical note: I worked on ANSA/ODP in the early 1990s, participating in the Enterprise Computing Project within the ODSA programme.) In my book, I talk about the fundamental principles of decomposing business into independent chunks, from a component perspective, but I also devote a great deal of space to the (sociotechnical) relationships between the chunks, and to the emergent properties of the whole ecosystem that is composed of these chunks.

In the past few years, there has been some huge shifts both in the technology itself, and in the way people are thinking about the technology. People are starting to become much more comfortable in thinking about service-orientation, and the technology is becoming more credible. For my part, I have started to talk less about the Component-Based Business and more about the Service-Based Business, but I see this as a shift in emphasis rather than a fundamental shift in perspective.

Elsewhere, some people are starting to take much more interest in the potential business impact of web services and SOA. (In terms of RM-ODP, this is a perfectly valid separation of concerns: other people can worry about the Technology and Engineering viewpoints, leaving me to devote my attention to the Enterprise and Information viewpoints.) As one indicator of this, we can see people starting to talk seriously about the component-based business as well as the service-based business. For example, IBM has been promoting a method called Component Business Modeling (CBM), which serves as a front-end to its Service-Oriented Modeling Approach (SOMA). However, based on the materials I have seen, I don't think that IBM's CBM represents the full power of the component-based business approach. (See separate posting on my Software Industry Analysis weblog.)

In my view, the main challenges of the component-based (/service-based) business include those of governance. A component-based approach must have a clear strategy for managing complexity, not just denying or suppressing complexity, and is probably going to draw ideas from complex systems engineering (systems, not software). This calls, among other things, for new kinds of modelling and new approaches to architecture.

There are two reasons why it might be a good time for me to produce an updated edition of my book.

• This topic is now getting much hotter, and I think people may be more ready to accept some of my more radical suggestions.
  
• I am now in a position to update some of the material, reference more recent technological opportunities and threats, and introduce a lot of practical business examples.

Or perhaps I should devote my energies to writing the sequel, with entirely new material, based on my more recent work. Please let me know what you think.

A Brief History of Methods

In this blog posting, I am going to apply a knowledge management framework called Cynefin to a series of Business/IT challenges: software development, systems development and service development.

Background

The Cynefin Centre spun off from IBM in July 2004 and describes itself as a network focusing on the application of complexity science to management and organisational practice. "At the heart of the Cynefin Centre is a distinction between ordered and unordered systems, and the consequent recognition that systems with fundamentally different qualities require the application of contextually differentiated methods for both diagnosis and intervention."

The Cynefin Sensemaking Framework has five domains, four of which are named, and a fifth central area, which is the domain of disorder. The right-hand domains are those of order, and the left-hand domains those of un-order.



For a full description of the framework, see paper by Cynthia Kurtz and Dave Snowden: The new dynamics of strategy: Sense-making in a complex and complicated world. IBM Systems Journal Vol 42 No 3, 2003 (html) (pdf). See also weblog by Willem van den Ende (Dec 6, 2004) (Jan 17 2005).

Development of Methods

Chaos	Uncoordinated building work No method
Known	Design of a single software system Methods include RUP and XP.
Knowable	Design of a software-intensive solution, as a system of systems (e.g. RUP/SE) Twin-track/ multi-track development (e.g. Select Perspective) Assumption of overall design authority - directed composition.
Complex	Design of a software-intensive experience, within a service-based ecosystem - true SOA. Complex systems engineering calling for collaborative composition. Methods could include XB.

RUP is the flagship method for IBM Rational. There is a plug-in for systems engineering called RUP/SE, which goes some way towards the demands of SOA. See separate blog posting.

There is a difference of opinion as to where extreme Programming (XP) belongs. If it is merely a software engineering method focused on the efficient production of small-scale software, then it belongs in the domain of the known. If it moves beyond software productivity into business agility, then it transforms into extreme Business (XB) and belongs in the domain of the complex.

SOA Challenges

IBM Rational has identified five unique development challenges for web services, and admits that it can't solve them.

IBM challenge	RV Commentary
Network dependence - Most services rely on networking protocols (TCP/IP and HTTP) that were never designed to support high-speed application-to-application communications.	The use of these protocols leads to a technical preference for a particular style of communication: asynchronous (loosely coupled) pre-processed ("cooked") information rather than raw data This technical preference influences the granularity of service decomposition.
Loosely coupled, tightly bound - Web services define only the interface of an information exchange. This makes both producers and suppliers vulnerable to changes to supporting systems.	One cause of vulnerability is when the design makes assumptions that are not explicit in the interface contract. This calls for a form of design by contract. A second cause of vulnerability is when the service interaction fails to comply with the service contract. This calls for a form of web service management that monitors contractual compliance.
Anonymous usage model - Web service producers may not be able to identify the consumers of their service — or notify them when something has changed.	Advanced syndication protocols such as Atom should be able to support publish/subscribe modes of change management. In any case, we should expect the web service registry to provide a notification service. If all issues are channeled via the producer, then this generates a dependency: if the producer fails to identify a change, then the notification procedure is not properly triggered. However, syndication mechanisms can be deployed in a way that bypasses this dependency: direct notification of issues by consumers can be automatically communicated to other consumers with similar profiles. This leads to a form of federated change management.
Multiple systems and platforms - While Web services are "platform agnostic", the data encoded within them may not be. It's up to the developer to ensure interoperability across heterogeneous environments.	Web service protocols only address certain aspects of interoperability. We need processes to deal with various other aspects of interoperability, including data semantics. A solitary developer can only achieve so much interoperability. Many situations call for complex collaborations, and the responsibility for ensuring interoperability lies with the prevailing form of web service governance.
Evolving standards - Web services standards are continuously evolving to provide robust security, state management, or transaction processing.	Well really! IBM is a major contributor to the emergence of web service standards, and is therefore helping to create the challenging environment with which the web service developer is trying to engage. Why is this a challenge? We handle evolving standards the way we handle other aspects of evolutionary change - by stratification. This is one of the lesser aspects of the true architectural challenge of SOA: to build adaptive geometries through collaborative composition.

I don't think these five are even the greatest challenges for web services, and they are certainly not the greatest challenges for SOA. However, they are interesting challenges, and although there are some useful ideas and experiences around (if you know where to look), they are not (yet) well-known. We shall be spending the early part of 2005 disseminating our approach.

Project Catalyst

Project Catalyst was announced by IBM boss Sam Palmisano in a speech to the IBM Business Leadership Forum in San Francisco, November 12, 2003. He made the following key points.

Provides a method for identifying the key components of a business.

Provides a three-dimensional view - strategic, financial, transformational.

Provides a way to highlight those areas of the business that are differentiating.

Other components that are not differentiating can be evaluated on a cost basis.

The point of the exercise is to show where to start an on-demand transformation.

At Veryard Projects, in collaboration with the CBDi Forum and others, we have been championing the component-based business for many years. We naturally welcome the high profile that IBM is now giving this important topic.

Update March 2005

I was misled by Sam's speech. I have now been briefed about IBM's Component Business Modeling approach, and I now understand that this was an entirely separate initiative and not part of Project Catalysis. See new blog postings on Component-Based Business, Component Business Modeling.