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.

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.

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

   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.

2. Replicate Data

   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.

3. Enable Data Manipulation in Teamcenter

   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.

4. Invoke Data Validations From Teamcenter

   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.

5. Stop storing data in the legacy system

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

The post Don’t Ditch Your Home-Grown PLM appeared first on The PLM Dojo.