sim-manajement-book/chapters/outlines/_archive_v1/outline-bab-10.md

OUTLINE DETAIL — BAB 10

Infrastruktur Digital: Cloud, IoT, dan Arsitektur Modern

Bagian: III — Analisis dan Perancangan SI
Level: Menengah
Estimasi Halaman: 18–22
Target Kata: 4.500–5.500

---

SEK 10.1 — PEMBUKA

Opening Bridge dari Bab 9: Business Case (Artefak 9.1) mendefinisikan kebutuhan bisnis dan justifikasi investasi. Salah satu keputusan terbesar dalam implementasi SI modern adalah tentang infrastruktur: di mana sistem ini berjalan? Bagaimana ia terhubung dengan data sumber? Berapa biaya operasionalnya dalam 5 tahun? Jawaban atas pertanyaan ini membutuhkan pemahaman tentang infrastruktur digital modern — perspektif manajerial, bukan teknis.

Hook: Direktur IT sebuah perusahaan retail nasional sedang rapat dengan CFO. Di satu sisi: proposal membangun data center baru seharga Rp 25 miliar. Di sisi lain: proposal migrasi ke cloud dengan biaya tahun pertama Rp 4 miliar. CFO bertanya: "Mana yang lebih hemat?" Direktur IT menjawab: "Tergantung." Pertanyaan yang benar seharusnya bukan tentang biaya — tapi tentang kapabilitas apa yang dibutuhkan bisnis dalam 5 tahun ke depan.

Pertanyaan sentral: "Bagaimana manajer bisnis membuat keputusan tentang infrastruktur digital — cloud strategy, IoT deployment, dan arsitektur SI — berdasarkan kebutuhan bisnis, bukan sekadar spesifikasi teknis?"

---

SEK 10.2 — MODEL UTAMA (Gambar 10.1)

Nama Model: Kerangka Infrastruktur Digital Berlapis (KIDB)

Mermaid diagram: graph TD, 5 lapisan dari bawah ke atas

Layer 1: Connectivity Layer
  - Jaringan (LAN, WAN, SD-WAN, 5G)
  - IoT Edge Devices
  - API Gateway

Layer 2: Compute & Storage Layer
  - On-premise servers
  - Private cloud
  - Public cloud (IaaS)
  - Edge computing

Layer 3: Platform Layer (PaaS)
  - Managed databases
  - Container orchestration (Kubernetes)
  - Data pipelines
  - AI/ML platforms

Layer 4: Application Layer (SaaS)
  - ERP, CRM, SCM
  - Collaboration tools
  - Custom applications

Layer 5: Experience Layer
  - Web apps, mobile apps
  - API untuk partner/customer
  - Voice/conversational interfaces

Panah = data flow; Semua layer terhubung ke Security & Governance layer (horizontal)

---

SEK 10.3 — DEFINISI KUNCI

1. 📌 Cloud Computing — Model layanan komputasi yang memungkinkan akses jaringan sesuai permintaan dan berbagi ke pool sumber daya komputasi yang dapat dikonfigurasi (jaringan, server, penyimpanan, aplikasi, layanan) yang dapat dengan cepat disediakan dan dirilis dengan upaya manajemen minimal (NIST, 2021). Relevansi manajerial: cloud mengubah pengeluaran modal IT (CapEx) menjadi pengeluaran operasional (OpEx) — ini adalah keputusan keuangan dan strategis yang melampaui domain teknis.

2. 📌 Internet of Things (IoT) — Jaringan objek fisik yang tertanam dengan sensor, perangkat lunak, dan teknologi lain untuk tujuan menghubungkan dan bertukar data dengan perangkat dan sistem lain melalui internet (ITU-T, 2022). Relevansi manajerial: IoT mengubah dunia fisik menjadi sumber data real-time — memungkinkan visibilitas dan kontrol operasional yang sebelumnya tidak mungkin.

