2024-11-23

Verzionisanje Sve: Kako PMFA Eliminiše Migracije i Downtime

Scenario: Vaš ERP sistem radi 3 godine. Imate 50,000 faktura u bazi. Klijent traži da dodamo novi approval step u workflow.

SAP/Oracle pristup:

  1. Development (3-6 nedelja)
  2. Database migracija (svi postojeći dokumenti)
  3. Testing (2-4 nedelje)
  4. Transport u produkciju (scheduled downtime)
  5. Rollback plan (ako nešto pukne)
  6. Total cost: $200K+, 3 meseca, visok rizik

PMFA pristup:

  1. Izmena YAML workflow definicije (5 minuta)
  2. Deploy nove verzije (instant)
  3. Stare fakture ostaju na starom workflow-u
  4. Nove fakture koriste novi workflow
  5. Total cost: $0, 5 minuta, zero rizik

Razlika? Verzionisanje.

Problem: Migracije Ubijaju ERP Projekte

SAP Horror Story (Real Example)

Kompanija: Evropski retailer, 2,000 zaposlenih
Projekt: S/4HANA upgrade + novi workflow za purchase orders
Migracija podataka: 8 miliona dokumenata iz starog sistema

Timeline:

  • Mesec 1-3: Analysis & design
  • Mesec 4-8: Development
  • Mesec 9-11: Data migration testing
  • Mesec 12: Go-live attempt #1 → FAILED (data corruption)
  • Mesec 13-14: Rollback + bug fixes
  • Mesec 15: Go-live attempt #2 → SUCCESS (ali sa kompromisima)

Final cost: €12M
Downtime: 72 sata (planned), dodatnih 48 sati (unplanned)
Lost revenue: €3M+ (ne mogu procesirati porudžbine tokom downtime-a)

Root cause problema:

-- Stara struktura
CREATE TABLE purchase_orders (
  id UUID,
  status VARCHAR(50) CHECK (status IN ('draft', 'approved', 'rejected'))
);

-- Nova struktura (sa dodatnim step-om)
CREATE TABLE purchase_orders (
  id UUID,
  status VARCHAR(50) CHECK (status IN ('draft', 'pending_manager', 'pending_director', 'approved', 'rejected'))
);

-- PROBLEM: Kako migrirati 8M dokumenata?
-- Koja faktura treba 'pending_manager' a koja 'pending_director'?
-- Šta ako business pravila nisu postojala pre?

Nema dobrog rešenja.

PMFA Rešenje: Verzionisanje Kao First-Class Concept

Šta Se Verzioniše?

U PMFA, apsolutno sve je versionable:

# metadata/entities/purchase-order.yml
entity: PurchaseOrder
version: 2.0  # ← Version identifier

fields:
  - name: id
    type: uuid
  
  - name: status
    type: enum
    values: [draft, pending_manager, pending_director, approved, rejected]
    # v1.0 imao samo: draft, approved, rejected

workflow:
  version: 2.0  # ← Workflow version
  states:
    - name: draft
      transitions: [submit]
    
    - name: pending_manager  # ← NOVO u v2.0
      transitions: [manager_approve, manager_reject]
    
    - name: pending_director  # ← NOVO u v2.0
      transitions: [director_approve, director_reject]
    
    - name: approved
      final: true
    
    - name: rejected
      final: true

PMFA automatski:

✅ Čuva v1.0 workflow za postojeće dokumente
✅ Koristi v2.0 workflow za nove dokumente
✅ Nema migraciju
✅ Nema downtime

Kako PMFA Tehnički Implementira Verzionisanje?

1. Meta-Model Verzionisanje

Database schema:

-- Meta-model definitions tabela
CREATE TABLE pmfa_meta_models (
  meta_model_id UUID PRIMARY KEY,
  entity_name VARCHAR(100),
  version VARCHAR(20),  -- "1.0", "2.0", "2.1"...
  definition_json JSONB,  -- Puna YAML/JSON definicija
  created_at TIMESTAMP,
  created_by UUID,
  is_active BOOLEAN DEFAULT false,  -- Samo jedna verzija je active
  is_deprecated BOOLEAN DEFAULT false
);

