Tools—Some Assembly Required
In my last story, I wrote about my love-hate relationship with automated tools and mentioned a few things to keep in mind when implementing said tools. One of those items was "have a long-term plan.” That plan can range from eighteen to thirty-six months.
This is critical because whichever automation functionality you implement across your development, testing, and deployment lifecycle should be capable of passing certain information from one tool to the next. No one wants to reenter information from tool to tool, and you'll most likely want (and your key stakeholders will need) reports that span the information contained in different tools.
For example, a product owner may enter information into a Word document, Google Doc, Excel spreadsheet, or a SharePoint site regarding user stories. These then need to be moved into your agile project management tool, where technical staff, testers, and other key members add information.
The information from your agile project management tool will be used as programming begins (in an IDE), in a configuration management tool as builds are created, and in a test management tool as tests are designed and executed. Incidents are logged into the incident management tool and then a set of deployment tools are used for moving the features into production.
Alternatively, requirements are described in a requirements tool, and then a UML tool may be employed. The various documents created during development may reside in a document repository, while multiple IDEs may be used for different code implementations or technology platforms. Unit testing tools, system test tools, performance test tools, and more than one test execution environment may be needed, and a test management tool will most likely be in the mix. Data management and encryption or masking tools may be employed as well as incident management and deployment tools.
You have existing tools in your environment today. Some of those tools you want to keep, others you may want to retire, and still others you want to upgrade. As you think about the next "cool tool" that will improve your organization’s efficiency, you'll want that new automation component to play nicely with your existing tools.
Thus, understanding how the new tool integrates with your existing tool environment requires some forethought; otherwise, you will end up with a heap of fairly useless—or at least isolated—automation islands. Whether implementing open source, purchasing commercial tools, or building your own, I highly recommend that you create a tool architecture.
A tool architecture is simply a picture of all your development, testing, and deployment tools and how they fit together. Creating a "current state" diagram and then looking forward and creating a "future state" diagram helps you understand where tool integrations would be beneficial. It also helps you prepare to ask the hard questions of the suppliers of the tools you are considering and get a clear picture of how much assembly is going to be needed to assimilate the new automation component into your environment.