3. 📌 Model Layanan Cloud (IaaS/PaaS/SaaS) — Tiga tingkat layanan cloud: Infrastructure as a Service (IaaS — sewa infrastruktur mentah), Platform as a Service (PaaS — sewa platform pengembangan), dan Software as a Service (SaaS — sewa aplikasi siap pakai) (NIST, 2021). Relevansi: pilihan model layanan menentukan seberapa besar tanggung jawab teknis yang "dialihdayakan" ke penyedia cloud vs dikelola sendiri.

4. 📌 Arsitektur Microservices — Pendekatan pengembangan software di mana aplikasi dibangun sebagai kumpulan layanan kecil yang independen, masing-masing berjalan dalam prosesnya sendiri dan berkomunikasi melalui API, dapat di-deploy secara independen (Alim, 2025). Relevansi manajerial: microservices memungkinkan organisasi mengubah satu bagian sistem tanpa mengganggu seleruhnya — mengurangi risiko dan meningkatkan agility.

---

SEK 10.4 — KONSEP INTI

10.4.1 — Cloud Strategy: On-Premise, Cloud, Hybrid

Argumen utama: Tidak ada satu pendekatan yang benar untuk semua organisasi — keputusan cloud adalah portfolio decision, bukan binary. 4 model deployment cloud:

1. On-premise — semua infrastruktur di dalam gedung. Kontrol penuh, biaya tetap tinggi, capex besar.
2. Private cloud — virtualisasi on-premise atau dedicated hosting. Keamanan lebih baik dari public, tapi tetap capex.
3. Public cloud — AWS, Azure, GCP. Pay-as-you-go, elastis, tapi shared environment.
4. Hybrid cloud — kombinasi. Workload sensitif on-prem/private; workload elastis di public cloud.

Panduan keputusan per tipe workload:

• Core banking, data sensitif regulasi → on-premise atau private
• Development & testing → public cloud (elastis, tidak perlu permanent)
• Analytics & big data processing → public cloud (biasanya lebih efisien)
• Standard SaaS (email, CRM, collaboration) → SaaS (tidak perlu build sendiri)

Total Cost of Ownership (TCO) — perbandingan 5 tahun:

• Include: hardware refresh, data center space, networking, security, maintenance staff
• Cloud: usage cost, egress fees, support plan, potential vendor lock-in

10.4.2 — IaaS, PaaS, SaaS: Memilih Level yang Tepat

Argumen utama: Semakin tinggi level layanan, semakin sedikit kontrol — tapi semakin sedikit beban manajemen. Responsibility matrix (shared model):

Tanggung jawab	On-Premise	IaaS	PaaS	SaaS
Physical security	Anda	Provider	Provider	Provider
Network hardware	Anda	Provider	Provider	Provider
OS & patching	Anda	Anda	Provider	Provider
Runtime & middleware	Anda	Anda	Provider	Provider
Application	Anda	Anda	Anda	Provider
Data	Anda	Anda	Anda	Anda (dalam batas)

Panduan praktis untuk manajer:

• SaaS: default pilihan untuk aplikasi standar (email, project manage, CRM)
• PaaS: untuk developer yang perlu deploy custom apps
• IaaS: untuk workload yang butuh kustomisasi OS/environment

10.4.3 — IoT: Dari Objektif ke Insights

Argumen utama: IoT mengubah aset fisik menjadi sumber data real-time — implikasinya bagi manajemen sangat transformatif. 5 kategori penggunaan IoT di manajemen:

1. Asset monitoring — kondisi mesin, kendaraan, peralatan
2. Environmental monitoring — temperatur gudang, kualitas udara, energi
3. Supply chain visibility — lokasi shipment real-time, kondisi cold chain
4. Customer experience — behavior di toko fisik, queue monitoring
5. Predictive maintenance — analisis sensor untuk anticipate failure

Arsitektur IoT:

• Edge: sensor dan gateway di lapangan
• Fog: computing di antara edge dan cloud (pre-processing)
• Cloud: storage, analytics, ML model training

Tantangan IoT:

