Almost any description of a job involving software configuration management—or more generally, application lifecycle management—will include the words “best practices.” Kareen Kircher writes on how to make best practices a reality for your work. The five ingredients to making successful changes happen are relationship, timing, automation, pertinent documentation, and refining.
Almost any description of a job involving software configuration management—or more generally, application lifecycle management—will include the words “best practices.” Too often, the most attention that will ever be paid to the concept of best practices is during a job interview, when the SCM thought leaders are penning the latest release of their process documentation, or when an organization is scrambling to assemble something credible for an upcoming audit. However, it is indeed possible to make your methodology of choice become part of the fabric of day-to-day life rather than simply being a collection of irrelevant documents. The five ingredients to making successful changes happen are relationship, timing, automation, pertinent documentation, and refining.
Relationships are the foundation of not only society but also of organizational change. You don’t need to be particularly outgoing or outspoken to make things happen, but you do need to convey to the right people that you are thoughtful and thorough in your approach. Nobody likes a “know-it-all,” even if you do know it all. Allow people to get to know your problem-solving approach. The people who allow you the opportunity to make changes that affect the enterprise need to know that you are careful with their reputation, and that you performed your due diligence. Examine the culture of the company, particularly in how it has managed change in the past. Try to find out the track record of the people you are counting on to be fellow champions of your process. Sometimes even people who are in a position of leadership will retreat in the face of opposition, or otherwise preserve their political capital for another fight.
For smaller concerns like a startup, a conversation may be all the blessing you need to get started. Medium-size companies may require a more formal analysis and justification for your proposed changes. In large organizations with multiple functional divisions, start a pilot program with the team with whom you have the most credibility; this team can help evangelize wider adoption later on. Regardless of the size of the organization, you may never have as much latitude as you would like; be prepared, and watch for smaller opportunities to advocate for your solution. Persistence and resilience can help to eventually carry the day, particularly if there is someone in the organization whose outsize influence tends to derail attempts at changing the status quo.
Once you partner with a team in a pilot program, learn about its pain points and the sort of efficiencies that would make the team members’ lives easier. Don’t think about implementation just yet, as you may miss opportunities to solve a real problem and end up delivering a “nice-to-have” but superfluous solution. What recurring issues do your team members face, and to what degree does it affect their productivity? If you’re willing to listen and take action on their behalf, people will tell you what their needs are. Leverage your partner team’s feedback, and incorporate its ideas into the process. It is imperative to keep an open mind and probe for honest feedback even when the feedback is negative. Your pilot partner needs to be sufficiently invested in order to help you anticipate and counter objections that will undoubtedly come up as implementation progresses across the organization.
Next, be sure to approach people at the right time. Say that your company produces commercial software and everyone is at a point where they are in fire-fighting mode; you will not find a receptive audience, and a premature attempt will convey a lack of awareness of priorities. When you sense that the time is right, be practical yet strategic. Demonstrate your understanding of the objectives and align the benefits of your solution with those objectives. Even in the fast-paced life of a hot startup or an investment bank, there are opportunities to introduce gradual efficiencies that will add up to systemic improvements over the long term.
Remember that office politics do not magically cease to exist because you have secured the necessary approvals and promises of collaboration. In addition to real-life circumstances that pose a threat to accomplishing the goals, there are sometimes uncooperative people that will seek to circumvent and undermine the efforts. Leverage automation throughout the application lifecycle stages to guard against both types of threats. Traceability and accountability are the parents of compliance.
Automation does not replace human checkpoints, but can greatly enhance confidence that the proper controls are in place. Start by recommending tools that increase code quality and efficiency. Such tools will already be in existence and in use, to some degree, depending on the maturity level of the organization. Systems such as Team Foundation Server (TFS) can easily host plug-ins such as ReSharper and StyleCop, which help developers refactor code dynamically. Check-in policies involving code analysis can also help and they can be customized so that the rule sets are not an obstacle to agility. Giving teams a “grace period” for compliance is a worthwhile goodwill investment that will pay dividends for you both.
The software build and validation processes present additional opportunities for automation. Code inspection and security scanning can help discover areas of weakness that still exist after developers have checked-in their code. For testing teams there exist numerous tools—commercial and open source—that can automate all or significant portions of their work.
Deployment regions, particularly those that are less stable, can benefit from automated alerts to guard against unapproved changes. Deployment artifacts can have automated versioning, be digitally signed, or be supplied with checksums as appropriate. In addition, application monitoring, network monitoring, and security tools can be configured to identify deviations from the norm and warn the appropriate staff about inappropriate access.
Short of architectural constraints in the application, you should endeavor to eliminate the roadblocks that prevent automation. However, some organizations may be required by auditors or regulatory bodies to be able to demonstrate that certain things can be manually inspected and validated. Therefore, it is imperative that you understand how your automation tool works or, at the very least, be able to extract parameters that are used during execution.
The universe of automation options is vast and there is no single magic bullet. Consequently, you need to communicate the relative importance of these requirements and negotiate the degree of compliance that must be achieved over time. This kind of documentation is truly relevant as it is a framework that serves everyone, from new staff members who need orientation to the auditors who have to certify that you have established the proper controls. There should never be so much documentation that people can claim they were not aware of what is required of them; this reflects poorly on process owners. Review the merits of the content, and have a plan to retire outdated information.
Even when a process is automated, there should be at least some workflow documents to illustrate how it works. Do not make the mistake of creating or maintaining documentation that does not reflect actual practices in your organization. That divergence, if allowed to continue, can make it difficult to steer the organization towards a real commitment to continuous improvements. Process leaders need to be well informed about the application architecture; seek the perspectives of designers, developers, testers, and others who know the shortcomings of the existing system. Without their input, you can develop a false sense of security about the reliability of your controls.
The business of software requires a great degree of humility and willingness to probe the limits of your knowledge; essentially, you need to know what you don’t know and mitigate the risks. This is where the concept of refining comes in. Maintain ongoing conversations with managers and staff in addition to seeking external knowledge and other sources of information. While there is no perfect system to guard against willful or unintended mistakes, the more systemic and automated your controls are, the easier it is to test for compliance and to implement better procedures when warranted. However, this does not happen in a vacuum. Remember, your prospects for success are increased when you remain intellectually curious and adaptable.
