Free is just too high a price to pay

Robert Scoble seems to be on a roll at the moment. His commentary on the the Twitter ecosystem are fascinating. Last week he discovered that the Auto-follow had made him dumber. Now he is being more selective and as a result the quality of his feed has risen dramatically. His latest post is about the demise of tr.im from Nambu and the shortcomings of the Twitter platform. It is well worth a read.

The took two things from Scoble's post:

1. The Network Effects keep pulling us back
2. Put your stuff in more than one place.

When Twitter has a bad day, like the Denial Of Service attacks last week, we just wait. Just like how Scoble can't get thousands of his followers to meet him on FriendFeed, each of us is daunted at the prospect of persuading our tens, or hundreds, of followers to move with us to another platform.

Facebook and Twitter probably both recognize this fact. It is not just the followers but how about all the ecosystem components I have connected to my Twitter account. Brightkite, TwitPic, Bit.ly, Delicious. The list goes on. Every application adopted makes a user more "Sticky." The adoption of OAuth by Twitter and Facebook's Connect feature make the respective networks more essential to us.

The need to put our information in more than one place has been driven home to me when Twitter Search "Broke". It is more likely that Twitter deliberately hobbled search in order to manage their resources more cost effectively. We now have access to only a couple of weeks of tweets. This means that the collective thoughts from numerous conferences, camps and meetups have vanished.

This tells us Twitter may have stumbled on yet another business model option. They could choose to charge us for access to that collective hive mind. Would you pay? I would certainly think about - but only if Twitter let me pick up those searches as an RSS feed and republish them freely on my blog, or other sites I use.

The actions of Twitter warn us that "Free" is often too high a price to pay for services from a startup. It may be too high a price to pay from even established companies, like Google.

Free services on the Internet are a wonderful thing. But be wary. You always need an alternative. Put your information in more than one place.

It also means that, if you are serious about your personal brand on the Internet, you need to invest in a domain and look at the tools you depend upon and purchase or use Open Source code on servers in your domain. There are examples of open source URL shorteners.

I think I need to look at my blog here on blogger and how I can reduce my dependence on bit.ly. I may also have to revisit implementing identi.ca (laconi.ca) on my own platform.

  

SocialWeb at Web 2.0 Expo

What has been happening with Data Portability on the Social Web. ie. OpenID, OAuth, etc.

The workshop is being run by @chrismessina, @daveman692 and @jsmarr

I will twitter comments from this session using the tag #w2e_sw

If you want to build new and innovative services you don't want to frustrate your users by asking for a bunch of account related data. If the data is out there go and get it. Don't Re-Key!

You need standards to enable mashups. Alternatively, you need consistent formats.

If standards exist - use them!

http://www.oxyweb.co.uk/blog produced a world map of popular social networks. This struck me as a great parallel to the HealthCare world with incompatible/competing health care players.

Functional sites, like Friendfeed, Twitter, last.fm and Dopplr represent specialist services. They have the opportunity to create combined value but they need a social graph to create this.

Facebook solved this for many, as long as developers were prepared to live inside facebook.

Activity streams are an emerging standard. No logo yet.

XMPP is not that popular yet, although it is one of the pipes that Twitter implemented and search.twitter.com leveraged.

Partuza is an Open Social - social Network site that uses Apache Shindig.

Pinax is a platform for rapidly developing websites using social tools such as IM, chat,

The emerging theme is "Connect"

Facebook Connect, OpenSocial Connect.

New building blocks:

• Who you are
• Who you know
• What's going on

These are aspects of the social ecosystem. These create the virtual circle of sharing/knowing.

The anatomy of "Connect":

• Profile (id, accounts profiles)
• Relationships (friends, followers)
• Content
• Activity
• Goal (search and discovery)

Most sites are building on the Open Stack:

• MySpace
• Yahoo
• Google
• Plaxo
• Microsoft

Supporting:

• OpenID
• XRDS-Simple
• OAuth
• PortableContacts
• OpenSocial

Facebook is different but is matching these standards.

Why do this?:

- Why do people have to:

• Create a new account on every service
• Re-create their profile
• Give away their password to every site that asks
• Re-discover their friends
• re-friend their friends
• Learn new ways to share and communicate

Why do developers have to?:

• Deal with forgotten passwords
• create another profile form
• Support every new service API that emerges
• Force members to invite everyone they know
• Implement and unsafe method to import contacts
• Create widgets for incompatible social networks
• Manually interpret feeds for activity streams

