At WSO2, we pride ourselves to have built a very strong runtime platform, which is called Carbon. All products are based on Carbon, no exception.
For Carbon V5, we rebooted the architecture to make it leaner, as it had grown a bit of a fat belly over the last 8 years, but the principles remain the same: modular, composable, extensible architecture. We continue to leverage OSGi, which has served us well, but we are removing the dependencies on technical components which also served us well, such as Axis2, but have unfortunately grown old and are not so fit for the new IT world.
Developer Studio, which is based on Eclipse, already has a modular/extensible architecture. In V4, we are just changing the packaging so that each product team can release their tooling individually. Starting very soon, you will see appearing dedicated tooling for each product (such as Dev Studio for ESB) on every product page but of course, as for Carbon, you will be able to combine the ESB features, for example with the DSS and CEP ones if you need to to have a single IDE across all the WSO2 products.
For analytics, Data Analytics Server (DAS) is our combined offering for all types of analytics: batch (analyzing data at rest), streaming (analyzing data in real-time) and predictive (learn from existing data and predict behavior). Again , Data Analytics server serves well as a platform, since applications to be installed on top (aka toolboxes) are packaged individually and deployed. So Data Analytics for API Manager will be nothing more than the DAS product with pre-installed toolboxes for log analysis, API activity and technical monitoring. Similarly to Carbon and Dev Studio, analytics for multiple products can be combined on a single DAS server.
In fact, in order to provide a consistent experience across a large number of products, you have no choice but thinking about the underlying components first. What I explained above extends to our stores (API Store, Apps Store, Processes Store, etc.) . To do that right, we first created an enterprise store, which is really a framework for building your own store. To build dashboards for analytics, we needed a dashboard product, on which our teams could build their own visualizations and gadgets. That was User Engagement Server, now renamed as Dashboard Server.
This philosophy can be represented in the diagram visible below: at the bottom, you find the foundation servers and frameworks. On top of those, product teams build extensions and don’t have to worry about the core functionality of the framework. Of course, customers can also create extensions, or modify the default ones, typically adding their own analytics and own visualizations.
At WSO2 we are committed to this approach, as it has allowed to quickly evolve and innovate in the past 10 years. Customers benefit from this in many ways, primarily on consistency in installation, behavior, or operational management.