I have seen many Agile projects, particularly those focused on brand-new product lines, struggle with getting their infrastructure up and running. Much of the reason is the time and effort that is needed to get infrastructure established far exceeds the time it takes to start development using an Agile method, effectively the first iteration. Typically the approach used to establish infrastructure is ad hoc and often not always aligned with the needs of the project. Therefore, a task must be identified to establish infrastructure. The question then is, how to best approach the establishment of infrastructure for a project using Agile methods? We do not want to build excessive infrastructure that may constrain us in the future yet we want to establish enough to keep us stable and productive.
Early implementations of Agile focused on brand new or newer product-lines. More recently, Agile is gaining acceptance in the legacy product space where the project teams are moving away from their company's traditional (aka, waterfall) methodology and moving toward an Agile approach. In these cases, the project team that begins to use Agile methods are typically inheriting an existing infrastructure that was constructed for a phased (aka, waterfall) approach.
In most software engineering organizations, development and test labs continuously demand regular computer, storage, and networking infrastructure upgrades and continuous support. Lab administrators have moved toward server consolidation powered by virtualization platforms from vendors such as Citrix, Microsoft, and VMware, often accompanied by a management layer called virtual lab automation (VLA). Together, virtualization and VLA enable the lab to operate as a private, on-premise cloud. While this solves some problems, there are still other challenges to consider. Some test labs now leverage public cloud infrastructures such as Amazon Web Services. Jacob Ben-David reviews virtual labs enabled in private, public, and hybrid clouds, and explains how they improve development, build, and test processes.
Traditionally, testing IT applications is done in isolation on a stand-alone platform. However, when applications interface with the corporate IT infrastructure, you need to plan, engineer, and execute an additional level of integration testing. David Watt describes a typical IT infrastructure and the historical problems, costs, and complexities of conducting infrastructure integration testing. Because of the complexities common to many IT infrastructures, this level of testing is often ignored and omitted. David explains how enhancements to testing techniques and test process management can remediate many of these complexities and make infrastructure integration testing possible. David introduces the concept of an Enterprise Test Bed and explains how strict management techniques can make this resource a reality for your infrastructure integration testing.
Automation tools are often viewed as a cure-all that will instantly reduce test cost and effort. However, without up-front planning and infrastructure design, automated tests can quickly become difficult to create and maintain, and the tools nothing more than expensive shelf ware. This paper describes how to initiate a successful automation effort by developing standards and processes for automation and an infrastructure designed for success.
Bill Boehmer and Bea Patterson, Siemens Building Technologies, Inc.