• Security: setiap device adalah potential attack vector
• Connectivity: remote areas, intermittent connectivity
• Data volume: 1 pabrik dengan 1.000 sensor bisa menghasilkan terabyte per hari

10.4.4 — Microservices dan API Economy

Argumen utama: Arsitektur monolitik yang baik-baik saja untuk era lalu mulai menjadi hambatan di era perubahan cepat — microservices memberikan agility yang memungkinkan inovasi lebih cepat. Monolith vs Microservices:

• Monolith: semua fungsi dalam satu codebase. Mudah develop di awal, sulit scale dan maintain.
• Microservices: setiap fungsi independen. Lebih kompleks sistemnya, tapi setiap service bisa di-deploy, di-scale, dan diubah secara independen.

API Economy:

• API (Application Programming Interface) adalah "kontrak" antar sistem
• API-first approach: rancang API dulu sebelum UI atau backend
• Open API: membuka kemampuan sistem untuk digunakan partner/developer eksternal

Contoh Indonesia: Bank Negara Indonesia (BNI) Open API — puluhan fintech mengintegrasikan layanan perbankan melalui API BNI tanpa negosiasi per-integrasi. Ini contoh API economy yang menguntungkan ekosistem.

10.4.5 — Edge Computing dan Real-time Processing

Argumen utama: Tidak semua data harus dikirim ke cloud — edge computing memproses data di dekat sumbernya untuk latensi ultra-rendah. Kapan edge computing penting:

• Real-time decisions yang tidak bisa menunggu round-trip ke cloud (autonomous vehicles, industrial control)
• Bandwidth constraint: area dengan konektivitas terbatas
• Data residency: data tidak boleh meninggalkan lokasi tertentu (regulasi)
• Privacy: PII data tidak perlu dikirim ke cloud

Contoh:

• Kamera CCTV dengan AI object detection di edge (bukan stream semua video ke cloud)
• Sensor mesin pabrik yang mendeteksi anomali secara lokal dan hanya mengirim alert ke cloud
• Point-of-sale di remote area yang beroperasi offline, sync saat konektivitas tersedia

10.4.6 — Containerization dan Cloud-Native

Argumen utama: Manajer tidak perlu tahu cara menulis Dockerfile, tapi perlu memahami mengapa containerization mengubah cara aplikasi di-deploy dan di-scale. Container (Docker) vs Virtual Machine:

• VM: simulasi seluruh hardware, berat, startup menit
• Container: berbagi OS kernel, ringan, startup detik, portable

Kubernetes (K8s):

• Orkestrasi container pada skala: auto-scaling, self-healing, rolling deployment
• Relevansi manajerial: sistem yang menggunakan K8s bisa di-scale saat traffic tinggi dan scale-down saat traffic rendah — directly translates to cost efficiency

Cloud-native principles:

• Immutable infrastructure: servers dibuat baru (bukan di-patch), instance yang bermasalah dibuang dan diganti
• Infrastructure as Code: seluruh infrastruktur didefinisikan dalam kode → reproducible, auditable

10.4.7 — Vendor Lock-in dan Multi-Cloud Strategy

Argumen utama: Mengandalkan satu cloud provider memberikan kemudahan tapi menciptakan risiko strategis dan tergeser posisi tawar. Tipe vendor lock-in:

1. Platform lock-in — penggunaan servis proprietary yang tidak ada di provider lain
2. Data lock-in — sulit/mahal memindahkan data dari satu provider
3. Skills lock-in — tim hanya bisa dengan satu platform
4. Contract lock-in — committed spend terikat kontrak multi-tahun

Multi-cloud strategy:

• Gunakan lebih dari satu provider untuk redundansi dan leverage negosiasi
• Pertimbangkan: biaya kompleksitas operasional vs manfaat negotiating position
• Cloud-agnostic tools (Terraform, Kubernetes) mengurangi platform lock-in

Regulasi Indonesia: POJK No. 11 (2022) — perbankan harus memiliki cloud exit strategy yang terdokumentasi dan bisa dieksekusi dalam 6 bulan.

---

