Native vs. Third Party Applications FOR NON-TECHIES

Demystifying the Advantages of a Natively-Built Application versus a Third-Party Integration

www.nuvolo.com • [email protected] We’re All Coders

For non-IT people, software can sometimes be intimidating. The people that create the tools we use seem to be a smarter than the rest of us, and the language used by technologists is often cryptic and can seem like it comes from another world. Let’s start by letting everyone in on a little secret: if you can create a formula in Microsoft Excel, you are a software developer, and you have a basic understanding of a programming language.

When you type @SUM(A1:A10) in Excel, you’re using a programming language and your computer software understands to add a column of numbers. If you were unfamiliar with Excel and saw this strange string of characters, it would most likely look alien to you. But it becomes familiar quickly as you learn the language of how to use a spreadsheet. We see a similar phenomenon when people live in another country and surprisingly quickly become comfortable with the native language.

Our objective here is to explain, in the simplest possible terms, what it means to be “native” to a software platform and why it’s important to users. With that in mind, let’s take a short walk through the world of software, demystify a few technology terms, and ultimately, help the reader understand how software applications talk to one another.

Application Programming Interface (API) - Defined

Folks that work in the software industry are fond of a term that even everyday people are familiar with - application programming interface, or API. It sounds exotic, but it’s just a way for one software program to share or exchange data with another software program. Most commonly known software programs use or manipulate data. These applications collect, consume and then act on the data available to them, producing some kind of result. The result is then intended to provide value for the user. Most commonly, an API solves the problem of how to get data from one application to another and back again. APIs let the applications “talk” to one other.

Think of an API as a bridge between two cities. The challenge is that bridges are expensive to build and maintain. If there’s a problem and the “bridge” gets closed or needs to be repaired, the result is chaos (just ask our former New Jersey Governor Christie). Even if the bridge is open, and traffic patterns change on either side of the bridge, the same chaos can result. Make no mistake about it, bridges are essential infrastructure to traverse rivers and valleys. However, all traffic engineers agree that a bridge is a last resort and should be built only when less expensive and problematic options are unavailable. Think of APIs in exactly the same way.

www.nuvolo.com • [email protected] Like the bridge, the big problem with an API is that The integration is then tested, and any issues found it’s static. The team that builds the API makes a are resolved. Then it is turned on and is working. decision, up-front, what data to send to or pull from Depending on what the two applications are and the other application. For example, the initial API the complexity of the integration, this process design might call for first name, last name and date could take months. Then things get interesting. of birth to be pulled from the database of the other What happens when the company’s business application. Software code is written to access the requirements change – which they do all the time. other application and to pull those three fields from Now, instead of the three data fields being pulled, a specific location in the application’s database, we need a fourth. You guessed it. The process is and the code also assures those fields are mapped repeated over and over again. properly once the data is received.

Native Application

The alternative to bridge building, or API integration, is a native application. In the simplest terms, when an application is native to the platform it resides on, it uses the exact same database as its platform. The important thing here is that there is no API. Native means a seamless transfer and exchange of data between the application and the underlying platform. No messy bridges to build, repair or upgrade. Now, let’s return to our spreadsheet example. Let’s say you’re working in a spreadsheet built by one of your colleagues and you want to add some capability. You will need to do one of two things if you need variables or data:

• You can use data fields your colleague already • Alternatively, you can create a new field that created. For example, if you need first name, you need for your application. That new field you just pull that data from rows and columns or variable (for example, hair color) is created in that already exists. There is no requirement the same spreadsheet or database. It simply to re-create that “database element” in your gets added to the existing list of variables spreadsheet. (rows and columns). Using a term that software teams use, you’re just, “extending the data table”.

When the application is native to the platform – the data is all in the same “spreadsheet”, to use our example above. Adding new fields is easy and can be done at any time. Most importantly, if your colleague updates their part of the spreadsheet and accidentally breaks something that you’ve done, it’s easy to find and fix the problem. Conversely, when either or both of the two applications connected by a bridge or API change, and the integration is broken, what happens? You guessed it. Stuff stops working and the development and testing process has to be repeated.

www.nuvolo.com • [email protected] It’s All About the Movement of Data

Similar to how countries negotiate trade deals to manage the flow of goods across borders, APIs are the trading rules and tariffs of data moving across the “borders” between applications. Yet, in native applications, there are no borders. Goods move seamlessly from point A to point B. For example, in a native application, the work order generated by HR to purchase a desk for a new employee and move it to a specified location uses the same database as the purchasing department that buys the desk. The Facilities Department, using the same application and database, accepts the desk at the loading dock and delivers it to the office. All of the data that makes up the collection of work orders, including location, item cost, work order number and originating department, is in the same format for the purchasing application, the HR application and the Facilities application. There are no APIs to translate anything, because nothing needs to be translated.

Time to Value…Flexibility…Risk

Ultimately, native applications are easier, less expensive and faster to implement. They provide customers infinitely more flexibility over the life of the application. Most importantly, native applications greatly reduce the risk of the deployment over time. As our parents used to say, if you go looking for trouble, it will find you. Selecting an integrated application over a native one is doing just what our parents warned us not to do…looking for trouble.

www.nuvolo.com • [email protected]