From Networked BI to Collaborative BI

Back in September 2005, I commented on some material by MicroStrategy identifying Five Types of Business Intelligence. I arranged these five types into a 2x2 matrix, and commented on the fact that the top right quadrant was then empty. 

 
The Cloud BI and analytics vendor Birst has now produced a similar matrix to explain what it is calling Networked BI, placing it in the top right quadrant. Gartner has been talking about Mode 1 (conventional) and Mode 2 (self-service) approaches to BI, so Birst is calling this Mode 3.

While there are some important technological advances and enablers in the Mode 3 quadrant, I also see it as a move towards Collaborative BI, which is about the collective ability of the organization to design experiments, to generate analytical insight, to interpret results, and to mobilize action and improvement. This means not only sharing the data, but also sharing the insight and the actioning of the insight. Thus we are not only driving data and analytics to the edge of the organization, but also developing the collective intelligence of the organization to use data and analytics in an agile yet joined-up way.

I first mentioned Collaborative BI on my blog during 2005, and discussed it further in my article for the CBDI Journal in October 2005. The concept started to gather momentum a few years later, thanks to Gartner, which predicted the development of collaborative decision-making in 2009, as well as some interesting work by Wayne Eckerson. Also around this time, there were some promising developments by a few BI vendors, including arcplan and TIBCO. But internet searches for the concept are dominated by material between 2009 and 2012, and things seem to have gone quiet recently.

---

Previous posts in this series

Service-Oriented Business Intelligence (September 2005)
From Business Intelligence to Organizational Intelligence (May 2009)
TIBCO Platform for Organizational Intelligence (March 2011)


Other sources

Gartner Reveals Five Business Intelligence Predictions for 2009 and Beyond (Gartner, January 2009). Dave Linthicum, Let's See How Gartner is Doing (ebizQ, May 2009)

Chris Middleton, Business Intelligence: Collaborative Decision-Making (Computer Weekly, July 2009)

Ian Bertram, Collaborative Decision-Making Platforms (Gartner 2011)

Wayne Eckerson, Collaborative Business Intelligence: Optimizing the Process of Making Decisions (April 2012)

Monique Morgan, Collaborative BI: Today and Tomorrow (arcplan, April 2012)
Tiemo Winterkamp, Top 5 Collaborative BI Solution Criteria (arcplan, April 2012)

Cliff Saran, Prepare for two modes of business intelligence, says Gartner (Computer Weekly, March 2015)

The Future of BI is Networked (Birst, March 2016)


Updated 21 April 2016 (image corrected)

Collaboration Chasm

I've just been looking at a Collaboration Framework published by the CISCO community earlier this year [Insights from the Collaboration Consortium Year One], which uses the well-known Crossing-the-Chasm model of technology adoption, popularized by Geoffrey Moore and loosely based on the work of Everett Rogers. The CISCO term “collaboration chasm” refers to the notion that there is a discontinuity between the use of a limited number of technologies by early adopters and the large-scale adoption by mainstream users.

Rogers himself modelled adoption as a continuous S-curve, but Moore's notion of a chasm is popular with supply-side marketing people, because it suggests a single heroic leap from an experimental product to a commercial success.

In the context of collaboration technologies within the enterprise, the "chasm" metaphor can be interpreted in multiple ways, all of which are discussed or implied in the CISCO document.

• The categorical difference between individual early adopters and everyone else. A simplified model of adoption would regard "early adopter" as a personality type, predicting a person's attitude to any kind of innovation, similar to the Adaptor/Innovator scale developed by Michael Kirton. (Rogers himself recognized that a person could easily be an early adopter of one technology and a late adopter of another.) Additionally, some writers may wish to characterize particular organizations as early adopters.
  

• The categorical difference between Generation X and Generation Y. The assumption that because younger people are likely to be more comfortable with certain classes of technology, they will therefore be more positively inclined to the adoption and use of these technologies in the workplace.
  

