Legacy software vendors that traditionally provide on-premise solutions still face a couple of architectural challenges. Those allow them to provide cloud-native applications as well as a solid foundation for offering a natural bedrock on which to construct bots, ultimately allowing them to offer a conversational user experience.
Many vendors of legacy software struggle to accomplish a smooth transition from a monolithic architecture to a cloud-enabled service oriented architecture, as such a transition involves rewriting, which comes at a significant price. However, the previous economic benefit of re-architecting to ensure a more efficient use of compute and storage resources is gone due to increasingly cheaper IaaS and PaaS services.
Re-architecting any major application is not only an expensive exercise, but it's also a daunting one. Prior to engaging in that, it is worth considering whether there is enough added value. It is true that by breaking down the monolith and splitting it into smaller services, you gain an advantage from the perspective of deploying modules independently, giving you greater flexibility when deploying new features to customers. Further, it allows you to organize teams more efficiently around specific domains — catering to more efficient teamwork, a higher degree of ownership, and more self-driven teams.
As most vendors would prefer to preserve and repurpose existing investments, but at the same time move to a modern cloud-native architecture, it is necessary to find new approaches to extending the existing application without adding additional, or at least minimal, code to the monolith.
These elements are definitely worth taking into consideration when balancing investing in different areas of the application; however, there could be a more efficient model. Rather than investing in re-architecting, the focus could be in extending the application. It wouldn't be in the traditional sense — by adding features within the existing code base; but rather by creating new services decoupled from the monolith.
The Embracer Pattern
The strangler pattern is about providing new features/functions in services, then slowly supplanting functionality in the monolith. The thinking is that over time, you end up having moved all functionality from the monolith into new services. To me, that is the same as a re-architecting strategy, just with another name. You will end up re-developing functionality in the services already existing in the monolith. If you do not do that, you will not get rid of the monolith anyway.
The embracer pattern is about embracing the monolith, rather than strangling it. Fundamentally, the idea does not differ significantly from the strangler pattern. Rather than incrementally moving functionality from the monolith when features need to be enhanced, the embracer pattern embraces the functionality within the monolith and focuses on providing an abstraction to existing functionality while also on combining existing features within the monolith in new and interesting ways.
The services being created as a result of the embracer pattern acts as a service oriented service layer encapsulating the monolith by exposing a new API toward new external consumers of the services offered by the monolith. The embracer services are fine-grained access to specific functions within the application — and also where new features should be implemented.
Figure 1: Embracer API as Services
Bots and Conversational User Experience
Recently, another paradigm shift happened in the user experience space. A number of tech companies announced embracement of conversational user experience in either their platform offerings or solutions. However, there is more to providing a conversational user experience than the technology alone.
The Functional Aggregator Pattern
Generally, monolithic applications work by means of users executing a number of tasks manually through a user interface. User interaction will, over time, become very repetitive in nature — as most users tend to do the same tasks over and over again. Some applications provide macro-like functionality for capturing and repeating those interactions, eventually by showing entry screens when input is required. A well-known approach to this is VBA for applications from Microsoft — where one can write small applications that run within a host application, offering some level of automation. This being said, the users will still need to interact with the software using a graphical user interface.
This repetitive nature of application usage, where casual users follow the same path through the application each time they are using it, is a constant source of frustration. Another source of frequent frustration for the casual user is dealing with seldom-used functionality within the application. In this case, the frustration stems from the fact that infrequent use causes users to forget routines. It becomes a re-learning experience each time a casual user needs to deal with a specific, infrequently used, functional area of the application.
The Functional Aggregator Pattern is about leveraging existing functionality within the application from outside. Rather than implementing templates, macros, etc. to the application, you would implement intrinsic functionality from, to the application's point of view, the outside in an external service.
In using a combination of the embracer and functional aggregator patterns, software vendors can efficiently transition to a cloud-enabled architecture while retaining the investment that, over time, has gone into constructing the original application. The combo also provides a new functional service layer, offering access to the functionality — within the monolith — at a higher level.
Figure 2: Functional Aggregator and Embracer Pattern Driven Architecture
The new functional service layer functions as the glue between the digital assistants — like Cortana and Wanda — to provide a conversational user experience. An additional benefit facilitated by the patterns is the ability to provide a functional reach API for developing custom applications.