Lesson 1: Introduction to Integrative Programming

Integrative programming is the discipline of making separate programs, systems, and services work together as one solution. Most real software is not a single program — it is a web app talking to a database, a mobile app calling a payment service, or a school portal pulling grades from a registrar system. This course teaches the "glue" skills: exchanging data between systems, calling services over a network, and designing interfaces so components built by different teams (often in different languages) can cooperate. For example, when you pay a bill through GCash, the app talks to a bank's system, a biller's system, and an SMS gateway — none of which GCash wrote. Integrative programming is what makes that conversation possible, and it is one of the most in-demand skills for Filipino IT graduates because companies rarely build everything from scratch.

Organizations accumulate many systems over time: payroll, inventory, HR, accounting, customer apps. These are often bought from different vendors or built years apart — a situation called heterogeneous systems. Rewriting everything as one giant program is too expensive and risky, so instead we integrate. Common motivations: (1) avoiding double encoding — staff should not retype the same data into two systems; (2) real-time visibility — a sale in the store app should immediately update inventory; (3) new services from old systems — a university can expose its old enrollment database through a modern mobile app. In the Philippine setting, think of how LandBank, PhilHealth, and SSS systems must exchange member data, or how a barangay records system might feed a city-wide dashboard. Exams often ask you to explain why integration beats rewriting: lower cost, less disruption, and reuse of proven systems.

There are several classic approaches to integration, and you should be able to compare them. File transfer: one system writes a file (like CSV), another reads it — simple but slow and error-prone. Shared database: two applications read and write the same tables — fast, but tightly couples the systems. Remote procedure calls / APIs: one system calls a function or web endpoint on another — the dominant modern style (REST APIs fall here). Messaging: systems drop messages on a queue that others consume later — great for reliability and decoupling. Each has trade-offs in speed, coupling, and complexity. A typical exam question gives a scenario ("a sari-sari store POS must send daily sales to head office over unreliable internet") and asks which approach fits (messaging or file transfer, because they tolerate downtime). Throughout this course we will use these four approaches as our map.

Ready to apply this? The practice set below walks through exam-style problems with step-by-step solutions.