About The Project

RoviSys is a system integrator offering information and automation solutions to multiple vertical markets. Because the organization started with a heavy control systems focus, the rapidly growing software contingent has struggled with its host of growing pains.

My Role

While having input on all issues "Software Congress" tackled, I was responsible for various initiatives over the lifespan of this project, including source control, reuse, and implementing agile software methodologies.

The Challenge

After years of extremely fast growth, RoviSys needed to look internally and implement processes and standards to sustain and better manage its sizeable software development operations. Growing from a small business where everyone knew everyone and a “wild west” anything goes attitude into a large organization presents numerous challenges when studying, recommending, and implementing strategies to keep a small business feel while streamlining development operations. Some of the challenges faced were:

  • duplicate source control systems
  • out of date support systems
  • rogue development servers and services
  • lack of defined processes
  • lack of standards before releases of new tools
  • inflexible project methodologies
  • lack of training
  • senior employees resistant to change

Any work we did to consolidate and update systems and standards had to be flexible enough and work for the entire organization – after all, we were attempting to reduce and simplify our overhead.

The Process

Background & Content Analysis

Before making and implementing any recommendations, we first needed to understand what exists within the organization. We analyzed notes of previous efforts that were established to accomplish many of our same goals to understand their processes and progress. We took inventory of existing systems, tracking down rogue servers hosting services that no one claimed ownership of, talking to senior developers who remember various legacy systems storage locations. Once we had a comprehensive list of existing services, we then analyzed the content that they served – source code, reuse items, build servers, backup information, and archived training material, to name a few. Having all of this information allowed the team to gain a holistic lay of the land, which we could then use to plan our next steps.


Because technologies and organizations both evolve, the research phase of this project is an ongoing process. We’re constantly keeping abreast of new and emerging methods and tools used to support development operations. Initial research centered on gathering relevant information around our already existing services and platforms. We needed to know if there was any feature overlap, how we could effectively integrate these tools into our day-to-day processes, and if they could support our business needs. We also needed to understand if the existing tools were still supported, actively developed, scalable, and cost effective. We consumed whitepapers, case studies, blog posts, product forums, and reached out to others in the industry to understand how these tools and platforms were used.

Design & Testing

Once we became aware of our infrastructure and how we were using it, we could start planning where we wanted to go. We learned that each service was hosted on its own machine, creating a nightmare for IT to manage. Our first order of business was to consolidate physical servers, allowing IT to effectively backup, maintain, and manage our server. This also created a ‘one-stop-shop’ for developers, no longer needed to remember various host names or their nomenclature.

Our first order of business was consolidating our versioning and source control providers. We were maintaining six different providers, on four different servers, some of which were offsite: Vault, Visual Source Safe, SVN, GitHub, and Team Foundation Server (TFS) (both with TFSVC and git). It’s a wonder anyone could remember on which system a particular module of code was stored.

We took the pulse of the organization using a survey and found that developers were moving away from SVN and towards git.

The Solution

Before we started any technical work, we created the necessary standards and documentation detailing who owned the new source control system, what the processes were to maintain it, and how users were to interact with it. We formulated a plan to migrate code from Vault and Visual Source Safe into TFS (using the git as the source control provider), but first we performed a trial run of a few code bases to make sure users could still access their code and were satisfied with the new tools. Once users were satisfied with their code bases and new tools and processes in interacting with TFS & git, we performed the migration in full. This allowed us to decommission our servers, going from four managed assets to one.


This source control system case study was only our first order of business. We’ve since tackled code reuse, training, and introducing agile software development methodologies into the organization using many of the same principles described above. We’ve been able to reduce our IT managed assets, create a happier and more effective workforce, and we’ve given developers actual named resources to contact when they need something taken care of that relates to development operations. These intangible successes have reduced costs to the business in terms of employee turnover, reuse of existing work, and more efficient employees.