API Di Dalam vs. Di Luar Perusahaan

Batas antara fungsionalitas TI internal dan eksternal dalam suatu perusahaan adalah perbedaan yang salah. Tidak ada yang bisa memprediksi bagaimana data akan digunakan atau di mana informasi akan mengalir. Bahkan jika Anda tahu di mana garis interior / eksterior perusahaan Anda ditarik hari ini - garis-garis itu hampir pasti akan menjadi target yang bergerak di masa depan.

Ambil Pitney Bowes, perusahaan tempat saya bekerja dalam peran saya di tim Apigee di Google. Sementara banyak dari sejarah abad dekat telah berakar pada solusi pengiriman fisik seperti meter ongkos kirim, perusahaan juga mengembangkan pembayaran dan kemampuan e-commerce selama bertahun-tahun dan memperoleh sejumlah besar logistik, pengiriman, dan data geolokasi. Ketika Pitney Bowes berevolusi dari layanan analog ke dunia perdagangan terkoneksi saat ini, ia memperoleh nilai dari aset dan kompetensi ini dalam organisasi - tetapi diakui bahwa aset dan kompetensi dapat berharga di luar perusahaan juga, hingga pengembang dan mitra yang dapat menggunakannya untuk membangun aplikasi dan layanan baru.

Untuk memanfaatkan peluang ini, Pitney Bowes menawarkan lebih dari 160 API publik melalui cloud, membuka jutaan potensi pendapatan baru dan membantu upaya perdagangan digital perusahaan menjadi bisnis tahunan senilai $ 1 miliar lebih. Data dan fungsionalitas yang dulunya hanya internal sekarang eksternal juga.

Ada pelajaran di sini: memikirkan solusi bisnis dan strategi dalam hal "internal" dan "eksternal" atau dalam hal "mengintegrasikan Sistem A dan Sistem B" sudah ketinggalan zaman. Masalahnya bukanlah bagaimana Anda akan menghubungkan sistem internal dan pengguna Anda - koneksi itu dapat dibuat dengan beberapa cara. Sebaliknya, masalahnya adalah apa yang dapat Anda lakukan dengan koneksi begitu koneksi dibuat.

Jawabannya tergantung pada jenis koneksi - statis versus dinamis. Di dunia solusi titik lama, misalnya, fokusnya sering hanya integrasi statis, mendapatkan informasi dari sistem A ke sistem B. Mekanisme monolitik yang digunakan sering rapuh dan kompleks, hanya berfokus pada lintasan A → B saat ini, seolah-olah rute masa depan ke C, D atau E tidak akan pernah berani.

Tapi tentu saja bukan itu masalahnya. Seperti yang ditunjukkan oleh contoh Pitney Bowes, jalur data hari ini mungkin tidak terlihat seperti hari esok. Dalam jangka panjang, semua koneksi harus dinamis, siap ditingkatkan atau turun sesuai kebutuhan, dan siap untuk berinteraksi dengan apa pun yang diperlukan. Agar tetap kompetitif, Anda tidak bisa hanya menggunakan teknologi yang sama dan terus berlari, dan Anda tidak bisa bergantung pada kerangka yang hancur seperti "di dalam" dan "di luar."

Lebih khusus lagi, berikut adalah persyaratan minimum untuk akses internal ke suatu sistem:

  • Keamanan
  • Jejak audit
  • Visibilitas
  • Kinerja runtime (waktu aktif, latensi)
  • Biaya (penghindaran biaya, penghematan biaya)

Secara tradisional, banyak bisnis berhenti di sini. Tetapi ada poin tambahan yang harus dipertimbangkan di dunia yang bergerak cepat saat ini:

  • Wawasan / analisis
  • Kemudahan penggunaan
  • Kemungkinan diperpanjang
  • Opsi penerapan (mis., Wadah, awan, skala)
  • Monetisasi
  • Kontrol berbutir halus

Seperti yang diperlihatkan persyaratan baru, jika Anda tidak membangun sistem dengan harapan bahwa mereka harus berinteraksi dengan sistem yang belum ditemukan, Anda berisiko mengunci diri sendiri. Terlalu banyak orang yang masih keliru berpikir bahwa tantangannya adalah mengirim potongan besar data melalui keamanan kasar ke aplikasi klien yang tebal.

Tetapi ke depan, aplikasi dan arsitektur harus sangat granular dan terukur. Untuk sampai di sana, bisnis harus berkembang dari mentalitas integrasi ke pendekatan yang lebih modern yang membuat sistem tersedia secara terperinci, andal, dan terukur sambil memasok visibilitas, wawasan, kontrol, dan keamanan. Landasan untuk sebagian besar arsitektur atom dan lincah ini akan menjadi API yang diproduksi - yaitu, API yang tidak hanya digunakan untuk mengekspos aset tetapi yang dirancang dan dikelola sebagai produk yang memberdayakan pengembang, baik internal maupun eksternal, untuk membuat aplikasi baru, memperluas jangkauan merek, dan membuka kemungkinan pendapatan baru.

Perbedaan ini penting: API digunakan saat ini dalam banyak skenario integrasi, jadi intinya adalah tidak memiliki API - API dirancang dan dikelola untuk konsumsi, penggunaan kembali, dan peningkatan berkelanjutan. Dengan kata lain, dengan pola pikir integrasi, API dapat memecahkan masalah jangka pendek - tetapi begitu orang melihat bahwa divisi internal / eksternal telah runtuh dan bahwa kasus penggunaan integrasi tidak lagi memadai, manajemen API menjadi solusi yang paling masuk akal.

[Tertarik dengan lebih banyak kiat untuk mengelola API dan mengemudi bisnis digital? Lihat ebook baru Apigee, “Pola Pikir Produk API.”]