Read Blog Post

Read Blog Post

Contributed on July 16, 2018

1.9K

547

How Long to my ROI?

Blog: The Tibco Blog

TIBCO has a long relationship in supporting open source software (OSS) and community-driven standards. We realize it is the way of the future. In fact, we just announced production-level support for Kafka and Mosquito MQTT.

Open source provides organizations with a low barrier to entry in adopting capabilities into their solutions and TIBCO provides production support for projects built on open source, giving our customers the confidence to migrate these solutions into production where appropriate.

At the same time, the world of OSS is a vast space. Technologies like Kafka, MQTT, HDFS, Cassandra/HBase, are infrastructure that runs with some configuration out-of-the-box and some level of coding to incorporate their capabilities. These systems are called “short code” systems. Adoption of short code systems tends to be straightforward.

The next step is to build systems on top of this infrastructure, and in the case of Kafka/MQTT, they are event-driven real-time applications. This is where the Apache/Hadoop stack becomes less certain and the selection more difficult. Why? Because these systems require significant development and a high level of expertise to implement. For the purpose of this discussion, we will refer to these systems as “long code” systems.

ROI that pays after one year or an ROI that pays in 3 years. Which would you prefer?

While one can discuss the merits of different OSS systems, one often neglected point for long code systems surrounds the economics of the decision. We will save the technical aspects of this conversation for a more appropriate venue and focus on the economic concern in selecting the tools that we are going to use to build the solutions on top of this infrastructure.

With the idea of long code, or secondary set of open source options, you end up with tremendous flexibility, but at the cost of a significant development effort in building everything from scratch.

To create projects in open source, there a lot of things that contribute to and raise the cost:

• First, is the selection of the tool as there are usually two or three competing open source projects for the same concept.
• Second, you need to teach yourselves the latest variation of that tool, and they change constantly in fundamental ways.
• Third, you need to build an ecosystem or wrap that tool with baseline utilities and connecting it to your other systems.
• Fourth, you have to sit down to develop the system functionality itself, a time-consuming effort
• And finally, for the fifth part, you end up maintaining either a particular version of this code tied to a particular open source release or commit yourself to constantly upgrading as the open source tool itself evolves.

This is QUITE a large amount of work. And all this works adds up to dollars and time, which equates to more dollars.

Open source projects often equate to a large amount of work which often equates to a large number of dollars. So, I would ask you, which is better? An ROI that does not begin to pay out until after year three (which is the case when you use open source)? Or an ROI that starts to pay off within year 1 (when you use a pre-built software solution)?

This question of when would you prefer your ROI to kick in underlies the “true cost of developing software” in today’s fractured and often misleading IT environment. As corporate citizens, architects, developers, and managers, we must look beyond our own jobs and roles and look at the impact of a decision like this across the organization.

We basically have two choices. One is the ROI that pays off in a year and one is the ROI that pays off in three years. The choice of ROI that pays off within a year means adopting vendor-provided, high-productivity, modern software. This is software that works seamlessly with the short code open source infrastructure that you have selected. It maintains itself to the latest version and best practices. It provides connectivity to these tools and a host of other vendor-specific feeds. And they provide modern, high-productivity development environments that dramatically accelerate the ability to create, test, evolve, and maintain solutions.

But that conversation so far only even covers the software development and maintenance aspects of a project.  In order to understand the full impact of tool selection on ROI, we need to go further and deeper.

Creating and deploying a service based on a technology solution has become an increasingly complex endeavor. When we first started building solutions, a technology team would be responsible for every facet of building, deploying, and delivering that solution to their business unit. As organizations have grown, the technical landscape has shifted and become more complex. At the same time, the technology solutions themselves have become the backbone of most organizations’ ability to conduct business. There are a number of effects and impacts from this evolution, but in looking at the pure the cost of a system, it gets split amongst a number of different groups including the business unit, the technology team, and even a support or operations group.  With that, the understanding of a cost of a system becomes a murky subject.

With that in mind, let’s break down the costs associated with delivering a software project:

Up-front Licensing: The cost to acquire the tools necessary to build and deploy the solution.

Development Resources: The number of Full-Time Equivalent Developers required to implement this project from design to rollout.

Maintenance: The ongoing people and tools costs to keep the project running Hardware – The cost of the servers and infrastructure required to run the solution in production

With today’s corporate structure, these five costs are spread amongst different groups, each of whom has a different role in acquiring this software. Often the developer team, or the group that owns the developers, is tasked with the cost only of maintaining a headcount and acquiring the tools and the software required to actually develop and deploy that application. The rest of these costs become hidden into a business group or organization that does not appreciate the burden that they are being asked to shoulder.

That creates a great burden on the organization, as the decision to create this solution is often left solely with the development team, who act to the best interest of their goals and targets, which in today’s culture tend to be tied to developer headcount. To balance this, they will seek to minimize their spend on tools and adopt open source solutions, where all the developer team has to do is staff itself with knowledge workers who know how to build solutions in that OSS software.

Therein lies our dilemma. While OSS has a very low barrier to entry, it is actually one of the worst scoring options for nearly all of the other four areas of software cost. Let’s look at these costs individually:

People: OSS from Apache is designed to offer maximum flexibility and development customization. As a result of this, and the provenance of these tools as starting in the polished ecosystem of a parent company, they are offered as low-level tools. As a result, any organization that is seeking to leverage these tools needs to hire or more likely train highly specialized developers around these tools, and ensure that there are a sufficient number of developers to create a solution from the ground up. A typical open source project requires five or more developers over the design, development and testing cycle of the project.

Maintenance: There are two costs that OSS promulgates. First, as this software is low-level, it requires a significant amount of expertise to understand what was built to keep it running and then to also extend it. The second cost is that of upgrades. OSS undergoes a furious rate of change, with updates, upgrades, and patches occurring at the whim of the software producer. While Apache and other organizations seek to formalize this process, it still leaves organizations with a need to either maintain a fast upgrade schedule or to maintain expertise in that outdated version of the software.

Hardware: This is the unsung cost of a system, but it can have a tremendous impact on the cost of a solution. Modern business applications, especially those that process data in real time and IoT systems, are experiencing an explosion of data volumes. This leads to a requirement for significant computing horsepower, often for workloads that software was not designed for. This can lead to a requirement for a large number of individual processing systems for everything from developing application logic to processing and handling real-time data.

Time-to-Development: The issue here is not a cost per se, but the time it takes for a system to be available for use from the time it is specified. And that time translates into cost. OSS projects typically require a significant amount of time to design, implement, test, and tune. Once the solution is released, it often requires significant tuning or optimization to meet a business need. This becomes a major issue in that during that long development cycle, business needs will shift as requirements for data volumes, transactions per second, and other metrics increase.

Cost of building a project in OSS vs. building a project with TIBCO software

With all of this in mind, let’s take the costs associated with an OSS project and compare them to building one with TIBCO software which is built for a purpose. The following data is anonymized but it comes from the direct experience of a customer of ours:

*NOTE: The following project cost is purely representative of a project Cost Comparison.  It makes no effort to establish a particular license fee for a particular service.

*EXAMPLE Project Cost

* Hardware Costs: These costs represent the baseline cost for an EC2 instance without ANY other supporting network or storage services; some organizations range into the $1000s of dollars per month for co-located and data center servers

This simple exercise clearly shows that at the end of two years, the OSS project will have nearly a million dollars of Negative ROI. It will take another full year (until the end of year three) before this system will be in positive ROI. And this assumes that everything runs perfectly, with no additional redesign or custom development in order to maintain baseline features on expanded volume or data requirements.

This is in stark contrast to building with TIBCO. With TIBCO software, you finish the first two years with already a positive ROI of $574,000, and year three tacks on a full year’s revenue less maintenance.

With the increasing scale and complexities of a system, this disparity only increases to favor building with TIBCO. We are more than happy to sit with you and work with you to understand the true cost and ROI of your solutions. Please contact us today.

Again, note that this piece is specifically targeted around the application development process that exists around the OSS ecosystem. We fully encourage and work with our customers to establish their open source environments, and will support them through the entire development lifecycle, no matter where the deployment.