The basic Rational mission has remained largely unchanged for the past decade. We still strive to ensure customer success in developing software, as well as business systems that rely on software. Indeed, the basic principles that have helped focus IBM Rational during our transition remain as important today as they ever did: Focus on architecture, develop iteratively, manage change and assets, and continuously ensure quality throughout the lifecycle. These principles guide the people at IBM Rational by helping them scope the products and services we offer and inform our customers about the strategic decisions being made.

The new reality

Yet a lot has happened over the past few years that fundamentally alters the context in which the Rational mission and principles are applied. Understanding those changes guides how Rational fulfills its promise to ensure customer success. In particular:

• IT organizations are different. IT professionals are required to show direct impact in areas that differentiate the business. They need to demonstrate a return on investment (ROI) for IT expenditure and leverage existing IT investments in support of new business opportunities.¹ All of this is in the context of new and emerging technologies, the increasingly pervasive role of software in all aspects of our lives, and the need to drive innovation in the products and services being delivered.
• IBM Software Group is different. As Rational joined IBM, the IBM Software Group was going through a significant change in the technologies and solutions it offered. The middleware technologies had recently been collected under a single WebSphere brand (both the application server and the business integration servers); acquisitions of Holosofx and Rational had highlighted the increasing role of tools in driving and differentiating IBM's middleware offerings; and there was strong support for an open standards-based infrastructure for all tooling based on the Eclipse technologies for tool integration, Java-based standards for application development and deployment, and the emerging commercial viability of the Linux operating system and associated software.
• IBM is different. Consolidation in the platform and server markets has been underway for some time. IBM had struggled through some difficult years, but emerged with a renewed focus on how it provides customer value. This is based on a solutions-and-services focus to ensure customer success, delivery of a complete application deployment platform with supporting management capabilities, and a mature J2EE-based runtime programming model based on industry standards offering a viable alternative to Microsoft from design to deployment.

This context is important. It shapes the kinds of investments that IBM Rational will make in the near future to remain successful. In particular, while many of the key principles for improving software development practices promoted by Rational remain intact, there are many essential changes for how those principles are applied. The greatest impact can be seen in four important areas:

1. Understanding the context. Most software is not delivered as a stand-alone product, but as a key component of a larger system (business or product). Understanding the operational and development context of the software is increasingly critical.
2. Providing a solutions focus. IBM's delivery of solutions and services is an essential part of its success, and the Rational brand represents an important component of those solutions because of the tremendous potential to combine forces with other IBM Software Group brand strengths.
3. The role of Rational technologies is to drive IBM solutions, services, and platforms. Direct revenue from tool sales is important to IBM Rational. Yet in terms of the parent company, the Rational brand represents a relatively small percentage of IBM's overall revenues. At the same time, Rational service capabilities has a substantial effect in the marketplace for delivering services and solutions, and in driving Software Development Platform sales.
4. The platform matters. The traditional Rational message has been that we are agnostic to the particular languages and platforms used to implement solutions. That was yesterday. IBM is designing and delivering the industry's leading computing platform for the implementation, delivery, and management of enterprise solutions. The new Rational role is to encourage, support, and help differentiate that platform from our competitors.

These principles do not imply that Rational is committed only to IBM platforms -- quite the contrary. We clearly recognize that our customers will continue to deploy applications across heterogeneous platforms, and IBM Rational will be there to help them assemble, deploy, manage, and evolve those solutions. Our long-held commitment to open standards is what enables the goal of supporting deployment and management of solutions to complex, heterogeneous environments. However, in terms of creating solution components, the Rational brand will help illustrate that IBM's platforms and technologies are preeminent, and it will offer customers the quickest route to delivering high-quality enterprise solutions.

IBM is in the productivity improvement business; it provides solutions that enhance productivity within two key business functions:

• Traditional IT. These are the organizations that support the business to better manage vital transaction-based processes. Examples include, but are not limited to, retail operations, supply chain management, and back office processes.
• Product and system development. Examples include pervasive and embedded devices, deep computing, gaming, simulation, command and control systems, and large manufactured items, such as automobiles and aircraft.

Many IBM customers are large, commercial organizations with a traditional focus on IT, who understand the role IT plays in supporting their businesses. For this reason, much of the discussion in this paper concerns how the Rational strategy supports that community and how it supports IBM's solutions and services in general. The value of Rational tools is most easily demonstrated via these IT-dominated businesses, including large enterprises (IBM's traditional strength) as well as influential small-to-medium businesses.