Industry trends:

• User control of data
• User centric web services
• Locatin based services
• Real time content delivery ubiquitous connectivity
• Interoperable app platforms
• content aggregation and syndication
• increasing quantities of data to work with
• democratization of digital media creation tools

How do customers benefit:

MySpace has built login with OpenID and OAuth to compete with Facebook Connect.

OpenID popup extension is being developed to simplify the user interface, ala facebook connect.

The emerging issue is that once an item has been made "public" on a social network it can't be withdrawn. If you withdraw an item it may still exist in other places that were connected to the original publishing location.

Demos:

• Eventbox

Now for the technical stuff:

OpenID Demo:

Mapquest (owned by AOL). You can sign in to mapquest with OpenID.

In 2009 there are over 30,000 sites that let you login with OpenID (Relying sites). Growth from 20,000 in August 2008 and 10,000 in Jan 2008. (source: http://blog.janrain.com)

Implementing OpenID as a relying party (ie. accept OpenID)

Internally you need to map one or more openIDs to an internal account.

The OpenID User experience

Directed Identity is emerging as one solution to avoid need for users to know URLs.

At least there aren't too many major providers so the button option is still feasible.

Once people have become known to a site it is possible to tailor re-sign in based upon where a user has come from. eg. If they arrive from Gmail then assume a gmail account.

Personal Discovery standard is emerging, driven by EU demands.

The browser knows who you are so this may be a way to simplify login. This moves away from web sites trying to guess which accounts you use.

The Popup extension is emerging as a technique. The challenge is to avoid spoofing. People don't look at the URL bar.

Remember - you can use email address as an indicator of which OpenId providers to support.

Different sites have different account preferences. This leads to sites supporting multiple standards. eg. OpenID + facebook. At least supporting OpenId means you automatically support Yahoo, AOL, Google, MySpace and other popular sites.

Microformats are also important.

Microformats enable webpages to be an API.

Semantic information can be embedded in a page. Some of the oldest standards are hCard (vCard in HTML)

Use CSS classes to markup and style the data. Very simple way to markup information in existing web pages.

This is ideal for database driven sites because you can edit one output web page and apply a microformat to every database record that is displayed through that web page.

Twitter supports hCard and includes the rel=me setting. If you want your blog to be the top search result on your name in Google then add this value to your blog. Simply add rel="me" to a relevant link on your blog.

Discovery

The more you publish the more you need a way to identify what you are publishing as yours. Our desktop is moving out in to the cloud.

Identity enables discovery. XRDS-Simple "the name is more complex than the concept"

XRDS - defines services.

eg. OpenID, PortableContacts

eg. OpenID points to one service. PortableContacts points to Plaxo.

WordPress OpenID plugin supports creating XRDS file.

XRDS-Simple can be used for a personal discovery or for sites to publish their service endpoints

LRDD - Link-based Resource Descriptor Discovery (emerging work)

Authorization

Authorization is important so you don't have to make data public to make it portable.

Will OAuth work in a mobile mode? Yes!

iPhone example is FlightTrack Pro works with Tripit. The iPhone app uses OAuth and Safari to authorize the app on Tripit.com.

OAuth is a protocol for developing password-less APIs.

Plaxo was recently bought by Comcast. Comcast saw a 92% success rate with login using OpenID in collaboration with Google.

The Plaxo-Google connection uses a hybrid. They do the OpenID dance and also handle the OAuth token acquisition at the same time. They also collect and notify user on the basic information that will be used. eg. name and email address.

The Comcast-Google test worked so well that the business folks at Comcast wouldn't let them turn the experiment off!

OAuth can be used asynchronously to allow one user to give permission to someone else to gain access to their information. eg. Dave allows Chris to see his phone number in his contact record.

Relationships and Contacts

Rather than have to support writing to address book APIs for each major service they instead implement a standard protocol. That is PortableContacts. This builds on OAuth and vCard standards.

GMail now supports Portable Contacts. ie. No Google specific code is required to use information from the Google Addressbook.

OpenSocial REST People Protocol is now PortableContact compatible.

vCardDav compatibility is coming with IETF.

Linking Accounts

The XFN Microformat is being used to link accounts and services.

Add a Rel=Me link to connect pages on services..

You can also use Rel=Contact to identify friends.

Google's Social Graph API does this in a simple form. A demo is available.

Activity Streams

Activity Streams are in the realm of "LifeStreaming"

Friendfeed support approximately 59 services. Each was hand coded by Friendfeed.

Activity Streams is about creating a protocol that can be leveraged across sites.

Social Discovery. eg. Plaxo Pulse, LinkedIn network updates, Facebook status updates.

Messaging: Twitter, Yammer, Eventbox (desktop app)

Brand/Personal Monitoring: GetSatisfaction's Overheard searching Twitter.

Primitives: Active, Verb, Object

Actor, Verb Object (context)

Build on Standards

Use ATOM for lists. (aka feeds)

Activity Stream is using a derivation of ATOM to share streams.

Activity Streams is targeted to go in to OpenSocial.

Check out http://activitystrea.ms for the latest info.

Gadgets and OpenSocial

Allow applications to be added tomultiple sites. Write a gadget once and allow in to run on multiple sites. Over 700M users acorss multiple sites support OpenSocial from Myspace to Plaxo to Ning oor Orkut etc.

Shindig is an Apache incubator project for gadgets in OpenSocial.

You can also build OpenSocial apps in the Google AppEngine.

This standard simplifies Engineering integratin and allows developers to focus on PRODUCT integration - ie. How to fit in to the target environment. eg. Ning is different from MySpace.

Next Steps - Homework:

1. Markup existing Data

2. Stop leaking passwords

3. Support OpenID and OAuth

These tools are mature enough to enable simple integration across sites and business partners.

Check out theSocialWeb.tv for the latest news in the space.

Enterprise Mashups - A definition

A couple of weeks ago Luis Derechin, CEO of JackBe, was interviewed on FoxNews. He was asked to define what an Enterprise Mashup is.

After the event JackBe ran a little competition for their developer community where they asked for a better definition of an enterprise mashup. The winner being awarded the honorary title of "Mashup CEO".

I submitted the following definition:

"An enterprise mashup is a real-time application that can be built by users or developers using data pulled from public or internal sources that creates new insights and understanding as a result of combining previously unconnected information in new ways.

The Enterprise Mashup Platform enables Just-in-Time development of solutions that reflect the real world reality that we need to use information from a wide variety of source applications in ways that were never dreamt of when the applications were originally designed and implemented.

The Enterprise Mashup platform differs from Consumer Mashup Services in recognizing and working within the security and audit requirements of an organization while enabling public and internal data to be brought together to create valuable and actionable information."

It appears that this definition was one of 6 selected in week 1.

Here is a video version that I uploaded to Screencast:

Enterprise Mashups - Moving from Hype to Reality

This session was given by John Musser of Programmable Web.

What is an Enterprise Mashup?:

1. Lightweight application
2. Developed inside the enterprise
3. Created by IT or business staff
4. Created in days not months
5. Uses a web oriented architecture
6. Often uses internal and external web services
7. Done at the data, logic and/or presentation layer.

Why Mashup?

1. Save money - Workflow mashup. Great lakes loan services. Integrating docusign web services achieved a 75% cost decrease
2. Save time -  Deal tracking and collaboration by Societe Generale. An upgrade took 3 days instead of 3 months
3. Save Effort - CRM mashup - PGP and Dunn and Bradstreet
4. Reduce the IT Backlog

Mashups are familiar

1. Lightweight composite applications
2. Portals and dashboards
3. Enterprise Application Integration
4. Extract, Transform and Load

Mashups are like these - just simpler and faster. Smaller scope means we can implement disposable applications because the time to value is orders of magnitude faster.

External Drivers for Enterprise Mashups

Web 2.0 is coming to the Enterprise with OpenAPIs. Web sites are becoming programmable services. APIs at programmable web are adding 120 APIs in Q1 2008. This is a 150% increase over the previous year.

Mapping is one of the most popular API sets. Enterprise API sector is now in the top 15 categories. Finance segment doubled in 6 months. Telephony, mobile and messaging now have over 50 APIs.

Internal Driver for Enterprise Mashups

• Getting the ROI from SOA.
• Enterprise Mashups already exist. Enterprises call this the Excel spreadsheet with cut and paste.

Mashups depend on a Web Oriented Architecture

1. REST - The way the web works
2. URIs and URLs - How everything is addressed
3. Open Data Formats - lain old XML, RSS, JSON and ATOM

• SOA comes from the middleware legacy and is more structured, static and top-down.
• WOA is more dynamic and simpler and is more application centric.
• Programmable Web maps APIs by type. 68% support REST. 29% support SOAP. REST is also growing much faster.

Data as a Service:  Xignite and StrikeIron 

Infrastructure Services: Webmetrics and Mashery

Professional Services: IBM and CapGemini

App Marketplaces: The AppExchange (Salesforce.com), Serena and Google Solutions Marketplace.

Where will you run your enterprise mashups?

There are a growing array of choices:

• Do it yourself
• Managed Hosting - Opsource
• Cloud Computing - Joyent, Amazon Web Services, Mosso
• Cloud Interactive Development Environments - Force.com, Bungee Connect
• Cloud Application Builders - Coghead

Top 4 Enterprise Mashup Challenges:

Taken  from Dion Hinchcliffe's Top Ten challenges:

1. Immature Marketplace - We are in the early adopter phase
2. SLA for APIs - Lack of SLAs is a barrier
3. Security - Access Rights, Identity, compliance and regulations
4. Data Quality and Trust - trust applies to internal and external data

Mashup advice for IT

1. Beware the hype
2. Make SOA a mashup platform - use open standards an expose services
3. Start simply
4. Think tools - to enable adoption and speed of creation
5. Add governance as needed

Addressing the challenges:

• Amazon and Google are addressing the SLA issue. Premium service offerings provide paid support.
• Vendor software will increasingly offer mashup capabilities in their tools. For example IBM Websphere can incorporate Google Gadgets in to the portal server. Salesforce.com has integrated with Facebook to bring social context to enterprise applications.

There is a lot of activity around scraping tools. This is seen as a stepping stone to allow the API enablement of existing applications. The other strategy is to use database extract tools.

Next Generation SOA

Yesterday, while waiting for a plane I managed to catch the audio portion of Dion Hinchcliffe's Webinar on "The Future of SOA: How Web-Oriented Architecture Makes SOA Work." This was a content packed Webinar. Dion made a couple of really compelling points: 

• Enterprise Architecture can't keep up with the demand for new applications.
• SOA takes too long

Enterprises need something more flexible to service the long tail of enterprise application demand. This is exactly where products like JackBe's Presto come in to play. We are moving to a world where disposable solutions are developed from diverse web parts, mashed together using drag and drop interfaces by end users or semi-technical staff.

Another reason why enterprises need mashup platforms as a supplement to their SOA toolset is that in many traditional industries many of the vendors do not really understand Web Services and SOA. This means that re-purposing partner data can't always be done using web services and SOA constructs. Instead mashup tools that allow web clipping, screen scraping or html/xml page consumption need to be utilized to harness and re-purpose partner data.

This approach leaves the enterprise Architects to focus on the mission critical, high volume interfaces that will underpin the data and services that are critical to an enterprise's success.

The Underwhelming Success of SOA

Sitting at the Gartner Conference I read the ZDNet article on "The best way to sell SOA? Try Web 2.0 techniques."

My comment on that post is reproduced below.

SOA and Web 2.0 - Convergence of the Enterprise Mashup

SOA has been an underwhelming success for many organizations, as the rough numbers demonstrate in my blog post on Portals and Mashups (http://ekive.blogspot.com/2008/03/portals-and-mashups-putting-powr-of-soa.html) from the Gartner Portals and Collaboration Conference. Web 2.0 in the shape of the Enterprise Mashup tool has the potential to transform the success of SOA by allowing end users and technical analysts in the enterprise to self-serve their needs themselves by creating lightweight composite applications that amalgamate disparate information feeds to create new value added information streams. We may need heavyweight back-end services that are at the heart of many SOA initiatives but the increasing trend towards disposable applications says there is a valuable role for Enterprise Mashups that can be created quickly and easily and then jettisoned when no longer necessary.

On Demand meets the Enterprise Portal

Mike Minelli of Compuware Covisint. Rooted in the auotmotive industry Covisint provides hosted portals, messaging and trusted identity frameworks to clients in an on-demand model of business service delivery. At the Gartner Conference they talked about "Leveraging an OnDemand Model to Consolidate Shared Enterprise Portals"

I wonder if this will just be a 30 minute infomercial or will there be something of value?

The evolution of the portal - the phases of growth:

• Information Explosion
• Information Consolidation
• Information Convergence
• Communications Convergence

Gartner's evolution of the portal places the portal in the business integration phase but not yet contributing to Business Transformation. This would seem to indicate that the lessons of Web 2.0 and Enterprise Mashups provides the potential to enable the agile enterprise - built on the infrastructure strengths of the portal.

 

A well designed and implemented portal enables new information feeds and composite applications to be delivered quickly without having to specifically develop functionality for security, personalization and other basic features of a good portal.

Okay - so yes - mainly an infomercial. Still it gave me a chance to catch up on twitter. On that front I am getting to like Quotably a lot. 

Portals and Mashups - Putting the Powr of SOA in our hands

Ray Valdes presented a session on Portals and Mashups at the Gartner conference in Baltimore.

Portals bring the personalization in the presentation of information. Mashups enable information feeds to be filtered and adapted to meet emerging needs.

Heavyweight Portal Deployments bring complexity and this leads to an "Agility Gap." If we are to create agile organizations we need the ability to adapt to business needs quickly.

Portal technology is a massively layered solution requiring extensive skills to support and leverage. However, portals are still an essential tool to enable personalization, manage access and control the delivery of information.

Service Oriented Architecture (SOA) enables composite applications but these are typically heavyweight designs using complex, over-engineered protocols. 

 

Web 2.0 Mashups are lightweight and often use simpler technologies, such as REST. The emerging Enterprise Mashup market, led by tools such as JackBe's Presto offer an opportunity to combine the best of SOA and Web 2.0 and deliver the results via the portal infrastructure.

The challenge is to enable mashups without unleashing anarchy. IT organizations need to apply some governance around the use of SOA to ensure consistent use of feeds that implement codified business processes.

Interestingly in this large audience over 50% are using portals and SOA. More interestingly only about 10% of those feel their SOA initiative has been a success. The usual situation is a long deployment cycle, complex environment and little benefit to be demonstrated until well in to the deployment phase - typically 2 years or more after initiating the project.

Services are autonomous, connected, contracted (typically via WSDL's), loosely coupled, independent, discoverable (via a registry such as Systinet) and built on standards.

Portals bring application modules (portlets), user and system administration, personalization, search, access control and identity management all built on an Application Integration Interface. Think of it this way. Information is delivered through a Portal, Not by a Portal.

The next evolution of portals will be to expose the portal sub-systems as services themselves. In our quest for reusability this is a good thing.

The objective of a portal should be to deliver strategic services at tactical speeds. The basic infrastructure such as access management is delivered by the portal framework.

The next evolution in the use of portals on the Internet needs to address Distributed Identity and Shared Metadata.

Web 2.0 is driving the agenda in SOA with moves in to the Open cloud, lightweight, AJAX enabled, loosely coupled and even embracing community development. 

Enterprises have had Mashups in the Enterprise for many years. It is not a new requirement. It is just that the capability was delivered using Microsoft Excel and manual cut-and-paste. Mashups provide a dramatically enhanced capability with automatic updating and the ability to merge and filter information much more easily and then deliver it wherever the user needs it.

Examples of Web 2.0 mashups included Housing Maps and Tripit. Facebook, while a social network has delivered an application platform and now has the ability to deliver applications anywhere.

A couple of great quotes:

"Organization with warped lines of communication can build systems that are fragile and don't interoperate."

"dysfunctional organizations can get stuck in constant battles with design defects, bugs and performance issues."

As we have learned with the wisdom of crowds the social architecture of the system can be as important as the technical architecture.

What did I take away from Ray's session? Portals are a delivery service. Enterprise Mashups that leverage Web 2.0 approaches and enable self-service development are a critical component in the solutions armoury if we want to build and enable an agile enterprise.

Opportunity and the Enterprise Portal

IBM presented at the Gartner conference. It was probably just an excuse to get more mileage out of "Buzzword Bingo."

IBM did present Lotus Mashups - A drag and drop enterprise mashup tool.

The portal case studies using Websphere came from ADP and Kaiser Permanente.

For ADP the biggest advantage was to present a consistent user interface for customers to multiple back-end systems.

What we have to remember is that a Portal is just a tool. A business still has to decide what services they want to deliver and the user experience they want to create. 

Advice

• Don't just focus on portlets. Look at the infrastructure and resilience from Day one.
• You don't have to have everything has to be deeply integrated on day one.
• Keep the core infrastructure stable but add portlet capability frequently.
• Focus on usability to control support costs. 

Kaiser Permanente

Problems:

• Aging J2EE Application
• Monolithic custom built
• Centrally controlled

It's all about the user:

• Focus on user experience
• Enable self service capability
• Enable innovation at touch points between stakeholders

The platform is a service, built on top of an Enterprise Service Bus. This is a three tier platform: 1) Shared Application Services 2) Core Infrastructure Services 3) Physical platform.

