Why a definition matters
A development environment contains everything required by a team to build and deploy software-intensive systems (where software is an essential and indispensable element). So why is having a consistent definition of a development environment important? Put simply, many organizations want to reduce time-to-market, reduce cost, and improve quality, and all of these business goals are directly influenced by the quality of the environment used to produce these systems. Having a consistent and comprehensive definition of a development environment at hand ensures that nothing is overlooked when you're planning an initiative to improve the current environment, defining requirements for the environment, defining the architecture of the environment, assessing the environment, ensuring an appropriate return-on-investment when changing the environment, and so on. A development environment definition is a critical input to all of these tasks.
Putting the development environment in context
Before looking at the specific elements that comprise a development environment, it really helps to first understand where this environment sits in the grand scheme of things.
In Figure 1, you see a Center of Excellence that is responsible for creating and maintaining the development environment. This environment is used on development projects that, in turn, create and maintain software-intensive systems (or some other software-related deliverable, such as components or services). This simple visualization helps clarify the distinction between the role of any Center of Excellence that is in place (including its team member's roles, processes, and key deliverable: a development environment) and the projects that use the development environment (and their roles, processes, and deliverables).
Figure 1. Distinguishing a Center of Excellence from a development project
Elements of a development environment
To IBM Rational software experts, a development environment comprises these six elements, each of which is shown in Figure 2 and described in detail in the sections that follow:
Figure 2. Elements of a development environment
You might be familiar with "people, process, and technology" as key ingredients of a successful development project. However, this model is overly simplistic for the purpose of this article. Nonetheless, the elements shown in Figure 2 build on this model:
- People are represented by enablement and organization.
- Process equates to method.
- Technology is represented by tools and infrastructure.
Adoption is a new (and very important) element that is focused on the introduction of the development environment within an organization, business unit, or development project.
A key element of any development environment is the method that is followed, formally or informally, by practitioners. These are the key method-related elements:
- Core method elements, such as roles, work products, tasks, and processes
- Supplementary method elements, such as standards, guidelines, checklists, templates, and examples
- Method deployment topology that might be considered when, for example, the method is deployed as a website on the company intranet. In this example, a web server is required to host the content, and workstations must have an appropriate web browser installed and connectivity to the web server.
Development tools automate aspects of the method being followed. For example, you might use a tool for storing and managing requirements on a development project, or use a tool for visually modelling your architecture and design, or use tools for testing your software, and so on.
These are the key tool-related elements:
- Development tools and their integrations
- Development tool configurations and installation scripts
- Development tool deployment topology, which considers the software and hardware required, both client-side and server-side, along with any target platform and emulators as relevant (such as when you are developing for real-time or embedded devices)
Enablement of practitioners (training and mentoring) in using the development environment contributes to successful adoption. Therefore, the definition and creation of training and mentoring materials that can be applied are aspects of a development environment. Mature organizations also pay particular attention to the professionalization of their staff and alignment with external professional organizations.
These are the key enablement-related elements:
- Training curriculum and courses. This covers a variety of training needs, from training experienced practitioners in refinements to the development environment, all the way up to a comprehensive training curriculum for a practitioner taking on a new role.
- Mentoring materials. These are applied by individuals when coaching less-experienced colleagues on projects.
- Enablement deployment topology. Consideration of a deployment topology is necessary when, for example, enablement is provided through web-based training. Again, a web server is required to host the enablement materials and workstations equipped with web browsers. The deployment topology might also specify locations and rooms required to deliver classroom training.
Another consideration of a development environment is ensuring that an appropriate organization is in place to define, deploy, and manage it. This might include specialists in certain aspects of the development environment (such as method experts, tool specialists, trainers and mentors), personnel to administer and support the environment, personnel with appropriate skills on the company help desk, and appropriate communities of practice.
These are the key organization-related elements:
- Definition of organizational roles and units that are part of the development environment
- Organization deployment topology that indicates the locations of these organizational units
A development environment considers infrastructure in terms of both hardware and software. This has already been hinted at previously when discussing method, tools, enablement, and organization. However, there are three reasons for considering infrastructure as a key element independently:
- The first is consolidation. For example, by looking at the infrastructure needs of the development environment as a whole, you might find that you only need a single web server to support both web-based method content and web-based training.
- The second is to ensure that there is appropriate consideration of any additional hardware and software supporting the development environment, such as operating system software, a database management system, or board-level controls, and test harnesses if you are developing for real-time or embedded devices.
- The third is that a Center of Excellence might require infrastructure to support the development and test of the development environment, before it is made available on any production infrastructure in support of business projects.
These are the key infrastructure-related elements:
- Locations, nodes, and connectivity
- Software (such as operating systems, database management systems, board-level controls, and test harnesses).
In addition to the elements listed already, it is also important to be concerned about the adoption of the environment within an organization, a business unit, or a development project.
These are the key adoption-related elements:
- Adoption plan. This plan defines the tasks that are normally performed when adopting the environment, such as the acquisition of any hardware and software.
- Techniques for driving organizational change. These will be required to introduce and embed the development environment into the day-to-day work of the affected organizational areas.
- Definition of environment metrics. The metrics are used to gauge the effectiveness of the environment.
Also relevant is the solution context (where the development environment is the solution under consideration). The context represents the requirements on the development environment and can be considered in terms of functionality, qualities, and constraints.
- Functionality represents a software engineering practice or discipline to be provided by the development environment. Realizing such requirements leads you to consider all of the elements mentioned previously. For example, and as shown in Figure 3, a requirements management discipline would be supported by:
- Requirements management method
- Requirements management tools
- Training and mentoring in requirements management
- Help desk staff that know the requirements management solution
- Hardware and software to support the requirements management-related elements
- Appropriate adoption of the requirements management discipline on projects
Figure 3. Required functionality involves all elements of a development environment
This thinking can be applied to other capabilities that are part of the development environment, such as architecture or quality management. It can also be applied to specific practices, such as iterative development (at the heart of an agile approach to software development and delivery), which also requires you to consider all elements.
- Qualities represent properties that the development environment should exhibit. This, too, requires consideration of all elements of a development environment. For example, a scalability quality (the ability to support a varying number of concurrent users, for example) might be accommodated in these ways:
- A method that can be customized to fit the size of project
- Tools that can be configured to support a configurable method
- Appropriate mechanisms and levels of training for different sizes of projects
- An organization that provides appropriate levels of skill among team members to support the anticipated number of development projects
- An infrastructure that can scale to support the anticipated number of concurrent users
- Appropriate mechanisms to adopt the environment.
- Constraints that the development environment should accommodate also require consideration of all elements of a development environment. For example, the need to migrate from an existing environment might result in these actions
- Taking practices from an existing method and incorporating them in a new method
- Migrating work products from a deprecated toolset to another (or needing to integrate with existing tools that will be retained)
- Providing enablement that acknowledges current understanding and is customized appropriately
- Providing personnel to ensure a smooth transition from an as-is state to the to-be state.
- Specifying an infrastructure that maximizes reuse of an existing infrastructure (such as reusing existing hardware and software licenses where possible)
- Appropriate adoption mechanisms that acknowledge the migration to be performed
Another important constraint when an organization considers a change to its existing development environment is the return on investment (ROI), of course. For such an initiative to succeed it must, clearly, deliver positive results that are in line with the business case for the initiative. Each area of a development environment influences the ROI in terms of both cost and benefit.
Although not shown in Figure 2, functionality, qualities, and constraints are typically aligned with any business context that has been defined, such as business goals. In this sense, the solution context also embraces business considerations. This can be especially important when showing how the development environment contributes to achieving business goals, directly or indirectly.
Define, deploy, manage
In defining the various elements of a development environment, it has proved useful to consider the following elements of the environment's lifecycle (shown in Figure 4), because in addition to the solution context, they each have specific concerns that influence the definition:
- The definition of the environment
- The deployment of the environment
- The management of the environment
Figure 4. The life cycle of a development environment
Before looking at these areas, it is worth explaining why these different areas are linked in a cycle in Figure 4. This figure acknowledges that effective change (in this case, improvements to the development environment) is usually achieved through a series of incremental changes rather than a big bang approach to change (evolution, not revolution) where each increment represents a single pass through the cycle. However, the change that has been implemented in an increment, by definition, changes the context for the next increment (for example, practitioners may now have improved skills, new hardware may be available, new tools may be in place and so on) – hence the cyclic nature shown.
Consideration of each element of a development environment, in conjunction with solution definition, solution deployment and solution management, is given in the sections that follow.
Earlier discussion focused on the key elements to be considered when defining a development environment. That discussion is not revisited here although, for completeness, the various items that are defined are reproduced in Table 1.
It should also be noted that the definition is typically considered at an organization level and may require a local instantiation to address the needs of a particular business unit or project when it is deployed. This is reflected in the sections below.
Table 1. Definition considerations
|Method||Roles, work products, tasks, processes|
Standards, guidelines, checklists, and so forth
Method deployment topology
|Tools||Development tools and integrations|
Development tool configurations and install scripts
Development tool deployment topology
|Enablement||Training curriculum and courses|
Enablement deployment topology
|Organization||Organizational roles and units|
Organization deployment topology
|Infrastructure||Locations, nodes and connectivity|
Supporting software (such as operating systems)
Techniques for driving organizational change
Deployment of the development environment introduces specific concerns with respect to each element, Table 2 shows.
Table 2. Deployment considerations
|Method||Define local configuration|
|Tools||Perform local configuration|
Migrate local data
|Enablement||Perform local configuration|
Deploy enablement materials
|Organization||Define local configuration|
|Infrastructure||Define local infrastructure|
Provision locations, nodes, connectivity
Provision supporting software
|Adoption||Define local adoption plan|
Validate the environment
Key method-related elements:
- Define the local configuration. When deploying the method to a business unit or development project, it might require some local configuration to reflect the specific characteristics of the business unit, development project, or system (for example, by providing an appropriate level of ceremony).
- Deploy method. This ensures that the method is available to practitioners.
Key tools-related elements:
- Perform local configuration. Any local tool configuration is applied to automate the local method configuration.
- Install tools. Make the installed tools (and their integrations) available to practitioners.
- Migrate local data. It might be necessary to migrate data from an existing toolset to the updated toolset, for example.
Key enablement-related elements:
- Perform local configuration. Adapt, refine, or update training materials as necessary. For example, you could revise enablement materials to accommodate the process defined for that business unit or development project.
- Deploy enablement materials. Ensure that the enablement materials are available to practitioners, including access to any web-based training.
- Train practitioners. The practitioners are trained and feedback on the training gathered.
Key organization-related elements:
- Define local configuration. It might be necessary to provide experts to support the specific needs of a particular business unit or development project.
- Reorganize. Organize personnel and resources to support the development environment.
Key infrastructure-related elements:
- Define local infrastructure. Define the infrastructure required by a particular business unit or development project.
- Provision locations, nodes, and connectivity. Make any hardware required available (including any target platform and emulators when developing for real-time or embedded devices).
- Provision supporting software. Install any software that supports the development environment (such as database management systems or test harnesses).
Key adoption-related elements:
- Define local adoption plan. Refine the adoption plan to reflect the specific needs of the business unit or development project.
- Validate the environment. Test the deployed environment to ensure that it meets the defined requirements in terms of providing the desired functionality, meeting the stated qualities, and functioning within defined constraints.
As Table 3 shows, management of the development environment after deployment also introduces specific concerns about each element.
Table 3. Management considerations
|Method||Gather feedback on method|
|Tools||Backup, archive, or restore data |
Gather feedback on tools
Gather feedback on enablement
|Organization||Gather feedback on organization|
|Infrastructure||Provision or retire infrastructure as required |
Gather feedback on infrastructure
|Adoption||Measure environment effectiveness|
Gather feedback on adoption
Key method-related elements:
- Gather feedback on method. A key aspect of managing the development environment is to continually improve. Therefore, gathering feedback on each element is a theme that pervades all elements. Feedback is typically gathered subjectively by using, for example, a questionnaire.
Key tools-related elements:
- Backup, archive, or restore data. Ensure that work products created by practitioners are managed appropriately and "good housekeeping" practices are applied.
- Gather feedback on tools. Gather feedback (positive and negative) on the capability and performance of the tools.
Key enablement-related elements:
- Mentor practitioners. Assign mentors to projects to ensure that practitioners know how to use the environment.
- Gather feedback on enablement, thus about any training or mentoring.
Key organization-related elements:
- Gather feedback on organization. Practitioners give feedback on the support that they have been provided in using the development environment (such as the quality of help desk support).
Key infrastructure-related elements:
- Provision or retire infrastructure as required. As projects start and conclude, the development environment needs to resize accordingly to optimally support the number of practitioners who are using the environment at any given time.
- Gather feedback on infrastructure, including both hardware and supporting software.
Key adoption-related elements:
- Measure environment effectiveness. This is a key aspect of successful adoption. For example, you could provide a questionnaire to practitioners and ask them to gauge how effective they have been in adopting the new practices.
- Gather feedback on adoption. Feedback on the approach to adoption is gathered.
Finally, bear in mind that the various elements of a development environment are not as independent as this article might imply. An alternative representation of Figure 2 is shown in Figure 5, which illustrates that each element has relationships with all other elements.
Figure 5. Interdependencies among elements
Here are a few examples of dependencies between elements:
- The method (method) references available training courses (enablement).
- Tools (tools) automate tasks (method).
- Administration roles (organization) are defined to support the tools (tools).
- Servers (infrastructure) are provisioned to host the toolset (tools).
- Adoption of practices (adoption) is assessed using the defined approach (method).
This article adds to one by the same author, Peter Eeles, published by The Rational Edge in 2008: The Rise of the Development Environment Architect. The sections here elaborate upon the key elements that comprise a development environment in detail and point out the different concerns when defining, deploying, and managing such an environment. This provides a simple framework for ensuring that all of these aspects are considered when planning an initiative to improve the current environment, defining requirements on the environment, defining the architecture, assessing the environment, and so on.
- The earlier, less detailed article is available here: The Rise of the Development Environment Architect by Peter Eeles (The Rational Edge, 2008).
- Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, any time, and many of the "Getting Started" ones are free.
Get products and technologies
- Get the free Trial Download or check the Trials and Demos page for Rational software.
- Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
- Join the Rational software forums to ask questions and participate in discussions.
- Share your knowledge and help others who use Rational software by writing a developerWorks article. You'll get worldwide exposure, RSS syndication, a byline and a bio, and the benefit of professional editing and production on the developerWorks Rational website. Find out what makes a good developerWorks article and how to proceed. Start by finding out what makes a good developerWorks Rational article.
- Follow Rational software on Facebook and Twitter (@ibmrational), and add your comments and requests.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
- Connect with others who share your interests by joining the developerWorks community and responding to the developer-driven blogs.