• The difference between social and workplace use of these technologies. Jagdish Vasishtha thinks this has something to do with personal choice, saying "there is a growing chasm between how people now communicate in their personal space and how they are forced to communicate in a corporate environment" [Crossing the Chasm, May 2009 (pdf)]. The CISCO document points out several reasons why technologies such as social networking or instant messaging don't necessarily transfer easily from one’s personal life to the workplace, and quotes Ray Ozzie on the "chilling effect" of organizational dynamics [Churchill Club, June 2009]. See also Richard Dennison, BT 2.0 Case Study, November 2007.

• The step from undirected ("bottom-up") investigation to directed ("top-down") business process change. "Carefully shaping a subset of collaboration initiatives in a top-down fashion to align them with business priorities provides the required structure to scale up an organization’s efforts into the performance stage."

• The step from isolated experimental use to integrated use. CISCO describes a 3-stage development strategy (1: Investigative, 2: Performance, 3: Transformational), and positions the "chasm" between stages 1 and 2. For an SAP example of the "chasm" between stand-alone collaboration and embedded collaboration, see Irwin Laazar, Collaboration in Context (May 2010).

• "Collaboration creates shifts in the organizational mindset." This might possibly qualify as a second chasm between CISCO stages 2 and 3.
  

However, there are some misalignments between these different notions. For example, the fact that many young people are familiar with social networking in their private lives doesn't necessarily imply that they will be better able than their parents to use social networking effectively in their professional lives. Effective use in a given social context depends on purpose and style, and social and organizational experience may be more relevant here than technical skill and enthusiasm.

---

In my work on technology adoption within the enterprise, I make the distinction between broad adoption and deep adoption. Broad adoption basically means that a given product or platform is used by a lot of different people in a lot of places, but this usage may be casual, occasional and uncommitted. Deep adoption means that the product or platform is used intensively, is embedded in processes and working practices, as well as being integrated with other relevant technologies, but may only involve a few people or departments.

The distinction between broad adoption and deep adoption implies two "chasms" at right angles - one between narrow and broad, and one between shallow and deep. The tactics required to encourage broad adoption are significantly different from the tactics needed to implement deep adoption. CISCO's basic 3-step strategy appears to involve crossing both of these chasms at the same time, but the document also refers to some alternative strategies, including a "cultivation" strategy followed by Statoil. Some adoption strategies may permit different aspects of technology adoption to be decoupled; indeed, a number of the examples cited from CISCO's own internal processes involve localized collaboration within specialized processes, although this may be because enterprise-wide cross-process collaboration is harder to explain.

The distinction between broad adoption and deep adoption may also encourage us to look at early adopters more critically. Those who constantly quest for technological novelties may not appreciate or experience the full power of a revolutionary innovation, and may not the best people to lead serious and sustained commitment to its enterprise-wide and system-deep adoption. By the time the organization is moving into CISCO's stage three, the so-called early adopters may have switched their attention and allegiance to something else.

Are BPM professionals experts in collaboration?

@ReduxOnline posts a link to a student project How to measure the collaboration of knowledge workers in the enterprise.

1. To understand the factors supporting collaboration between knowledge workers, a questionnaire was sent to BPM professionals. The paper doesn't make clear whether they were being asked about their own personal collaboration, or about their opinions about collaboration in general. In any case, we might imagine that BPM professionals have a particular perspective on collaboration, which might distort the survey.

2. Nearly a quarter of the BPM professionals couldn't make sense of the collaboration model on which the survey was based, and were unable to answer all the questions. Instead of treating this as a sign that there might be a problem with the model, the researchers chose to exclude these from the analysis. They then argue that the remaining responses validate their model.

3. The survey doesn't measure collaboration, it measures opinions about collaboration, from a carefully selected group of knowledge workers. Perhaps not surprisingly, the opinions are pretty consistent with the kind of management literature that these knowledge workers might be expected to have read. Except that the answers about "purpose" were all over the place (which I can well imagine, given the uncertain intentions of the question), so this factor failed a statistical test (Cronbach's Alpha) and could be quietly dropped from the model.

