≡ Menu

Don’t Ditch Your Home-Grown PLM

Share the knowledge

Does this situation sound familiar? Your company has an in-house system for doing some portion of what is now part of Teamcenter (or Windchill or Aras or…). The Powers That Be have decreed that Teamcenter will replace the homegrown software. Everyone hates the old system. It old and complicated and ugly. When it was new it was state of the last decade’s art. Everyone, from management to users, wants to know how soon it can be replaced and decommissioned.

Well, I’ve been pondering this question myself lately. I think I have the answer you should give them. I say, tell them that you will never get rid of the old system.

Here’s why — and what I think you should do instead.

Old, Ugly, and Battle Tested

Do you remember Netscape Navigator? Nowadays there are probably more than a couple of you who don’t, but once upon a time it was the internet web browser. And now it’s gone. Writing back in 2000, Joel Spolsky gave an analysis of what had gone wrong:

[Netscape made] the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch…

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive.

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. All those years of programming work.

Joel Spolsky, Things You Should Never Do, Part I

Completely replacing your old, in-house, system with Teamcenter runs the same risks as rewriting your application. That old system does something, right? In order to replace it you’ll have to either eliminate or replace each task it currently performs. And some of those tasks probably don’t map directly to the new software, do they? Don’t get me wrong; I hate hearing, “the new system must look and act just like the old system.” This is the time to rethink your old assumptions and to review your current pain points. But I’m betting that there’s still going to be something that can’t be eliminated or replaced. You’ll have to customize Teamcenter to make it do something that the old system is already doing. And that’s where you can get in trouble.
[box type=”info”]I’m saying Teamcenter in this post, cuz, well, this is a Teamcenter focused blog and that’s what I know. But I think that this could apply to any system you’re moving to — PLM or otherwise. So if that’s the case, just mentally edit what follows to replace Teamcenter with your software of choice.[/box]

Don’t Eliminate, Integrate

What do I propose instead? My proposal is a phased approach using as Service Oriented Architecture (SOA):

  1. Expose legacy data and functionality using SOA
  2. First, provide services so Teamcenter can access the data and functionality of your old system. The services can be web services, CORBA, XMLRPC, or whatever. If you’re familiar with the Model-View-Controller paradigm, you’re providing a controller layer that Teamcenter will use to get to your old system.

  3. Replicate Data
  4. Next, use the services to make data in the old system visible in the new system. At this stage the data is still authored, edited, validated, and stored in the legacy system, which remains the system of record. If you want to push data updates from the old system you may need to add SOA services to Teamcenter that you can use to push the data.

  5. Enable Data Manipulation in Teamcenter
  6. Next, using your services to allow users to author and edit data in Teamcenter that will then be pushed to the legacy system. The legacy system is still the system of record and any data validations are still done there. Teamcenter is basically still operating as an interface layer. Now you can start thinking of having users only use Teamcenter as an interface to the data.

  7. Invoke Data Validations From Teamcenter
  8. This may be the hardest step. You may opt to skip it. By now users are interacting with the data as if it was owned by Teamcenter even though it really lives in the legacy system. The validations happen when the data is entered into the it. Our next goal is to stop storing data in the old system. To do that we need to enable Teamcenter to invoke the validations directly. This requires that the validations themselves be available as a service, which may mean detangling them from the data they validate. Ideally validations are implemented as pure functions, with no dependencies on state nor side effects. Things are often not ideal, however. So some refactoring and redesign may be required.

  9. Stop storing data in the legacy system
  10. If the last step was successful we can stop entering data into both systems. If you missed something, you’ll find out now. Now Teamcenter is the system of record and the legacy system is merely a service that validates data.

Final thoughts

So that’s my idea anyhow — keep the old logic around, but transmorgify it into a service that performs its old functions in service to Teamcenter (or whatever you’re using). That way you don’t have to recreate all those years of accumulated effort from scratch.

I would very much appreciate hearing your thoughts, especially your criticisms and suggestions. I learn as much as anyone from the discussions.

If you like this post, your +1s, likes, tweets, and shares are all appreciated and bring the Dojo one step closer to achieving world domination. (Just kidding, I’ll settle for a continent or two).

  • Teamcenter Heretic

    One of the greatest risks in maintaining legacy systems is that all the programmers will retire or die (some seem dead already but still take up a seat) . Better to move off that old cobol/f77/rpg program now while you have a chance!
    I’ve spent quite a bit of time patching together programs after the original owners left and it ain’t pretty.

    I agree that wholesale replacement may not be prudent, but neither is letting the old beast live past its prime.

    I also agree that putting a new “face” on the old app helps but sometimes you just need to put a stake thru its heart!

    Oh, and you will never get users to accept a COTS system as well as that old loveable beast that they have known and loved for the last 20 years.

    • Dustin Neifer

      Or the infrastructure (e.g. hardware) that the legacy system is running on will retire/die and reliable spare parts can’t be found on craigslist or ebay.

      • Teamcenter Heretic

        I worked on a system last year where parts of it ran on Vax VMS system which was last purchased on eBay.These machines are getting harder to find every year.

        BTW, the only reason I was even working on this system is that Siemens is no longer supporting some old HP hardware and there was a complex release system built around UGOpen and the HP OS. The client had no choice when they mover off Nx4 😉 but redo this part of the process.

      • Teamcenter Heretic

        I worked on a system last year where parts of it ran on Vax VMS system which was last purchased on eBay.These machines are getting harder to find every year.

        BTW, the only reason I was even working on this system is that Siemens is no longer supporting some old HP hardware and there was a complex release system built around UGOpen and the HP OS. The client had no choice when they mover off Nx4 😉 but redo this part of the process.

  • Jens Krueger

    Hi Scott, thank you for your article. I think you described one possible approach – but not the only one. Companies might have to deal with additional factors such as obsolescence of the old system, i.e. it simply cannot be supported any longer. They might also run into financial problems of having to maintain two systems in parallel and managing the co-existence of them for a longer period of time. Best regards, Jens

  • Dustin Neifer

    There are times when I wonder if there’s any room left for shredded plastic grass since we’ve put so many eggs in the Teamcenter basket. Vault for multiple MCAD systems, drawing image repository, 3D lightweight visualization, problem reporting, change management, configuration management, process planning, etc.

    • http://plmdojo.com/ Scott Pigman

      I get the feeling that they are so caught up in pushing this years hot new feature (HD PLM!) that’ll appeal to the suits with the money that they neglect doing more that just patching core functionality. “Well, yes, Mr. CEO, we could invest in improving our core data management functionality but LOOK! SHINEY NEW IPAD APP! FETCH!”

      • Teamcenter Heretic

        HD PLM… a solution looking for a problem!
        At least I got a couple of t-shirts at PLM world 😉

Optimization WordPress Plugins & Solutions by W3 EDGE