It's an interesting question, with many facets, so I was not sure how to respond. After some thought, here are the five areas I chose to highlight from my context of design and construction tool strategy. These are areas that have been occupying much of my thinking and discussions lately with customers, IBM Research, and the Rational teams. These are changing the kinds of software tools we are delivering, and the features the tools support.

1. Connecting business with IT: Business-driven development. The importance of understanding the business context for IT investment has never been more obvious than it is today. More organizations are recognizing the role of IT as a determining factor in the efficiency of their operations, and a bottleneck in their ability to innovate.

I am spending a lot of time with customers who want to explore business alternatives, drive IT projects more directly from business needs with well established business goals and ROI, choreograph services to realize their business processes, and monitor those services in execution to relate operations to the needs of the business. Support for that flow (in its myriad variations) is essential. As we use the current generation of tools in this context we are seeing the emergence of new roles, usage scenarios, and support needs. The lessons from this work are leading to a complete refactoring of tooling capabilities.

2. Greater transparency in the software development process: Auditing, traceability, and accountability. Software plays a pivotal role in all our lives. It runs our financial institutions, controls the power and utility infrastructure, is embedded in almost every useful device we use, and so on. With this important role comes a certain responsibility.

Government regulators, lawyers, and auditors are beginning to pay increasing attention to the software industry to verify that the software we all rely on has been developed according to some provable quality standards. Sarbanes-Oxley and BASEL2 are just the tip of a very large iceburg. For example, in discussions with those in the auto industry I was overwhelmed by the role software plays in the design, manufacture, control, and management of automobiles, and the kinds of requirements they need fulfiled by the software tools they are using.

Suppose there is a major design flaw in the software managing the anti-lock brakes on a popular model of car that results in injury of a number of people. How does the manufacturer of the braking system prove that it was not negilgent in the design and implementation of that software? Were the engineers developing the software certified against some recognized standards? Were the processes used to develop the software audited for quality? How were software designs analyzed and validated before they were put into production? And so on.

This kind of rigour and auditability will become the norm. Tools must permit this level of access and control. I refer to this as transparency...of prcoess, design, realization, etc. New tooling will emerge that supports and enforces these design principles. Traceability and reporting at all levels will become essential.

3. RAD using new programming models: As Grady Booch likes to say, software drives the world's economies and in some regards we can consider software development to be the most important job in the world!. Yet we all know that the skills and qualities of the best software engineers are in short supply.

It must be possible for a larger community of people to develop sophisticated enterprise solutions and deploy them to heterogeneous runtime environments. We have a long way to go to make this happen. The gap between the way domain-focused users view the problem space and the way in which they must describe systems in the solution space is far too great. In the past, various ways of addressing this gap with CASE tools and 4GLs solved part of the problem, but created their own challenges in return (e.g., proprietary runtime layers, non-standard artifacts, lack of openness to integrate with other systems and services, inflexible high-ceremony design approaches, and so on).

Over the last few years we have seen ways to overcome these limitations with the emergence of robust patterns and frameworks for application development in many technology and business domains. We can raise the abstraction of programming model to be closer to the end-users' mental model of their problem space and use the patterns and frameworks to transform that to the solutions space for today's technologies. Techniques such as generative programming and MDA are a realization of this. We are seeing a lot of innovation in the software tools here.

4. Collaboration among individuals and teams: Much of the inefficiency in software development is a result of the friction between individuals and teams as they work together to share a common understanding of some element of concern, investigate issues from multiple perspectives to make a balanced decision, solve multi-dimensional problems, and so on.

There are many great advances in collaborative tools for interaction and sharing. It's great to be able to start a chat session in a new window while understanding a new piece of code, to view a remote desktop to see the problem a customer is experiencing in their environment, or to create a teleconference as needed to resolve a design issues among colleagues. But there is much more to be done to make those kinds of capabilities part of the software tools workbench of the teams. We'll see those ideas become much better aligned with software development tools so that software engineers can more easily work together on all aspects of the design process, and we'll see design practices evolve to take better advantage of their capabilities.

5. "Pay-per-use" software tools: New licensing and subscription offerings. There are many pressures on software tool vendors to change the way in which tools are packaged and delivered. Initiatives such as open source software and hosted services via ASPs challenge conventional thinking on software tools.

We've seen some reaction in the marketplace (e.g., open source development tools workbenches such as Eclipse, and on-line testing services from different vendors). Customers are demanding more -- greater flexibility in how software tools are delivered, less overhead in upgrading software tools, more creative pricing based on how the tool is used, when it is used, and how much of it is used.

We are working on different kinds of software tool offerings in response to this by re-factoring the products we offer, increasing the ease with which different tool capabilities can be interchanged, and allowing access to software tool capabilities in a variety of access modes (various flavors of fat client and thin client access). Safe-to-say that lots of people building software in the future will not be buying, installing, and using tools in the way they do today.

Alan W. Brown blogged these comments originally at developerWorks.com. Reproduced here with the kind permission of the author.