Smarter Planet

Despite what @wendytarr says, whether we are ready for IBM's Smarter Planet (whoever "we" might be) is not about people's readiness to embrace the technology. As a lot of people have been saying lately, including on IBM-sponsored websites, readiness and resistance is not about people trusting the technology but about people trusting one other.

• "Do we really want to have a two-way conversation with our employees, partners, and suppliers?" [Jeanne C Meister and Karie Willyerd When your company culture isn't ready for social media (Harvard Business, Jan 2010)]
  

• "Are you willing to accept uncensored comments that might be contrary to your organization’s point of view or that threaten the status quo?" [Heather Clancy: Your company may not be ready for social media (Smart Planet, Jan 2010)]
  

• "IBM can only go so far in convincing people that Smarter Planet systems are not only beneficial but trustworthy. After that, we have to trust the people behind the systems." [John Webster, Are we ready for IBM's Smarter Planet? (cnet news, Jan 2010)]
  

• "Attempting to introduce open and frank communications and interaction into a fairly rigid command-and-control corporate environment may result in dashed expectations and a frustrating, counter-productive experience." [Joe McKendrick, Can an organization not be ‘ready’ for Enterprise 2.0? (Fast Forward, Jan 2010)]
  

• "If you don’t have a supportive culture, it’s nearly impossible to find real success with any social tools (beyond small scale deployments — which may be very successful for your team, but not at the enterprise level.)" [Gil Yehuda, Enterprise 2.0 initiatives and corporate culture awareness (Jan 2010)]
  

Webster tells us how IBM has always swung between between trying to sell the technology (for example computers) and trying to sell the business systems that use the technology (for example, the benefits of computing) - and how IBM has always been more commercially successful when doing the latter. So it's not about the technology, it's about smarter systems of systems.

Even within a single organization, trust between people and departments is (sadly) the exception rather than the rule. See Jack Vinson's post They are making us do it, in response to my post Why New Systems Don't Work. One of the things Jack mentions is that "people tend to focus on the software, even if that isn't the primary driver behind the change". Even within IBM, then, there may be people who suffer from this fallacy.

Lotus Knows

There are several interesting aspects of the IBM "Lotus Knows" campaign.

The campaign started as a debate with the extended Lotus community (people inside and outside IBM) about the best ways to promulgate the benefits of Lotus. The debate itself used some of the latest crowd-sourcing and idea-sharing features of the Lotus platform (including a third party app called IdeaJam), and therefore served as a practical demonstration of some of the topics under discussion. The campaign is therefore an exercise in metacommunication - an act of communication between two or more agents that also communicates something about the communication itself and/or about the relationship between the agents.

Much of the resulting material consists of a long enumeration of all the complicated details of our daily lives that Lotus "knows". For example, whether to take an umbrella to a meeting.

Okay, here's my algorithm for taking an umbrella. If I am wearing my best suit, and I expect to walk in a dignified manner across an unsheltered carpark, then I will take an umbrella if the probability of rain is greater than 25%. If I am wearing smart casual, then I can always sprint if there is a shower, so I will only bother with an umbrella if the probability of rain is greater than 50%. And if I'm slumming it in jeans, the threshold goes up to 75%. If the meetings in my diary are classified by dress code, then Lotus should be able to combine my schedule with the local weather forecast, in order to give me an up-to-date umbrella advisory.

But the important point is that my umbrella preferences may not be the same as yours. So how does Lotus know what my umbrella preferences are? Presumably I have to teach it my preferences. And how exactly do I do that?

Alan Lepofsky adds

'"Lotus Knows where that file is" would mean more to me if it said "Lotus Knows how you can share files with your team, or with your customers".  Or, "Lotus Knows which calls you want to answer, and which ones you want to avoid".  Make it personal.' [Cute Lotus Knows ad, but]

For my part, when I see the slogan "Lotus Knows", my first question is not "How many different things does this clever Lotus actually know?" but "How exactly does Lotus know the things it knows?".

In other words, I want to know the process. I want to think of Lotus not as a bit of magic that produces knowledge from nowhere, but as a platform supporting an intelligent and collaborative way of working.

And what about the collective brainstorming that kicked off the Lotus Knows campaign? How much reliance can be placed on ideas that emerge from a free discussion? David Tebbut points out a small flaw.

"A terrific idea, except it's a bit like asking a church choir what songs they should be singing. They're going to choose the easy ones, the catchy ones, the ones that appeal to the choir itself." [Lotus knows, but do you?]

In many situations, the intelligent approach is neither entirely traditional nor entirely crowd-sourced, but a balanced combination of both. So how does a platform like Lotus help us achieve this, and how do we know if we've got the balance right? How does Lotus know whether what it knows is Good Enough?

(I expect there are good answers to these questions, and I intend to discover them, but they are not the questions that are given most emphasis on the Lotus Knows website.)

#LotusKnows

IBM Acquires Telelogic 2

After several months of internal discussion, IBM has finally explained how the Telelogic acquisition (announced in June 2007) is going to be folded into the Rational brand. I have just listened to an analyst call with Danny Sabbah (general manager of Rational) and Neeraj Chandra (EVP of Telelogic).

Let’s take the minor headlines first. IBM has announced three main areas of integration across the extended product family.

• end-to-end, extensible, open standards-based platform
• community-based collaboration
• preserve and protect client investments in Rational and Telelogic products

This seems to be about interoperability between the different products, interworking between teams using different products and upward compatibility (i.e. no forced migration) of client models and other assets built using the different products. These are the inescapable challenges of software industry consolidation, which IBM and its customers are very familiar with.

But it’s the other three headlines that are the interesting ones, because they reveal what IBM thinks it is gaining from the Telelogic acquisition. According to IBM, the Rational product family is extended in three main areas:

• systems with embedded software
  
• product lifecycle management
  
• enterprise architecture
  

with an emphasis on sectors with complex requirements for systems and software

• electronics
  
• aerospace & defense
  
• automotive
  
• telecom
  

What I find interesting about these two lists is what they leave out.

Firstly, requirements management doesn’t get a headline mention. Requirements management was a major strength of Telelogic, and DOORS is the market leading tool. Perhaps we are supposed to believe that Rational already had a perfectly adequate approach to requirements management, and Rational System Architect works fine, thank you very much, except in a couple of specialist areas (systems engineering, product engineering).

Secondly, it ignores the current push towards enterprise architecture in other sectors, notably Government, where I understand Telelogic’s System Architect tool (ex-Popkin of course) has a significant presence. (The IBM materials mention DODAF and MODAF but not TOGAF, FEA, or xGEA.)

And thirdly, not much mention of SOA, except as an enabling technology for back-office systems. Telelogic System Architect had come out with an SOA-enabled version shortly before the acquisition announcement, but it isn’t yet clear where this is going. Danny Sabbah did mention expanding the opportunities for Telelogic's architectural frameworks products in the SOA space, but this seemed to be in reference to sales rather than development.

There are two domains in play, according to IBM: an IT domain (supporting business operations) and a systems domain (producing products). Although Neeraj Chandra wanted us to know that Telelogic could contribute to the IT domain as well, the official Rational line seems to be that the Telelogic is to be used primarily in the systems domain.

For systems domain read systems-of-systems domain. Examples cited include aerospace systems and consumer electronics, where interoperability between multiple systems is needed to solve a complex requirement.

But as I have long argued, SOA itself is essentially a systems-of-systems approach – interoperability between multiple services to solve complex sets of requirements. So I hope IBM doesn’t intend to bury SOA somewhere in the IT domain. Shouldn't there be a separate services domain?

There are of course plenty of outstanding questions. In answer to a question on reuse, Danny talked briefly about architectural governance, but I'd like to have a much longer conversation about this. And Neeraj mentioned methodology and workflow, but it wasn't clear how any of this gets plugged into RUP (or perhaps RUP/SE).

I do think the acquisition of Telelogic gives IBM Rational a tremendous opportunity, but clearly they have plenty of work to realise this opportunity. Certainly not the end of the story.

IBM 4 Enterprise

Redmonk's James Governor is undoubtedly being mischievious mischievous in his latest post - The Definitive Proof that Ruby on Rails is enterprise technology.

Here is his so-called proof.

1. A recent recruit at IBM is doing things with Ruby.
2. Presumably IBM hired this person for his Ruby skills.
   
3. Therefore IBM has endorsed Ruby.
4. Anything IBM does is enterprise.
5. Therefore Ruby is enterprise.

But this argument overlooks a critical decoupling that is evident in IBM's history - between R&D and Sales.

The history of IBM certainly includes some pretty impressive research, including a number of Nobel Prizes. IBM employed Mandelbrot. IBM made a computer (Deep Blue) that can beat grandmasters at chess. IBM also takes credit for the invention of the relational database and the personal computer - inventions which were (much later) widely adopted by the enterprise.

IBM also has a history of trust, and a powerful sales organization. Nobody gets fired for buying IBM, went the whispers.

Sometimes there is a very long lead time between the invention and the enterprise adoption. One of the trust factors in IBM's favour is that it doesn't have a history of rushing new technology prematurely to market. IBM may have invented the relational database, but it didn't produce a commercial RDBMS until long after the first movers.

From many points of view, a disconnect between Research and Sales would be regarded as an organizational weakness. But it is also a strength, and reflects the fact that Research and Sales have different loyalties. Enterprise customers can trust the IBM salesman, the argument goes, precisely because he is closer to the enterprise.

IBM has changed a lot in recent years, and perhaps the historical disconnect between Research and Sales is now less evident. But the idea that an experimental use of a technology within IBM is equivalent to enterprise endorsement is still far-fetched. One swallow doesn't make a summer.

Technorati Tags: IBM Ruby

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.

Component Business Model

I first heard about IBM's Component Business Modeling CBM approach in a speech by Sam Palmisano (speech, my original comment). At first, it seemed as if this indicated a move by IBM into the subject of my 2001 book: Component-Based Business (book, blogpost).

I have now had a chance to look at some examples of CBM in practice.

• Component business modeling: A private banking example (June 2004)
• Component business modeling - mapping the way in insurance (June 2004)
• Component business modeling in retail banking (June 2004)
• Financial services firms prepare for an on demand world (July 2004)

As far as I can see, IBM's method is pretty close to the Information Engineering methodology, which I practised in the 1980s. The business component model (or component business map) looks remarkably like an old-fashioned business system architecture or functional decomposition. It is drawn as a neat stack of rectangular boxes, arranged into three management levels (direct, control, execute), without any explicit interaction between the boxes.

In the materials I've looked at, IBM doesn't tell us how it arrives at this model. The model is closed, internally focused, and apparently set in concrete. There seems to be little attention to the coupling between the business components, or to the interfaces between the business and the outside world, which might seem to be important architectural concerns. The case studies seem to be largely at the ISP (information strategy planning) level, rather than business strategy.

This kind of model supports a divide-and-conquer agenda, and is undoubtedly useful for managing the IS portfolio, as the IBM case studies indicate. However, it doesn't deal with some of the system-wide emergent properties and structural complexities of the large enterprise, into which my own component-based business approach was an early venture.

For more on the component-based business, see my Architecture blog.

Web Services Dashboard

IBM is currently launching web service management tools into the WebSphere/Tivoli space, including a web services dashboard. This now appears as two slightly different products: IBM Web Services Navigator and IBM Tivoli Monitoring for Web Services.

• IBM page
• CBDI Commentary (21st October 2004)

The web services dashboard is designed to support the "Services Architect". This is a new role, acting as broker between development and operations. IBM estimates that 70% of services architects will have a development background and 30% will have an operations background. 

The web services dashboard displays the interaction patterns of web services, and these can be tracked against predefined profiles. A service profile is a recognised pattern of service interactions (an orchestration scenario). A service profile distribution is a statistical pattern indicating the occurrence of service profiles. (For example, this might allow the system to generate an alert if a given exception condition is executed for more than x% of cases. More generally, it supports Statistical Process Control.) Deviation from accepted service profiles or profile distributions may generate an alert, demanding someone's attention. Alternatively, the alert may be passed as a signal to the web service platform, where it triggers some autonomic response. 

A major issue for any tool of this kind is scalability. A screenful of information may be good enough for a small demonstration, but how does the tool cope with larger and more complex situations, when the information would spill over many screens? 

This is precisely why you need an architect, who can break the information down into manageable chunks. In a separate post on Web Service Management, I discuss the role of the service architect, and the web services management process.