4. The direct relation between collaboration and the performance of an enterprise is not tested, because the questionnaire did not consists of any financial questions. (It would seem that financial information is "sensitive"; collaboration itself presumably isn't.) Let's hope the students manage to extend their research to include questions about the financial situation of an enterprise, allowing them to demonstrate and explain how maturity of collaboration of knowledge workers (as perceived and understood by BPM professionals) might actually help to improve the performance of an enterprise.

5. I generally regard opinion surveys as low-grade research because they usually merely recycle received opinion. While I understand that this may be the easiest and cheapest form of research, especially for students and software industry analysts, I expect to see some acknowledgement of the potential distortion, rather than merely taking the collected opinions at face value.

Social Networking at Work

According to the ReadWrite Enterprise, social networks are changing how manufacturers view their operations and manufacturers are becoming the "surprise adopters" of social computing. For example, wikis for recording best practices and capturing knowledge of departing engineers are big with these companies. (Facebook In the Factory: Manufacturers Want Social Software Too, via Ethan Yarbrough)

Why social? Because business is a social system for creating value. (This is one of the key principles of my Foundations of Business lecture series.) Collaboration is a social activity.

Some people think that "social" means spare-time activity. Thus in the work environment, "social" is what you do when you aren't actually performing your primary task. However, the word "socialize" doesn't just mean making friends with your colleagues, or time-wasting at work, but getting your colleagues to make friends with your ideas. Among other things, that means telling interesting stories (and not just dry bullet points and irrelevant clipart) - informal as well as formal communications. Good social activity also promotes trust. There are fewer and fewer jobs that don't require this kind of activity.

It's difficult to see how anyone could survive as a manager without understanding this, although some advocates of social networking and social computing feel the need to spell out the benefits of "social". See for example, Ethan Yarbrough's post In Defense of Social: Enterprise 2.0 Social Technologies Are Critical, Not Casual. But just because a manager understands the benefits of social doesn't mean she is going to encourage all her staff to spend a proportion of their working time on Facebook. One possible objection to Facebook is not that it is social, but that it isn't social enough. (Similar arguments have been put against the use of Facebook by teenagers, although some of these arguments involve some extremely dodgy science as documented by Dr Ben Goldacre, Bad Science Feb 2009.) There is an important question about the contribution of so-called social networking tools to the sociality (if that is the right word) of the organization, but this question would surely have to be investigated by sociologists, rather than by technologists or neuroscientists.

If we don't want to get sidetracked into sociology, perhaps we should sidestep the "social" label. In his post What do we call social media tools, Ethan suggests that we could call them "knowledge media" tools instead. But I am not sure this helps. I'd prefer to call them collaboration tools.

Meanwhile, there are people looking at how social media could transform public services, including the NHS. In November 2009, a UK group called Patient Opinion organized a conference on myPublicServices. See BBC News, 27 November 2009. Patient Opinion captures stories about what happens to people when they get medical treatment, and routes their criticism or praise to people in a local health authority who need to know and can, if need be, use that information to improve services.

Some people might regard the story-telling as an intrinsic part of the service. However, I guess most people would regard the story-telling as part of a collaborative effort to improve the services, which transcends the boundaries of those organizations traditionally tasked with managing these services. So there is still a way to go to integrate social media into the services themselves.

Selfish Collaboration?

With some Web 2.0 tools, people are often working with parallel goals rather than common goals. For example, many people tag their own bookmarks for their own selfish purposes, and any resulting benefits to other people (network effects) are merely happy side-effects. Angela Ashenden of MWD asks Is this really collaboration?

One of the comments to her post suggests a distinction between "social" and "collaborative", but I'm not convinced this really solves the problem. A lot of Web 2.0 activity doesn't really count as social either.

A key question here is whether collaboration has to be conscious and deliberate. Angela thinks that if we are to take the word literally then co-involvement has to be conscious, with explicit intention. This would presumably rule out various forms of asymmetric collaboration.

But in a large organization different people may have different levels of awareness of what is going on, and intentions can sometimes be pretty non-specific or half-hearted. So someone might post some material on the intranet with a vague hope that this might prove useful to somebody or other. If there is an explicit but weak intention, it might just about count as collaboration according to Angela's definition, but of course it's a pretty feeble kind of collaboration.

However, many successful collaborations involve people with conflicting intentions; sometimes it is precisely this conflict that drives creativity, even though this may be largely implicit.

Testing 2.0

Andrew Johnston [spelling corrected] is looking for best practices in test automation (dodgy permalink).

"I am looking for one of my clients into how costs can be reduced, or quality increased, by increasing the extent to which testing is automated."

Jonathan Kohl thinks he has the answer: Software Testing 2.0.

"The Context-Driven Testing School is a small, influential community. ... One thing this community has done is build up and teach skilled testing, and has influenced other communities. Everywhere I go, I meet smart, talented, thoughtful testers. In fact, I am meeting so many, that I believe a new community is springing up in testing. A community born of experience, pragmatism and skill. Testers with different skillsets and ideas are converging and sharing ideas. I find this exciting."

Although Jonathan's evident enthusiasm for systems thinking is infectious, I think there are some problems with a Testing 2.0 approach that seems rather reliant on a concentration of rare skills. I think that Web 2.0 introduces some entirely different (and equally radical) opportunities for transforming software quality and testing.

• long tail
• publish/subscribe (RSS/Atom)
• community of users

Back in the days of component-based software engineering, I proposed some ideas about component testing that relied on information flows between users, and from users to developers. More recently, I described a pull model of documentation and support, where documentation evolves as the user community grows. Common to both proposals is a radical rescoping of software quality. Software testing could cease to be based on an US/THEM split, but become a complex collaborative process instead, in which the diversity of use-contexts is seen as an asset rather than a liability. Testing never stops - every time the software is executed, some new test results are produced. Massive sharing of test data and test results - instead of MySpace, think MyTest.

One of the supposed advantages of Open Source is that you have a large community of people not only testing the software, but fixing the bugs. But with the right platform we might possible get some of these advantages with Web 2.0, even without Open Source.

Documentation and Support

Phil Wainewright and his ZDNet colleagues are producing a set of IT commandments. Phil's latest commandment is "Thou shalt document all thy works".

Documentation is the lifeblood of collaborative computing ... How is anyone supposed to reuse a piece of code or a service if the documentation's inadequate?

... And when I say 'document' ... I'm talking about a veritable cornucopia of practical information: what the program does and how is just the start. Other people need to know what it was and wasn't designed for; how it performs and what the limitations are; how it's been tested and what the results were; along with a host of other things.

Many people regard documentation as a tedious virtue - something you only do because there is a parental voice in the back of your head nagging you to do it. Or you find excuses not to do it, or to do it later, or whatever. Or you fantasize that the next generation of technology will be clever enough to generate perfect documentation retrospectively.

The trouble with documentation is that you may have to anticipate all the questions that potential users might ask, and then express the answers in a form that potential users might understand. Modelling helps, because the models can (under certain conditions) provide a lot of the documentation, in a commonly recognized (and possibly machine-readable) form. But models don't always provide all the information the user might want.

What is this information?

• Has this service been used in this context, and how did it perform?
• Can this service handle transaction volumes within this range?
• Why am I getting this effect? Is is supposed to do that, or is it a bug? Is there a workaround?
  
• Are there any known security issues?
• Are there any known interoperability problems when using this together with service Y?
• How quickly does the service provider deal with problems?
• Does this service really work, and can I rely on it?

Are the developers the best people to provide this information? Not necessarily. Isn't it sometimes better to ask other users? And not just the users selected by the service provider to provide glowing references either.

Which brings me to an idea I proposed a long time ago in the context of software quality management - user-led quality documentation. If you are using a service, you should be able to do two things. Firstly you can publish a view of your use of the service, including how you are using it, in what context, what you are using it for, what service levels you are getting, what issues/problems you are having. (Some of this can be automatically generated from your service management system, including problem tracking. Of course, you can control how much of this you choose to expose to fellow users inside your own organization and/or outside.) Secondly you should be able to subscribe to other people using the same service, filtered in various ways.

Service providers (including developers) will want to be active participants in this user community. Of course, the software industry is familiar with the concept of user group - but this has traditionally been organized for very large software products and platforms. A three-day conference in Florida or Vegas, attended by thousands, and carefully orchestrated either by the vendor, or by an independent organization that depends on the vendor's goodwill.

Does this absolve the developer of the responsibility to document? Not at all. But we should no longer expect the developer to be the sole source of documentation. Phil's commandment is consistent with a push model of documentation - perhaps it's time to combine this with a pull model.

Technorati Tags: documentation publish+subscribe quality SOA service-oriented

Enterprise Mashups and Situated Software

Situated software and mashups are regarded as closely related concepts. (See for example Redmonk's James Governor.) But there are some important differences between the two concepts, which I want to explore in this post.

I also want to talk about the related concept of Bricolage. As we shall see, many popular examples of both situated software and mashups involve strong elements of bricolage.

(Update: I've just added a post to my SOAPbox blog about the Lightweight Enterprise. I now have a number of related posts, which I need to tie more firmly together.)

Bricolage

Bricolage is a form of improvisation practised by some engineers, using whatever resources and repertoire come to hand, in order to perform the immediate task. A person who practises bricolage is called a bricoleur.

Bricolage may be contrasted with following a disciplined and repeatable engineering process.

Situated Software

Clay Shirky defined situated software as "software designed in and for a particular social situation or context." This may be contrasted with software that is produced as a universal solution for some generic problem. For some examples, see my post on Situated Software (January 2005).

The late Claudio Ciborra saw bricolage as a useful way of delivering situated software. The Wikipedia article on Bricolage glosses Ciborra's argument as follows. "By valuing tinkering and allowing SIS to evolve from the bottom-up, rather than implementing it from the top-down, the firm will end up with something that is deeply rooted in the organisational culture that is specific to that firm and is much less easily imitated."

We can perhaps understand the link between bricolage and situated software by considering the link between their respective opposites. The economics of scale in software production appear to point towards a disciplined (and easily automated) software engineering process, producing universal (standard, one-size-fits-all) software artefacts. (In the Boxer model of Collaborative Composition, this is represented as an anticlockwise arrow.)

Both bricolage and situated software seem to represent an entirely different ethos - driven by the particular rather than the universal. (This is represented by a clockwise arrow in the Boxer model.)

However, bricolage doesn't always produce situated software. (Tinkering doesn't always produce something that is deeply rooted in the organization - it only does this under certain favourable conditions.) And conversely, some situated software often requires a highly focused and disciplined approach as well. (Similar to what Christopher Alexander calls a Timeless Way of Building.)

IBM's Ali Arsanjani (Kant versus Hume) has suggested that we can identify two styles of SOA, which he associates with the philosophers Kant and Hume. My interpretation of this is that Kant represents the production of services (and other software artefacts) from some apriori (generalized, enterprise-wide or industry-wide) schema, while Hume represents the production of services and software artefacts from the specific local requirements, grounded in the strategic context of a specific enterprise and its customers?

Some people like to refer to the universal/rational/Kantian position as top-down, and the grounded/empirical/Humean position as bottom-up. But I think this is a misleading equation - after all, it is the Humean position that is driven directly by the actual business requirements, while the Kantian position is based on reusing abstract constructs from elsewhere.

Mashups

So where do mashups fit into this story? In recent months, there has been a rapid growth of composite applications, based on apparently arbitrary combinations of online services such as GoogleMaps, Flickr, del.icio.us, and so on. (Philip Boxer has done some analysis of these interoperability landscapes for the Asymmetric Design blog.)

One of the explanations for this rapid growth is that such mashups can be produced very easily using new platforms such as AJAX and Ruby on Rails. But I don't think that the definition of mashup depends on using any particular technical platform. I also don't think that the basic concept of mashup is affected by the physical location of the mashup execution - whether on the client-side (browser) or on the server-side - although this is obviously important from a technical point of view.

Large numbers of simple mashups can be produced through bricolage. (Many of these are based on images, because this gets around some of the security restrictions of the standard browser.) But many of these I don't see as genuinely situated applications. They are produced from rational analysis of abstract domain knowledge, not from empirical analysis of context and situation. They follow an anticlockwise development path rather than a clockwise one.

From an enterprise point of view, the interesting mashups might involve composing real enterprise services - something like mixing SalesForce services with mySAP services. But this requires more than bricolage - it requires careful analysis of the semantic interoperability of the services to be mashed-up. This analysis will be situated (and therefore possibly not repeatable elsewhere) to the extent that my particular way of combining SalesForce with mySAP is grounded in the particular way I want to run my business.

Synthesis

• Not all mashups are situated. (However, complex enterprise mashups are more likely to be situated.)
• Not all clockwise software production is based on bricolage.
• Enterprise software is rightly suspicious of bricolage. But this is not a sufficient reason to reject situated software or enterprise mashups.
  
• The architectural challenge is not to replace anticlockwise software production with clockwise, but to develop higher-level platforms to support collaborative composition - allowing clockwise to be combined with anticlockwise.

Activity-Based Computing

Just had an interesting demonstration from IBM Lotus of some new collaboration technology they are developing. Looking beyond the demonstration (and what IBM currently has working) there is some exciting potential for the convergence of three sets of technologies:

• CSCW (computer-supported collaborative work). Allows co-workers to collaborate around some activity. Distribution and co-development of documents related to the activity, including rich media.
  

• BPM (Business Process Management). More structured collaboration, possibly involving orchestration and workflow, as well as BAM (Business Activity Monitoring).
  

• Web 2.0. Liberal use of tags, feeds and other internet mechanisms.
  

I'm not going to go into details about IBM's current and future technology here, but here are a few examples of how this kind of technology might be used.

• A team within an organization producing a proposal for a customer. (This is a classic example, because it typically involves workers who are engaged in this class of activity as a major part of their jobs, often working on several large and complex proposals in parallel.)

• Handling a customer complaint. (Even if most complaints are relatively simple, the scope of this class of activity is much greater, potentially involving any aspect of the organization's operations. Although there may be a customer service department with primary responsibility for handling complaints, other parts of the extended organization may be pulled in as needed.)

• Solving a production problem. (A problem may be broken down into subproblems, and this may involve spawning a number of other activities. See my earlier post on BPM and SOA, which includes a discussion of the problem-solving methodology TRIZ.)

• A doctor orchestrating medical intervention for a patient - tests, drugs, physiotherapy, and so on. (The interesting aspect of this class of activity is that the collaboration typically goes outside the boundaries of the doctor's own organization. So we would need some kind of federation - for example to coordinate the activity between the clinic and the hospital.)
  

Now let me mention some of the opportunities and challenges that this kind of technology throws up.

• Balance between standardization and flexibility. We're not talking about rigidly prescriptive business processes here, but about situated processes - in other words, processes that are driven by the requirements of a particular situation. For example, although it is certainly possible to standardize some aspects of customer complaint handling - every complaint gets logged, policies for providing refunds, and so on - many complaints will require detailed investigation whose exact form depends on the content of the complaint itself. Meanwhile, management will typically want to have a standard basis for measuring the efficiency and effectiveness of such activities. It is obviously possible to define standard activity patterns, and standard services to support flexible activities - but the establishment and enforcement of these standards is a crucial aspect of activity governance.

• Model-based management. A collaborative activity may be described by an activity model or workflow model (for example using UML or BPEL for People.) It may be possible to use these models in the creation or governance of activities. It may also be possible to infer models (and therefore extract patterns) from the actual history of activities. (The demonstration I was given did not include any process visualization or inference - but there are various IBM and other Eclipse-based modeling tools with which this collaboration technology could presumably be integrated.)

• Publish/subscribe. Use of tagging and feeds potentially provides a neat way of making connections with occasional users. (Atom is a more tightly structured standard than RSS, and may be more appropriate for applications like these that go far beyond simple news.)
  

• Pull/push mechanisms. Subject-matter experts within an organization might subscribe to various tags, with the effect of identifying activities where their expertise might be relevant (thus pulling themselves into these activities). Other social networking mechanisms may also be relevant in making connections between the Expertise and the Work.
  

• Semantics. A small team may have a fairly homogeneous set of tags. As collaborations get more widely distributed, the meaning of a given tag becomes increasingly uncertain, and so the semantic value of the tags may be diluted. This problem may be tackled either top-down (ontology) or bottom-up (folksonomy) - but there are some important issues either way.

• Federation and interoperability. How do we manage collaborative activities that cross organizational boundaries? (a) If the clinic and the hospital are using separate installations of the same collaboration technology. (b) If the clinic and the hospital are using different collaboration technologies.
  

We also had a very interesting discussion on AJAX, enterprise mashups, situated software and other Web 2.0 topics, which I shall write up separately.

Mix06 Keynote

A fascinating keynote speech by Bill Gates at Mix06, without any slides. (He's obviously been reading the blogs about his use of PowerPoint). Some great presentations by mySpace and the BBC, followed by a conversation with Tim O'Reilly.

Tim tried to push Bill into supporting Web 2.0. Can we find some examples of collaborative, bottom-up emergence in the Microsoft/Windows experience? Bill's answers all seemed to be about Microsoft controlling things better, putting in better security features and so on, based on install volume (what economists call "learning by doing") and user feedback. I don't think this was really what Tim was pushing for.

Tim also asked about competition from companies with different business models - Google, Apple - and Microsoft competing with telcos. Bill evaded these questions, and talked instead about Microsoft moving away from a device-centric model of computing towards a user-centric model of software. Your user preferences are available (though services) to any device you happen to pick up - including (if you are authenticated to use it) your friend's phone. This looks like a very important development, which is related to the context-based services I've been talking about on my SOAPbox blog.

This is relevant to the competition with Apple, because the Apple solution remains proprietary and tightly controlled - especially in terms of DRM - and this gives some credibility to Microsoft's attempt to position itself as more open and interoperable. As a representative of a major content provider, the BBC speaker was positive about Microsoft's DRM position.

The keynote lasted longer than I had expected, so I had to leave before the end. I'll try to catch the rest on the Internet later.

Business Collaboration Framework

A strange notice appeared on the BCF website before it went off the air, from which it appeared that the various parties building the Business Collaboration Framework had not managed to develop/sustain satisfactory terms for their own collaboration. Something to do with IPR.

As a result of the lack of any policy statement that can be evaluated by our legal advisors we are compelled to concur with the potential risks and exposure identified by Mr. David Marsh, UN/CEFACT Legal Rapporteur, during his presentation at the May Plenary session. Accordingly, we have had no alternative but to inform the UNECE that Ge-BAC has suspended all active project team participation by its employees within UN/CEFACT and its Groups.

Further, on the advice of our legal counsel, Ge-BAC has suspend its hosting services for the TMG and BCF web sites, as well as the TMG list server, in order to avoid legal challenges related to the ownership and distribution rights of the IP reflected in the content of all online material. Ge-BAC regrets this action, but as a small company we must avoid all unwarranted potential legal actions. At such time as the UNECE can successfully provide IPR policy documentation, we will evaluate the acceptability of that policy to our business operations and continued full participation in UN/CEFACT activities.

Standardization is an unusual enterprise, and its committees are often dominated by people of a certain personality type. But even so, one might have thought that those engaged in standardizing collaboration would have the knowledge and skill to construct an effective collaboration for themselves.

However, a standards effort must anticipate and represent all possible difficulties. The BCF collaborators had clearly stumbled across some intractable difficulty, and had the clarity and wisdom to recognize it as such, instead of fudging it as other less self-conscious collaborators might have done.

post relocated from previous site