cancel
Showing results for 
Search instead for 
Did you mean: 
PFugereCSO
OneStream Employee
OneStream Employee

So, the answer is ‘yes’.  If you want to know more, keep reading.  First start by making sure you back up your databases unless you are on the cloud.  This is important.    The cost of not backing up your development instance would be losing all the project work to date.  While good consultants will make occasional extracts, I would not take that risk.

If you have a system and do not have separate environment, you are just about asking for a crisis.  Every mission critical application, which OneStream is, needs to have some controlled environment to manage changes that need to be made to the system.  You need to test changes before you make them.  Change control is the formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner.  A good process makes you think what changes you want to make, and how you can ensure they are done right.

OneStream should not just have multiple applications, but it should always have multiple environments. At a minimum, there should be two; a development/test and production environment.  Each should have their own separate hardware.  If possible, you should break the development and test into two, so there would be three (3) environments (development, test and production) with the test and production having identical hardware and software configurations. Any patches for any software could be tested thoroughly in the test environment before it is applied to production.  Change control manages the migration of changes from one of these environments to another.

Again, all of this is important unless you are in the cloud.  When you are in the cloud you have many servers supporting you.  One box failing will not even be something you notice.  In more sophisticated environments you might want to consider multiple instances though.  And while you might want similar hardware for a physical install, you can have a scaled back develop/testing instance in the cloud with much less risk.

This is a GREAT reason to consider being in the cloud.  When people are working through the costs, are they really considering what additional hardware they will need to support the two environments?  Or if they think, ‘Well, I’ll have a big one and a simple small one…’  That might be ok, if you accept it is completely possible in a physical installation a single software change could pass the small environment and cause a failure in the larger one.  That could be cause of configuration, or just data volumes.  For extra cost, being in cloud reduces this risk.

One question everyone asks is, ‘what are things we should test, and what are the things we should let users do directly?’  I answer that, by making the distinction of what application changes could make the system not functional for the whole set of users as opposed to the getting an error on the specific tasks.  In other words, if I get an error writing a bad report, then only I will get an error when I try to use that report.  If I write a bad rule, I can prevent all users from running any calculation or consolidation.  Both could be bad, but a bad rule.

2 Comments