Then there’s the matter of what comes under the term “business logic.” I find this a curious term because there are few things that are less logical than business logic. When you build an operating system you strive to keep the whole thing logical. But business rules are just given to you, and without major political effort there’s nothing you can do to change them. You have to deal with a haphazard array of strange conditions that often interact with each other in surprising ways. Of course, they got that way for a reason: Some salesman negotiated to have a certain yearly payment two days later than usual because that fit with his customer’s accounting cycle and thus won a couple of million dollars in business. A few thousand of these one-off special cases is what leads to the complex business “illogic” that makes business software so difficult. In this situation you have to organize the business logic as effectively as you can, because the only certain thing is that the logic will change over time. (Martin Fowler, 2002, Patterns of Enterprise Application Architecture)

Ada banyak jenis perangkat lunak dilihat dari domain di mana perangkat lunak tersebut digunakan. Ada perangkat lunak untuk pengelolaan bisnis, telekomunikasi, sains, embedded system, game, dan sebagainya. Setiap domain perangkat lunak memiliki tantangan dan kompleksitas yang berbeda-beda. Tantangan utama dalam membangun perangkat lunak untuk aplikasi bisnis adalah bagaimana memahami dan memodelkan logika bisnis agar dapat dibuat perangkat lunaknya.

Seperti kutipan dari Martin Fowler yang saya tulis di atas, logika bisnis diberikan begitu saja kepada kita oleh pengguna. Seringkali logika bisnis tersebut “tidak logis” karena banyak terdapat aturan-aturan pengecualian. Bisa jadi hal tersebut terjadi karena memang sulit untuk membuat proses bisnis pengguna berjalan secara konsisten antara satu bagian dengan bagian lainnya.

Padahal, secara umum perangkat lunak ditulis dan berjalan atas logika yang sifatnya pasti. Perekayasa perangkat lunak pun terbiasa untuk merancang semuanya secara konsisten dan logis. Sebagai contoh: dulu saya menggunakan framework CakePHP untuk membangun berbagai sistem informasi. Framework tersebut memiliki struktur, konvensi, dan konfigurasi yang konsisten untuk setiap bagian sehingga kita mudah mempelajarinya.

Kenyataan yang sering terjadi di dunia bisnis adalah lebih sulit untuk mengubah proses bisnis agar mengikuti logika perangkat lunak daripada mengubah perangkat lunak agar mengikuti perangkat bisnis (setidaknya bagi pengguna, toh mereka yang membayar :D ). Tentu saja hal ini sulit bagi perekayasa perangkat lunak yang terbiasa berpikir logis dan merancang perangkat lunak dengan aturan-aturan yang konsisten :D .

Saat ini saya terlibat dalam proyek penerapan Pernyataan Standar Akuntansi Keuangan (PSAK) No. 50 & 55 di sebuah bank di Indonesia. PSAK penuh dengan aturan-aturan yang rumit, khususnya bagi saya yang memang latar belakang pendidikannya bukan akuntansi. Belum lagi mengenai proses bisnis di sisi klien yang tidak ideal. Ada pengguna yang meminta agar aplikasi bisa dijalankan secara backdated, ada juga permintaan agar suatu proses bisa dijalankan ulang jika terjadi kesalahan input data. Hal-hal tersebut membuat perangkat lunak yang dibangun harus menangani banyak sekali kemungkinan kasus, sementara kami dari sisi konsultan dipacu untuk mengejar jadwal.

Saya belajar bahwa, dalam pengalaman pertama saya yang baru sekali ini terlibat dalam proyek pengembangan perangkat lunak untuk enterprise, tantangan utama terletak pada sisi bisnis, bukan pada sisi teknis. Mungkin tantangan teknis terbesar adalah mengenai masalah kinerja, di mana perangkat lunak harus mengolah data yang besar dalam waktu yang sesingkat mungkin. Namun tantangan terbesar tetaplah mengenai bagaimana kita mampu memahami konsep PSAK dan proses bisnis klien, serta bagaimana menerjemahkannya dalam bentuk perangkat lunak.

Related posts:

  1. Sebuah Jawaban Atas “Misteri Proyek Rekayasa Perangkat Lunak”
  2. Apa Fungsi Sistem Informasi untuk Bisnis Anda?
  3. Belajar Rekayasa Perangkat Lunak – Bagian II
  4. Belajar Rekayasa Perangkat Lunak – Bagian I