However, the attention given to IT does not imply that this is our only focus. While enhancing the Rational role in these areas is central to IBM's traditional enterprise business, it is also important to address regions of the system and software landscape that live beyond the enterprise, which represent important areas of growth outside of traditional IT areas. In particular, as software becomes a core part of all aspects of society we see increased demand and innovation in system and software development for pervasive and embedded devices, deep computing, gaming, simulation, command and control systems, and many others. Historically, Rational tools and techniques have had great impact in these "technical developer" communities, and IBM Rational must continue to support existing customers in these areas. In fact, our insights regarding software development tools and best practices can provide support and pull through to IBM's core enterprise businesses, and be instrumental in creating growth for IBM in the larger system and software domain.

Back to top

A new view of design and construction

The traditional Rational view of software design and construction focused on the following sequence: requirements analysis, systems architecture, then detailed software design and construction in an IDE, followed by deployment to an runtime environment. This view is no longer sufficient for today’s enterprise solutions. There are three drivers for the way organizations are looking at their next-generation solutions platforms:

• A services view. Increasingly, companies are considering the collection of capabilities offered across an IT infrastructure as a set of services that are assembled to meet specific business needs. System architectures are designed as collections of services governed by inter-services protocols and explicit service-level agreements (SLAs).
• Rapid assembly and reassembly of solutions. Greater flexibility can be offered by treating an IT organization as a "software factory" for creating solutions that meet evolving business goals. To achieve this, development teams must be able to easily assemble and reassemble pieces and parts of the solutions as the business and market conditions demand. This requires close relationships between the business analysts and IT architects, and a disciplined approach to managing the pieces and parts that are assembled.
• A focus on asset management and reuse. As organizations seek to obtain greater business efficiency, there has been increased emphasis on reuse throughout the software development lifecycle. In particular, the once-limited concept of reuse through shared code libraries has been expanded to the reuse of business processes, requirements definitions, architectural design elements, test scripts, and so on. This broader concept of reuse changes the solution lifecycle in substantial ways, altering the roles of individuals in the organization and creating different project practices for creating, harvesting, applying, and managing assets across the lifecycle. This must be based on strong governance practices for reusable assets tied to a flexible asset management infrastructure.

Also, the Rational approach traditionally ignored parts of the IT organization with whom IBM is deeply involved via its other software offerings (business specialists, IT operations, financial analysts, etc.). IBM customers demand a more complete lifecycle solution than Rational was ever capable of providing as a separate entity. The new capability for IBM to offer a complete set of solutions holds tremendous value and potential as the leading IT solutions provider and the incumbent vendor in many large enterprises.

This new capability requires us to understand the tools and platforms from a services perspective, which offers a way to tie the business and IT perspectives more effectively together. From this perspective, the “wiring of services" becomes the new metaphor to replace the former "extending object models" metaphor. We are better able to take advantage of exposed service-based middleware, and we can facilitate greater management and reuse of solution fragments. The consequence is different kinds of solutions, different roles, and different expectations from the tooling.

The importance of this service-oriented approach is easily seen in the messages being delivered by IBM, and more broadly across the software industry with service-based technologies coming from Microsoft, BEA, Oracle, Sun, HP, and others.

Back to top

The emerging design and construction landscape

As vendors address customer needs, a broad vision is emerging for how the design and construction landscape will evolve, as illustrated in Figure 1.

Figure 1. The emerging design and construction tooling landscape

Broadly defined, the design and construction landscape consists of five areas:

• Middleware platform. There have been many advances in the runtime platform for enterprise solutions. Robust enterprise application servers have emerged to form the backbone of today's distributed service-based solutions. A wide variety of technologies exist, and most organizations today deploy solutions to a heterogeneous mix of middleware technologies. Consequently, it is important to be able to manage enterprise solutions deployed to a variety of platforms, while encouraging the development of new solutions based on open standards. For example, J2EE standards define how applications and services can be built to deploy to standards-compliant containers running in the application server. Additional functionality layered on the application server supports 1) direct execution of business workflows expressed in standard languages such as BPELWS,² and 2) creation and assembly of portal-style applications from collections of reusable portlets.
• Runtime programming model. The interfaces to the middleware platform define a programming model that must be understood by software architects who want to design, build, and deploy solutions to the middleware platform. This requires that users of that platform have a well-defined conceptual view of the enterprise solution and its physical realization into executing components.
• Workflow orchestration. In assembling systems, it is useful to consider many kinds of applications as "orchestrated" collections of interacting business processes. Many of these business processes may be automated, while others will require manual tasks carried out by members of the team. Orchestrating these workflows provides a much more business-focused view of how tasks are carried out. There are now sufficiently rich languages for expressing these business workflows (e.g., BPELWS) that they can be directly executed on a suitable runtime platform, typically built as a layer on top of an enterprise application server.
• Business-level tooling. The business models must be defined in a language and notation appropriate for business specialists, and must be supported by business-level simulation of those processes to explore potential impact of variations in the process. Business impact must then be deduced to manage business performance by inferring business-level implications from collections of lower-level technology-driven events that occur in the middleware platform. These two aspects, business process modeling and business performance monitoring, go hand-in-hand for organizations dedicated to driving business value from their IT investments.
• Architecting systems from components. The assembly of services and their deployment to a middleware platform implies that those services must be created and combined in the context of an architectural blueprint. In many cases, the services will derive from various sources: for example, from existing applications and packages in production, mined from previous projects, or they may be acquired from third-party suppliers. In other cases, the services must by altered to meet new requirements, or they must be built from scratch. Managing libraries of existing services, realizing new services, and assembling them in the context of an appropriate system architecture are key tasks to be supported.

