Actor-Centered Business-Logic
Ketika merancang sebuah sistem informasi umumnya kita mengikuti pola 3-tiers:
- Data Logic
- Business Logic, dan
- Presentation Logic
- Module-Centered Business-Logic adalah persepsi Business-Logic pada umumnya, saya definisikan ulang disini sebagai sebuah konsep logika yang menyusun kerangka suatu sistem kedalam modul-modul yang mandiri dengan pola pikir HAL APA SAJA yang ada dalam sistem tersebut. Contohnya: Modul Penjualan, Modul Pembelian, Modul Pengguna, Modul Keuangan, dan sebagainya.
- Actor-Centered Business-Logic saya definisikan sebagai sebuah konsep logika yang menyusun kerangka suatu sistem kedalam Aktor-Aktor mandiri dengan pola pikir SIAPA SAJA yang berada dalam sistem tersebut. User disini misalnya Aktor Guest, Actor Admin dan Aktor Member, dan lainnya jika ada. Dalam sistem berbasis web bisa dibilang jenis credential seorang pengunjung halaman pada saat itu.
Kalau dari diagramnya, terlihat Actor-Service mirip dengan Module namun terpisah secara logika bisnis. Tapi pola pikirnya tetaplah dengan Actor, bukan Module, karena kalau tetap Module maka rancangannya malah bisa menjadi module-centered generasi ke-0.
Jika diibaratkan sebuah sistem dengan pendekatan Module-centered seperti sebuah instansi yang loket-loket pelayanannya memiliki plang nama masing-masing departemennya. Ada Departemen Penjualan, Departemen Pembelian, Departemen Keuangan dan lain-lain. Cukup familiar bukan? Pengguna yang memiliki keperluan dapat mendatangi loket-loket yang bersangkutan. Idealnya, keperluan yang meliputi proses lintas departemen dapat dilayani di satu loket saja (sistem satu pintu). Orang telah berpikir bahwa kebutuhan internal harus dijalankan secara berbeda dari kebutuhan eksternal. Sehingga loket-loket dengan pendekatan ini diubah plang namanya menjadi, loket pengurusan tanah, loket pengurusan identitas, loket pengurusan pajak kendaraan dan lain-lain.
Pola pikir penulis sebelumnya masih berpusat pada pendekatan ini. Namun penulis merasa ada yang kurang tepat dalam pola pikir ini. Sekalipun nampak valid dalam cakupan perancangan sistem, ada ketidakselarasan yang terasa dalam proses pengembangan nyatanya. Salah satu masalah yang terjadi dalam proses pengembangan nyata adalah masalah pembagian tugas. Perancangan logika bisnis berbasis pendekatan ini penulis rasa juga menyulitkan dalam pembagian tugas dalam sebuah tim. Hal ini lebih cocok dihadapi dengan pendekatan jenis kedua (actor-centered).
Pendekatan Actor-Centered selayaknya sebuah instansi dengan loket-loket pelayanannya berupa orang-orang yang menjadi pendamping (-bukan perantara). kita istilahkan disini sebagai Agen. Misalnya ada agen untuk Pelanggan (Customer Service), agen untuk pengunjung baru (Receptionist), agen untuk rekanan (Sales and Marketing Agents), agen untuk internal (Office Boy/Girl). Contoh dalam sebuah aplikasi web adalah: Actor Guest, Actor Admin, dan Actor Member.
Pendekatan yang kedua ini bukanlah pengembangan atau penambahan dari pendekatan pertama. Artinya bukan sesuatu yang mungkin lebih baik. Perlu dipikirkan lebih lanjut. Cara kedua ini tidak saja hanya digunakan dalam memenuhi kebutuhan eksternal, pemenuhan kebutuhan internal juga dilayani seperti ini (sehingga tidak terjadi kerancuan dua pendekatan digunakan sekaligus). Hal ini bisa terjadi ketika daya bagi dan akses sumber daya (resource) sudah sangat cepat dan terbuka. Tidak lagi perlu dibagi menjadi departemen-departemen fisik yang awalnya untuk mengelola dokumen-dokumen fisik. Sementara pemisahan logika sumber daya nantinya diserahkan pada lapisan Data Logic-nya. Hukum/aturan (business-rule) sejatinya tidak diterapkan pada APA, tetapi kepada SIAPA.
Manfaat lain yang mungkin bisa diperoleh dari pendekatan kedua adalah adanya konsistensi desain dari awal hingga akhir. Mengurangi missing-link dalam desain dan implementasi. Namun hal ini masih dipengaruhi lagi oleh dua lapisan logika lain nantinya. Kecap, kecap… 
