Predicts 2004: MDSFs Offset J2EE Complexity

Transcription

1 Strategic Planning, M. Blechar, M. Driver Research Note 22 December 2003 Predicts 2004: MDSFs Offset J2EE Complexity Model-driven service frameworks with architecture-based code generators will become as prevalent as traditional fourth-generation languages were in the 1990s and help less skilled developers build J2EE and.net applications. Core Topics Application Development: Architecture and Design for Application Development; Constructing Applications Key Issues How can AD organizations "architect" and design integrated applications that support new and traditional business initiatives? Is Java sufficiently mature for enterprise application development, and can enterprises manage the needed skills for it? IS organizations are increasingly deploying the next generation of Java 2 Platform, Enterprise Edition (J2EE) and.net serviceoriented architectures. J2EE and.net application development (AD) is moving from the "early adopter" phase of the market where approximately 15 percent of sophisticated "Type A" organizations have been primarily using these methods and tools into the hands of the approximately 65 percent "mainstream" development organizations (see Figure 1). Strategic Planning Assumptions Through 2008, IS organizations that use rapid application development methods and ISEs to deliver services and components can be at least 40 percent more productive and responsive in design and construction than those using a traditional 3GL integrated development environment (0.8 probability). Through 2008, IS organizations that use model-driven application development methods and MDSFs to deliver enterpriseclass services and components can be at least 60 percent more productive and responsive in analysis, design and construction than those using a traditional 3GL integrated development environment (0.8 probability). The MDSF market will experience at least a 30 percent compound annual growth rate through 2008 (0.8 probability). Gartner 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 Increasing Project Complexity and Developer Skills Requirements Figure 1 The J2EE Complexity Gap Application Complexity and Criticality Type A developers are 90 percent of the market prior to 2002 Type B and C organizations begin leveraging Java for missioncritical applications in 2002 Average Developer Skills Type A developers are 10 percent of the market by Source: Gartner Research (December 2003) Moreover, applications built in these architectures are moving from a simple, client-facing type to "enterprise class" solutions, which use Enterprise JavaBeans (EJBs) and C# components. Building and maintaining these solutions require developers who have a better understanding of technical architecture and moreadvanced design skills. Hence, a gap is growing between the skills of the average developer and the types of applications he or she is expected to build (see "Predicts 2004: Developing Java and.net AD Strategies"). Prediction Because of the growing complexity of applications being built in Java, coupled with less skilled developers being used to build them, IS organizations will increasingly turn to model-driven service frameworks to automate the generation of the more complex aspects of the code. Developers find the new generation of service-oriented applications inherently more complex to work with. For example, although traditional client/server applications may have shared reusable data in the form of corporate databases, in most IS organizations, process flow and business logic were generally transaction-specific. There was no issue comparable to building shared, loosely coupled services invoking highly shared and interrelated components, especially in terms of the volumes of 22 December

3 access made possible by Web interfaces. Nevertheless, developers trying to overcome the J2EE complexity gap face many of the same problems as they did with client/server applications. A similar set of circumstances prevailed in the 1960s, when only highly skilled technical programmers were able to build applications in native third-generation languages (3GLs) like the Assembler language. With the benefit of hindsight, we can see that the emergence of COBOL was a major step forward, enabling less technically knowledgeable people to write applications. During the 1970s, other solutions emerged, which ranged from 3GL workbenches to fourth-generation languages (4GLs) and code generators. These, in turn, gave way during the 1980s and 1990s to more-modern 4GLs and model-driven code generators. In fact, by the mid-1990s, the majority of IS organizations were using model-driven enterprise 4GLs, like those available from Compuware, Forte and Oracle. Most of these tools provided some "insulation" for the developer between the programming of data access/update and business and workflow rules apart from the actual deployment environment. Developers familiar with this history will not be surprised that a similar evolution is afoot today. Through 2003, the vast majority of J2EE and.net development has been done using program scripting in Java or VisualStudio "integrated service environments" (ISEs) focused on a codecentric and component assembly approach to AD (see "Modeling and Automation Drive SODA Productivity Layers"). Most ISEs come with some best-practice frameworks and patterns, which developers can reuse as they see fit. However, these do not enforce architectural compliance nor, in most cases, remove enough of the architectural complexity issues to enable mainstream developers to successfully build enterprise-class EJBs. As a result, the next generation of solutions is currently emerging in the form of model-driven service frameworks (MDSFs; see Figure 2). 22 December