Kaiser's shared components include:

Facilities directory - Spring 08

Medical staff directory - Summer 08

Enterprise Search - Fall 08

Sign-on - Summer 08

Enterprise UI Templates - Fall 08

Portals going beyond Web 2.0 - Really?

David Gootzit talking about the Portal's future and beyond Web 2.0.

What is a portal? Web software that provides relevant access to web assets in a highly personalized fashion to target users and groups.

The portal is dead, long live the portal. It is just the tool to provide personalized views to information. Enterprise Portals are serving as an entry point to mashups such as JackBe's Presto platform.

The "MyPortal" will enter the Enterprise and will be a portal service aggregator.

Portals are being decomposed to extend the life of legacy portal technology.

Users and workers already engage with multiple portals. We adapt to the portal. The portals are meta-stovepipes. They only aggregate data within their own environment.

A portal fabric or portal mesh will emerge through inter-operability efforts. What Gartner is really talking about but not verbalizing is an evolution of OpenSocial. I want to take my profile and background information and contacts between social networks and portals.

Directory, security and Identity management will be critical services provided by and for Portals.

I am thinking that the evolution of widget-capable Wikis represent a potential MyPortal platform. 

Approximately 30% of the audience have MyYahoo and iGoogle pages.

The five touchpoints for portals:

