I was talking with Stephen Hunt a few days ago about RTC Extensions. Stephen’s the manager of the Integration Engineering Team (IET) at IBM Rational. It turns out that he’s got a cost-effective way of developing RTC Extensions: Let someone else do it.
I pointed out in Extending RTC – First Look that it’s hard to learn to write extensions. There’s a big learning curve, you need to know Eclipse plug-in development and Java, and the API is not fully documented or supported. Information about extensions is spread out across a lot of web pages (though the new RTC Extensions Landing Page helps a lot with that). The unofficial parts of the API can (and sometimes does) change between major releases, potentially breaking custom extensions. Eventually this will stabilize, but for now creating and supporting RTC Extensions is not for the faint-of-heart.
Am I discouraging you from writing extensions? No! For one thing, it’s fun (but I’m weird). For another, every business is different and development organizations have particular business processes they need to enforce for legal or competitive reasons. RTC has a lot of flexibility and customizations built into it, but it’s impossible to accommodate everyone in every situation. So it’s inevitable that as your organization depends more on RTC (or any software for that matter), the way you need to use it will become more sophisticated and complex. That’s good – it shows maturity in your process and adoption.
But it begs the question: When should I start to write RTC extensions? When should I take a bite of the learning curve, and when should I take on the burden of supporting plug-ins that use a changing API?
That’s where Stephen’s IET group comes in. They’re the “someone else” who can create the extension (IET also builds integrations between 3rd party products and RTC). They already have a library of extensions that might have something that serves your needs. And for a maintenance fee, they’ll support and upgrade the extensions as the API changes. They already have the expertise and personnel to get the job done quickly. I was surprised to learn that they usually knock out an extension in less then a week!
You may find just what you need in their library. You may find it’s cost effective to have IET write extensions for you. And you’ll be able to use IET to make the learning curve more gentle as you come up to speed with building extensions in-house. It can be tough to learn new technologies while you’re laboring under a deadline to build something based on an API that’s not fully documented and that may have changes in the next release. It can get expensive to test your extensions under new releases of RTC, then potentially fix broken API calls.
If you’re building your in-house RTC extensions capability, you may want to use IET to produce what you need now, so you have the space to digest all there is to learn about extensions without impacting your deadlines. If you need extensions now or in the not-too-distant future and you haven’t already developed that capability, you may want to look at IES as a cost-effective way to develop and support your customized extensions.
The best way to contact IES is to ask your IBM Rational account manager about it. You can contact Stephen Hunt directly.
Whether or not you use IES, it’s still better to leverage someone else’s work whenever possible. This is a good development practice anyway, but too often we forget about it. We assume we’re unique when in fact we’re solving a problem that’s similar to one that’s already been solved.
In the long term, we’re planning to set up a place to download sample extensions that will go a long way to enable aspiring extensions developers and solve common problems. In the meantime, keep an eye out on Jazz.net for the Extensions Landing Page coming soon. There will be some links to sample extensions you can start to make use of.