Information technology is a critical element for many organizations, whether their IT supports internal systems or the creation of software products that represent their core In both cases, software is an essential element of their success, and these organizations naturally seek an environment for developing high-quality software in a timely, cost-efficient Such environments present challenges; and, interestingly, these challenges are similar to those of the systems they For example, development environments have to deliver against the required functionality and properties (such as performance and usability), often have to coexist with legacy systems (such as, in the case of a development environment, existing methods and tools), and have to acknowledge other constraints (such as the distributed nature of development teams, and existing skills and infrastructure) All in all, creating a well-oiled development environment that accelerates, rather than hinders, project performance is a science unto This is why IBM® Rational® has spent many years specifically developing a services capability that understands the challenges faced by organizations that 1) want to improve developer productivity, and 2) regard their development organization as a strategic differentiator, rather than simply a cost Our experience has led the Rational team to define a role within the software development lifecycle called the "development environment " In October 2007, one hundred of Rational's most experienced development environment architects from across the globe gathered together in the first conference dedicated to this role to share their This article is a result of that conference and the discussions that took As you read the concepts presented here, you may well question whether the development environment architect should be a role itself, or whether the individual or team who normally functions in the software or systems architect role should simply add consideration of the development environment to their list of architectural I believe that both propositions are Furthermore, whenever the role of the "architect" is discussed, it is always qualified with the domain under consideration; thus we speak of a "building architect," "software architect," "systems architect," "enterprise architect," The development environment is simply one of these domains, and one that is not traditionally a concern for the "software architect" I therefore believe that the "development environment architect" role is one that hasn't been emphasized before -- hence this This article has several audiences and It is relevant to organizations undertaking an improvement to their development environment and who need to understand the value of a development environment architect to help guide their It is also relevant to those who are responsible for the technical content of the development environment -- , development environment architects -- because this article introduces this responsibility as a role not previously Finally, this article may supplement material contained within a development environment, in helping communicate its content, the role of its architect, and the benefits of having such a role in I will discuss the following concepts, in order: