Sunday, February 12, 2017

Why a developer does not need to learn a new programming language or an API to work with RoboMQ?

There has been a huge amount of research in the last decade indicating that learning a second language is beneficial to a child’s cognitive growth and his or her future potential. Research has indicated that children who speak multiple languages have better attention spans, advanced grammatical skills in their first language, greater professional success later in life, and an overall faster development. In more recent years, a preference has arisen against learning new language and rather be able to do what you want using any language that you already know. However, this trend is not among the bilingual elementary schoolers, but instead among the trained programmers.

For years, it has been the norm for a programmer to teach him or herself a new programming language or a new protocol in order to develop a specific project involving new needs or a new technology. And the reality of our industry is that such situations are more frequent than we think. We live in an industry where the pace of change is much faster.
There are a lot of businesses out in the tech world that use specific protocols and programming languages for their businesses. In order to work alongside them, a developer would have to take the time and effort to learn a new programming language or an API (Application Programming Interface) in order to provide specific services. This process could be tedious and would generally slow down the developer productivity. This also has a cost for the organization. The organization has to hire a pool of developers with specific skill set in terms of the programming language and data protocols or the APIs for its specific initiatives.

However, there is now a solution to this inconvenience. RoboMQ is a protocol and programming language agnostic middleware, which means it can do the protocol or the API translation for you!

RoboMQ is an integration middleware and microservices development platform that support all available protocols and APIs out of the box. The microservices are independent and atomic containers which implement the business logic and are developed by the programmers. These microservices are chained together in a workflow by Message Oriented Middleware (MOM) provided by RoboMQ. The Microservices acts like workers specializing in a task picking the job from the input queue and dropping the processed output in the output queue. Since the interaction of the microservices to the rest of the world is via the message queues, they can be programmed in any language of your choice.

Fig 1: Microservices written in any programming language work together in a workflow chained by protocol agnostic message oriented middleware

RoboMQ was was built for the future, which is already here, where there is huge diversity of the data interchange protocols and APIs. In this world, the applications co-exist following different protocols or APIs and are still able to exchange information and work together. To support this model, RoboMQ does not have an API of its own. It can accept any of the industry standard protocols or the APIs and provides protocol converters and translators at the core to perform the translations among them.

RoboMQ is versatile and developer-friendly: we aim to create a positive experience in which developers do not have to learn new protocols or languages and spend a lot of time and energy making themselves up to speed to use our product and services. They can be productive from the get-go using the skills they already have to integrate systems or build business workflows using microservices.

If you are interested to learn more about RoboMQ, contact us at or check out our website at

Wednesday, February 8, 2017

Bimodal IT, SaaS & Hybrid Cloud– an opportunity for the CIO/CTOs to embrace

What is Bimodal IT?

It is same as the “shadow IT” or the application server under a business analyst’s desk. This is the same server that one fine Monday morning does not work because the business side analyst who owned and operated it has left the company. This server was running critical reports for the executives and nobody knows why the report was not generated this fateful Monday. IT is running around like headless chicken to find the issue with no clue or the trace of this application. Finally, someone connects the dots between the report and the analyst that who left the company. Now IT is on it, to get things under control and provide an enterprise grade quality of service that is its charter to deliver.

Sounds familiar? Many of us who have spent some years in a corporate IT will relate to it. Just another day, another story... isn’t it? But this is after all the craziness and the fire fight on the Monday morning that you had to suffer.

As a CIO or the CTO do you want to have such a Monday?

Let’s look at it. What is this mess wrapped in fancy tongue twisting word “Bimodal”? A quick google search will tell bimodal as having two modes.

1.    having or providing two modes, methods, systems, etc.
2.    Statistics. (of a distribution) having or occurring with two modes.

Gartner defines Bimodal as the “practice of managing two separate but coherent styles of work: one focused on predictability; the other on exploration. Mode 1 is optimized for areas that are more predictable and well-understood. It focuses on exploiting what is known, while renovating the legacy environment into a state that is fit for a digital world. Mode 2 is exploratory and experimenting to solve new problems and optimized for areas of uncertainty.” 1

Fig 1: Mode 1 vs. Mode 2 - two required elements for growth and sustainability

Predictability vs. exploration, well known state vs. experimentation, new ventures vs. keep the current market share, change or stay the course – these are all the choices that we face in business and the marketplace every day. The Bimodal IT is no different, it is facing these same tough choices in the digital world. However, as technology leaders, we need to manage these apparently conflicting, yet mutually reinforcing modes to continue to grow and adapt to the changes in the marketplace while minimizing the impact or the damage like the one on the fateful Monday morning.

Fortunately, there is a better way now for the technology and the business leaders to collaborate and continue the Bimodal IT without hiding the application servers under the desk. SaaS applications or a Cloud-first strategy could be the answer.

SaaS applications offer an easy way for the mode 2 where at a low cost you can try and play with the new ideas and explore features with new and highly specialized SaaS product. The business analysts and LoB (Lines of Business) executives can experiment new ideas before the company adopts these SaaS products or the new way of doing things. SaaS applications come with the leading edge features and tooling since they are built for the collective market segment. You can easily adopt best of the breed practices for your industry at a fraction of the cost using these SaaS applications.

SaaS applications also do not carry the same risk that exists when someone runs an application on a server under his or her desk. The SaaS vendors provide enterprise grade quality of the service, reliability, 24x7 uptime, disaster recovery, upgrade etc. at a fraction of the cost thanks to the economies of scale. Once the organization decides on using a SaaS application, the IT team can seamlessly take the ownership of the application, if required, and transition to Mode 1 providing the reliability, assurance and peace of mind. 

The one key challenge that remains is the transition to Mode 1 from the Mode 2 that the technology team will be responsible for. In simple words, managing the transition from experimentation and the exploration phase to adopting the SaaS application as one of the long-term enterprise application and integrating it with the rest of the enterprise application set.

This could be a challenge and as well as an opportunity since we know that the enterprise applications don’t operate in silos. Let’s say you have adopted a SaaS expense management system then you will need to integrate it with accounting, compliance and the approval workflow systems.  Similarly, if you go with the Workday HRMS SaaS platform, you may need to integrate it with Active Directory for identity and email provisioning, with finance and payroll systems for pay processing among others.

The technology leadership team should plan and prepare for the SaaS integration with the rest of the enterprise to make the transition from Mode 2 to Mode 1 smooth and predictable. You will need a sound middleware integration strategy that is built for the world of Hybrid Cloud and SaaS utilizing advancement in the technology like Microservices and Docker. 

Some of the things to look for in an integration middleware platform could be:

1.      Support for the diversity of the protocols and language
2.     Core support for the SaaS and Hybrid Clouds
3.     Modular, expandable and distributed architecture in line with the trends in the industry

With a sound integration middleware platform and a well-planned strategy, the CIO and the CTO can be the champions of change in the organization facilitating the exploration and experimentation and at the same time providing a path to a well-integrated and predictable enterprise applications with the robust quality of service that the technology organizations are known for.

1.      Gartner definition
2.     Deliver on the Promise of Bimodal
3.     Microservices based SaaS and Hybrid Cloud Integration

Tuesday, January 17, 2017

Baking cookies and making Microservices

Microservices are getting a lot of attention recently: articles, blogs, discussions on social media, and conference presentations. Everyone has questions regarding Microservices:  What is Microservices? How is it different from Service Oriented Architecture (SOA) or traditional monolithic architecture? What are the benefits of using Microservices over SOA system? and so on... This blog will attempt to explain Microservices in layman terms.

Traditionally, software developers create large, monolithic applications. The single monolith would encompass all the business activities for a single application. As the requirements of the application grow, so does the monolith. If application becomes a success; traffic and usage increase dramatically. More features are added and more and more developers are brought in to work on it. Your once-simple application is now large, complex.... beast. You now have multiple independent development teams working on it simultaneously. These presumably independent development teams are actually not independent at all. They are actually working on the same code base and changing the same sections of code - or may be meddling in each others code.  These activities go on for the life of the application, which is years and at times tens of years. In this situation, code quality—and hence application quality and availability—are likely to suffer. So, the traditional process is based on tightly knit highly coupled approach that can introduce bugs, issues and lead to application failures, performance bottlenecks and can at times affect the business operations in a big way.

Microservices based architecture is a more distributed and loosely coupled one. A single application would be constructed as a collection of independent Microservices each of which would perform single or minimum task individually. The benefit of distributing different responsibilities of the system into different smaller services is that it enhances cohesion through independence, decreases coupling and gives you the flexibility to change and add functions and features to the system at any time.

We all love cookies and at some point of time we have made them or helped someone make them. If not, we have at least eaten the yummy cookies.  Let’s understand Microservices in terms of cookies making process. Sounds sweet?

The traditional monolithic or SOA based application which is explained above is like an automatic cookie maker. A single unit completes every step from collecting ingredients, mixing, preparing dough, shaping, baking and finally packing the baked cookies. But, if something goes wrong somewhere in that machine, cookie production will stop until you locate and fix the issue. And all of your efforts for that batch of cookies are now in the trash bin. 

But what if all these processes were distributed, then it would be easy and flexible to manage, scale and auto-heal. Now, you must be thinking… Hell how? What is the benefit in dividing the process? The owner has to buy more machinery instead of having one automated cookie maker, right? 

Let’s divide each of the process to make the cookies as below and checkout the benefits.
Fig1: Cookie making flow chart with independent processes 

Now, you don't make the cookies in a single machine. You have multiple machines to take care of distinct independent tasks.

Independent Entity and Reusability

If all tasks are divided between different machines, it would be as below. Each machine knows the task it has to perform. Each can work independently and can be reused/utilized for some other work as well e.g. in the idle time, oven can be used to bake bread, croissant, pies etc. Similarly Microservices are also independent entities with distinct task . So if one Microservice is assigned to insert data into database then multiple instances with different configurations of the same Microservice can be used in a larger project to handle different task with the similar functionality. We are reusing the functionality rather than rewriting redundant code again and again as in a monolithic development style.

Fig 2: Cookie making in action with independent machine

Flexibility to add new features and functionality 

Now,  the owner wants to manufacture chocolate chip as well as coconut cookies. With automatic machine, it is not possible to make multiple types of cookies. But with a decoupled system, it is just a simple tweak to add one more process to add chocolate chips or coconut shredding before preparing dough without touching or impacting any existing functionality. Just add one more feature in whole process. 
Fig 3: Adding a new feature or a functionality

To add new features in monolithic system, developer needs to change some code and  compile the whole piece or the pieces code. Now,  a single bug in that new feature could effect the whole flow. But with Microservices based architecture, new features would be added as a new Microservice and chained in the existing flow where it is required. Nothing else will change in existing process and if there is any issue in the new feature, it could be removed or updated very easily.


System is decoupled and each component is doing well defined work. But baking process does take a lot of time. And there is a queue of hungry customers at the door.  Did I say with crisp dollar bills? How do we accelerate the cookie making process? 

In the decoupled scenario, the baking is the time consuming process. We might call it a step in the critical path or the bottleneck. Applying the theory of constraints is simple here. Just add another oven and you accelerate the baking process. This is what is known as scalability in the technical terms. Meanwhile with the old automatic cookie machine, accelerating the production process would not be easy. To scale up cookie production there, you will need to buy multiple automated cookie making machines. Doesn’t it seem silly to buy an entire systems because oven is taking more time to bake? 
Fig 4: Illustrating Scalability

Getting back to Microservices vs. the traditional application development, in Microservices based flows, if one Microservice is facing heavy load/traffic, more instance of the same Microservice could be deployed to divide the load and accelerate the process. And this scaling could be automated in through container management services to scale up on heavy load and scale down during idle time. It would be very difficult to do auto scaling in response to variable load in a monolithic or SOA based system.


We at RoboMQ adopted this architecture early on. For all our integration services development, we have followed Microservices architecture. The Microservices architecture needs few simple building blocks:`

1) An API gateway
2) Messaging fabric or message queue infrastructure
3) Container technologies like Docker that is used to package Microservices as atomic and autonomous unit

Fortunately, we have all of the above and more. As part of RoboMQ product we provide a multi-protocol gateway, “ThingsConnect” and the hosted message queue service. Multi-protocol gateway allows Microservices to use any data integration protocols without any language constraints. It also allows easy integration with existing legacy services facilitating a brownfield approach. 

Message Queues as a service, including the hybrid messaging cloud, provides the wiring or the plumbing for services to interact, process and delegate tasks to each other thereby assembling complex business processes. Using RoboMQ, you can build your business processes across networks and cloud boundaries.

This blog tries to explains the advantages of using Microservices based architecture over monolithic or SOA architecture with a simple example. Building complex applications is difficult. A Monolithic architecture only makes sense for simple and small applications. The Microservices architecture pattern is certainly a  better choice for complex, evolving applications and RoboMQ provides all the basic building blocks.

For more details on Microservice based architecture, please checkout out the microservices page on our website. You can also reach us on email at if you have specific questions or need us to help you out in your Microservices journey.

Monday, November 21, 2016

Announcing RoboMQ at Gartner Application Strategies & Solutions Summit

RoboMQ is very excited to announce that we are closing the 2016 year with positive growth and achievements to write home about. We have accomplished so much in the last year from our new products and services (check out our APD Integration Service or our new Integration Flow Designer) to our wonderful new clients! To celebrate this year of success and growth and start pushing for an even better 2017 we will be attending the upcoming Gartner Application Strategies & Solution Summit Summit, taking place December 6-8 in Las Vegas.

Expanded to include customer engagement and workplace technologies,Gartner Application Strategies & Solutions Summit 2016, Dec. 6–8 in Las Vegas, takes a comprehensive look at the application strategies driving today’s competitive advantage. RoboMQ will be presenting a demonstration of our Microservices based iPaaS platform for SaaS, EAI, Hybrid Clouds & IoT at the Solution Showcase. The session is titled, “Microservices based Application Integration for SaaS, Hybrid Clouds and IoT”.

In this session our CEO, Bramh Gupta will discuss how, Enterprise applications are getting defragmented and distributed thanks to SaaS, Hybrid Clouds and emergence of IoT. It translates to a diversity of protocols and data interchange mechanisms. In addition, miniaturization, compostability and fine-grained services are now a reality with Microservices and container technologies like Docker. How do you take advantage of this tectonic shift to build applications “Lego Style” across networks and clouds to create revenue generation opportunities and cost savings?

In addition attendees will have the opportunity to hear from RoboMQ’s customer, Topgolf during our solution provider session Thursday, December 8th at 10:15 am.

If any of this interests you, consider joining us to learn how to enhance customer experiences, improve employee engagement and drive agility and innovation! Check out Gartner's registration page or for more details or reach out to us at with any questions!

We look forward to seeing you in December!

Monday, October 31, 2016

RoboMQ Workday Integration

Workday is a leading provider of enterprise cloud applications for human resource and finance and it is quickly becoming the centerpiece of the enterprise HR ecosystem. It is a Software-as-a-Service (SaaS) application built for the HR and operations needs for today’s business. You can learn more about Workday here

RoboMQ is a leading-edge Integration Services Platform (iPaaS) that can connect any device, sensor, SaaS, Cloud, mobile or enterprise application, using any standard protocol. At the core, it is a distributed and federated message-oriented middleware with our ThingsConnect suite of adapters & connectors that provides Microservices based integration application development platform, management UI, messaging dashboard with real time analytics engine and monitoring and alerts capabilities. Using RoboMQ, you can build enterprise business workflows that can connect your application across networks and clouds.

If you are using or planning to use any of the Workday's products like Human Resource, Finances, Professional Services Automation (PSA) – you will have an inevitable need to integrate the data and the information to and from Workday and other enterprise systems running on the cloud or on premise. These applications may be SaaS applications, COTS products or just home grown legacy systems.

We can solve this problem for you and accelerate the deployment, adoption and assimilation of Workday in your organization and with your key stakeholders. RoboMQ Workday Integration offers the fastest and easiest way to connect Workday with the rest of your enterprise applications and data sources, both in the cloud and/or behind the firewall.

Fig 1: RoboMQ as the connecting glue with the rest of the enterprise

It allows businesses to extend the capabilities of Workday and enable seamless interoperability with third party SaaS applications, systems and services that are vital to a ‘best of breed’ human resources ecosystem, such as recruiting, talent management, core HRM, payroll, benefits, and more. It also creates connectivity to essential applications such as SAP, ADP, Active Directory and Salesforce through numerous Workday APIs, such as the Workday Payroll, Time Tracking, Procurement, and Expense Management.

Remember, it is just not the connectivity of Workday with other application, it is more about building the business workflow using multiple systems collaborating and sending information in real-time to react to an activity or to complete a complex workflow in response to an event or an action.

RoboMQ makes this integration possible thorough differentiated product offering as part of its integration suite:

ThingsConnect Suite of Adapter and connectors: ThingsConnect makes RoboMQ protocol agnostic or protocol-less. RoboMQ has no Integration APIs of its own and can integrate with systems using any protocol, API or language. ThingsConnect performs protocol adaption or conversion. When using RoboMQ developers can use their own choice of protocol or programming language totally eliminating any learning curve whatsoever.

Customers use RoboMQ's ThingsConnect suite for integration of devices, enterprise systems, and applications for automation of manual processes and optimization of their business operations.

Microservices based integration architecture: Microservices based architecture allows you to build integration with Workday in a modular, expandable and highly scalable and expandable fashion using independent and atomic Microservices running as docker containers.

Guaranteed Delivery business workflow: RoboMQ is built on top of leading messaging protocol providing the guaranteed delivery, and eventual consistency benefits of Message Oriented Middleware (MOM).

Drag & Drop Microservices integration using Integration Flow Designer: You can integrate Workday with rest of the enterprise systems with a drag and drop of the Microservices nodes in RoboMQ Integration Flow Designer.

Integration of Workday events and actions

RoboMQ provides Workday integration solution with cloud and on-premises applications to automate any of the HR and finance events and activities. Some of the common use cases are employee life cycle management or integration of finance data with reporting analytics, BI and other business operations systems.

Let us understand Workday Integration with some common work flows in a typical organization.

1. New employee on-boarding  
When a new employee joins an organization, a large number of coordinated activities happen to get the employee smoothly on boarded. This experience has a lasting impact on the employee morale and the perception which is very important for the company.
    • When a new employee starts working at a company, his or her information is entered into the company’s Workday HR system, Payroll system, Absence system, Benefits system etc. 
    • Some information is also entered or updated in Recruiting system and Staffing system in Workday. 
    • Upon above actions in Workday a sequence of actions need to be taken on systems outside of workday, like - 
      • Active Directory Provisioning - An account should be created in Active Directory for the new employee 
      • Provisioning of emails, access to document share and other essential productivity tools 
      • Provisioning of Role Based Access (RBAC) in other enterprise applications like Sales, operations, resource management etc. based on the rights and privileges of the employee. 
All of the above actions triggered upon employee hiring in Workday can be performed automatically using RoboMQ Workday solution with no manual actions saving operational cost and creating efficiencies.

With RoboMQ Workday Integration, High level view will be as follows.

Fig 2: New employee on boarding workflow

The image below shows one of the simple solution for above on-boarding process with RoboMQ Integration Flow Designer, where a customer can use new hire data from a recruitment system and map the data fields to Workday using the browser-based workflow Designer. Integration Flow Designer makes configuring and deploying a business workflow as simple as dragging and connecting nodes from a palate of nodes. Once the flow is deployed successfully then whenever new employee is hired, business processes above will get executed.

Fig 3: Designing the New Employee on boarding process with Integration Flow Designer

2. Employee Life Cycle Management

Employee Life cycle events like promotion, change of role, transfers, long term leave, pay raise or terminations start in Workday. These events can then be integrated with the rest of the information systems by making the Workday part of near real time business process flow using RoboMQ.

Think about the consequences if all the access removal does not happen for an involuntary termination of a disgruntled employee. As much as we wish such events away, they do happen in real life.

Without RoboMQ workflow automation all of these employee changes will be time consuming and error prone manual activities.

3. Integration of Finance and Payroll activities

Financial transactions including payroll related activities generate data and events that are meaningful if they are automatically made available to other enterprise and third party applications.

Some of such scenarios could be integrating the time worked data from time reporting system or the POS (Point of Sales) system as in retail and restaurant industry so that correct payroll could be generated.

Another scenario would be to propagate the job codes or the pay rate information to other systems for time reporting, business operations planning or for the reporting purposes.

With RoboMQ Workday integration solution, companies can greatly increase the flexibility of its employee on-boarding process and other HR processes so that both its IT and HR teams can focus on more strategic business priorities then doing redundant repetitive work. This automation can do the repetitive work more predictively and at lower cost while creating a superior experience and higher employee satisfaction.

RoboMQ Workday integration solution has flexibility to adopt any policy/rule changes events in any workflow without impacting the existing functionality since it is built on a Robust and scalable Microservices platform.

For more information on RoboMQ workday Integration Solution and RoboMQ's other products visit our website,