Topik yang paling menarik dalam Project Management

Sudah beberapa bulan ini berhenti menulis di blog. Sungguh bulan-bulan yang menyibukkan sehingga produktifitas posting di blog menjadi berkurang. Tapi bukan berarti berhenti belajar dan menulis, beberapa hal baru dipelajari dan didokumentasikan dan bisa saya bagi disini.

Beberapa bulan yang lalu saya memutuskan untuk mempublikasikan file-file presentasi training PMP yang saya buat. Saya jamin kulitas konten pada slide yang saya buat tidak kalah dengan apa yang Anda bisa dapat dari perusahaan yang menawarkan training PMP di Indonesia. Point-point penting untuk mendapatkan sertifikasi PMP dari buku PMBOK maupun Buka Rita Mulchahi bisa didapatkan pada slide presentasi yang saya bikin.

Slide presentasi tersebut dan juga slide yang lain bisa Anda lihat di http://www.slideshare.net/ejlp12/presentations.

Saya belum berniat untuk membuat file tersebut downloadable, tapi jika Anda berminat untuk mendapatkan softcopy atau hardcopy-nya, silakan hubungi saya lewat email. Mudah-mudah berguna, dan jika ada kesalahan dalam slide tersebut silakan beritahukan saya juga.

Dari slide presentasi saya tersebut, saya melihat topik Project Risk Management adalah topik yang banyak dicari dan dilihat dari beberapa topik pada project management. Tidak heran, buat saya risk management juga memang hal yang menarik saat awal-awal mempelajari topik project management dan biasanya menjadi hal yang dilupakan buat project manager pemula seperti saya.

Berikut adalah urutan dari slide dengan topik project management yang paling banyak dilihat:

1. Project Risk Management

2. Project Human Resource Management

3. Project Communication Management

4. Project Quality Management

5. Introduction to Framework (PMBOK)

6. Project Time Management

7. Project Cost Management

8. Project Procurement Management

9. Project Scope Management

10. Project Integration Management

TMForum Frameworx = The next of NGOSS

Bulan Maret lalu TMForum mengumumkan sebuah Service-oriented Integrated Business Architecture yang disebut Frameworx.

Frameworx merupakan kumpulan framework yang dikembangkan dari framework yang sudah ada pada NGOSS dengan suatu pendekatan baru yaitu service-oriented dan standar proses arsitektur IT seperti ITIL dan TOGAF sehingga menjadi suatu blueprint untuk mengimplementasikan Service Oriented Enterprise.

Frameworx rencananya akan dirilis secara penuh bulan Juni ini. Beberapa deliverables dari Frameworx ini adalah:

• Business Process Framework (eTOM) version 8
• Information Framework (SID) version 9
• Application Framework (TAM) version 4
• Integration Framework version 2
• A platform architecture approach to facilitate collaboration and management of value chain and outsourcing partners
• Frameworx Roadmap release 1, showing the release strategy and content for the next 12 months

Lebih lanjut silakan lihat tautan berikut:

- Press release

- Halaman TMForum Frameworx.

Memilih Metodologi Manajemen Proyek

Sebuah perusahaan vendor IT atau vendor apapun yang hidup matinya bergantung pada keberadaan proyek, memiliki masalah yang sama dalam menentukan metodologi apa yang cocok untuk digunakan dalam pengerjaan proyek. Dalam dunia IT lebih dalam lagi akan ada pertanyaan metodologi apa yang cocok untuk pengembangan software atau untuk digunakan sebagai acuan Software Development Life Cycle (SDLC).

Pengalaman membuktikan, tidak adanya kejelasan metodologi yang jelas yang digunakan perusahaan akan membuat proyek berjalan tanpa arah dan akan sangat tergantung dari individu manajer proyeknya. Jika kondisi itu berlangsung pada proyek yang kompleks dan ditangani oleh manajer proyek yang tidak berpengalaman maka akan berakhir pada kegagalan proyek. Bagi orang yang lebih tinggi yaitu atasan dari manajer proyek, hal tersebut akan membuat proyek-proyek tidak bisa dimonitor apalagi dikontrol.

Memilih metodologi proyek memang bukan hal yang mudah. Kita tau ada berbagai macam metodologi mulai yang general, yang bisa diimplementasikan pada proyek apapun seperti PMBOK, PRINCE2 maupun yang spesifik untuk domain tertentu misalnya SWEBOK, XP, Scrum yang digunakan pada proyek development software. Masing-masing metodologi memiliki keuntungan dan kita perlu untuk TIDAK memilih begitu saja satu metodologi karena saya percaya tidak ada metodologi yang "one size fits all."

Kita dapat mengelaborasikan beberapa metodologi dan membuatnya pesifik untuk perusahaan dengan catatan metodologi tersebut didefinisikan agar sesuai dengan sifat dari proyek-proyek yang ada dan sebisa mungkin masih dapat disesuaikan (tailored) sesuai dengan besarnya proyek.