-- Primer: Purchase Order entity ima 3 verzije
INSERT INTO pmfa_meta_models VALUES
  ('uuid-1', 'PurchaseOrder', '1.0', '{...v1 definition...}', '2023-01-01', 'admin', false, false),
  ('uuid-2', 'PurchaseOrder', '1.5', '{...v1.5 definition...}', '2023-06-15', 'admin', false, false),
  ('uuid-3', 'PurchaseOrder', '2.0', '{...v2 definition...}', '2024-01-10', 'admin', true, false);

Key concept: PMFA nikad ne briše stare verzije. Sve ostaje u bazi zauvek.

2. Document-Level Version Binding

Svaki dokument pamti svoju verziju:

-- Business dokument tabela
CREATE TABLE purchase_orders (
  id UUID PRIMARY KEY,
  
  -- Business data
  supplier_id UUID,
  total_amount DECIMAL(15,2),
  status VARCHAR(50),
  
  -- Version tracking
  meta_model_version VARCHAR(20),  -- "1.0", "2.0"...
  workflow_version VARCHAR(20),
  ui_version VARCHAR(20),
  
  created_at TIMESTAMP,
  updated_at TIMESTAMP
);

Kada se kreira novi dokument:

// PMFA automatski vezuje current active version
const newPurchaseOrder = await pmfa.create('PurchaseOrder', {
  supplier_id: 'supplier-123',
  total_amount: 15000,
  // meta_model_version se automatski setuje na "2.0" (current active)
  // workflow_version se automatski setuje na "2.0"
  // ui_version se automatski setuje na "2.0"
});

Kada se učitava stari dokument:

// PMFA učitava dokument sa njegovom original version
const oldPurchaseOrder = await pmfa.findOne('PurchaseOrder', 'old-doc-id');

// oldPurchaseOrder.meta_model_version = "1.0"
// oldPurchaseOrder.workflow_version = "1.0"

// PMFA koristi v1.0 workflow definiciju za ovaj dokument
// Nema breaking changes

3. Workflow Version Isolation

Stari i novi workflow žive paralelno:

# Workflow v1.0 (za stare dokumente)
workflow:
  version: "1.0"
  states:
    - name: draft
      transitions: [submit]
    - name: approved
    - name: rejected

# Workflow v2.0 (za nove dokumente)
workflow:
  version: "2.0"
  states:
    - name: draft
      transitions: [submit]
    - name: pending_manager
      transitions: [manager_approve]
    - name: pending_director
      transitions: [director_approve]
    - name: approved
    - name: rejected

PMFA runtime:

// Za stari dokument (v1.0)
const oldDoc = await pmfa.findOne('PurchaseOrder', 'old-id');
const availableTransitions = pmfa.workflow.getTransitions(oldDoc);
// Returns: ['submit'] (samo v1.0 transitions)

// Za novi dokument (v2.0)
const newDoc = await pmfa.findOne('PurchaseOrder', 'new-id');
const availableTransitions = pmfa.workflow.getTransitions(newDoc);
// Returns: ['submit', 'manager_approve', 'director_approve'] (v2.0 transitions)

Nema konflikt. Sve radi paralelno.

Real-World Use Case: 3 Generacije Workflow-a

Scenario: Banka ima kreditne zahteve iz 2021, 2023, i 2024. Svaka godina ima drugačija pravila odobravanja.

2021 Proces (v1.0)

workflow:
  version: "1.0"
  states:
    - name: submitted
      transitions: [approve, reject]
  
  approval_limit: 50000  # Jedan approver do €50K

2023 Proces (v2.0)

workflow:
  version: "2.0"
  states:
    - name: submitted
      transitions: [risk_check]
    - name: risk_approved
      transitions: [manager_approve, manager_reject]
    - name: approved
  
  approval_limit: 30000  # Dodatni risk check, niži limit

2024 Proces (v3.0)

workflow:
  version: "3.0"
  states:
    - name: submitted
      transitions: [ai_risk_assessment]
    - name: ai_approved
      transitions: [auto_approve]  # Auto-approval do €10K
    - name: manual_review
      transitions: [director_approve]
    - name: approved
  
  approval_limit: 10000  # AI automation, ručno samo >€10K

U SAP-u?

→ Moraš migrirati SVE stare dokumente na novi proces
→ Ili imati 3 različita modula (technical debt nightmare)
→ Ili kompromis: "hybrid" rešenje koje nikad ne radi kako treba

U PMFA?

→ Sve 3 verzije žive paralelno
→ Svaki dokument zna svoj workflow_version
→ Zero migracija. Zero problema.

