Recently I have been spending quite a bit of time with IBM people and our customers explaining what OSLC is and why it is important.  Like everything else in my life, if I have to explain it more than twice, it becomes a blog posting.  Now please be patient, this post gets a bit long but I am trying to explain the concept, and why it is important, to a non-technical and semi-technical audience.

OSLC is the Open Services for Lifecycle Collaboration group.  In practice, people use it as a generic term for all of the things that conform to the various OSLC defined standards for software development tools.  The general idea here is to have a set of “rules” (or standards) for how software development tools present and share their information with other tools, and with the world at large.  A well defined standard will allow vendors and customers to focus on the capabilities of the tools, and not so much on the how the tools will communicate and integrate with each other.  This forms the foundation for the Collaborative Lifecycle Management that IBM likes to talk about, with all aspects of software development sharing data to help streamline and automate processes.  Perhaps an example would help clarify this.

Let’s pretend that email functionality is something that software developers consider a tool, and that it has an OSLC interface defined for it (we all know that in reality the email standard is something different, and is not OSLC).  Now there are multiple vendors out there that provide this email service for users.  There is gmail, hotmail, yahoo mail, and others.  Since each of these supports the OSLC interface for email in our pretend example, they are all considered as OSLC Providers.  This means that each of these is considered a “web service” that is providing a capability for it’s users.  Still with me?  These all have web based interfaces for their service, which communicate via the OSLC interfaces.  Since these web pages use the “service” that is provided, and give users a way to communicate with the underlying email service, these web pages are considered OSLC Consumers.  The iPhone and iTouch both have a generic email app that communicates with all of these services, but there are other email client applications available for these devices as well.  So this is the basis for my example which will show how OSLC helps enable innovation, and makes life better for software geeks, their managers, and consumers.

I have a great idea for a new service called “Vox mail”.  (Disclaimer: This probably already exists somewhere, somebody has probably already implemented it, and I have no plans to market this idea, so put down the sharp objects and call off the copyright lawyers.)  The idea is that from my iPhone I can speak and leave a brief voice memo, have it encoded into an mp3 format, and have this mp3 attached to an email which I can then send to one or more of my email contacts.  This new idea uses an existing technology (our OSLC enabled email service), but adds a bit of new functionality to it.  My iPhone app to do this provides the voice recording capability as well as the capability to attach the mp3 file to an email.  It will also automatically play mp3 files attached to emails that I look at with my iPhone.  This iPhone app can thus use ANY of our OSLC Producers (gmail, hotmail, yahoo mail, etc.), and is considered an OSLC Consumer.

My wonderful idea gets me a number of customers, and some competition.  People using Android smartphones also want to have this capability.  So someone else creates an Android application that does the same thing, which is another OSLC Consumer product that can utilize the services of ANY of our OSLC Providers.  These are examples of how an OSLC consumer application can provide innovation, capability, and potential revenue.

At this point my OSLC Providers are getting a bit weary of being used as a platform for this wonderful new idea.  They would like to be able to offer related services of their own that provide value.  The first step is easy, they provide some metrics about the size, frequency, and usage of the Vox mail capability by their users (think Google).  This can be done by each in it’s own way, and it provides some transparency and visibility into how the underlying OSLC service is being used.  This can be used for billing purposes, for monitoring productivity, and to actually help measure the impact that Vox mail may be having on productivity.

The next step is an example of how a vendor can leverage it’s OSLC provider capabilities to help innovate and improve capabilities and potential revenue for the OSLC provider.  One of our OSLC providers looks at their collected data, and is able to determine that a majority of the usage is between Asia and North America.  A little bit of further study leads them to believe that Vox mail has helped improve collaboration and communication between people working together in Asia and North America.  It is easier for non-English speaking users to learn how to speak English, than it is for them to write in English.  Vox mail provides them a vehicle to communicate their ideas more effectively to their North American (and English speaking) counterparts.

So our OSLC Provider uses speech recognition technologies available to them to provide transcripts of the Vox mail that is being sent using their services.  As they recognize Vox mail messages, they then write a transcript of the mp3 recording into the body of the email message.  Now customers with limited connectivity can see the text of the messages being left for them (for a nominal fee).  This new capability is provided as a new OSLC service, a part of the overall email service.  Since this is interfacing with OSLC consumers in a standard manner, this innovation is immediately available to ALL OSLC consumer applications using their email service, even the ones that they don’t know about.  No more integrating with multiple different vendors.  Users of Vox mail love this new capability, and begin to migrate to the new OSLC provider product, while still seeing the same interface on their mobile devices (since they have not changed their OSLC consumer application, they are just pointing at a different OSLC provider now).  This provides their customers with increased capability and efficiency, and provides a potential source of revenue for them.

Finally we have a second OSLC Provider, but this provider does not provide an email service, they provide an archival storage service.  All of those mp3 attachments are causing people to hit the storage limits with their email services quite quickly.  So our second OSLC provider provides the ability to copy those mp3 files from the email provider, to their more cost effective storage areas.  It then uses OSLC services to modfy the emails, removing the mp3 files and replacing them with hyperlinks to their new home in the archival system.  We now have a vendor providing an innovative solution to an unanticipated problem, leveraging existing technologies, and setting up an integration to ANY OSLC compliant email provider.

So you have read through this entire scenario, and hopefully you have been able to understand things thus far.  What does it all mean, and what have you learned about OSLC?

  • OSLC stands for Open Services for Lifecycle Collaboration.  It represents a set of standards for how software development tools provide their services and data to the outside world.
  • There are OSLC Providers, which are the “web services” that provide the software development tool functionality, capability, and data.  They are providing the “plumbing” that you don’t directly see, but make use of.
  • There are OSLC Consumers, which provide an interface for users to the web services made available by OSLC providers, and may provide additional functionality for end users.  OSLC Consumers will consume the web services provided by the OSLC Providers.
  • OSLC helps decouple the data and basic operations provided by OSLC providers, from the “look and feel” and user presentation concerns of the OSLC consumers.
  • By providing a standard interface for various different tools, OSLC provides a way for various different tools to interface and integrate their data without worry about vendor specific implementations.  In our example, with a standard “email” OSLC interface, you could easily link email from one OSLC Provider to a second OSLC provider service that provides archival services for long term storage.  No more “mailbox limit has been reached” messages!
  • OSLC represents a new thought process on how software development tool capabilities are provided to development teams.  It removes complexity of multiple tool integrations, and frees data to be used by ALL tools without having to replicate data.  Related data is linked to (like our archival example above), and lives in only one place.

Are you a more technical reader that wants to know more about OSLC?  Here are some more technical sources of information that will get you started:

Advertisements