Untuk mengelaborasi metodologi, sebaiknya kita mulai dengan studi beberapa metodologi yang sudah ada. Ada baiknya kita membuat listing yang lengkap dari metodologi yang yang sudah ada, mempelajarinya secara high level, kemudian menentukan yang menjadi main interest, lalu melakukan klasifikasi seperti yang dijelaskan sebuah artikel "Defining & Classifying Project Management Methodologies." Berikut ini gambaran level dari klasifikasi metodologi manajemen proyek dari artikel tersebut.

Ada baiknya perusahaan membuat sebuah referensi metodologi manajemen proyek pada Level 3 (Organization specific, customized methodology). Yang dibuat sedemikian rupa sehingga dapat diadaptasi menjadi L4 maupun L5 sesuai kemampuan manajer proyek.

Sebuah kesimpulan yang menarik terkait pemilihan metodologi ini dapat kita lihat dari artikel "Methodology Per Project". Menurut penulis artikel tersebut, Alistair Cockburn, metodologi memiliki sepuluh elemen dasar yaitu: roles, skills, activities, techniques, tools, teams, deliverables, standards, quality measures dan project values. Tidak semua metodologi mencakup semua elemen tersebut, semakin besar proyek maka harus semakin besar metodologinya artinya aspek elemen yang dicakup harus semakin lengkap. Hal tersebut bisa dilakukan dengan cara mengelaborasi beberapa metodologi.

Lebih jauh lagi, perusahaan seharusnya tidak hanya mendefinikan acuan metodologi tetapi sebuah common frame of reference yang mencakup [lihat artikel berikut]:

1. A common project management model.
2. Companywide project management training programs.
3. Project management career development.
4. Knowledge-sharing activities.

Project Value Mangement di PROPS

Buat mengingatkan kita, dalam PMBOK, didefinisikan 9 Knowledge Areas yaitu:

1. Project Integration Management
2. Project Scope Management
3. Project Cost Management
4. Project Time Management
5. Project Risk Management
6. Project Quality Management
7. Project HR Management
8. Project Communication Management
9. Project Procurement Management

Adakah knowledge area yang lain yang didefinisikan di framework lain yang tidak ada di PMBOK? Ada, salah satunya adalah yang ada di PROPS atau PROPS-C yaitu Project Value Management yang terdiri dari:

• Value Analysis
• Value Definition
• Value Control

PROPS adalah model/framework untuk project management yang dibuat dan digunakan Ericsson. Sayangnya model ini cukup tertutup, walaupun sebagian kecil penjelasannya bisa dibaca di http://www.semcon.se/spm/props/props_online_intro/xprops/en/x.pe.intro.html.

PROPS mengadopsi semua knowledge areas dari PMBOK dengan tambahan Project Value Management. Tapi sayangnya, di website semcon tersebut Project Value Management" juga tidak ada penjelasan detailnya.

Ada yang punya informasi lebih detail tentang Project Value Mangement di PROPS?

Apakah Project Value Management di PROPS sesuai dengan apa yang dimaksud dalam buku Cost and Value Management?

Sukseskah layanan 3G di Indonesia.

Saat mulai booming-nya 3G di Indonesia dan juga dinegara lain di dunia, yang paling digembar-gemborkan adalah layanan multimedia terutama video call. Operator-operator seluler di Indonesia pun berlomba-lomba untuk tidak sekedar membangun jaringan akses 3G juga membuat layanan multimedia berbasis video teleponi yang berbasis jaringan circuit switched seperti layanan video portal.

Saat itu 3G tidak digembar-gemborkan sebagai layanan akses mobile broadband. Tapi yang terjadi adalah semakin populer layanan akses data 3G sebagai mobile broadband yang perlahan tapi pasti semakin banyak digunakan, apalagi dengan banyaknya produk modem 3G untuk laptop atau PC. Justru layanan seperti video call tidak banyak digunakan pelanggan, apalagi layanan video portal yang bisa dibilang sudah mati.

Akses data menggunakan jaringan telepon seluler malah lebih berkembang setelah adanya implementasi HSDPA, produk khusus data akses yang dikeluarkan oleh operator dan makin populernya BlackBerry dan Facebook.

Dengan fakta tersebut, bisa kita bilang 3G sukses sebagai layanan mobile broadband tapi berapakah biaya yang sudah dikeluarkan untuk meningkatkan kapabilitas jaringan agar bisa menjalankan video call dan membuat layanan video portal? Jika layanan itu bisa dibilang mati, berapakah biaya yang terbuang?

Dengan pengalaman itu dan banyak pengalaman ketidaksuksesan yang lain, operator seluler semakin berhati-hati dalam menginvestasikan uangnya untuk membuat layanan baru dan mengadopsi teknologi baru.

