Reaching a Solution - CDEs and Process Automation

Reaching a Solution

CDEs and Process Automation

IT must now utilize the same automation methods that have been used to integrate other business teams. This includes shifting environments to be more portal-like and creating underlying process, semantic, and analytic facilities to enable team members to work efficiently while still providing the desired controls and measurements. We view this as creating supply chain automation for IT assets. This shift started five years ago with initial efforts to link pieces of the process together, such as models and code, but the main inflection point begins this year and will evolve rapidly during the next five years. These solutions will initially be focused around the development and deployment process and then expand to encompass overall portfolio management and the integration of business with IT. This integration is also critical to the overall success that organizations will find in shifting toward SOA.

A Combination of Tools and Practices

Although tools will provide a boost, they must be combined with best practices. The most productive, efficient teams tend to follow several patterns as outlined by Coplien and others. Attributes such as small numbers (10-12), close proximity, and architects who implement work because of the ability to communicate and retain flow as well as the removal of "translation" loss.

Figure 2 - Roles in Action

Structured processes provide a great deal of formal guidance and documentation. The concept is to drive out defects early in the process (when it is cheap) by being exact. However, two things happen that challenge the success of this idea: projects take long enough that business requirements change between specification and delivery, and users often have a difficult time specifying what is needed until something is actually delivered. Thus, a waterfall might work fine for application maintenance because the requirements are well known; at the same time, it is ill suited to brand-new applications, where the requirements are less exact.

Organizations that want to improve collaboration should attack these social issues first. They must find ways outside the context of projects for IT team members to interact with their business counterparts. Organizations must establish guidelines around the use of instant messaging and spend time training project leaders on running effective meetings. If the organization currently is lacking in process standards or operates at a low Capability Maturity Model Integration (CMMI) level, placing a collaborative process-driven tool might help, but it is more effective to determine and train on an effective process foundation first. This is answering some of the big questions before proceeding to the details.

As organizations shift toward more agile development methodologies, they are seeing positive benefits in overall productivity and code quality. However, the tools used by teams are still more suited to waterfall methods. Each tool is designed for a specific task and with no underlying integration or meta model. This leads to process inefficiency and miscommunication. In a traditional cycle, each individual (and supporting tool) hands off the results to the next participant. This new person must interpret the input to produce the next set of artifacts. Each translation step opens the possibility for misinterpretation, yielding defective software and lack of customer satisfaction. During the past, it has been shown that effective teams use highly collaborative development techniques, and these reduce or remove communication barriers. During 2005, vendors (e.g., Microsoft, IBM, Borland) will begin to deliver a new era of development environments, stepping beyond integration (integrated development environments) to deliver collaboration (CDEs). There will be three primary access or control points for these collaborative environments: change management, collaboration portals, and role-directed IDEs. We believe role-directed development environments will be the dominant players because fundamentally this is still about developing and delivering software services. However, at the same time, the core concept is the integration and collaboration backplane that will enable different participants to work in familiar views.

By 2007, tool suites will have grown to include integration for project metrics and portfolio management, enabling organizations to make business-driven decisions about what projects are delivering and what projects to undertake. This will be driven both by vendors building out solutions as well as by the acquisition of existing solution providers. By 2009, the shape of development environments will have been dramatically altered to support SOA that will knit together forms and services through scripts and rules. This will demand the ability for closer team coordination, along with task-specific tools that enable teams with broad-ranging skills to coordinate application changes. Throughout this period, we expect to see dramatic market consolidation and a growing range of open-source products.

One of the greatest challenges is leading developers to make changes. As a group, developers tend to be wed to a routine and to chosen toolsets. This is one reason working from the IDE is so

important. If a product seems to be an impediment or creates a break in the flow, it will be rejected. By bringing process into the developer's working environment, less disruption occurs, and by working across a unified system, metrics become easier to gather. This has been illustrated by several early products that have integrated specific select development processes, such as modeling and code, unit testing, and pattern-driven design guidance. Rules can ensure that static analysis has been run and that unit tests have been created and passed before a piece of code is checked in, but this needs to occur without jumping between different systems and writing various configuration scripts. Early-generation tools often expect the developer to spend a lot of time writing tools to bridge the gaps. Workflow will enable projects to follow a process, notifying team members about tasks to complete. Although increasing process steps, these tools will raise productivity by leading to more maintainable systems, and catching errors earlier in development and automation will help keep them from being in the way. This does not mean that developers will be excited for more process, but integration and value will enable quick return on investment.

While IDE vendors will expand the breadth of offerings, there will continue to be a strong market for third-party solutions to fill in the gaps and to provide common tools across platforms. In addition, we expect a wide variety of useful open-source products to continue to emerge. However, differences in schemas and a lack of standards will limit the ability to have a complete unified toolset across all of IT.

Conclusion

Although iterative development practices have been shown to improve development productivity and customer satisfaction, they are difficult for organizations to use because of the mismatch with existing tools and the lack of support for providing management and metric information. In addition, tools have been lacking in their ability to help team members in different roles interact with each other. A shift toward more collaborative environments with integrated development process support will provide the necessary foundation for improvements to IT productivity. This will be the beginning of software's ERP era.