4 Figure 2 Model-Driven Service Frameworks Patterns J2EE and.net Compliant Code Frameworks MDSF or UML Models Code/Rules Generator Business Rule Engine Runtime Business Process Management BPA Models BPM Workflow Rule Generator (Optional) BPA = business process analysis BPM = business process management J2EE = Java 2 Platform, Enterprise Edition MDSF = model-driven service framework UML =Unified Modeling Language Source: Gartner Research (December 2003) Like ISEs, MDSFs provide organizations with best-practice frameworks and architectural and design patterns as a starting point for development. However, unlike ISEs, the MDSFs enforce the use of these by generating, on average, at least 80 percent of the code, including everything dealing with the technical architecture. The frameworks and patterns can be customized by the IS organization's technical architects to follow corporate standards and allow for architectural uniqueness. MDSFs also generally have interfaces to leading Unified Modeling Language (UML) and business process analysis (BPA) modeling tools to reuse and automate the data and business models into code as well and not just the EJBs, but also the runtime workflow rules needed by business process management (runtime workflow) tools. Some of these tools are also beginning to generate rules for business rule engine products, instead of Java. Overcoming the skill gap is not solely a tool issue. Organizations will want to address related issues such as governance/ownership of shared processes, services and components, as well as changes to AD and IS policies, procedures, methodologies, and organizational roles and responsibilities. We do not expect MDSFs to replace the code-centric approach needed for the most-sophisticated applications (which make up approximately 5 percent to 10 percent) or, arguably, for the 20 percent to 30 percent of simple client-facing applications. 22 December

5 However, MDSFs will be important for the "sweet spot" that lies between these and is worked on by the bulk of mainstream developers. That said, as a reflection of the 4GL market's history, many IS organizations, rightly or wrongly, will continue to work in a code-centric manner on the majority of their AD projects. Given the complexities of the next-generation AD, however, we expect to see increased use of MDSFs, including a convergence of traditional integrated model-driven tools moving down into this space and ISEs moving up into this space. Strategic Planning Assumptions: Through 2008, IS organizations that use rapid application development methods and ISEs to deliver services and components can be at least 40 percent more productive and responsive in design and construction than those using a traditional 3GL integrated development environment (IDE) (0.8 probability). Through 2008, IS organizations that use model-driven application development methods and MDSFs to deliver enterprise-class services and components can be at least 60 percent more productive and responsive in analysis, design and construction than those using a traditional 3GL IDE (0.8 probability). The MDSF market will experience at least a 30 percent compound annual growth rate through 2008 (0.8 probability). Action Recommendation for 2004: All enterprises will need to move to service-oriented architectures, but they should do so at speeds commensurate with business opportunities, threats, and their levels of technical expertise and risk-aversion toward new technology. This will be a crucial point in the migration of the organization to maximize the value of services-oriented development of applications (SODA), and will require major changes to policies, procedures, standards, training, infrastructure and similar elements to succeed. Enterprises looking to "push the envelope" should focus on opportunities involving mobile computing. They should also focus on ways to automate business processes using Web services, business process modeling, workflow analysis, and design and business process management deployment software, to improve speed and agility. All enterprises should (minimally) have a metadata repository that promotes reuse of shareable assets such as services and components. Adherence to metadata standards will provide a "safety net" for SODA-built applications and open up opportunities as new standards-compliant business solutions emerge. All IS organizations should move to ISEs in conjunction with moving to a service-oriented architecture. 22 December

6 Acronym Key 3GL third-generation language 4GL fourth-generation language AD application development AMD architected model-driven ARAD architected rapid application development BPA business process analysis EJB Enterprise JavaBeans IDE integrated development environment ISE integrated service environment J2EE Java 2 Platform, Enterprise Edition MDSF model-driven service framework SODA services-oriented development of applications UML Unified Modeling Language Most organizations should move to architected rapid AD (ARAD) methods and tools as a primary way of enabling SODA. Enterprises able to handle the sophistication of architected model-driven (AMD) methods and tools should include them in their "tool chests" others should be less concerned about automation of business rules. Bottom Line: Gartner expects the model-driven service framework market, which will reach approximately $10 million to $20 million in 2004, to grow at a rate of at least 30 percent each year through 2008 as mainstream development organizations look to improve the quality and reliability of new applications. This growth will occur as a direct result of efforts to boost the productivity of less sophisticated developers. 22 December