Femtocell

Topik femtocell, mungkin topik hot yang belum pernah dibahas disini. Kenapa? Ketika mempelajari tentang femtocell terutama konsep dasarnya, saya pikir femtocell ini tidak akan "jalan" di Indonesia.

Saya belum akan membahas topik femtocell ini disini, tapi mungkin ada yang punya pandangan tentang arah perkebangan implementasi femtocell di Indoensia? Silakan memberi komentar sementara saya menyiapkan tulisan tentang femtocell :-)

Evolved Packet Core (EPC)

Anda mungkin sudah tahu teknologi LTE (Long Term Evolution) yaitu teknologi terkini yang dipersiapkan untuk jaringan akses radio telekomunikasi bergerak yang merupakan jalur evolusi untuk 2G GMS dan 3G UMTS.

LTE dikembangkan agar dapat memenuhi standar 4G dengan kecepatan akses yang lebih tinggi dari HSDPA, HSPA+. Perubahan teknologi akses radio ini juga diikuti dengan core network dari provider telekomunikasi bergerak.

EPC adalah core network untuk mendukung teknologi LTE dengan konsep arsitektur All-IP, artinya jaringan tersebut menggunakan protokol IP yang berbasis packet dan tidak lagi menggunakan TDM/ATM. EPC dibuat dan distrandarisasi oleh 3GPP pada Release 8 dan terus dikembangkan hingga saat ini (Release 10). Studi pembuatan packet core network baru untuk LTE ini disebut System Architecture Evolution (SAE) dengan fokus sebagai berikut:

• Arsitektur yang sederhana dan mendukung kecepatan transfer data yang tinggi
  
• Merupakan jaringan All-IP
• Mendukung jaringan akses paket apapun misalnya WiFi, WiMAX
• Mendukung mobilitas, roaming
  
• Dapat tetap bekerja atau saling tehubung (interworking) dengan legacy system misalnya PSTN, GSM, UMTS, CDMA dll.
  
• Mendukung layanan real-time dan multimedia dengan Quality of Experince (QoE) yang baik

Berikut ini digambarkan posisi EPC pada arsitektur jaringan operator telekomunikasi bergerak.

[Gambar diambil dari sini]

Berbeda dengan core network pada generasi sebelumnya yaitu 2G dan 3G, pada EPC tidak dikenal pembagian CS (circuit switched) domain dan PS (packet switched) domain. Pada EPC hanya digunakan protokol berbasis paket (IP) dari perangkat pengguna ke eNodeB, sebutan base station pada LTE, lalu ke EPC dan ke service domain atau application domain dalam hal ini biasanya adalah IMS (IP Multimedia Subsystem).

Penggunakan IP ini sesuai dengan perkembangan konvergensi teknologi telekomunikasi atau arsitektur next generation network (NGN) yang telah dirumuskan oleh organisasi-organisasi telekomunikasi dunia, seperti ETSI/TISPAN, 3GPP, 3GPP2, ITU.

Berikut gambar EPC yang meperlihatkan konektifitas dengan akses radio 2G, 3G, Internet, PSTN dan PLMN.

Klik gambar untuk meperbesar

Elemen dari EPC terdiri dari:

• Mobility Management Entity (MME)
• Serving Gateway (SGW)
• Packet Data Network (PDN) Gateway (PGW)
• Policy & Charging Rule Function (PCRF)

Kemana arah evolusi jaringan operator telekomunikasi Indonesia?

Menurut saya, evolusi arsitektur jaringan dari operator telekomunikasi bergerak terutama GSM sudah sangat jelas yaitu mengikuti standard dari 3GPP. Standard tersebut sudah mengantisipasi global market trend.

Tiga pilar pengembangan (enhancement) yang terefleksikan dalam standar yang dibuat 3GPP
adalah

• Access network
• Arsitektur core network
• Service dan atau service layer

Perlu diketahui saat ini kebayanakan operator telekomunikasi bergerak di Indonesia memiliki core network dari implementasi standar 3GPP Release 4. Sedangkan jaringan aksesnya mengimplementasikan teknologi GSM, UMTS, HSDPA bahkan sudah ada yang menggunakan telkologi HSPA+.

Jadi jika dilihat dari domain core network dan service layer, apa yang harus diadopsi oleh operator telekomunikasi bergerak saat ini sesuai dengan standar 3GPP adalah menambahkan arsitektur IMS (Standar 3GPP Release 5).

