Many years ago in seemingly a past life, I was part of an IT department working as a MicroStation CAD Specialist. I sat next to a Unix Support Analyst (yes, Unix!) and would often hear his user conversations. Many times he would say, “can you reduplicate the problem?” Part of me wanted to correct him; but the cynic in me let it go because it just sounded hilarious! So in honor of a fond memory, let’s talk about “reduplicating” what I call ProjectWise “Infrastructure Environments” in an on premise ProjectWise implementation.
First, do not confuse an infrastructure environment with an attribute environment; they are completely different. Rather, consider each infrastructure environment as a specific set of servers, services and functions available to a ProjectWise administrative team to use at specific intervals. Depending on your organization (and complexity of your ProjectWise installation), an infrastructure environment can be a set of (duplicated) ProjectWise servers that represent your Integration, Web or iCS for PDF servers. Or the infrastructure environment can simply be a separate ProjectWise datasource. All ProjectWise users will have at least one infrastructure environment: PROD (Production). However, my belief is that every user should have at least two; TEST and PROD. Some larger installations make the case for three and (rarely) four environments. Let’s look at some examples of what each infrastructure environment can represent:
DEV – Used for the development of the system process. Here you begin to lay the groundwork for how ProjectWise server modules interact, review redundancy plans and start to build the framework of your ProjectWise datasource (security, workflows, attribution, data migration, etc.). ProjectWise Administrator training is also delivered using the DEV environment. The DEV environment also comes in handy if you want to upgrade and evaluate a new version of ProjectWise without impacting production.
TEST – Like all Infrastructure Environments, TEST continues where DEV leaves off. Often times this environment is much like a “proof of concept”, where you can run-through the system processes to ensure that server resources and scalability run as expected. This is where you continue to build upon the ProjectWise work processes defined in DEV.
QA – Again, QA will be a continuation of TEST. However, in this stage, you will introduce some combination of an expanded design/engineering user group to functionally test the practices that your ProjectWise team has put in place. QA will also help measure your overall server performance and resources (RAM, server cores and processors, etc.). At this point you should have a datasource(s) that closely resemble what Production will look like, have developed an adequate UAT (User Acceptance Testing) plan to review ProjectWise functionality and have started to review all your training requirements.
PROD – This will be your Production system. In short, UAT has successfully completed, all required documents (CAD drawings, etc.) have been migrated to ProjectWise, documentation and user training is complete and backup and restore procedures are set. You are ready to “go live”.
Your ProjectWise datasource – moreover, your ProjectWise database – starts in DEV and is transferred (exported/imported) to each environment as you move forward in the process. Generally speaking, when you move to QA, you should have at least 90% of your datasource (folder structure, attributes, workflow, security, etc.) in place.
Of course, there will be instances where a certain business process may need to change at any point prior to “go live”; workflow states, folder structure or document attributes are typical examples of this. Depending on the change, you may decide to update the earlier environments (or not). For example, if you catch something in UAT, you may wish to update DEV and reevaluate how that affects the overall process, then move the datasource (database) forward again (DEV to TEST to QA). Once you are ready to move to Production, you might also consider migrating your QA datasource back to DEV and TEST, meaning that upon “go live”, all four datasources are synced.