SEK 10.5 — KOMPARASI (Tabel 10.1)

Judul Tabel: "Infrastruktur On-Premise Tradisional vs Cloud-Native Modern: 8 Dimensi"

Dimensi	On-Premise Tradisional	Cloud-Native Modern
Model biaya	CapEx besar di awal	OpEx, pay-as-you-go
Waktu provisioning	Minggu–bulan (pembelian hardware)	Menit (API call)
Skalabilitas	Terbatas kapasitas yang dibeli	On-demand scaling
Disaster recovery	Mahal, backup site diperlukan	Built-in multi-region
Security patching	Manual, sering tertunda	Managed, automated
Inovasi kecepatan	Dibatasi kapasitas dan proses procurement	Akses ke layanan AI/ML terbaru segera
Vendor dependency	Hardware vendor, lebih mudah ganti	Cloud provider, lock-in lebih kuat
Compliance Indonesia	Data lokal lebih jelas terjaga	Perlu governance untuk data residency

💡 Insight: Cloud bukan selalu lebih murah — tapi hampir selalu lebih cepat dan lebih fleksibel. Keputusan cloud yang tepat bukan tentang meminimalkan biaya sekarang, tapi tentang memaksimalkan kapabilitas dalam 5 tahun ke depan.

---

SEK 10.6 — REALITAS LAPANGAN

Fenomena 1: Indonesia Data Center Boom vs Cloud Adoption

Konten: Google, AWS, Microsoft, dan Alibaba Cloud semuanya mengumumkan pembangunan region/data center di Indonesia antara 2023–2025, total investasi >$5 miliar. Namun KPMG (2023) menemukan bahwa 73% perusahaan Indonesia yang bermigrasi ke cloud belum sepenuhnya memanfaatkan kemampuan cloud-native. Sebagian besar hanya "lift-and-shift" — memindahkan server fisik ke virtual machine di cloud tanpa mengoptimalkan arsitektur.

💡 Insight: "Lift-and-shift" cloud migration memberikan biaya cloud tanpa keuntungan cloud. Nilai sejati cloud berasal dari cloud-native architecture — yang membutuhkan redesain aplikasi, bukan sekadar pemindahan.

Fenomena 2: IoT di Pertanian Indonesia — Smart Farming

Konten: Kementan dan sejumlah startup (TaniHub, TaniHub, iDFarm) mengimplementasikan IoT sensor di lahan pertanian: soil moisture, temperature, humidity, CCTV berbasis AI untuk pest detection. Data dikirim ke platform cloud, petani menerima rekomendasi via SMS/WhatsApp. Tantangan: konektivitas di daerah rural masih menjadi hambatan utama. Solusi: edge computing device yang beroperasi offline dan sync saat ada sinyal. (Alim, 2025)

💡 Insight: IoT paling menarik di Indonesia bukan di kota besar yang sudah punya infrastruktur — tapi di sektor primer (pertanian, perikanan, perkebunan) di mana data visibility sebelumnya hampir nol.

Fenomena 3: GovCloud Indonesia — PDNS (Pusat Data Nasional Sementara)

Konten: Insiden siber PDNS 2 pada Juni 2024 — ransomware attack mengakibatkan 200+ layanan pemerintah Indonesia terganggu selama berminggu-minggu, termasuk imigrasi dan sistem penerimaan mahasiswa baru. Pelajaran: tidak ada backup data untuk sebagian besar layanan yang terdampak. Ini bukan kegagalan teknis cloud semata — ini kegagalan governance, backup policy, dan business continuity planning. (BSSN, 2024)

💡 Insight: Infrastruktur cloud paling canggih sekalipun tidak menjamin resiliensi jika governance, backup, dan incident response plan tidak ada. Ini adalah tanggung jawab manajerial, bukan hanya teknis.

---

SEK 10.7 — JEBAKAN KOGNITIF

1. ⚠️ "Cloud selalu lebih murah dari on-premise"

   • Mengapa salah: Untuk workload yang statis dan predictable, on-premise dengan hardware amortisasi 5 tahun seringkali lebih murah. Cloud paling efisien untuk workload yang variabel dan baru.
   • Koreksi: Lakukan TCO analysis 5 tahun yang jujur — include semua biaya, termasuk egress fees, support, dan internal management overhead.

2. ⚠️ "IoT = pasang sensor, data mengalir sendiri, insight langsung tersedia"

   • Mengapa salah: IoT deployment yang bermakna membutuhkan: connectivity planning, device management platform, data pipeline ke analytics, model analitik yang tepat, dan UI yang actionable bagi pengguna.
   • Koreksi: Mulai dari use case bisnis yang spesifik, bukan dari "ayo pasang sensor sebanyak mungkin." Pertanyaan pertama: keputusan bisnis apa yang akan berubah dengan data ini?

3. ⚠️ "Microservices selalu lebih baik dari monolith"

   • Mengapa salah: Microservices menambah kompleksitas operasional yang signifikan. Untuk aplikasi internal sederhana atau startups tahap awal, monolith yang terstruktur baik jauh lebih efisien.
   • Koreksi: "Start with a monolith, break apart when you must" — Martin Fowler. Pindah ke microservices hanya ketika skalabilitas atau team independence menjadi hambatan nyata.

4. ⚠️ "Setelah migrasi ke cloud, keamanan menjadi tanggung jawab cloud provider"

   • Mengapa salah: Cloud security menggunakan "Shared Responsibility Model" — provider bertanggung jawab atas security OF the cloud (infrastruktur), tapi pelanggan bertanggung jawab atas security IN the cloud (data, aplikasi, akses).
   • Koreksi: Pahami shared responsibility matrix untuk setiap provider dan layanan yang digunakan. Data Anda, tanggung jawab Anda — meskipun disimpan di cloud orang lain.

---

SEK 10.8 — STUDI KASUS

Kasus A (Dasar): Bank BJB — Cloud Migration Journey

Sumber: Annual Report Bank BJB 2024 Kondisi awal (❌): 2019 — Bank BJB beroperasi dengan 3 data center on-premise legacy di Bandung. Kapasitas terbatas, pembaruan infrastruktur butuh proses procurement 6–12 bulan. Launching fitur mobile banking baru butuh 8–12 minggu karena keterbatasan environment. Perubahan (✅): 2021–2024 — Hybrid cloud strategy: core banking tetap on-premise/private cloud (regulatory), tapi semua aplikasi digital baru (mobile app, analytics, API developer portal) di-host di public cloud. Feature deployment turun ke 2–4 minggu. Biaya infrastruktur per-transaction turun 45% untuk workload digital. Tabel: Timeline deployment, biaya infrastruktur, uptime, fitur baru per tahun Pelajaran: Hybrid cloud memungkinkan regulasi-compliance terjaga untuk core systems sambil mengambil keuntungan cloud untuk digital innovations.

Kasus B (Lanjutan): PT Pelabuhan Indonesia (Pelindo) — IoT Port Management

Sumber: Annual Report Pelindo 2024, Alim (2025) Kondisi awal (❌): 2020 — Manajemen pergerakan kapal dan kontainer di Pelabuhan Tanjung Priok masih sangat manual. Waktu tunggu kapal rata-rata 58 jam. Tidak ada visibilitas real-time posisi kontainer di lapangan. Koordinasi antar sistem (bea cukai, angkutan, operator crane) melalui telepon dan kertas. Perubahan (✅): IoT & Integrated Port Management System: RFID tracking pada semua kontainer, sensor crane dan kendaraan, CCTV AI untuk monitoring lapangan, integrasi real-time dengan sistem bea cukai dan >50 shipping lines via single API. Waktu tunggu kapal turun ke 32 jam. Port throughput meningkat 40%. Pelajaran: IoT bernilai terbesar saat mengintegrasikan multiple stakeholders dengan shared data — bukan hanya monitoring internal.

---

SEK 10.9 — TEMPLATE PRAKTIS

Nama Template: Cloud Strategy Decision Canvas

======================================
TEMPLATE 10.1 — CLOUD STRATEGY DECISION CANVAS
======================================

ORGANISASI: ____________________________

BAGIAN A: INVENTARISASI WORKLOAD
(Daftarkan 5–8 aplikasi/sistem utama, kategorikan)

Nama Sistem | Tipe Data | Regulasi | Variabilitas | Rekomendasi Hosting
------------|-----------|----------|--------------|--------------------
            | [S/K/PII] | [Y/T]    | [T/S/R]      | [On-Prem/Hybrid/Cloud]
            | [S/K/PII] | [Y/T]    | [T/S/R]      | [On-Prem/Hybrid/Cloud]
            | [S/K/PII] | [Y/T]    | [T/S/R]      | [On-Prem/Hybrid/Cloud]

Keterangan:
Tipe Data: S=Sensitif, K=Konfidensial, PII=Personal Identifiable Info
Variabilitas: T=Tinggi (musiman), S=Sedang, R=Rendah (statis)

BAGIAN B: TCO ANALYSIS (Simplified, 5 Tahun)
              | On-Premise | Private Cloud | Public Cloud
Hardware/Infra| __________  | _____________| N/A
Licensing     | __________  | _____________| __________
Operations/IT | __________  | _____________| __________
Total 5 Tahun | __________  | _____________| __________

BAGIAN C: CLOUD STRATEGY PILIHAN
[ ] Full on-premise    — alasan: ____________________________
[ ] Private cloud      — alasan: ____________________________
[ ] Public cloud first — alasan: ____________________________
[ ] Hybrid (default)   — core: on-prem | digital: cloud

Workload yang TETAP on-premise/private: ____________________________
Workload yang PINDAH ke public cloud: ____________________________
Timeline migrasi (phased):
  Phase 1 (Q1-Q2): ____________________________
  Phase 2 (Q3-Q4): ____________________________
  Phase 3 (Year 2): ____________________________

BAGIAN D: GOVERNANCE & RISK
Cloud provider utama yang dipilih: ____________________________
Multi-cloud atau single provider: ____________________________
Vendor lock-in mitigation strategy: ____________________________
Data residency compliance (UU PDP): ____________________________
Exit strategy terdokumentasi: [ ]Ya [ ]Belum ada

======================================

---

SEK 10.10 — PETA KONSEP (Gambar 10.2)

Root: Infrastruktur Digital Modern
├── Cloud Strategy
│   ├── On-Prem vs Private vs Public vs Hybrid
│   ├── IaaS / PaaS / SaaS (responsibility split)
│   └── TCO analysis + vendor lock-in
├── IoT Architecture
│   ├── Edge → Fog → Cloud
│   └── Use cases: asset, supply chain, predictive maintenance
├── Modern App Architecture
│   ├── Monolith (start here)
│   └── Microservices + API Economy (when to move)
├── Edge Computing
│   └── Low latency + offline capability
└── Governance & Security
    ├── Shared Responsibility Model
    └── Data residency (UU PDP, POJK)

---

SEK 10.11 — RANGKUMAN

7 poin takeaway:

1. Cloud computing mengubah infrastruktur IT dari keputusan CapEx menjadi keputusan OpEx — ini bukan keputusan teknis, ini keputusan keuangan dan strategis yang harus melibatkan CFO dan manajemen.
2. Hybrid cloud adalah default pilihan untuk sebagian besar organisasi Indonesia: workload regulated tetap on-premise, digital innovation di public cloud.
3. IoT mengubah dunia fisik menjadi sumber data real-time — kapabilitas visibility dan kontrol operasional yang sebelumnya mustahil kini tersedia. Tantangannya adalah governance dan connectivity.
4. "Lift-and-shift" cloud migration memberikan biaya cloud tanpa manfaat cloud — nilai sejati membutuhkan cloud-native architecture.
5. Microservices dan API Economy memberikan agility — tapi complexity overhead membuatnya tidak tepat untuk semua konteks. Start simple, evolve when needed.
6. Security di cloud adalah tanggung jawab bersama — provider mengamankan infrastruktur, Anda mengamankan data dan aplikasi Anda.
7. Vendor lock-in adalah risiko strategis yang harus dikelola dengan cloud exit strategy, multi-cloud consideration, dan penggunaan cloud-agnostic tools.