Saya sendiri termasuk yang skeptik akan keuntungan implementasi IMS dalam waktu dekat. IMS yang sudah mulai dikembangkan tahun 2002 dan kemudian standarnya selesai tahun 2005 pada 3GPP Release 5, saat ini sudah banyak diimplementasikan di operator-operator telekomunikasi baik mobile maupun fixed di luar negeri. Jika kita melihat di berita-berita, implementasi IMS mungkin bisa dibulang sukses, tapi saya tidak yakin implementasi itu sudah membuat suatu nilai tambah yang besar. Tidak ada layanan-layanan yang jadi booming dan menghasilkan revenue besar, bahkan layanan VoIP lewat jaringan IMS pun belum banyak digunakan saat ini.

IMS yang distandarisasi pada 3GPP Release 5 pun masih terbilang terburu-buru, sehingga terus dikembangkan sampai sekarang. Standar dianggap cukup lengkap setelah Rel-5 adalah Release 8 yang dikeluarkan pada tahun 2008 dan sering disebut Common IMS dan hingga Rel-9 dan Rel-10 spesifikasi IMS masih terus dikembangkan. Jadi mungkin adopsi IMS yang banyak dilakukan di tahun 2006 dan 2007 bisa dibilang sangat terburu-buru.

Jika kita melihat teori hype cycle-nya Gartner, saat ini kemungkinan perkembangan implementasi IMS telah mencapai "peak of inflated expectation" dan "through of disillusionment" sehingga mudah-mudahan di tahun ini IMS mulai menemukan tempatnya sehingga satu atau dua tahun kedepan bisa mulai masuk tahap "plateau of productivity" seiring dengan dorongan dari teknologi LTE.

IMS memang dibuat untuk menggantikan arsitektur jaringan saat ini yang berbasis circuit switched menjadi packet switch (berbasis protokol IP). Tapi saya kira belum saatnya investasi pada circuit switch digantikan sepenuhnya dengan packet switch, bahkan untuk 5 tahun mendatang. Investasi operator pada infrastruktur jaringan circuit switched sudah cukup besar.

Oleh karena itu jika operator telepon bergerak punya visi mengimplementasikan IMS saat ini, sejujurnya menurut saya hanya akan jadi penting sebagai strategi marketing, bahwa operator tersebut menjadi operator terdepan dalam menggunakan teknologi baru.

Tapi jika operator adalah operator yang memiliki jaringan fixed, mobile atau mungkin layanan digital TV, layanan internet xDSL, maka IMS akan sangat berperan penting untuk menuju kearah arsitektur Fixed Mobile Convergence (FMC) atau Next Generation Network (NGN). Jadi benefit yang lebih besar dari IMS akan sangat dirasakan oleh operator jenis itu.

Selain itu yang menjadi penting dari IMS, menurut saya adalah bagaimana layanan-layanan dasar yang sudah ada sekarang dapat diekspos sehingga layanan-layanan baru bisa dibuat dengan mudah dan pihak ketiga bisa berperan banyak dalam membuat layanan-layanan baru tersebut. Untuk mengekspos layanan-layanan dasar yang ada tersebut tidak harus ditempuh dengan mengimplementasikan sepenuhnya arsitektur IMS tapi bisa dengan mengimplementasikan "service broker" (OSA/Parlay).

Untuk menggunakan IMS sebagai infrastruktur pengganti layanan dasar teleponi berbasis ciscuit switched pun perlu didukung oleh jaringan akses radio yang baik dengan kecepatan minimal HSDPA. Pada saat ini cakupan akses HSDPA dari operator Indoensia pun masih terbatas dan kualitanya belum baik. Oleh karena itu implementasi IMS sekarang hanya akan menjadikan IMS sebagai service framework dan belum menjadi core network, karena layanan dasar teleponi dan layanan supplementary yang standar (MMTel) belum layak dijalankan.


Deployment IMS.

Dari segi implementasi atau deploymentnya, IMS akan tergantung pada produk vendor, artinya akan tergantung dari kondisi existing jaringan yang dimiliki operator. Ada beberapa vendor yang bisa melakukan evolusi bertahap dengan hanya upgrade software dari produk softswitch atau media gateway sehingga lebih efisien.

Oleh karena itu operator perlu melakukan riset untuk analisis bagaimana produk-produk yang sudah digunakan bisa di-upgrade menjadi jaringan IMS dan menganalisis antara evolusi yang sudah dibuat oleh standard body dengan kondisi market dan kondisi existing network. Sehingga didapatkan arah pengembangan (evolusi) yang efisien dari segi biaya dan menghasilkan keuntungan yang besar.

Selain analisis, riset juga membutuhkan proof of concept dari layanan-layanan yang akan dibangun diatas arsitektur IMS. Kita bisa ambil contoh dari implementasi layanan-layanan baru dari operator lain di luar negeri yang sudah mengimplementasikan IMS. Tapi menurut saya itu hanya akan menjadi contoh yang mungkin tidak "menjual" disini, sehingga diperlukan ide-ide layanan lain yang lebih cocok untuk market Indonesia.