Back to top

The IBM approach

Of course, IBM has not been standing still as these trends have emerged. In fact, IBM has been instrumental in driving standards and technologies in support of these customer needs. The IBM approaches to these challenges are well underway, and are now beginning to be automated and simplified in IBM's tooling and infrastructure. A number of key components to the IBM approach are illustrated in Figure 2.

Figure 2. The IBM design and construction tools approach

The IBM solutions focus on the five areas identified in the previous section:

• The IBM Middleware Platform. IBM offers a rich set of middleware technologies based on the WebSphere Application Server. Additional capabilities extend the basic capabilities for workflow execution (WebSphere Server Foundation) and portal development (WebSphere Portal Server). The direction for this platform is to re-architect its capabilities to allow them to be combined in more flexible ways. The middleware platform can be considered the execution platform for an ESB architectural style in which services can be defined, deployed, executed, and communicated through a common event mechanism.
• The IBM Programming Model. The capabilities of the middleware platform are substantial and complex, but significant changes to the runtime programming model are underway to simplify the view a software practitioner has of the capabilities the middleware platform makes available. This, of course, will present a services-oriented view, abstracting many of the underlying implementation details that will be managed by the middleware infrastructure. This will bring together Service Data Objects (SDO) as a uniform abstraction for different sources of data; JService as the way to describe services, services assembly, and services interactions; and portlets and JavaServer Faces (JSF) as the user interaction view. These concepts will be directly supported in the middleware platform as it evolves to support an ESB.
• WBI Server Foundation Tools. The services must be described in sufficient details that they can be choreographed to support business tasks by a business integration specialist. The WBI Server Foundation Tools present a graphical workflow view of the services; they allow a business integration specialist to map the business processes into services that have sufficient detail that they can be executed on the ESB. This tooling supports the “wiring together" of services that come from multiple sources (partner provided, wrapped legacy systems, and newly constructed). Support for BPELWS provides a standards-based approach for describing business workflows, and ensures a measure of interoperability among workflow execution engines.
• WBI Workbench. Describing the overall business goals requires tooling suited to domain specialists, such as business analysts. The WBI Workbench provides the WBI Modeler tooling to support definition of business activities, organizational structures, shared artifacts, and resources. Business processes can be modeled and their behavior simulated to improve business understanding and to optimize business workflow design. These descriptions can then be used to seed workflow execution and development activities. Executing processes in the ESB emit events that can be correlated to business activities in the WBI Monitor. This supports a range of business performance management tasks to tie operational systems to business processes.
• Rational Design and Construction Tools. ³ A rich set of modeling, design, and implementation tools are needed to implement services and assemble them into architecturally sound structures. The Rational design and construction products provide the capabilities to harvest components and services from existing systems, build new services optimized for the IBM runtimes, and architect application and services using industry-standard notations and techniques.⁴ Three initiatives are essential here: rapid design and development techniques to improve productivity, a quality-focus across the lifecycle, and strong analytical approaches to ensure quality of delivered services and solutions. Underlying team-based asset management capabilities ensure that the pieces and parts of a system can be readily identified, assembled, and managed.

Back to top

Toward the IBM Software Development Platform

While individual improvements in Rational product capabilities are important, the real value to customers is the combination of capabilities in a robust software development platform for creating and deploying this new generation of service-oriented solutions. Moreover, the vision being promised is a set of capabilities for managing IT projects with a level of accuracy and clarity that does not exist today. The notion of software development as a "business process" -- one that is measurable, predictable, and manageable -- offers a compelling vision that can only be delivered through the deep integration of tool and run-time capabilities across all different aspects of the business. Toward this goal, the recent announcement of the IBM Software Development Platform is a critical step. As IBM evolves and simplifies the programming model and middleware platforms based on services concepts and the ESB, our design and construction tools must reflect those changes in order to support solutions for deployment to that infrastructure. Five aspects are critical:

