I’ve spent most of my career working in or running software integration businesses. It began with object brokers, then middleware, then ESBs and subsequently included all manner of adjacent technologies including event processing, process modelling and process mining. New application architectures were developed to exploit this infrastructure, enabling ever greater levels of re-use and flexibility.
For me however, the idea that you could design an enterprise application without any appreciation for the UI simply made no sense. Database schemas were built that were great for backend data manipulation but no-one seemed to appreciate that a well-designed user interface would place additional requirements and constraints on those schemas and indexes etc Time after time, I saw the UI being designed at the last minute (by a non-UI developer), only to realise that when deployed it was next to useless and/or incredibly slow.
More worryingly, the way that UIs were being developed meant losing all of the benefits of having a granular and re-composable back-end. To me, this was the ‘dark-side’ of the integration business, the tender under belly where no-one dared look.
For example, web-services were used to decouple backend components from each other – yet no-one seemed to worry about the monolithic and inflexible UI that was being developed for the application front-end. Even as the balance between client & server ebbed and flowed over the decades, the UI code-base grew in complexity and size, making the absence of a technology agnostic front-end architecture even more critical. Needless to say, the UI is the last mile of the integration journey and the most difficult part to fix.
Now, decades after we embraced (back-end) middleware, it seems that we are beginning to make progress on the front-end. If you live in the world of financial services, you may be familiar with the concept of ‘interop’. This is where light-weight platforms are deployed on the client side to allow applications to talk to each other, allowing functionality built in different languages to ‘interoperate’. A good platform will also support inter-client comms via a ‘UI bus’; the better ones will also embrace open and other-vendor APIs to allow maximum connectivity.
In the last year, the FINOS foundation has promoted the idea of standards to help client-side application components to find each other at runtime, each offering a statement of intent so that their capabilities can be determined. Add to that an ability to seamlessly weave a new user experience from existing UI elements and you’ve got something that supports the concept of the ‘micro frontend’. Better still, this new level of componentization is forcing application developers to reconsider what an application really is. No longer should this be the single monolithic application that believes it owns the entire screen real-estate. Instead, it should behave as a good corporate citizen doing the minimum needed (and no more) to complete a well-defined atomic task, combining logic and UI within a re-usable component.
Sure, I accept this is not ground breaking. All I’ve said here is that what is good for the back-end is good for the front-end too! The “new-news” is that companies like Glue42 are leading the way to combine enterprise-class security, scalability and UX management with an ability to integrate with just about every technology in sight.