Tentu saja pandangan saya diatas perlu didiskusikan lebih lanjut dan bersifat debatable. Silahkan yang mau mengkritik atau memberikan pandangan lain.


Catatan:

Saya tidak membicarakan mengenai Evolved Packet Core (EPC) atau SAE (Service Architecture Evolution) yang merupakan tren terkini dari jaringan telkomunikasi untuk teknologi LTE, karena saya kira masih terlalu dini teknologinya untuk diimplementasikan. Dan IMS merupakan bagian yang masih penting dalam EPC karena IMS merupakan jaringan yang access network agnostic artinya IMS bisa saling bekerjasama dengan EPC.

Rich Communication Suite (RCS)

Ketika melihat terminologi Rich Communication Suite (RCS) di sebuah halaman website tetang spesifikasi produk IMS saya sudah bisa menebak apa maksud dari RCS. Dalam pikiran saya saat pertama membaca istilah RCS adalah komunikasi multimedia. Ya, tertanya memang tidak jauh dari itu pengertiannya.

Istilah RCS sendiri sebenarnya diawali dari sebuah initiative atau konsorsium dari beberapa provider komunikasi dan vendor produk telekomunikasi pada Februari 2008. Press rilisnya bisa dilihat disini. Tujuan konsorsium tersebut adalah membuat fitur-fitur atau layanan komunikasi yang lebih kaya (rich communication) yang dapat saling beroperasi antar provider (interoperability) dengan berbasis pada standar yang ada. Selain itu juga bertujuan untuk memberikan petunjuk (guideline) untuk implementasi dan melakukan test layanan tersebut.

Awalnya fitur utama RCS didefinisikan sbb:

• Enhanced Phonebook, with service capabilities and presence enhanced contacts information
• Enhanced Messaging, which enables a large variety of messaging options including chat and messaging history
  
• Enriched Call, which enables multimedia content sharing during a voice call

Pada bulan September 2008 kemudian GSMA mengambil alih initiative tersebut dengan lebih banyak superter. Kemudian GSMA membuat dokumen spesifikasi RCS. Informasi tentang RCS dari GSMA dapat dilihat di halaman introduction, bisa dilihat di halaman tersebut, fitur lain dari RCS adalah

• Broadband access client and support for a multi-device environment so user access to services and applications will be possible from both mobile and fixed terminals (PCs)

Berdasarkan dokumen RCS release 3, group fitur RCS adalah:

• Social presence information enhancements
  
• Enhanced messaging
  
• Network value added services (NVAS)
  
• Content sharing enhancement
• Broadband access (BA) enhancement

Dalam menspesifikasikan RCS, GSMA mengadopsi spesifikasi dari organisasi lain yang sudah ada seperti dari 3rd 3GPP, Open Mobile Alliance (OMA), Telecommunication Technology Committee RCS group (TTC RCSS).

Jadi intinya layanan RCS bukanlah sebuah layanan baru, tapi layanan yang sebenarnya sudah ada dan biasa kita gunakan lewat Internet. Seperti halnya kita saat ini menggunakan Yahoo! Messanger dimana kita bisa berkomunikasi dengan chat/teks, voice, video call dan juta saling bertukar gambar atau file. Layanan seperti itu diadopsi dalam komunikasi bergerak dimana jaringan telekomunikasi sudah menyatu dengan jaringan Internet dengan adanya IMS dengan mengedepankan interoperability dengan standar teknis yang terbuka.

RCS pada dasarnya akan dapat berjalan juga pada jaringan 3G dengan menggunakan jaringan CS dan PS, tapi tentu saja untuk beberapa layanan seperti video atau image share mungkin tidak dapat dilakukan.

Berikut gambaran arsitektur RCS yang disederhanakan yang memperlihatkan hubungan antara dua provider RCS.

Gambar diambil dari dokumen spesifikasi RCS R3 Technical Realization
[Klik gambar untuk memperbesar]

Keterangan gambar:

• CS/PS GW adalah gateway yang digunakan untuk menjembatani antara CS voice dengan PS Voice (MMTel).
• IPX = IP Packet Exchange
• VS AS = Video Sharing Application Server
• IMS = IP Multimedia Subsystem
• XDMS = XML Data Management Server
• DM = Data Management
• DS = Data Synchronization
• IM = Instant Messaging Server
• Presence = Presence Server

Bisa kita lihat RCS tidak terlalu special tapi menjadi special karena istilah tersebut sebuah istilah 'jualan' (marketing) sehingga menjadi populer. Yang menjadi penting adalah interoperability atau interworking sehingga layanan dapat berjalan dari berbagai jaringan akses (2G, 3G, LTE, Broadband) dan dengan menggunakan berbagai perangkat.

Telecom Service Broker