• Portlets
• User profiles
• Directory
• Security
• Metadata

Federated Identity Management is a critical capability and OpenID is an increasingly serious player in this area. I believe this because one lesson from the Internet is "Simple is best."

60% of enterprise portals have been implemented as replacements for Intranets.

Corporate blogs have not been implemented often on internal enterprise sites. More often used in Business to Consumer roles. On the other hand Wikis supplement portals and are not competing against portals. 

 Wiki and blogs benefit the enterprise more than email because the content can be shared and made searchable.

Enterprise Mashups will be integrated by 50% of enterprises by 2011. They will typically be integrated into portals. Enterprise Mashups are open standard, user defined platforms. Typically consumer and enterprise data is merged. For example, a customer list overlaid on a Google map. 

Adobe Flex and Air, Mozilla Prism and Microsoft Silverlight will confuse the landscape by driving the use of rich clients. Up until now the browser-based thin web client has been the predominant delivery method.

At the same time expect portals to de-compose and effectively deliver portal functionality as services.

The portal of the future will:

- Be aggregation friendly

- support end-user mashups

- integrate social networking

- part of the overall enterprise user experience

- extend the life of legacy web applications as portal services extend to non-portal applications.

The last item is probably where the best Return on Investment will be found.

Finally, as you evolve a portal strategy you need to understand the needs of the digital native.

