"The wonderful thing about standards is that there are so many of them to choose from."
This was said decades ago by network guru Grace Murray Hopper, but the same might be said for middleware today. In an effort to facilitate development and accommodate trends like mobility and virtualization, vendors have introduced a bewildering variety of middleware tools that are individually helpful, but sometimes collectively incompatible or unwise.
To harmonize middleware and foster consistent practices, development managers and architects need to visualize applications in a multidimensional framework of needs and resources, consider the "prime motivator" in their application evolution, select a primary toolkit and harmonize related middleware through middleware-focused application lifecycle management (ALM) practices.
It's always been true that development processes at all levels have to harmonize with two things -- the goal of the application in a functional sense and the resources targeted for application use. Sadly, middleware has not always been seen in either context. Many developers and architects see middleware purely as a programming accommodation, a view that can create conflicts as applications evolve.
Shifting attention where it matters
Traditional development practices tend to focus attention on each application rather than the broad mission being served. This creates middleware issues, as middleware is often central in adapting applications to business changes and resource policies. Developers need to consider more than the application itself; they need to consider the application systems, changing functionalities and resource needs.
Applications today support three primary functional goal frameworks: Web-retail, mobile-productivity and process-workflow. Web-retail apps are about presentation to buyers and partners, mobile-productivity apps about information dissemination to workers and process-workflow apps about chained transactions or process control. Java platforms are the preferred approach to Web-retail application development today, mobile middleware for the mobile-productivity applications, and service-bus or SOA tools for transactional- and process-control applications. Start your middleware harmonization by assigning your application to one of these groups. Then focus on the primary tools associated with it.
On the resource side, the cloud dominates technology planning, and so any application middleware selections should accommodate cloud deployment. While the public cloud gets all the attention, the reality is that nearly all midsize and large businesses will retain their own data centers for the foreseeable future, so hybrid cloud deployment of applications can be expected. That means that after the functional considerations have established a middleware framework for applications, the framework options should be tested for hybrid cloud readiness.
That's the next step in harmonizing middleware. Broad requirements like hybrid-cloud-readiness and application-specific requirements that are supported via middleware are considered within the framework of the application architecture you've selected. It's best to start with the areas that are most important in terms of application design and development, as well as those where middleware choices are the most limited.
What makes this step challenging is the multiple layers of relationships among middleware products and the threat that application evolution -- in either functional or resource terms -- appears to pose to middleware decisions. Development managers are often encouraged to adopt a piece-part approach rather than adopting a suite of middleware tools to avoid having to make radical changes should business needs or resource commitments change. It's a valid fear, but one that can be managed.
All three of the functional application categories -- Web, mobile and workflow -- are evolving slowly toward a common microservices model. That model is inherently cloud-compatible, providing that the component integration and service design processes are designed to be cloud-friendly. This is less a middleware issue than an application design approach. For example, RESTful microservices should be written to support either front-end (client-side) or back-end (database) state control. That means that all three of the application classes should use these principles; this will reduce the largest risk of forced change as business and resource policies evolve.
Selecting your middleware
For the actual middleware selection, look for suites that integrate without creating silos. Major software vendors like IBM, Microsoft, Oracle and open-source champions like Red Hat all provide complete middleware strategies for all three functional application categories, and they are all designed to support hybrid cloud applications. Look at the suites that are most compatible with your current applications, but also look at the middleware elements in each to ensure that there are competitive alternatives. The fact these alternatives exist shows that the vendor isn't creating a lock-in with their products, one that could tie you not only to that vendor, but to a single approach that might prove less than optimum down the line.
Selecting middleware from the top down like this should significantly reduce your need for more detailed harmonization, since the mission dependencies of the top-level choices will drive features that will then influence lower-level choices. However, even if this top-down approach results in selection of a harmonious middleware suite from a single vendor, with add-ons or substitutions only where needed, you'll still have to test the unity of your result.
Managing your middleware's lifecycle
Middleware-driven ALM is, or should be, different from basic ALM. With ALM, the goal is one of certification of the present, but with middleware-driven ALM, the goal is as much to preserve the future. You're selecting a set of middleware tools because they'll work together not only in your current application model, but in the future models that will evolve. That means testing the features that provide proof of that harmony, even when they're not currently used.
You can't write future applications today, so the key with middleware-driven ALM is to find test suites and test generators that will exercise the features and then design tests that validate middleware harmony everywhere your likely application evolution might lead. This isn't as difficult as it might sound, because most middleware applications have test frameworks available. It's just a matter of assembling them into an ALM suite.
Organization is the key to successful IT, and middleware selection and use demands it in particular. Take a top-down, hierarchical approach to your middleware decisions and ensure your application design overall handles the evolution to the microservice model, and you'll spare yourself and your company a lot of grief.
Prepare for potential middleware tool security risks
Discover how middleware can be used to speed software delivery
Learn more about IoT middleware.