Tulisan dari LightReading berjudul "Telecom Service Broker" ini menarik untuk dibaca. Dalam artikel itu kita akan tau apa, bagaimana dan siapa yang membuat produk "telecom service broker."

Konsep telecom service broker memang sama dengan service broker yang ada di dunia IT atau Service Oriented Architecture (SOA) saat ini. Tapi perlu diingat kata pertama dalam judul itu (Telecom) membuat konteksnya agak lain.

Istilah service broker di area provider telekomunikasi ini mulai menjadi berita ketika beberapa produsen produk ini membentuk Service Broker Forum bulan Maret 2009 oleh Aepona, AppTrigger, Convergin, jNetX dan OpenCloud.

Pada dasarnya elemen telecom service broker dibuat untuk memberikan kemampuan pada operator telekomunikasi untuk melakukan konektifitas antar aplikasi, interaksi antar layanan, network orchestration dengan menggunakan standar 3GPP.

Telecom service broker juga mengadupsi konsep elemen Service Capability Interaction Manager (SCIM) dalam jaringan IMS. Perlu diketahui awalnya SCIM adalah konsep yang belum didefinisikan dengan jelas tapi sudah dituliskan pada standar IMS di 3GGP R7. Studi tentang service broker oleh 3GPP bisa dilihat di TR 23.810 Study on Architecture Impacts of Service Brokering yang merupakan bagian dari 3GPP R8.

Pada website Service Borker Forum, dijelaskan paling tidak fungsi utama dari service broker adalah

• SCIM
• IM-SSF
• IN-IN Trigger Management
• Protocol/Call Flow Management
• Subscriber Data Management Interaction

Gambar berikut memperlihatkan posisi service broker seperti definisi yang dijerlaskan Service Broker Forum:

"A network element that efficiently manages service interaction and service composition and resides between the service layer and the converging network and is traditionally decoupled from the core switch and the service execution or service creation environment"

Gambar diambil dari Service Broker Webinar slide presentation

Seperti ditulis di artikel LightReading, :

"service-broker functionality has long existed in mobile networks, but that many operators were not translating this need into a defined product category"

Jadi konsep telecom service broker sejak lama dan sudah mulai diimplementasikan seiring dengan berkembangnya Parlay-X, IMS/SCIM, SDP, Next Generation IN, Telco 2.0, OneAPI dan API-API lain yang mengekspos jaringan/layanan operator telekomunikasi ke "dunia luar" (IT world/3rd parties/Internet). Dan saya pede untuk mengatakan kalo ini sebenarnya adalah strategi marketing vendor-vendor telekomunikasi yang punya produk tersebut untuk dapat menjual (atau istilah sopannya mengedukasi para customer dalam hal ini operator telekomunikasi).

Saya tidak yakin kalo operator-operator di Indonesia dalam waktu dekat akan migrasi ke MIS atau SIP dari tradisional signaling (SS7), jadi yang relevan buat operator-operator di Indonesia adalah telecom service broker yang mengekspos legacy system (seperti MSC, legacy IN, SMSC, HLR, dll) ke "dunia luar". Di beberapa operator juga banyak lebih memilih untuk mulai menggunakan SIGTRAN (SS7 over IP) dibanging migrasi menggunakan SIP.

Jadi dalam kasus telecom service broker ini yang akan jadi preferred choice di Indonesia adalah yang bisa mengekspos legacy system.

OSS/J

OSS/J awalnya merupakan grup perusahaan-perusahaan yang berusaha membuat implementasi dari OSS/BSS dengan menggunakan Java sebagai teknologinya dan arsiteturnya mengacu pada NGOSS (Next Generation Operations Support System).

OSS/J dibentuk tahun 2003 dengan menggunakan Java Community Process (JCP) untuk membuat standar API yang dispesifikasikan pada dokumen JSR (Java Specification Request). Tahun 2006, OSS/J mulai bergabung dengan organisasi TMForum dan tahun 2008 mulai masuk dalam satu payung dalam TMForum Interface Program.

OSS/J API ini dibuat dengan beberapa teknologi untuk integrasi yang disebut integration profiles, yaitu Java RMI/IIOP, XML/JMS, dan Web Services.

Integration Profiles

[Gambar diambil dari dokumen OSSJ Design Guidelines]

Core API dari OOS/J ini didesain sesuai Core Business Entities (CBE) yang diadopsi dari Shared Information Data (SID) model yang dibuat oleh TMForum.

Awalnya API yang dibuat adalah sebagai berikut:

1. Common API v1.0
2. Inventory v1.0
3. Trouble Ticket v1.0

Kemudian berkembang menjadi beberapa API sebagai berikut:

1. Common API (JSR 144)
2. Service Activation v1.1(JSR 89)
3. Quality of Service v1.0 (JSR 90)
4. Trouble Ticket (JSR 91)
5. IP Billing (JSR 130)
6. Inventory API (JSR 142)

