Most Read This Week
Cloud Development Using SCM 12.5
Saving money on activities related to software development and transforming state government with more status accounting
By: Al Soucy
Dec. 21, 2013 12:00 PM
Recently, I was asked by Mr. Peter Hastings (NH DoIT Commissioner) to take a look at cloud development concepts and see if there was any benefit for our development teams across the enterprise. After some investigation I could see that if all users/developers were on one server that contained all the licenses for the tool and the assets were centralized, and the SCM tool was standardized, the state could save money in various ways on activities related to software development and transform state government with more status accounting and visibility into software development not only for state developers but contractors as well.
I met with Commissioner Hastings and explained that developers would have less of a learning curve from department to department if the tool was standardized. The only thing the developer would have to learn is the application to develop code. The tool would already be known because SCM supports all the development platforms used at the state today. The state develops in Java, multiple versions of Visual Studio, COBOL for legacy applications, multiple versions of PowerBuilder, Visual Basic, etc. The list goes on with every agency that gets implemented in the enterprise as there are new tools I was unaware of and new ways of using SCM integrated with them.
After meeting with Commissioner Hastings I was directed to place all existing servers and developers in the virtual environment on one server and on one standard tool across the enterprise to centralize the State source data assets.
I met with Richard Sliwoski, State Database Manager, and we had a brainstorming session to hammer out a strategic plan for accomplishing this directive. It's one thing to be told what to do and it's another thing completely to actually do it. The current environment has three independent SCM servers. These servers house a number of data assets and users that represent a number of agencies across the enterprise. The idea was to consolidate the three servers into one in the virtual environment. Then the three physical servers could be decommissioned. There is a cost savings to the State with this initiative with fewer SCM servers in technical support and electricity alone and a myriad of other savings I'll speak to later. This initiative would centralize and standardize the users, licenses, assets and support across the enterprise for software development activities.
I requested three virtual servers. Rich and I determined the requirements for the database and application server needs based on what we were using today and planned for an enterprise model. The three servers would be comprised of one SCM production virtual server to replace three physical production servers in use today, a development server for testing and a dedicated virtual server that will eventually house production compiles using a new tool called OpenMake. A number of OpenMake licenses are owned by the State and will be used to ensure the stability of production executables and to standardize compiles across the enterprise. OpenMake supports all platforms used at the State today. Understanding the Open Make tool is planned for a future effort at this time but again it's part of Commissioner Hastings vision of the standardization and centralization SCM initiative (SACI).
As this effort is going to impact more than 200 developers across the enterprise today with more than 300 applications housed across three servers, timing is important. Whenever you upgrade, convert or migrate it has to be timed accordingly with the release cycles of development teams so it doesn't disrupt any production releases. I have worked with all the team leads to make these efforts as seamless as possible. When the entire implementation is complete there may be 300-500 users and 1 terabyte of data assets secured and controlled for the enterprise and managed by a small team.
Once a strategic plan was developed and the virtual servers acquired I moved forward with the conversion/migration part of this initiative from dedicated servers to the virtual environment. During this same time period in addition to the conversion/migration, Computer Associates released SCM 12.5, the latest version of SCM that has a new plug-in for Visual Studio called the Visual Studio Integration Program (VSIP). So Rich Sliwoski and I made the decision to upgrade the product at this time as well. This is the second part of the initiative to upgrade to SCM 12.5. This effort encompasses installation, set-ups, plug-ins, testing of the client, testing of interfaces, testing on various operating systems, etc. It's no small effort but it made sense to create a totally robust environment for development activities.
I pulled together a great test team comprised of professional quality folks from the State. This nine-person team was made up of talented tenacious developers who had one goal in mind: to produce a better product for the state. The test team is as follows: Casey Horner (DES), Colleen Giuda (DRA), Ryan Stevens (DOE), Robert Kelley (DAS), Eric Ferren (DHHS), Terry Laderbush (DHHS), Michael Brennan-White (Treasury), Sanjay Dua (Deloitte) and Chris Taylor (DHHS). I thank all these folks and their managers for allowing them to participate in this effort; they did an incredible job at beating the tool up and making CA a better company and allowing the state to get a better tool. The tool overall integrated better in this release but I'm already assembling another beta test team to push the tool even farther. There are enhancements that developers have already been communicating to me that I want in the next release. I personally would like to see full integration.
To me when the word integration is used I believe it should be seamless. I don't want to perform activities outside the tool once I'm in it. The tools should assist you in creating a better product. That means you don't have to waste time by going somewhere else to accomplish the task at hand. Today you still have to leave the Visual Studio IDE and go to the Workbench to delete a file. That's a waste of time and should be fixed. My hope is that in the next release we come even closer to a fully integrated product. There really should be no need to open the Client if full integration is achieved. In any case I'll have a great test team assembled again and produce an even better product for the State of NH, Computer Associates and other users in the development community as well.
I have been working with Computer Associates (CA) for some time now to achieve this goal of tighter integration and with every release they listen to me a little more. One thing that has helped is having smart folks from the State of NH on the front end beta testing the tool.
These folks are good at what they do and provide clarity to the CA development team. I was very pleased this time with testing after looking back at the 12.1 release, which I soundly rejected as bad development on CA's part. Needless to say it was very disappointing from such a mature product. They heard me.
Kevin Lin's team from CA came through this time and receives higher marks with 12.5. I did not like the clunkyness of SCM 12.02 the product always felt unstable to me. This release has a much more professional feel to it. Melinda Skelton (CA), Dave Carmack (CA) and the entire CA development team really gave us a much better product. Thank you! It only benefits everyone to get the very best product that we can to support such important intellectual property and source data assets across the enterprise of all state government.
There is no reason this environment couldn't be replicated across the States. Intellectual property is a valuable commodity and it needs to be secured and controlled. Standardizing tools and centralizing assets to reduce cost and streamline software development activities makes sense on so many levels (reduction in support, fewer physical SCM servers to maintain and support, less electricity, less software to install, fewer operating systems to maintain, fewer servers to back-up, easier to maintain SCM licenses, less of a learning curve for developers from one State agency to another on an SCM tool, more formalized development, more disciplined development, status accounting now available on software development activities, common code library can be shared to reuse code, future upgrades to the client are easier, standard defect tracking being used which is centralized, etc.). All these savings add up and benefit state government in managing the cost of software development activities.
In addition to the centralized virtual environment initiative there was now the SCM 12.5 upgrade, which made sense on another level as well. The State has many Visual Studio developers and I wanted to move to the new Visual Studio Integration Program (VISP). The previous version of SCM 12.02 used SCC API calls within the Visual Studio IDE. However, Microsoft was moving away from offering the calls up to competitors because they were releasing Team Foundation as the competing tool to SCM.
They were closing the door and CA needed to figure out another mechanism for performing SCM activities within the Visual Studio IDE without Microsoft's APIs. I truly never liked the SCC anyway as I explained earlier; I've always felt it was clunky and not stable. So CA developed the VSIP. I feel better about the VSIP and the state beta test team beat it up good. It feels more stable to me and CA has more control over the VSIP to work outside of the Microsoft constraints to accomplish good SCM. CA must keep improving as this market is getting more competitive every day; once other tools of this nature figure out how to create plug-ins that integrate into every development platform seamlessly, the playing field will be leveled. Right now CA still holds a slight lead in the area of integration but tools like MKS, PVCS, and TFC are going to figure it out and there will be integration into PowerBuilder, VB, Visual Studio, Java, Eclipse, etc.
I'll digress for one more moment. I am a professional musician as well and release my own albums every year and I have noticed this trend even in the music industry as it relates to software and integration. Several years back everyone recorded on Recording Workstations. A couple of years later workstations are gone and now it's all software. Keep going down the road now it's all about the plug-ins. Plug-ins for virtual drums, virtual stringed instruments, virtual pianos, virtual synthesizers, etc. It's a huge side of music software now and the same thing is happening in software development - the SCM tool that comes along that has plug-ins that integrate into every development platform wins.
This integration allows states to standardize a tool across an enterprise because it supports whatever development platform you choose. That to me is huge because states typically have a variety of development platforms in use. In my music software I want as much available to me as possible so I can be as creative as the software can stretch me and I believe developers want the same. I'd rather have more capability than less. I'm certainly not going to refuse a Mercedes if it cost less than the Yugo.
Rich Sliwoski (State DBA Manager) and I were having a conversation and the context was placed around a secure cloud within SCM and I came full circle back to the directive that Commissioner Hastings had initially instructed, which was to explore how cloud development concepts could be used and taken advantage of at the State of NH. It is amazing how one directive can take you down many roads. The next initiative would be to create a common code library for common functionalities between agencies across the enterprise and code that could be shared, reused, understood all under the secure umbrella of SCM. SCM allows groups to be created that have certain levels of access all the way down to a process or a file. It's easier to allow some teams or many teams the ability to browse this library of shared common code. It also educates other teams on how one team versus another might be developing common functionalities.
I asked a colleague of mine Eric Ferren (DHHS) to check if any of the development teams had common code that they thought could be reused by other teams and wouldn't mind sharing. Many teams were very forthcoming and offered common code that is now available for use. The common library was born. An SCM environment was created to house various frameworks of Visual Studio, PowerBuilder, Java, Eclipse, etc. This common library is a read-only library for all developers to check out anything they can use to cut down development time on common functions (e.g., passwords, log-ins, etc.). It's not available to all users at this point; it only exists for those developers who have been upgraded to the virtual environment using SCM 12.5.
If you have a robust SCM tool with a database behind it, you can have all of your users centrally located and standardized with access to the source code, not just for their projects under source code control, but all projects under development in source control. The administrator of your tool with a process-based tool can then create user groups and assigned user groups with any number of individuals associated with it to any SCM environment under the umbrella of source code control. If you had an aggressive development schedule you can potentially use developers from another agency to help temporarily by turning on access to a project, and when the project is done turn off the access. The point is that when everyone is centrally managed you can get creative.
Developers can browse development libraries for the Visual Studio Framework, PowerBuilder, Java, etc., and have access to this library to check out common functionality code that was already developed and modify or tailor the specifics for their new development activity, rather than writing this set of code from the concept stage. I believe over time the state will save money by having code that is reusable. There are many types of code that can just be tailored rather than completely rewritten. Plug in the correct variables for your functionality and your off and running. Certainly it's not that easy but it should cut down on development time.
With one virtual environment for development, upgraded to the latest release of SCM 12.5, using the latest plug-ins for integration of development tools comprised of a shared common development library, using a standard compiling tool for production executables, defect tracking standardization and a SCM test environment for future release testing, Commissioner Hastings has transformed State Government software development for many years to come. It has been quite a directive. I have been juggling many balls in the air but I have had some good support and encountered many cooperative, collaborative, professional, disciplined developers.
I could never pull this off alone so I thank all of those who helped to accomplish Commissioner Hastings vision. It takes courage in state government to move someone's cheese and that's exactly what is being done. There are always going to be teams that don't want to play and convincing teams that this is in the state's best interest is challenging at best but with solid IT managers understanding the importance of securing this intellectual property and mission-critical data assets, centralization can be achieved.
I have been thinking of some of the ways I considered this initiative could save the state resources, time and money on development activities:
If the tool were designed to be transparent and seamless to the front-end user, this would give managers more latitude in assigning developers to a particular project. I feel you could access your developers like never before because they would be in one pool using the same methodologies as developed via the life cycles in the tool that mirror their processes on the ground. Many large organizations have too many varying methods, tools, processes and this creates silos of development, which is overall counterproductive to the whole. This makes it harder to not only know what the team(s) are doing or developing in or having access to or to interchange that skill set with another development team.
When all developers are using the same tool they can easily be provided access to another project via the secure cloud of the tool and work any project and have a much smaller learning curve by not leaving the development environment but seeing a new project in their view in the SCM tool.
I have been working in Software Configuration Management (SCM) for a few years now and I am presently, the administrator of SCM at the State of NH. SCM is a process-based Software Configuration Management (SCM) tool for managing application source code. I manage 300 plus applications housed in SCM and support 300 users using the product. The development tools we currently use are PowerBuilder PBV8, PBV11 and 12; Visual Studio 2003, 2005, 2008, 2010 and 2012; Eclipse, Juno, Cold Fusion and Java, COBOL. VB, etc.
As the Software Configuration Manager (SCM), I provide the administration of the source code management tool. This includes the entire infrastructure of the environment for development, developing life cycles, providing the best practices, procedures, processes, documentation; maintaining build machines; and the training of all the developers on proper source code management using the development tool in our development environment.
The SACI (Standardization and Centralization Initiative) is comprised of a lot of moving parts from consolidating/migrating projects from one SCM database to another in coordination with teams' release schedules and then upgrading the developers to the latest release of the SCM client. Provide them with a view into the Common code library and integrate across the enterprise the standardization and centralization of the SCM tool and centralization of all state source data assets and missions-critical assets for disaster recovery purposes and work to get more teams using the Defect Tracking tool within SCM to standardize reporting as well and get rid of the access databases, Excel spreadsheets and word documents and centralize this data as well..
The final result should look like one virtual software development server with 300-500 users and one terabyte of data assets, which would include intellectual property of various types (application code - VS, PB, Java, docs, etc., or Oracle code, SQL code, Access, etc.) and mission-critical assets.
As I bring on new agencies across the enterprise they are integrated directly into the latest SCM 12.5 virtual environment while I continue to move other agencies from the SCM 12.02 perspective to the SCM 12.5 perspective. There are a half a dozen agencies using the Defect Tracking System that is built into SCM. It is part of the product and up to a few years ago only a few agencies adopted its use and over time more teams are engaging in the use of the form. The form is a Defect, Modification or Enhancement against an application under development.
This is how issues are reported and tracked. Many are kept in Excel spreadsheets and recorded there, Access databases, Word documents, etc. The SCM Defect Tracking Form is attached directly to a CR Package so it follows the SCM activity through the entire life cycle. All I'll say at this time is that it has value to again have a centralized Defect Tracking System contained within the existing SCM tool that you already own. This offers the state a cost savings and removes all the various forms of maintaining issues being reported in the same location as needed for development activities. I can discuss the details of this part of SCM another time. I'll just mention a few advantages: You can attach multiple files to a form (Word docs, Excel spreadsheets, etc.), you can use the form as a running history of development activities against a task and you can print out a details report.
What will have been achieved across the enterprise:
One last item I will mention is that a senior developer Robert Kelley (DAS) took the initiative to create a reporting tool and this is a brief description of the tool: "The goal of the Harvest Automation and Reporting Tool (HART) project was to become intimately familiar with the CA Harvest Software Change Manager Software Development Kit (SDK) by exercising as much of its capability as possible in a C# .NET application. The SDK was accessed by interfacing with a COM DLL provided by CA. The HART tool, when finished, will make it easier to check-in and check-out files on a project-by-project basis, provide ad-hoc reporting such as retrieving a list of all files that have been checked out for more than thirty days for one or more projects, and provide built-in reports such as looking for empty projects. The tool was also designed to separate the user interface from the business logic that makes use of the CA SDK so that the functionality seen within HART can be taken and placed within another project with a different UI."
One of the issues I keep my eye on is performance. The virtual environment was scaled correctly but with so many users and so much data there could be problems. My hope is that there won't be but it is a watch issue for me and basically has always been anyway. When you want to get your work done, you don't want any disruption with connectivity related to storage and retrieval activities.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads