May 3, 2018
What makes AppBus unique and how it enables companies to realize a true service oriented strategy
While the term “micro-service” has at this point been through the full hype-cycle, even the most cynical reader will agree that a service-oriented strategy can provide many benefits to organizations. When properly executed, it allows organizations to much more rapidly add, extend and integrate services. However, the realities of actually implementing this strategy are often more complicated than they first appear.
Companies like MuleSoft can provide a lot of value in helping rationalize a heterogeneous API ecosystem. While those platforms are necessary, they are not sufficient for realizing the value of a service-oriented strategy. In the real world, companies have applications that can be challenging to incorporate into this model. Sometimes this is due to a large existing tech footprint, but can also be the result of reliance on third-party systems that do not cleanly fit into existing frameworks. Additionally, services often need to be bundled and delivered to users, which is a non-trivial problem that is justifiably outside the scope of platforms like MuleSoft. On top of that, the agility gained from a service-oriented strategy is only useful if your organization understands the needs of the business. Therefore, incorporating activity data from how users interact both with and across applications is critical to the design feedback loop. In this last installment of the three-part series,The Mulesoft Acquisition and Importance of Context we will discuss some of the features that are unique to AppBus and how they can complement existing ESB platforms (MuleSoft, TIBCO, etc,).
Doing more with less means preserving value where it already exists
Preserving the value of existing applications while providing a framework for securely integrating and delivering new applications are core value propositions of the AppBus eXperience Platform. AppBus is able to do this by providing a secure end to end platform for the uplift, integration, and delivery of applications and services. To understand how AppBus can accomplish this, it can be useful to segment the AppBus eXperience Platform into three components: the integrator, the distributed application bus, and the edge container. These components are analogous to RPA solutions, ESB’s and mobile container providers respectively. While these product categories are valuable in their own right, there is substantial effort involved in integrating across these three adjacent technologies. Since AppBus provides a unified platform, significant efficiencies are realized from the interoperability between these three components.
Applications that require user interaction
For better or worse, the view layer of many applications is tightly coupled with the data layer. Some applications lack API’s or have API’s that are not fit for direct consumption by 3rd parties. These applications still provide value and are often required to participate in the service economy. However, without some form of well defined programmatic interface, ESB solutions provide insufficient support for interfacing with these applications. AppBus’s Integrator provides ways to mount programmatic interfaces on top of a wide variety of existing application types (.Net, Java, Web-based, 3270, etc…). AppBus can be used to drive automated workflows or simply provide a way for a solution like MuleSoft to interact with these types of applications. The Integrator has many of the capabilities you’d expect from an RPA tool; however since AppBus’s focus is on integrated workflows and delivery, it provides a level of interoperability and access to the underlying applications not seen in RPA tools.
The areas where MuleSoft and AppBus’s distributed application bus overlap was discussed in some detail in Part II of this series. However, one area that was not thoroughly discussed, which is unique to AppBus, is the concept of a “distributed application bus”. “Distributed” in this context does not refer to a bus’s ability to scale horizontally (capabilities that both MuleSoft and AppBus possess), instead it extends the bus paradigm to the edge. For example, let’s say you would like to integrate three applications that are running on a given VDI. It wouldn’t make sense to rely on a centralized ESB to pass data from applications running on the same machine. Many workflows involve a single user accessing multiple applications on a single VDI. AppBus allows you to design the integration and automation of the applications using a bus architecture and still scope the data appropriately. When data needs to be shared between users or VDI’s, AppBus’s middle tier provides the functionality of a traditional ESB.
What is built must be delivered
Once applications are built, they need to be consumed by users. The delivery of applications to the edge is outside the scope of most integration and API platforms. This last mile delivery can be challenging to implement securely and in a way that is truly cross-platform. AppBus Container provides many important security and workflow management functions and is available for every major edge device operating system. All data is encrypted in-motion and at-rest, only approved applications can run inside the container, and n-factor authentication methods can be easily layered on top of existing applications. By being able to securely deliver and integrate existing applications, you effectively extend the total lifetime value of applications without compromising user experience or security. Additionally, because AppBus manages the container, administrators have a rich audit log of what the user is doing in and across applications.
In this three-part series, we covered various aspects relevant to MuleSoft, its recent acquisition and how it relates to AppBus. In Part I we examined why context is so important when developing services, and ultimately why MuleSoft was such a strategic target for a company like Salesforce. In Part II we addressed the common question we are often asked which is where do the two platforms overlap in functionality? In this final part, we discuss some of the features unique to AppBus that are essential to realizing the value often promised when pursuing a service-oriented strategy. Using traditional methods, there is a tension between what users expect from their technology and the business’s need to preserve the value of existing technology investments. With AppBus, there is no need to compromise. The AppBus eXperience Platform satisfies the expectation of users while preserving the value of existing investments and securely delivering superior experiences to the edge.