Closing Bridge ke Bab 11: Infrastruktur digital (Bab 10) menyediakan fondasi teknis. Namun semua infrastruktur dan data yang tersimpan di dalamnya memiliki nilai yang sangat tinggi — dan oleh karena itu menjadi target serangan. Bab 11 membahas keamanan informasi dan manajemen risiko SI — perspektif yang tidak bisa lagi diabaikan oleh manajer manapun.

🔥 "Infrastruktur digital terbaik adalah yang paling tidak Anda sadari keberadaannya — karena ia berjalan mulus, aman, dan elastis, memungkinkan Anda fokus sepenuhnya pada bisnis."

---

SEK 10.12 — LATIHAN & REFLEKSI

Pertanyaan Reflektif:

1. Bayangkan Anda harus mempresentasikan rekomendasi cloud strategy kepada CFO perusahaan Anda. Bagaimana Anda menjelaskan manfaat cloud bukan hanya dari perspektif biaya tapi dari perspektif kapabilitas bisnis?
2. Insiden PDNS Indonesia 2024 mengungkap kelemahan fundamental governance cloud pemerintah. Dari sudut pandang manajerial (bukan teknis), apa yang seharusnya berbeda?
3. Sebuah perusahaan FMCG ingin memantau stok produk di 50.000 warung dengan IoT. Apa 3 tantangan terbesar yang harus dipecahkan sebelum implementasi bisa berhasil?
4. Apa perbedaan antara "cloud provider mengurus keamanan kami" dan "cloud provider membantu kami mengurus keamanan kami sendiri"? Mengapa perbedaan ini sangat penting?

Latihan Artefak 10.1 — Cloud Strategy Canvas Untuk organisasi pilihan Anda:

1. Inventarisasi 5 sistem/aplikasi utama dan kategorikan tipe data serta regulasinya
2. Buat simplified TCO analysis untuk 2 opsi (on-premise vs cloud hybrid)
3. Rekomendasikan cloud strategy dengan justifikasi
4. Identifikasi satu risiko vendor lock-in dan strategi mitigasinya

Artefak 10.1 menjadi bagian dari IT strategy document yang semakin lengkap.

---

REFERENSI BAB 10

• NIST. (2021). NIST SP 800-145: The NIST definition of cloud computing. National Institute of Standards and Technology.
• Laudon, K. C., & Laudon, J. P. (2022). Management Information Systems: Managing the Digital Firm (17th ed.). Pearson.
• ITU-T. (2022). ITU-T Y.4000: Overview of the Internet of Things. International Telecommunication Union.
• Alim, H. B. (2025). AI-integrated public digital infrastructure for geopark tourism. Journal of Informatics Management and Information Technology (JIMAT).
• KPMG Indonesia. (2023). Digital transformation in Indonesian enterprises. KPMG International.
• McKinsey Global Institute. (2023). The economic potential of generative AI. McKinsey & Company.
• OJK. (2022). POJK No. 11 Tahun 2022 tentang Penyelenggaraan Teknologi Informasi oleh Bank Umum. Otoritas Jasa Keuangan.
• BSSN. (2024). Laporan insiden keamanan siber PDNS 2024. Badan Siber dan Sandi Negara.
• Pelindo. (2024). Annual report 2024. PT Pelabuhan Indonesia (Persero).
• Sharda, R., Delen, D., & Turban, E. (2024). Analytics, data science, and artificial intelligence (12th ed.). Pearson.
• Porter, M. E., & Heppelmann, J. E. (2022). How smart, connected products are transforming companies. Harvard Business Review, 93(10), 96–114.
• Gartner Research. (2024). Top strategic technology trends for 2025. Gartner, Inc.