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…….

Advertisements