Hingga saat ini beberapa perubahan terlah terjadi yaitu

- Service Activation API diganti menjadi Order Management API.

- Billing Mediation atau IP Billing API dan Quality of Service API sudah tidak dikelola lagi.

- Bagian dari QoS API yaitu fault management dibuat terpisah menjadi Fault Management API.

Saat ini OSS/J API dikembangkan dengan prinsip SOA (Service Oriented Architecture) dengan spesifikasi sebagai berikut:

1. Common API v1.5 (JSR 144)
2. Order Management v1.0 (JSR 246)
3. Trouble Ticket v1.2 (JSR 91)
4. Inventory v1.2 (JSR 142)
5. Fault Management v1.0 (JSR 263)
6. Discovery v1.0 (JSR 254)

Dokumen spesifikasi tersebut bisa di-download disini (website TMForum) atau disini (website JSR).

TMForum juga mengembangan implementasi OSS/J yang gratis dan open source dan memberikan list beberapa produk yang sudah mengimplementasikan standar OSS/J.

VoLTE: VOLGA vs OneVoice Initiative

Agak telat berita ini saya tulis disini, tapi masih cukup segar, belum lama ini GSMA merilis berita bahwa mereka mengadopsi One Voice sebagai teknologi Voice over LTE (VoLTE).

Seperti pada tulisan sebelumnya, cukup mengherankan kenapa ada inisiatif One Voice ini, padahal sudah ada VoLGA dan juga IMS. Tapi cukup jelas bagaimana posisi VoLGA terhadap One Voice ini seperti yang dilansir oleh VoLGA Forum bahwa operator telekomunikasi berhak menentukan bagaimana evolusi jaringannya dan

"VoLGA is an excellent solution for voice and SMS over LTE for operators who decide to take an interim approach prior to IMS-based voice and messaging services"

Dan saya percaya untuk kondisi Indonesia, VoLGA masih lebih cocok sebagai jalur yang perlu ditempuh --untuk menuju LTE-- oleh para operator telekomunikasi kita yang masih menggunakan jaringan berbasis circuit switch dan enggan untuk berevolusi ke IMS.

TOGAF 9

Belum lama ini, 4 Februari 2010 telah dirilis TOGAF versi 9.

TOGAF merupakan singkatan The Open Group Architecture Framework yaitu framework maupun metodologi untuk arsitektur IT atau sering disebut Enterprise Architecture (EA). Bisa dikatakan TOGAF merupakan acuan (guide) untuk merancang atau membangun sebuah EA.

Dokumen TOGAF versi 9 bisa diunduh dari website The Open Group setelah melakukan registrasi.

Lagi lagi API untuk Telekomunikasi: OneAPI

Seperti sudah dijelaskan sebelumnya, usaha untuk membuat API atau interface yang membuka layanan dari operator atau provider telekomunikasi telah dilakukan beberapa organisasi, salah satunya adalah OneAPI yang diusing oleh GSM Assosiation, sebuah organisasi atau asosiasi internasional yang beranggotakan operator/provider telekomunikasi GSM dan vendor telekomunikasi.

Awalnya proyek OneAPI ini dinamai 3rd party access, yang dari namanya sudah jelas tujuannya adalah membuat API untuk memberikan akses kepada pihak ketiga ke layanan atau network yang dimiliki operator telekomunikasi.

Saya tidak akan membahas terlalu jauh tentang OneAPI karena API ini belum lama muncul, belum mature dan informasi atau dokumentasinya pun masih sangat minim.

Proyek pilot secara komersialnya baru dilakukan bulan lalu (Februari 2010), sedangkan spesifikasi dan dokumentasinya baru akan dirilis bulan Maret 2010. Saat ini API ini baru menspesifikasikan fungsi-fungsi untuk Messaging (SMS and MMS), Location, Payments dengan tekonologi Web Service dan RESTful. Spesifikasi OneAPI ini kemungkinan akan dikeluarkan oleh OMA.

Rencananya, OneAPI versi 2 akan memasukan fungsi-fungsi berikut:

• Data Connection profile
• QoS Quality of Service
• Remaining Credits Look-Up
• SMS triggering via UDH
• In-app billing

Lebih lanjut tentang OneAPI ini bisa dilihat di portal atau di library.

OneAPI: The first standard telecom RESTful API?

Saya sendiri bertanya-tanya mengapa dibuat standar baru dengan teknologi REST? Yang jelas REST ini lebih sederhana dibanding SOAP dan juga mudah karena menggunakan protokol HTTP.

Dan yang pasti beberapa vendor memang sudah mulai menggunakan REST sebagai interface untuk solusi SDP. Coba anda baca artikel "Who Makes What: RESTful Service Delivery Platforms". Bisa jadi RESTful API akan semakin banyak digunakan menggantikan SOAP seiring dengan makin populernya konsep Telco 2.0.

JAIN API

JAIN adalah komunitas di JCP (Java Community Process) yang berinisiatif membuat standar API untuk keperluan pembuatan layanan (service) teleponi baik itu layanan yang berbasis suara maupun data.

Nama awal JAIN adalah Java APIs for Intelligent Network karena tujuan awalnya JAIN adalah membuat API untuk layanan Intelligent Network (IN), tetapi kemudian berkembang cakupannya menjadi API untuk semua service di jaringan telekomunikasi sehingga namanya diubah menjadi Java APIs for Integrated Networks.

Dibuatnya API untuk mengekspos layanan teleponi ini dilatarbelakangi oleh trend konvergensi dunia telekomunikasi dan dunia IT/Internet (layanan data). Dunia telekomunikasi selama ini dilandasi oleh protokol yang berbeda dengan yang digunakan di dunia IT yaitu protokol TCP/IP tapi serkarang mulai berkembang pemakaikan protokol TCP/IP di jaringan telekomunikasi. Untuk dapat memberikan layanan-layanan baru yang mudah dan cepat dibuat perlu suatu interface atau API.

Selain JAIN, inisiatif untuk membuat interface atau API juga dilakukan organisasi atau komunitas lain misalnya OSA/ParlayX yang dibuat Parlay Group, OneAPI [link portal] yang dibuat oleh GSM Association & Aepona.

Berikut adalah beberapa spesifikasi yang sudah dibuat oleh JAIN yang bisa juga dilihat disini atau disini:

1. Java Application Interfaces for Communications:

- JAIN SIP 1.1

- SIP API for J2ME 1.0

- JAIN MGCP 1.0

- JAIN MEGACO

- JAIN Session Description Protocol (SDP)

- JAIN ENUM [lihat RFC2916]

- JAIN TCAP 1.1

- JAIN INAP 1.0

- JAIN Java Call Ccontrol (JCC) 1.1

- JAIN Java Coordination and Transaction (JCAT)

- Java Payment API (JPay)

- JAIN Presence

- JAIN Instant Messaging

- JAIN SIMPLE Instant Messaging

- JAIN SIMPLE Presence

- JAIN SIP Lite

- JAIN Service Creation Environment (SCE) SCML

- JAIN Service Creation Environment (SCE)

- Java - Server API for Mobile Services (SAMS): Messaging

2. Java Application Containers for Communications:

- JAIN Service Logic Execution Environment (JSLEE)

- SIP Servlets 1.0

Cukup banyak spesifikasi interface yang sudah dibuat oleh JAIN. Tapi perkembangan market penggunaan JAIN API maupun API sejenis di operator telekomunikasi saat ini saya kira masih rendah.

Operator telekomunikasi tidak perlu lagi WAP Gateway?

Produk-produk WAP Gateway atau WEB proxy yang digunakan operator telekomunikasi biasanya memiliki fitur penting yaitu

• kompresi, sehingga trafik ke internet menjadi semakin efektif (kecil)
• adaptasi kontent atau tampilan, yang membuat tampilan di mobile device menjadi sesuai dengan kapabilitasmobile device tersebut atau aplikasi web/wap browser-nya.

Tapi dengan adanya beberapa perusahaan yang memberikan layanan gratis untuk fungsi tersebut, fitur tersebut menjadi tidak penting buat sebuah WAP Gateway atau WEB Proxy.

Sebagai contoh misalnya Google, perusahaan ini memberikan layanan adaptasi tampilan. Coba saja search pada google dari browser handphone anda dan klik hasil pencariannya, Google akan menubah tampilannya, jika halamannya panjang maka halaman akan dipotong dalam beberapa halaman.

Contoh lain yang mirip adalah Opera Mini yang memiliki strategi bisnis yang bagus yaitu bekerja sama dengan operator untuk memberikan layanan browsing yang lebih efisien dan murah tapi mereka (Opera) juga dapat untung.

Gambar dari Opera.com

Dengan menggunakan aplikasi browser Opera Mini, aktifitas browsing tidak lagi langsung mengakses web server yang dituju, tetapi akses koneksi akan dilewatkan ke Opera Mini Server yang bertugas untuk melakukan optimasi seperti kompresi dan adaptasi konten. Jadi Opera Mini Server berfungsi sebagai proxy atau gateway default untuk aplikasi browser Opera Mini.

Mekanisme tersebut membuat akses internet menjadi optimal dan efisien baik dari sisi pengguna (pelanggan) maupun dari sisi operator telekomunikasi. Oleh sebab itu bisnis ini bisa dilirik oleh operator.

Berikut link yang menjelaskan pemaparan teknologi Opera Mini.