I'll be following the Microsoft OneDrive conversation closely as it may yield some potential answers, but I wanted to ask a parallel question here without muddying the waters there.
DOTs will typically provide localization via custom workspaces with cells, levels, linetypes, etc., and those resources will typically be placed on the C. I'm based in Atlanta and have (thus far) set up GDOT and NCDOT to coexist (largely harmoniously) on my machine. But we do share work frequently across offices, states, etc., and I'm wondering if anyone's had experience with successfully locating DOT workspaces in a shared environment (read cloud here rather than a local network). The explicit advantage would be the maintenance of a single instance per jurisdiction (keeping current and complete one workspace for Georgia, one for Florida, etc.) and the explicit disadvantage being that the instructions for localization (if these first two are any indication of the norm) are plainly intended to be entirely contained within and exercised from a local drive.
The thought of having to instantiate a new workspace (and its attendant linkages to GEOPAK or InRoads or whatever until we're all sufficiently open-roaded to smile and sing together) each time I add a state (actually, this I don't mind so much, but the thought of everyone - and inevitably some for whom it'll be uphill and intimidating - having to do it every time) isn't particularly comforting, and that process is just particular enough not to be well served by global/remote IT support.
So, now that we've rambled a bit: can custom workspaces be resourced from non-local drives (step 1) and can multiple custom workspaces be organized on a non-local drive such that I could potentially pull up a Texas or Wyoming or Iowa DOT launch and be ready to go from the drop?
My guess is that there's an actual technical barrier to doing so, but my hope is that it's virtually impossible (and thus, by definition, possible if only remotely so) and that someone might have made a bit of progress in this direction already. We can't be the only ones for whom this would offer a huge benefit.
Thanks in advance, and happy Wednesday.
Michael Schultz
Kennesaw, Georgia
I should clarify that I'm not ignoring the request to post specific release/version numbers, etc, precisely because this will deal with multiples according to jurisdictional preferences. I pretty well have to assume that if we were to implement successfully, we'd have at least two generations (probably more) of each product in play to align with the various workspaces and stated requirements. If I simply take my first two, GDOT won't offer technical support beyond V8i SS2 (with InRoads) while NCDOT requires V8i SS4 (with GEOPAK).
We don't do cloud but keep various client (most DOTs) workspaces on our local servers and replicate those workspaces to different offices that work on projects together. Our needs are that a user be able to switch between projects from different DOTs without doing anything on their local computer to switch projects. Additionally we should be able to sync the workspace between offices without needing to re-write any config and still have the user use the version from their local server.
One issue you'll run into if you have projects that last for awhile is that this: "The explicit advantage would be the maintenance of a single instance per jurisdiction" becomes impossible. Projects with a multi-year lifespan will refuse to upgrade to a DOT's newer workspace unless absolutely forced to by the client. Everybody becomes afraid of upgrading a workspace as is because they may screw up other projects using the same workspace.
With CONNECT we plan on moving to a scenario where the entire workspace for the client is part of each individual project. This kind of sucks for disk space (although that really isn't an issue for us anymore) and each project is in control of their entire workspace. Templates will let them setup a new project with the correct, latest version, of an client's workspace, while existing projects can upgrade or not as necessary and not worry about affecting other projects.
Honestly, if you are already planning on redoing a workspace in order to share work across offices I would recommend using ProjectWise with Managed Workspaces. It's a bit to learn but I think overall the effort is worth it.
Kevin,
Thanks for your thoughts, and I'll take a closer look at that last recommendation. You're right about the single instance needing a key qualifier. Locally, Georgia probably updates 5 or 6 times a year. I can still (potentially) account for each iteration once rather than multiplying out to Phoenix, Denver, Nashville, etc., but you're absolutely correct that it couldn't be a single entry per state.
ProjectWise with Managed Workspaces tutorials have shot up to the top of the to do list once the week's work is sorted out. Here's hoping the bright light's not a train.
Best,
Michael
Michael,
I'll second Kevin's recommendation for ProjectWise's Managed Workspaces. We've been using them for about 8 years now. They provide the ability to centralize the workspace for multiple users/offices. If there's a downside, it would be that many of these workspaces and custom apps. were not created with PW in mind. This can mean some trial and error when it comes to workspace set up. There are also separate levels of workspaces so if you want to have a base set of standards that will never change, but give people the ability to add on/override/update standards, you can. I've noticed some DOT's are starting to host projects on their own ProjectWise servers giving them control over the workspace.
Tom F