Why should you care about OSLC?

Been spending this week in Australia talking to our customers and learning all about the “Land down under“.  It has been an interesting few days, and I still have a couple of more days left to go.  I did have one really interesting conversation with a customer that has stuck with me.  It was one of those conversations that you keep thinking about, it sticks in your head and nags you.  You keep replaying it in your mind, wondering why the conversation didn’t quite feel right.  Then it comes to you!!  You realize that you could have burned through the complexity if only you had uttered one sentence, asked that one question.  You spend about 10 minutes thinking about what an idiot you are, and you decide to redeem yourself by writing a blog entry.  That happened to me this week.  This is that blog entry, and it all centered around OSLC.

I had been talking to a customer about the relative merits of the jazz platform, and how some of the core architectural decisions that we made have had some very profound impacts on our Jazz based products.  We spent some time discussing how the use of linked data and REST based objects in our Jazz architecture has made it possible to have a robust and flexible framework for integrating software development tools.  They had an interesting issue that they wanted to explore.

They have a set of homegrown tools for their mainframe development environment, and they are looking at the Jazz CLM solution for their distributed (what they called their mid-range) development teams.  They had a lot of questions about OSLC, and were very interested in how easy or hard it would be to do an OSLC interface to their mainframe SCM systems.  How would they do it?  (Check out the Lyo project for Eclipse)  The reason they were interested is that they wanted to be able to reference change sets from both the mid-range development teams, as well as the mainframe development teams, when they had work items that had work that was required in both domains.

I shared with them some of the concepts behind OSLC, as well offering them some use cases for this kind of work (like using a parent work item with child work items on either side of the mid-range/mainframe divide). Then we talked about flexibility of the Jazz environment, and the balance that you need to strike between having the power to modify and customize systems without limit, and the need to have systems that are easy to maintain and operate.  If that flexibility was without cost in terms of development and maintenance, then everyone would create their own custom software development environments.  We discussed how your development tools need to be good enough that they help speed your development, improve your quality, and enhance you collaboration, without having a high overhead expense associated with keeping them maintained and administered.

They kept coming back to the relative difficulty of producing an OSLC interface for their current mainframe SCM.  Without time to look at what they had in place, it was impossible for me to really tell them anything intelligent.  They seemed to be searching for an answer that I just couldn’t give them.  It was a good conversation, but it felt a bit unfinished.

It wasn’t until I was in the cab on the way back to the hotel that I realized what I had failed to mention.  It didn’t really matter how much effort was required to create an OSLC interface for their mainframe system.  What matters is the relative cost of that interface.  If they wanted to do this on their own, without OSLC, then they would need to create something similar to OSLC.  Which means they would need to do that, AND the effort that they had been asking me about.  What other alternative is there if you want to link your data?  The value of OSLC is that it is already there, already proven, and can be used as a framework enabling communication between different software development tools, without worrying about any vendor specific or proprietary interfaces.

I guess the lesson here is that the REAL value of OSLC isn’t in the bits and bytes, but it is in the concept.  Tools should be able to discover each other other, determine services, and create links and relationships between their artifacts regardless of vendor or technology.  OSLC is the common language that software development tools can use to seamlessly communicate with each other, without brittle and hard to maintain point-to-point integrations.  You can either use what is already there, and has been proven, or take the time and expense of trying to create it yourself.  When you frame it in those terms, the problem seems much less daunting, and the answer seems a bit more obvious.

Now all I have to do is find those guys so I can tell them…….

Differences in Implementing Jazz with WebSphere and Tomcat

In recent weeks I keep on getting requests from customers to answer their questions on the differences between using WebSphere and Tomcat as the web server for their Jazz deployments.  So like always, if I have to answer something more than twice, I try to blog about it.

So what are the differences between Tomcat and WebSphere?  At the most simple level, Tomcat is open source, and WebSphere is an IBM product.  You can Google “WebSphere vs Tomcat”, and see articles that claim that Tomcat is much better, and others that claim that WebSphere is superior.  In what I have seen in practice, and what my customers have told me, WebSphere seems to scale better, and has better support for enterprise types of functionality (like clustering, identity and authentication, and so on).  Some like Tomcat for it’s simplicity, which is pretty nice.  I think that it probably boils down to what your experiences have been, and where your organization has expertise.

From a higher level, IBM is able to sell WebSphere because it has advanced capabilities that the open source alternatives do not have.  WebSphere is easier to administer, and allows you to deploy things in different profiles, which allows you to take down one Jazz application without impacting the other running applications.  Some other Jazz related things that you can do with WebSphere that are difficult (or impossible) with Tomcat:

• Single Sign On solutions are easier to support with WebSphere, and Tomcat does not support a distributed single sign on capability (if you have different web servers for the various Jazz products).
• WebSphere has an Administration UI that greatly simplifies the following operations:
• Installation of applications
• Stopping and starting those applications (on an individual basis)
• The configuration of the JVM properties used by the applications
• The setting up of a reverse proxy
• More flexibility with LDAP security and support, with an ability to map LDAP groups and roles to Jazz application groups
• Ability to more easily use monitoring capabilities to observe web server performance

In addition, some of the newer planned capabilities for the Jazz applications will be initially implemented on WebSphere.  Now I can’t tell you what those capabilities might be, but a quick look at our plans out on Jazz.net should give you some idea of what those might be.