We’re All Coders Software can be intimidating. The people that develop software seem to be a lot smarter than the rest of us (many of them are), and the language they use is not only foreign-sounding, it appears cryptic at first (and second, and third) glance. But I’m going to let everyone in on a little secret: if you use formulas in Microsoft Excel, you are a software developer, and you know a programming language. When you type @sum(A1:A10) in an Excel cell, you’re using a programming language your computer understands to add a column of numbers. If you didn’t know anything about Excel and saw that string of characters, it would look alien, but it becomes familiar quickly as you learn the language, a phenomenon no different than living in another country and eventually becoming comfortable with the native language. With that in mind, let’s take a short walk through the world of software and demystify a few terms around applications and how they talk to one another. What is an Application Programming Interface (API)? Software types are fond of a term that even the general population has become familiar with: Application Programming Interface, or API. It sounds exotic, but it’s really just a way for one computer program to exchange data with another one. Most computer programs with which we’re all familiar manipulate data. They consume/collect data, do something with it, and then produce some kind of result, or otherwise glean some value from it. Often, one program needs data from another program. When that happens, the two programs need to “talk” to each other. That inter-program communication happens through an API. In short, it’s how one program accesses the database of another program. Think of an API as a bridge between two cities. Bridges are expensive to build and maintain. And if there’s a problem and they’re closed, chaos ensues. Even if the bridge isn’t closed, if traffic patterns change on either side of the bridge, it can negatively impact both cities. Without question, bridges are crucial tools to traverse rivers and valleys, but all traffic engineers will agree that a bridge is the last resort, and used only when less expensive, more reliable options are unavailable. APIs work exactly the same way. Like a bridge, the problem with an API is that it’s static. Designers decide up-front what data “fields” to pull from the other application. For example, the initial requirements might call for the first_name, last_name, and date_of_birth fields to be pulled from the database of the other application. Code is written to access the application, and to pull those 3 fields from a given part of the other program’s database, including “mapping” the field names (“date_of_birth” in one application may be named “dob” in the other one, for example). The integration is tested, and any issues found are resolved. It’s then deployed. Depending on the complexity of the integration, this process could take months. So, what happens when business requirements change, and instead of the 3 original data fields, we need a fourth: applicant_height? You guessed it. The whole process starts from scratch, and is repeated. Native Application The alternative to an API integration is a “native” application. In a nutshell, when an application is “native” to the platform it resides on, it uses the same database as that platform. That means no API – and no API integration software project – is required to transfer data between the application and the platform. Let’s return to the spreadsheet example. If you’re working in a spreadsheet built by one of your colleagues and you’re adding some capability to that existing spreadsheet, you’ll do one of two things if you need variables or data: 1. Use data fields your colleague already created. For example, if you need the first_name field, you’ll just pull from that data from the fields (rows/columns) that already exist; there’s no need to re-create that “database element.” 2. Or, create a new field that you need for your application. That new field or variable (for example, hair_color), however, is created in the same spreadsheet/database; it’s just added to existing list of variables (rows/columns). In the lexicon of software developers, you’re just “extending the data table.” When the application is native to the platform – the data is all in the same spreadsheet in our example above – adding new fields is easy, and can be done at any time. Moreover, if your colleague updates their part of the spreadsheet and accidentally breaks something that you’ve done, it’s relatively easy to find and fix the problem. When either or both of the two programs linked by an API are changed and the integration is broken, what happens? You guessed it. The development/testing process is repeated. It’s All About Data Movement Like countries that negotiate trade deals to manage the flow of goods across borders, APIs are the trading rules/tariffs, etc. of data moving across the “borders” between applications. Yet, in native applications, there are no borders; it’s more like goods moving from New Jersey to New York than from Germany to the United States. So, the work order generated by the HR department to purchase and move a new desk into an office for a new hire uses the same database as the Purchasing department that buys the desk, and the Facilities Department that accepts the desk at the loading dock and delivers it to the office. The data that makes up that work order (location, item_cost, work_order_number, originating_department, etc.) 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 much easier, less expensive, and faster to implement up front. They provide infinitely more flexibility over the life of the application. And perhaps 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. Share