• Bridging the business-to-IT gap. It is essential to align the business view of activities and processes with the technology used to realize these activities. This alignment includes the ability for business models to drive downstream development, and to evolve the business models and IT solutions in combination. Common design practices are essential to ensure that the concepts, artifacts, and activities are synchronized.
• Supporting the changing roles in the IT organization. The move to services thinking changes the skills and composition of teams in an organization. The focus of development moves toward finding, defining, managing, and assembling services, with architectural descriptions highlighting service-level agreements (SLAs) and inter-service protocols. The traditional breakdown of tool functions into today's lineup of products is not appropriate for this approach. There will be a different blend of capabilities required by the different members in IT organizations. The skills required by existing roles such as "software architect" are changing. Similarly, new roles, such as “business integration specialist," are emerging.
• A focus on assets and reuse. Considering services as key assets in the design of systems changes an organization's view of the value of reusing these services. A service assembly viewpoint leads to "software factory" thinking. As a result, technologies and techniques for management and governance of assets, and repeatable ways to capture patterns for combining assets, become much more important. The team infrastructure for managing assets takes a key role in this approach.
• Increasing levels of collaboration within and across practitioner roles. IBM Rational has always recognized software development as a “team sport." For this reason, we have consistently focused attention across the lifecycle on managing shared assets, artifact traceability, and shared practices and processes. The collaborative nature of software development is becoming more obvious as development organizations 1) widen their geographic distribution, 2) enhance real-time communication among individual team members, and 3) use embedded software as part of broader systems development initiatives. Increasingly, the IBM Software Development Platform will be seen as a collaborative development environment that embraces and advances these trends.
• Simplification of product offerings. Renaming and repackaging IBM design and construction tool capabilities will greatly improve the delivery of those offerings to our customers, because we will make it easier to understand how these products offer optimum flexibility and value in delivering service-oriented enterprise solutions.

For practical efficiency, the creation and delivery of a rich, integrated Software Development Platform requires the move to a common tooling infrastructure based on our own shared components. We are applying this services-based thinking and approach to our own tooling. The Eclipse infrastructure (its plug-in architecture, meta-model framework, shared meta-models, and libraries of capabilities) makes this possible. Through use of common components among IBM development teams built upon this shared infrastructure, our customers can use IBM products together more easily, and our own development teams can create and maintain these products more efficiently.

For all the reasons stated, Rational has a significant role to play in the future of IBM. The product releases we announced last month (to be generally available in December 2004) are helping to redefine the software requirements, analysis, design, and implementation experience. This represents a major step toward realizing the promise of the IBM Software Development Platform, an evolution of the Rational Design and Construction tool workbench to support the new market realities, and an essential shift of focus toward IBM's strategic middleware platform initiatives based on service-oriented technologies.

Back to top

Notes

¹For instance, Nicholas Carr's recent book, provocatively titled IT Doesn't Matter, illustrates changing attitudes toward the role IT plays in an organization.

²Business Process Execution Language for Web Services.

²The Rational Design and Construction Tools includes the next generation of WebSphere Studio tools, as announced recently.

⁴While this paper focuses on support for the IBM middleware platforms, the breadth of platform support is much greater. For example, IBM tooling supports solution creation, language-specific and cross-platform debugging, testing, deployment, and monitoring that is a mix of Web/portal, Java, COBOL (generated or hand-written) and third-party package application connector technologies.

About the author

Alan Brown is responsible for the technical strategy behind IBM Rational desktop products. He is also a key member of the leadership team responsible for aligning Rational tools with products from across IBM that compose the IBM Software Development platform. In addition, he has been responsible for guiding the vision and strategy for the company's model-driven development tools.

He earned the title of Distinguished Engineer for his contribution to IBM Rational desktop products, as well as for his broader contributions to the future of the software industry. For more than a decade, Alan has been an industry thought leader, directing evolution of the developer experience through his books, papers, and numerous interactions with top IBM Rational clients. For more information about his work and ideas, visit his Web site at www.jorvik.com/alanbrown/index.html.

Alan Brown received his PhD from the University of Newcastle-upon-Tyne in 1988.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• The new reality
• A new view of design and construction
• The emerging design and construction landscape
• The IBM approach
• Toward the IBM Software Development Platform
• Notes
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into Rational on developerWorks

Try Rational System Architect

See how this fully integrated collection of models and documents can help you better align your IT systems and infrastructure to simplify business processes

Special offers