Whenever I've started work on a new project I've had an introduction along these lines:
Wizard feeds into Pluto, which then re-values. It broadcasts changes that are picked up by Puma and recorded by Halo.
but what they really mean is something like:
The Market-data System feeds into the Trade Calculation Engine, which then re-values. It broadcasts changes that are picked up by the Trade Display GUI and recorded by the Audit system.
The IT industry seems to have a peculiar habit of giving projects names that have no relation to what they actually do. Perhaps we feel the need to make a dull system sound more interesting ("We can make the accounts receivable project exciting by calling it Skydive") and this is fine if you have only one system. I deal with architectures that have dozens of subsystems and this can be a real problem by adding to the learning curve and confusing newcomers.
There is an argument that a system's name shouldn't have meaning as the scope of the system will probably grow and change throughout its life. If a project has a very specific name such as "stock-option pricer" it will be inaccurate once you add the ability to price bond-options. A few years down the line it could actually be much confusing than calling it Pluto.
It would be nice if you could change the name of a project/system but this can be very hard. Not because you can't re-factor code and change configuration but because of funding, politics and the users familiarity.
What is your preferred technique for naming projects and systems? Something funky, something meaningful or a compromise? If you are attending the user group meeting this Tuesday you can share your craziest project name with me!
Update - It's been suggested to me that in a SOA system you should name a service very exactly and when the name no longer matches then it's probably time to introduce a new service. Neat!