SELECT 
  id, 
  created_at, 
  workflow_version, 
  status
FROM loan_applications
ORDER BY created_at;

-- Results:
-- 2021 documents: workflow_version = "1.0"
-- 2023 documents: workflow_version = "2.0"
-- 2024 documents: workflow_version = "3.0"

Sve radi. Bez downtime-a. Bez migracija.

UI Verzionisanje: Stari Dokumenti = Stari UI

Problem: Nova verzija workflow-a često zahteva novi UI. Šta sa starim dokumentima?

PMFA pristup:

# UI v1.0 (za stare dokumente)
ui:
  version: "1.0"
  layout: simple-form
  fields:
    - amount
    - supplier
    - status

# UI v2.0 (za nove dokumente)
ui:
  version: "2.0"
  layout: wizard  # Multi-step form
  steps:
    - step: basic_info
      fields: [amount, supplier]
    - step: approval_chain
      fields: [manager, director]
    - step: review
      readonly: true

PMFA automatski:

  • Stari dokument otvoren u browser-u → prikazuje v1.0 UI
  • Novi dokument otvoren u browser-u → prikazuje v2.0 UI

Nema "UI nije kompatibilan sa starim podacima" problema.

API Verzionisanje: Backward Compatibility Built-In

PMFA automatski generiše versionovane API endpoint-e:

# v1.0 API (za legacy klijente)
GET /api/v1/purchase-orders/:id
POST /api/v1/purchase-orders/:id/approve

# v2.0 API (za nove klijente)
GET /api/v2/purchase-orders/:id
POST /api/v2/purchase-orders/:id/manager-approve
POST /api/v2/purchase-orders/:id/director-approve

Stari mobilni app koristi v1 API. Novi web app koristi v2 API. Sve radi.

Rollback: Samo Flip Flag

Ako se nova verzija pokaže buggy:

-- Deaktiviraj v2.0
UPDATE pmfa_meta_models
SET is_active = false
WHERE entity_name = 'PurchaseOrder' AND version = '2.0';

-- Aktiviraj v1.0
UPDATE pmfa_meta_models
SET is_active = true
WHERE entity_name = 'PurchaseOrder' AND version = '1.0';

Instant rollback. Nema deployment-a. Nema restarta servera.

Benefiti: Zašto Ovo Čini PMFA Nepobedivom

1. Zero-Risk Deployments

Tradicionalno:

  • Deploy nove verzije = rizik od breaking production
  • Moraš testirati sve edge case-ove
  • Moraš imati rollback plan

PMFA:

  • Deploy nove verzije = samo dodaj novu version entry
  • Stara verzija i dalje radi za stare dokumente
  • Rollback = flip flag

2. Nema Migracija

Tradicionalno:

  • Svaka schema izmena = migracija podataka
  • Migracije traju satima/danima
  • Downtime obavezan

PMFA:

  • Nema migracija
  • Stari podaci ostaju na staroj verziji
  • Zero downtime

3. Parallelne Verzije

Tradicionalno:

  • Samo jedna verzija može biti aktivna
  • Stari dokumenti moraju biti migrirani

PMFA:

  • 10+ verzija može živeti paralelno
  • Svaki dokument zna svoju verziju

4. Perfect Audit Trail

SELECT 
  version,
  created_at,
  created_by,
  changes
FROM pmfa_meta_models
WHERE entity_name = 'PurchaseOrder'
ORDER BY created_at;

-- Rezultat: Kompletna istorija svih izmena
-- Ko je promenio? Kada? Šta?

Zaključak

SAP/Oracle/Dynamics:

  • Migracije ubijaju projekte
  • Downtime neizbežan
  • Rizik visok
  • Cost astronomical

PMFA:

  • Zero migracije
  • Zero downtime
  • Zero rizik
  • Instant deployment

Verzionisanje je superpower koji PMFA ima built-in.

Rezultat?

  • ✅ Deploy nove verzije za 5 minuta umesto 3 meseca
  • ✅ Rollback za 2 sekunde umesto 2 dana
  • ✅ Zero rizik za produkciju
  • ✅ 10+ verzija workflow-a može živeti paralelno

Ovo je razlog zašto PMFA može da bude 100x brža od SAP-a.

Zainteresovani za PMFA? Kontaktirajte nas na office@nonnotech.com za early access program.

← Nazad na blog