COM M. Blechar, M. Light

Transcription

1 M. Blechar, M. Light Research Note 17 January 2003 Commentary ARAD Brings Architectural Compliance and Developer Productivity Architectural and design patterns and frameworks enable enterprises to leverage the skills of their technical architects, ensure that their applications are compliant and highperforming, and improve developer productivity. In the past, we have written about the trends in methodology (see "Relating Business Processes to Technical Implementations") in which organizations were moving from traditional "waterfall" structured analysis and design approaches such as Yourdon, Information Engineering and Structured Systems Analysis and Methodology (SSADM) to object-oriented (OO)/Unified Modeling Language (UML) and business process analysis (BPA) methodologies (see Figure 1). These trends are continuing, as organizations evolve toward service-oriented architectures such as Java 2 Platform, Enterprise Edition (J2EE) and.net which require a better understanding of business process flow and object orientation for effective implementation in OO languages, such as Java and C#. Gartner 2003 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.

2 Figure 1 Methodological es to Application Development Traditional Waterfall OO/UML BPA Planning Business Process Modeling Analysis Construction Analysis Build and Assemble Workflow Workflow Assembly Programs Component Wrappers Data Source: Gartner Research Objects/ Components Deployment Framework During the "transition period," most enterprises will need to support at least two of these methodological approaches concurrently. We are increasingly seeing modeling tools move to support all three approaches, as well as database design, simultaneously in one tool or by providing bridges between those that are best-of-breed in each category. Any of these methodologies could be used with different degrees of rigor for a given project, such as where requirements and deployments are done in an iterative manner or where phases are deemphasized. For example, in simpler applications or for those in which time-to-market pressure is severe developers may perform few, if any, planning and analysis steps (see Figure 2). 17 January

3 Virtual Enterprise Figure 2 Project es vs. Application Types (Low) Application Complexity (High) AMD Enterprise Architecture Reuse Shareability/ Constituency NeoRAD ARAD Organizational Process Capability Workgroup Code, Fix (Refactor) Source: Gartner Research (High) Application Volatility (Low) Architected Model-Driven (AMD) Projects: This approach focuses on such issues as quality, flexibility, performance and reuse. In most enterprises, this project approach would be applicable for, perhaps, 30 percent of the application portfolio. An AMD project approach is most appropriate for applications, services or components that require robust analysis to understand the business rules and requirements and automate their design and delivery for maximum reuse and performance. It presupposes a development environment in which analysis and design models automate code generation and a development framework that supports large numbers of developers able to share artifacts within and across development teams and application releases. Fewer than 30 percent of all enterprises are able to handle this level of sophisticated development, and even those that do generally have less than 30 percent of their staff using these types of methods and tools. Therefore, many enterprises are looking for ways to be successful with less-sophisticated developers. As will be seen, some aspects of architected rapid application development (ARAD), such as architectural and design patterns, are also making AMD applications easier to develop, but will not fundamentally change the challenges to automating business rules based on models using an integrated development framework. Neo-Rapid Application Development (NeoRAD): This approach represents the approximately 30 percent of applications at the other extreme a project focus driven by time-to-market and low initial cost with limited design activities mostly, a "code and go" attitude. Here, the presumption is that applications, services and components will be delivered as quickly as possible with the intent of modifying or extending them over time using iterative improvement techniques. RAD programming fourth-generation languages (4GLs), such as Visual Basic (VB) and Java integrated development environments (IDEs), fit this approach well, especially when the applications are simple, developers are working independently or in small teams, and the real-time sharing of the artifacts being developed is limited to each project team. However, RAD applications can be poorly defined in terms of performance and reuse. As a result, many enterprises have sought ways to improve the design of the application via such NeoRAD methods as the dynamic systems development method (DSDM), "Xtreme 17 January