Reflections on Enterprise 2.0

Unfortunately I only had opportunity to attend the first day of the Enterprise 2.0 conference . Despite this it was a valuable trip. Reflecting on the conference these things stuck out for me:

• One thing the organizers got right was plenty of power outlets in the meeting rooms.
• The wireless worked better than at the Web 2.0 Expo, but then there were far fewer people. Probably 1,000 as against 10,000 at the Expo.
• Microsoft doesn't get it, or is biased by its revenue model. How c an you talk about unified communications across multiple devices and then talk seriously about sharepoint and integrated Office Business Applications that use the Office system - that ties me to my desktop
• Institutional IT doesn't get Web 2.0 yet. This was evidenced by the discussion on Mobile platforms and the desire of IT organizations to lock down mobile devices. Developing revenue growth powerin g mobile applications will spread beyond an enterprise boundary. IT will not be able to lock down, or even prescribe all the devices that will connect to data feeds, applications and services. Developing to open standards and interfaces is essential.
• Enterprise Mashups. I was disappointed to miss this session , which is being held on Wednesday June 21st. My thoughts on this area are that we must first get the basics right. Enterprise search (that really works!) is a critical first step. Add syndication capabilities via RSS and you have a solid foundation on which the organization can build emergent processes with minimal IT investment. When you combine Enterprise search with RSS and a Wiki publishing capability you have the essential components to create new knowledge and to be able to springboard new insights from that knowledge.