For example, an archive storage system I worked on was designed specifically for archiving data. This intended use had several manifestations: it was highly optimized for writing and not for reading; and data integrity was paramount, even at the cost of speed or price.
As another example, I worked on an electronic medical record system. It was designed to be very friendly for physician use and to be a "one stop shop" for patient medical data. This intended use meant that physician workflows (ordering prescriptions, for example), could be accomplished faster and withe fewer clicks than insurance workflows (reviewing payment data); we had optimized the system for physician use. The intended use also meant that we had many interfaces to other systems, but almost all of them were other clinical systems (labs, or radiology systems) and not to insurance payment systems.
Now, could you use the system for something outside its intended purpose? Yes, absolutely. To continue the example of the medical record system, it's entirely possible to deploy it in a medical billing office. It'll just be harder to use.
And that's today's lesson:
Work with your system, not against it.
Yes, it's frequently possible to use the system in ways the creators didn't intend. Most of the time it'll even mostly work. But it will be harder than it should be. You'll run across non-intuitive workflows. Performance will be a slower. You'll find odd bugs in things that most users will never see but that are important to your workflow. You'll get frustrated.
So before you go making a system do things that the creators didn't mean for it to do, try finding something that actually is intended to do what you want. If you can work with the system, you'll have a much easier time.