4 programming" (XP), feature-driven development, adaptive development and others, and many have reported substantial improvements over previous RAD methods. However, too frequently, what is rapidly built runs poorly and is costly to maintain. As will be seen, ARAD helps overcome this problem to a large degree. From Rapid Architected Applications Development (RAAD) to ARAD: In 1995, we first addressed the trend away from traditional AMD methods to more time-boxed techniques, using iterative development concepts from RAD and automating programming aspects related to the technical architecture using the acronym RAAD. This trend has been altered somewhat by the emergence of J2EE and.net, as well as related architectural standards and solutions. As previously mentioned, the iterative aspects of RAAD have crept into the AMD space. During the past five to eight years, we have seen users of structured analysis and design methodologies go to time-boxed approaches and add object/component design techniques. For example, many of the integrated, modeldriven code generators modified their tools to support a hybrid version of information engineering, with some OO concepts in the analysis and design phases of the methodology, even if the application was ultimately delivered in a standard third-generation language (3GL), such as COBOL. Other enterprises have adopted BPA and OO/UML methods to do analysis and design, with bridges into traditional 3GL and 4GL workbenches, while others are using these with newer OO languages. ARAD: Thanks to such new standards as J2EE,.NET, UML, XML/Simple Object Access Protocol (SOAP) and model-driven architecture (MDA), coupled with new development technologies, RAAD is becoming something new, which we've dubbed ARAD. At the heart of ARAD is the ability to take the J2EE and.net architectural and design patterns delivered with the newer development technologies, have the enterprise's best technical architects modify them to adhere to the organization's architectural standards and then have the ARAD technology generate all code involving the architecture in applications in a compliant manner. Early reports indicate that this can save an average of more than 70 percent of the coding effort for most applications. It also means that the programmers adding the non-architecturerelated code don't need as much expertise in J2EE and.net architectures, and the resulting applications tend to perform better and more reliably. A second aspect of ARAD is the business process flow. Many of the newer technologies are able to take UML or MDA business process models and generate the workflow specifications needed by business process management (BPM) software, which sits on the J2EE and.net servers (such as WebSphere Business Component Composer for IBM's WebSphere application server and BizTalk for Microsoft's.NET application server). This, again, increases developer productivity, because there's less code to build. It also decreases the programmer's need to understand the business processes and ensures compliance of the runtime workflows with the business processes. (For more on BPA, see "Business Models: The Architecture That Pays for Itself.") ARAD requires a move from structured analysis and design methods to OO/UML or BPA techniques; however, the benefits of this approach are obvious. There's no better way to improve productivity, reduce cost, and ensure scalability and performance of applications, while still putting methods in place that are "minimally invasive." ARAD will still be overkill for many of the simpler NeoRAD applications. And, morerobust AMD methods will still make sense for a portion of the application portfolio (AMD has the potential to be five to 10 times more productive when reusable models and business specifications managed in an integrated development framework can be used to regenerate code as business rules change). However, for most enterprises and applications, ARAD should prove to be a near-ideal approach to balancing speed and cost with "just enough" application quality and performance. 17 January

5 Balancing the AD Portfolio: Most enterprises will find that a balanced approach to developing the applications in the portfolio will look something like NeoRAD (20 percent to 30 percent), ARAD (45 percent to 55 percent) and AMD (20 percent to 30 percent). Although AMD has the greatest potential for factorial improvement of quality, productivity and total cost of ownership (TCO), through 2006, enterprises are advised to use this approach only on projects where rigorous software processes can result in widescale reuse of business rules, which is, generally, a minority of projects. ARAD, on the other hand, will be the most appropriate choice when the focus is on reuse of technical architectures and design rules to balance speed, cost and just-enough application quality and performance. Bottom Line: Emerging standards and newer Java 2 Platform, Enterprise Edition (J2EE) and.net technologies now support architectural and design patterns and process flow automation capabilities using an architected rapid application development (ARAD) approach to building applications. Most enterprises will find substantial advantages in changing to ARAD-enabling tools: programmer productivity, assurance of more-compliant and high-performing applications, less need for more-knowledgeable developers and automation of business process flows in a more dynamically changeable environment to improve responsiveness. 17 January