This product was created out of need. A client was recently acquired by a company that had never heard of the Pick/MultiValue DBMS (MVDBMS). Like most companies, the parent company uses relational DBMS products. Their request from their new acquisition was simple – they wanted data from the MVDBMS to aggregate into their corporate accounting. With such a simple request comes an implied set of expectations:
- They don’t want to hear about a different data model or details about issues, they just want results.
- They don’t want to hear that providing them reports is going to cost thousands of dollars.
- The more they hear about disparities, the more they will start to question the acquired IT department:
- They’ll start Googling for information.
- They’ll try to determine how popular the platform is.
- They’ll want to know how easy it is to find people who can provide what they need.
- They’ll start thinking about migrating the new assets to their own familiar platforms.
After looking at alternatives we decided to create something new.
The goals included versatility to deliver data at different time intervals. Transactional data requires triggers. Less time-sensitive data can be sent out every hour or so. Summary and historical data can be sent out overnight.
One challenge was to write new code that satisfied requirements, within a reasonable time frame. That meant avoiding too many fancy features, and keeping the solution small but effective, performant, and stable. At some point we realized that this was a common scenario, so we shifted from project mode to developing a general-purpose product – while remaining within these other constraints.
For a product, a primary goal was to be able to offer the software at a low cost compared to other offerings. In this regard we needed to consider features and value. More features meant more value and thus a higher cost. Not only would that increase development and support time but it would put the product out of reach of smaller businesses that just need basic functionality. The decision was made to focus on making this good at what it does, without trying to do everything.
That’s how PREMEUS evolved, and why it’s not intended to compete with more complex products in our industry. This is why PREMEUS does not include a report generator, GUI designer, or a complex developer API. We don’t think our audience will mind.