<homer>Mmmmm …. garlic mashed portals … </homer>
I received a question from a client about whether mashups are the same thing as portals. I’ve heard other analyst firms say mashups are the next version of portals too, so I wanted to clear up some confusion. They certainly have some aspects in common and are branches from the same conceptual tree, but they are not exactly the same.
Here is where they are related: they are both methods for building composite applications. Composite applications are apps made up of existing parts. Portals let you create composite applications using a screen real-estate metaphor by marrying a set of back-end integration and front-end delivery capabilities that provide information in context, personalized to a user’s role and needs. Other ways to build composite apps include business process management (a flow chart metaphor) and SOA development tools (a wiring diagram metaphor).
Here is where they differ: enterprise portals are defined by a set of infrastructure that is used to deliver contextual websites. Mashups don’t rely on that concept of personalization (although I’m sure you could put it in there, but it’s not core to the idea), and they don’t have the set of integration into enterprise applications. Another difference is that mashups can overlay information where portals isolate different information in their own square boxes. The mashups I find most exciting are those where the components are mashed up in the same window, like with Zillow or other apps that lay out information on a map. There are mashups that don’t rely on blending information from multiple sources in the same window, but those just seem to have the portal UI without the portal infrastructure so they don’t thrill me as much.
All these methods for building composite applications can be useful. But I’d never tell a client that has gotten into mashups that now they don’t need a portal product. What if they want to provide personalized access with common infrastructure to get at multiple enterprise applications? I don’t see a product I’d call a mashup tool doing that anytime soon. And I wouldn’t tell a client that has a portal product that it can handle all their mashup needs. A portal product isn’t going to help you lay out your sales data onto a map.
As readers may be aware, I’m not enchanted with the current fad of throwing “2.0″ at the end of every term. It just seems too easy as a platform for structuring a conversation about how something has changed, what was in 1.0, what will be in 3.0, how you’re a Luddite if you’re not with us on 2.0, etc. Someone asked about Search 2.0 the other day and, while I hadn’t heard that term before, I have no doubt I’d find a bunch of people talking about it if I Googled it.
But then another thought occurred to me … Craig Roth 2.0. I Googled “You 2.0″ and got tons of responses (29,000 to be exact). Many are related to the Time magazine cover or other ways of referring to whether you are using Web 2.0. Some are those emailed jokes about “husband 2.0″ and such. But I also saw sincere personal entries about people reinventing or versioning themselves. Treating oneself as a product to be versioned has its illuminating appeal.
Versioning oneself is nothing new. If I was a film maker, I’d probably be thinking in terms of sequels (Craig II: The Empire Strikes Back …). If I was an author I’d think in terms of chapters of my saga. But content-related versioning seems to refer to measuring the progress of your story rather than the progress of you. I like the way software versioning doesn’t inject the story as a refraction point and how it accounts for major and minor releases, which is a better analogy for life (and, as I argue, for the Web as well – who says we just hit 2.0000?).
Simplistic numbering schemes abound: 1.0 for childhood, 2.0 for college, 3.0 for workplace, etc. Or just age – when I was halfway through my 25th year I was CR25.5. These lack explanatory power, however, and sidestep the burden of value judgement that “.0″ places on one to indicate that a significant and discrete set of improvements has taken place. What’s the point of the exercise without this judgement?
Maybe I was 1.0 as a self-employed software developer, 2.0 as corporate code jockey, 3.0 as manager, 4.0 as analyst? If my identity is anchored to my profession, that makes sense. Or maybe I’m 1.0 as a child, 2.0 in college, 3.0 living on my own, and 4.0 married? This better reflects the stages of life.
Looking back at what stages I’ve been through and judging retroactively which changes turned out to just be a point release (like going from 3.0 to 3.1 or 3.01) and how I knew when there had been a major versioning is interesting. But what’s more enlightening is looking forward – asking myself the same questions I’d ask a software vendor about the next version of their product (tongue planted firmly in cheek):
- Is your next release going to be a major (“.0″) version or just a minor enhancement?
- What features can I expect in the next release?
- There have been some complaints with the current version (performance problems, unexpected behavior, poor jazz piano improvisation, etc.). Are those issues going to be addressed in the next release?
- When is the next release expected?
- Do you have a beta of the next version that I can see before it’s released to the public?
- Will there be any migration difficulties and support for people using the current version?
- How do I submit change requests for the next version?
Of course, who is to say versioning myself means I have to act like a product manager? It tends to happen on its own whether you notice it or not. To paraphrase an old saying: “versioning happens”.
And maybe I shouldn’t make the assumption that the numbers have to keep increasing. The software industry needs to keep upping the version numbers the way Pepsi needs to keep coming out with new flavors. But as people, is it OK to get to, say, version 6.24 and then just stay there? There are a lot of customers who continue to use very old versions of software because it works just fine and they see no reason to change for the sake of change. There’s something reassuring about a piece of software that really was built so well in the first place that it can be used for years without support and just do its job. And something just as reassuring about a person that has reached not a pinnacle, but a comfortable place that offers them all they want and remains a consistent rock to those around them.
Well, I’m not contemplating a major version change at the moment. But minor ones are in the works. And hey, versioning happens.
I’ve just completed a chunk of travel and am diving back into my report on business cases. It was democratically determined by my team that I’ll be focusing on business cases for collaboration (not really in the generic sense, but any number of technologies, projects, or organizational changes related to collaboration that involve technology) rather than KM. That’s fine with me – just as I don’t mean my report to cover collaboration generically, I never meant it to cover KM generically either. My findings will be quite applicable to other discplines that often support KM-type efforts like content management and portal as well.
I thought I’d post up the working set of headings that I recommend could be in a business case for collaboration. I say “could” because this is a laundry list of what could go into the case, but it would probably obscure the point to put them all in. The trick is to go for the path of least resistance – pick the sections that best make your argument and that the approver of the business case is most responsive to.
- Scope and methodology
- Relations to other business cases or initiatives (linked or nested business cases)
- Analysis of past and present business environment and trends
- Alignment to business objectives
- Analysis of information worker enablement
- Expected change in information worker productivity
- Competitive analysis (IT spending survey, etc).
- Examples of past use cases
- Examples of future use cases
- Financial analysis:
- Expected change in cash outflow / expenses (discounted over time) with proposal:
- Expected change in cash outflow / expenses (discounted over time) status quo:
- Expected change in cash inflow / revenues (discounted over time) with proposal:
- Expected change in cash inflow / revenues (discounted over time) status quo:
- Financial analysis
- Metrics and criteria for success
I’ll have another section on meta-business case arguments that attempt to rethink the basic business case model at a different spot in the report. If there are any methods you’ve seen work in business cases that aren’t on here, please drop me a comment and let me know.
Ken Camp published an interesting thought piece on “The Personality of Presence” that, among other topics, raises the question “What type of person (interrupt style) benefits most from presence?”. That’s a good and useful question, but I found it interesting that he came to the opposite conclusion I would:
To embrace presence, you must embrace the chaos that is interruption management. If you are not immersed in the flow for a myriad of diverse inputs (interruptions), if your day is based on planning aforethought and structure, presence is not likely a good thing. It removes personal control and places it in the hands of the interrupt.
For those of us who live by interruption and rarely adhere to a strict schedule, the idea of presences adds value, whereas for the structured world, presence is an anathema to order.
So he says interrupt-based workers would like presence more. My first instinct was the opposite.
I think people who are more scheduled and systematic would benefit more from presence because they wouldn’t want interruptions, would like an attention shield inserted into communication channels that tells message senders when they are busy, and they generally embrace rules and order. And the opposite type of people, those who embrace chaos and like to feel part of the flow or like a spider sensing movement anywhere in its web are more able to handle being interrupted and multi-tasking.
His view is not wrong – I think it shows a difference in how presence is viewed. A glance at my Enterprise Attention Management conceptual architecture shows we’re talking about different pieces. From a UC point of view presence is about intelligent routing (“Routing and channel switching” in the Attention Response Engine on the conceptual architecture diagram). From a desktop point of view presence is about attention shielding (“Rules and Scoring”).
The good news for presence is that I think the answer to this question is that both types of people can benefit. People that love being part of the flow of information (or riding the surf of it depending on how much you get) will like the location abilities of presence (time, place, and device on the conceptual architecture) to make sure they don’t miss a minute. People that are most effective when focusing on one task at a time and want to push synchronous attempts to contact them back to asynchronous methods when they can be handled at leisure will like the abilities of presence to block messages, push them to async mechanisms, or politely make others aware they are busy. Everyone wins!
A new study from McKinsey came out that shows the planned adoption of “Web 2.0″ technologies. You can take a look for free here: The McKinsey Quarterly: How businesses are using Web 2.0: A McKinsey Global Survey.
I found it interesting as much for how it chose to structure the survey as the answers themselves.
Definition of Web 2.0: McKinsey’s definition consists of blogs, collective intelligence, mashups, p2p networking (file sharing), podcasts, RSS, social networking, wikis, and web services. Web services? That struck me as an odd component to include as it doesn’t pertain to the two commonly accepted elements of the bundling: participatory web and rich internet applications. It seems collective intelligence and social networking overlap quite a bit as well. But it’s tough to come up with any set of discrete categories for Web 2.0 without hitting some overlap now and then.
Who they talked to: McKinsey surveyed 2,847 executives (44% C-level positions). Those who adhere to the Web 2.0 ”empowering the information worker”, “breaking down the hierarchies”, and “exploit the hidden network” mantras may find it odd to interview executives about what are inherently grass roots technologies. Accordingly, I think the somewhat low adoption figures are a bit distorted by the fact that these executives often aren’t aware of the use of these technologies and place more value in tools tied to the existing hierarchy and status quo than those that turn it around. In a web architecture workshop I led in 1999 I asked where the technical attendees thought they were in adoption and risk of web technologies and then where the executives thought they were and the differences were striking. I similar chart from this survey would have been interesting.
Timeframe: The survey asked about financial return on Web 2.0 investments over the past 5 years. While these technologies did exist 5 years ago, the term Web 2.0 is only about 3 years old, so there are 2 years where they are retroactively anointing investments as being Web 2.0.
So what about the results? Overall, I believe a modest picture emerged of adoption of these technologies.
- They found early adopters to be most satisfied, but I don’t think that translates into a broad recommendation since this is a self-selecting group.
- Mash-ups got mashed – not only did a mere 21% say they were using or planning to use them, but 54% said they were not even under consideration. This is an example of a case where I believe executives don’t see the impact from their point of view. But I believe mashups will seep into their organizations as a form of “composite application lite” whether they even notice or not.
- Most other technologies were being used or planned to use in 30-40% of organizations, but I believe this reflects formal usage (per enterprise standard) or usage the executives know about. I would propose that a more in depth study would uncover significantly higher usage of these technologies under the radar.
- India ranked much higher on Web 2.0 usage, but mostly because of the addition of web services in the package. When you take that out the numbers are similar to North America.
All in all, a good and timely survey and worth reading through. But I think it demonstrates that the disconnect between traditional enterprise hierarchies and tools and grass roots empowerment that is driving a lot of Web 2.0 interest is also reflected in this survey of executives. A fascinating study would be to talk to bottom level employees and architects in the same organization and compare their answers to those of their executives and publish the differences.