Application development and deployment is changing, perhaps as fast as it has in the history of IT. Not only that, the sheer number of different drivers for change and the areas that these changes affect have exploded. It's fair to say that application lifecycle management (ALM) has become the battleground for dealing with many of these changes. This is particularly true of Java ALM because Java itself is transforming. Today, Java ALM and Agile lifecycle management methodologies may be poster children for all the ALM issues the future will bring.
Enterprise applications of Java have followed the evolution of web-driven and mobile computing. Client devices, using apps or browser interfaces, interact with a web-like component that manages user sessions and hands off to a transaction management layer that provides an interface with traditional business applications. Java's application to enterprise computing has historically been in the presentation and transaction management layers.
Moving beyond waterfall development practices
The differences in technology between these layers and the different drivers that influence them encourage businesses to treat the layers as separate applications and to specialize ALM accordingly. Businesses have used the layer transition points as integration points to join different technologies and different ALM and Agile lifecycle management practices. This worked well with traditional waterfall development, but Agile development and continuous delivery initiatives have put the old model under stress.
That stress has been exacerbated by the increased use of Java deeper in the bottom or business application layer. Web services, and most recently microservices, encourage businesses to build useful application features as independent services accessed in a REST/web-like way, and Java is a perfect tool for this kind of development. In fact, Java 8 is being enhanced specifically to support this transformation of role. As this happens, ALM practices for Java are no longer stopping at that presentation/business layer interface.
Java developers tend to think more in terms of interactive development tools than in terms of broad ALM. The IDE roots of Java ALM reflect that original layered separation of Java from the rest of application development, and the numeric majority of Java IDEs tend to be specialized to a presentation mission (like Android development). Java ALM has evolved largely through accretion, by adding new open source components to baseline interactive development and project tools, nearly all of which are open source. The total collection of Java project tools -- from GitHub to Eclipse NetBeans and Mercurial -- can assemble a Java ALM approach.
Enhanced ALM tooling
Most large enterprises believe that ALM and Agile lifecycle management are facilitated if there's a unified tool available and if the tool handles all the languages used as well as compliance/security and project needs. The scope of things Java can run on and the number of missions it supports, combined with the application-layering practices of today, seem to be driving Java in the other direction. The decision of Inland Software to shut down its popular JavaForge open source development site and focus on the broadly capable codeBeamer ALM that formed the basis for JavaForge shows that Java ALM could easily be subsumed into broader ALM tools and practices. Whether it happens may depend on how those two stress factors introduced above develop across the market.
Whatever the potential for top-to-bottom use of Java in development might be, the practice is still to concentrate it in the presentation/device layers of applications. As long as that's true, then Java will have to coexist with other languages, and a Java-specific ALM model won't address all of a company's application needs. The specific Java edition associated with lower-layer business processes in applications is the Enterprise Edition, and many EE users are just confronting the migration to Java 7 EE; Java 8 EE is still being specified. While Java 8 has many strong features for business programming, including functional programming enhancements, it may be some time before they're rolled into production at the large businesses that need ALM the most. Even when they are, they won't immediately replace current business application implementations.
The evolution of ALM
Meanwhile, the Agile development and on IT organizations is mounting. It's difficult to collect all the possible ALM components needed for a Java-centric ALM toolkit, a formidable integration task in itself, when additional Agile/continuous delivery pressure is expanding and changing the functions needed. Open source projects are especially hard to evolve under diverse requirements pressures because there's no central coordination of features or even interfaces.
The Agile development and continuous delivery trend focuses on software projects, testing, version control and production release.
Java ALM could still evolve -- and even dominate. The Agile development and continuous delivery trend focuses on software projects, testing, version control and production release. These activities grow naturally from IDE-centric development and can be integrated with most IDEs fairly easily. Endeavour Agile ALM is an example of a project-management-driven open source ALM approach compatible with Java development, and there are other tools for test management and compliance management that can be added.
Commercial tools have the advantage of integration, but integration is difficult to accomplish in a rapidly evolving environment. Open source software is also the most important trend in software overall, the focus of more and more businesses. Eventually, best practices will create a reference architecture for Agile lifecycle management that creates open source tool convergence. Since Java is the most popular of all programming languages, it's likely this will focus on Java. Combine this with the enterprise-friendly Java 8 and Java 8 EE, and with growing support for microservice and functional programming in Java, and you could see all of ALM become Java-dominated.
ALM at the practice level has to be considered an ecosystem, not just a product hodgepodge. Java and Agile lifecycle management will certainly play a role in ALM evolution, and Java's own requirements and capabilities are already shaping the way we design and deploy applications. As applications become more inherently multi-platform, multi-layer, multi-host and multi-cloud that trend can only accelerate.
