[IT Architecture] Oracle D2K Study

最近在幫公司survey一些產品，發現有一家中意廠商的產品，他是用Oracle D2K開發。對我而言，D2K是比較陌生的工具，因此做了一些Study。另一方面也是擔心若選用D2K，會不會發生未來產品維護的問題。

網上有一篇文章，對D2K有簡單介紹，看來D2K的定位有點像VB，方便開發人員用它來快速開發

GUI介面，用的語言是PL/SQL。講D2K大家比較陌生，但是講到Oracle Form應該就比較有印象。

如果再回到oracle官網，看來在Oracle Fusion Middleware中，它整合了Oracle Form，讓Oracle 的開發人員可以用D2K也可以用JAVA開發，中間整合則用Fusion Middleware。

對Oracle而言，用Oracle Form的技術可以稱之為傳統技術（Traditional Technology），Oracle也將它整合至Oracle Application Server. 另一大塊就是Java，則是原本就在Oracle Application Server。還有一部分也是本BLOG曾提到的快速開發工具APEX。

下面是原文的內容，看來ORACLE還是會持續開發此技術，讓既有已使用此技術開發的產品可以繼續運作並和新的ORACLE JAVA技術作整合。

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

Oracle Forms Services 11g

Oracle Forms, a component of Oracle Fusion Middleware, is Oracle's long-established technology to design and build enterprise applications quickly and efficiently. Oracle remains committed to the development of this technology, and to the ongoing release as a component of the Oracle platform. This continuing commitment to Forms technology enables you to leverage your existing investment by easily upgrading and integrating existing Oracle Forms applications to take advantage of web technologies and service oriented architectures (SOA).

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

[IT Architecture] Oracle 11G VERSUS MS-SQL Server 2008

Oracle 和 MS-SQL 之間的比較已經是不少網友茶餘飯後的話題. 就在 Oracle 11G和 MS-SQL 2008陸續現身後, 一篇新的比較報告可供大家參考! 重點是此報告號稱使用 Oracle一年相較 MS-SQL可省下三萬三千多美元. 報告重點如下:

• DBA執行常態的資料庫管理功能時, 平均花費時間上來比較, Oracle比 MS-SQL 少掉41%的時間.

• 就執行步驟而言, Oracle比起MS-SQL少掉43%的步驟, 根據 Edison 的複雜度矩陣研究.
  
• 就 DBA的生產力而言, 因為前兩點的貢獻, Oracle的DBA平均可多節省 $33,520.47/每年.
• 就備份和還原而言, Oracle比起MS-SQL除了架構和功能上的優勢以外, 就操作面而言還少掉53%的時間/60%的步驟.
  
• 就效能校調方面, Oracle也比MS-SQl省掉87%的時間.

當然看完這篇報告, 肯定氣死不少MS-SQL的死忠者. 但是公說公有理, 婆說婆有理, 有興趣的人可以從連結的網址找到完整的報告, 也許比較有客觀的評估.

[IT Architecture] Oracle ILM- Information Lifecycle Management

針對過期資料做備份對資訊人員來說應該是天經地義的事情, 主要有以下三個考量

- 資料庫的效能考量: 純就 Oracle而言, Table 資料不做 purge, 放任成長, 對效能一定有影響.

- 成本考量: 一般資料多儲存於SAN, 儲存媒介所費不貲, 將過期的資料移儲至相較便宜的媒體, 對成本有一定的幫助

- 法律的相容: 所謂法律指得是像沙賓SOX, GLB and HIPAA 等規範對企業資料的保留期限的要求.

這方面的管理擴大到整個企業來說就是所謂的ILM(Information Lifecycle Management), 管理資料的整個生命週期：從抓取、創造、保留、備份、到銷燬資料的整個過程，以低成本的方式儲存大量的資料，還要能易於取得，且必須符合沙賓、HIPPA等法案所規定的資料保存與保護的需求.

ILM很自然的成為IT人員再開發系統之外另外一個要考量的重點. 但以現行企業多數的作法是根據應用系統的特性, 如果是套裝系統如SAP, 本身就有考量到資料備份(Archive), 則就使用SAP提供的Archive工具搭配合適的媒體管理工具(Media)就可以做到ILM. 而若是企業自行開發的軟體, 則多由資料庫端做 Archive. 由開發人員提供TABLE的設計邏輯, 將備份邏輯用PL/SQL(當然C或VB等語言也可以, 但是PL/SQL對資料處裡的效能最好)開發好後, 加入排程後, 將資料定期備份成檔案後由DBA將資料燒錄成光碟. 當然執行細節各家做法又會有差異. 而當使用者有查詢歷史資料需求時, 在請DBA從光碟中將資料回復提供使用者查詢.

從以上的流程可以看到得是, 整個過程有太多人為的作業, 出現問題的風險不低. 本人服務的公司就曾出現客戶端要求查閱三年前的生產資料, 但是DBA回應資料不知道再上述的哪一個環節出問題所以無法找到該資料. 真得是哪裏死的都搞不清楚?

Oracle對這個問題的解法就是ILM. 在Oracle 9i時代, Oracle的作法是在它的HTML-DB(現已改名為APEX)上開發一個做 Data Archive的應用程式包含以下功能

• 提供一個GUI介面去管理整個ILM環境

• 定義ILM各個階段的目的.

• 定義資料備份的規則後產生相關的Script.

基本上功能有但是都很陽春, 隨著 Oracle的版本演進和外在環境變化(主要是儲存媒介- 硬碟的成本下降), 11G 引進的一些新功能.

到了 Oracle 11g, ILM做了大幅度的修正, 整個流程的涵蓋度比起9i來說, 完整了很多, 主要在和儲存端的結合. 在技術上它整合了 partitioning, 允許資料的備份使用 partition-level的相關語法, 這對DBA而言是一個好消息.

1. 定義要做archive 的資料類別(Define the Data Classes): 簡單得說就是定義Table的重要性, 資料保存的期間, Table用哪一個欄位(Create_date,...)來判斷資料的新舊,..等等.
   

2. 建立儲存層別(Storage Tiers): 將資料根據存取的頻繁程度, 以下四個Level, 由上而下分別代表存取頻率由高至低. 舉例,一個Table的資料在資料類別定義後, 根據儲存層別不同會被儲存在不同的層別. 最新的資料儲存在'Ihgh Performance'層別, 以此類推. 這時Partitioning就派上用場, 如何將第一步的資料類別指定給儲存層別就是透過Partitioning.
   • High Performance
   • Low Cost
   • Online Archive
   • Offline Archive (optional)
   

3. 建立資料存取政策(Data Access and Migration Policies): 這邊就是定義資料如何被搬移和後續存取的權限管理.
   

4. 定義規範(Define and Enforce Compliance Policies): ILM的實施一部分是法律的規範, Oracle也將相關規範整合入系統, 以利後續管理目的.

透過11G的一些新功能如前文所提到的加上資料庫壓縮等功能, 整個ILM在11G有了新面貌, 當然Oracle的對手也不留情的抨擊Oracle的ILM視野太狹隘(ILM多由硬體儲存廠商提出為多, 構面不侷限於資料庫), 但是對資料庫來說, Oracle能夠提出Solution並內崁於DBA平日的管理工具中, 對賴資料庫維生的多數系統開發人員來說當然是佳音一則.

參考文件:

http://www.dba-oracle.com/t_11g_ilm_information_lifecycle_management.htm

http://www.zdnet.com.tw/news/software/0,2000085678,20127191,00.htm

[IT Architecture] 文件安全管理Solution Survey(Part I)

資訊安全的相關議題是身為一個MIS最常被老闆問到的幾個問題之一，尤其是當公司有新的產品接近量產或即將發表，老闆更是會像神經質般找這些不常不太搭理的MIS來，問問資訊安全有沒有SOLUTION，花錢沒關係！好像這些文件隨時都會有公司內部人員會將其外洩似的. 這時MIS就要找一堆VENDOR來，問一堆問題，談一堆需求，然後要報價單. 大夥忙完一陣子把報價和建議案提出來給老闆後， 這時老闆又會說，Proposal寫得不錯但是現在公司狀況不太好，可能先緩一下. 哈哈！這種CYCLE，MIS們是不是都有同感啊？ 近來小弟就是接獲類似需求，既然是個CYCLE那就趁這一次把報告弄得完整一點，以被未來不時之需.

０．Ｗiki定義 ：
最近的習慣是做一些SURVEY時先去WIKI看看DEFINITION，避免走偏方向．不過WIKI關於這方面好像不夠深入，我再加了一些東西！

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

信息安全或資訊保安有對立的兩方面的含義：一是指作為維護政治穩定的國家的信息安全，一是指最作為人權需要的個人的獲取信息的自由。簡單來講，有關信息安全的內容可以簡化為下列三個基本點：

• 機密性（Confidentiality）
• 完整性（Integrity）
• 可用性（Availability）

基於這個原因，任何有違信息的「可用性」都算是違反信息安全的規定。因此，世上不少國家，不論是美國還是中國都有要求保持信息可以不受規限地流通的運動舉行。

對信息安全的認識經歷了的數據安全階段（強調保密通信）、網路信息安全時代（強調網路環境）和目前的信息保障時代（強調不能被動地保護，需要有保護——檢測——反應——恢復四個環節）。

安全技術嚴格地講僅包含3類：隱藏，訪問控制和密碼學。 典型的安全應用有：數字水印屬於隱藏；網路防火牆屬於訪問控制；數字簽名屬於密碼學。

資訊安全的目的在於保護電腦資源，包括硬體、軟體、資料及程式等，以防止不當的變更、破壞及未受權使用；綜合言之，資訊安全管理乃是保護電腦資料隱密性、 完整性與可用性的目的，對電腦系統內的整體架構（包含軟、硬體、作業程序、相關人員等所做的預防措施、災害緊急應變處理原則及復原裝置，以防範電腦資訊遭不當的變更、破壞及為授權使用，促進資訊的正當合理運用）

===================================================================
整個資訊安全的廣義範疇會包括網路安全(防火牆/網路攻擊/駭客攻擊/流量管控/..), 應用程式安全管理(即時通訊管理/郵件管理/應用程式管控/..), 文件安全管理. 另外電腦和通訊資產管理(PC&NB管理/USB管控/儲存設備/..)可說是執行以上管理的基礎工作, 所以一般資安專案也會多少考慮資產管理.
而文件安全的討論則著重在機密性和完整性，舉凡文件的加密(Authentication)，適當的人在適當的時刻用適當的方式看到適當的文件(Authorization)，文件的增刪改查都被適當的管控等等都是文件安全管理的範疇.

１．名詞解釋：
DRM (Digital Rights Management) ：數位內容使用權利管理

２．參考產品：
目前在初步GOOGLE後，SORTING出來的廠家或產品列表如下，睿揚/意藍/喬篷/以柔/博格/數位商業EZ-Lock/微軟/TrustView/錦衣衛/EMC. 主要會針對TrustView和EMC IRM的功能面和架構面做一些評估和大家分享.

[IT Architecture] 供應鏈管理系統（SCM） - 台塑網

目前服務的公司, 自去年初 SAP上線後, 內部流程已大致底定. 但SAP著墨的重點在內部流程的銜接, 經過一年的使用，一大半使用者的問題來自於整個系統還有一塊大缺口就是供應鏈管理的部分. 而所謂的廣義的供應鏈管理定議如下 - From Wiki:
=====================================================================
供應鏈管理的目標是在滿足客戶需要的前提下，對整個供應鏈（從供貨商，製造商，分銷商到消費者）的各個環節進行綜合管理，例如從採購、物料管理、生產、配送、營銷到消費者的整個供應鏈的貨物流、信息流和資金流，把物流與庫存成本降到最小。
供應鏈管理就是指對整個供應鏈系統進行計劃、協調、操作、控制和優化的各種活動和過程，其目標是要將顧客所需的正確的產品（Right Product）能夠在正確的時間（Right Time）、按照正確的數量（Right Quantity）、正確的質量（Right Quality）和正確的狀態（Right Status）送到正確的地點（Right Place），並使總成本最小。
一個公司採用供應鏈管理的最終目的有兩個：

（1）提升客戶的最大滿意度（提高交貨的可靠性和零活性）
（2）降低公司的成本（降低庫存，減少生產及分銷的費用）
====================================================================
但公司目前最迫切的是對供應商之間的供應鏈管理(因為對客戶端的供應鍊管理多半由客戶端主動要求), 這一段一直被忽視, 因此定義出了幾項需求出來:

0. 基本上，整個需求定位在ERP系統流程的延伸就是將流程管理延伸至供應商包含資料流部分, 也就是供應商B2B的部分. 有點像將內部流程的觸角向外延伸至供應商和交貨商（Forwarder, Broker).

1. 既然是SCM, 市面上一堆SCM的套裝軟體, 底下是一個網站（http://www.business-software.com/erp-solutions/supply-chain-management/index.php）上的比較資料， 基本上這些套裝軟體不在我SURVEY的範疇，各位看官有興趣可以點以下連結看看.

• Consona
• Epicor
• Infor
• JDA
• Logility
• Manhattan Associates
• Microsoft Dynamics
• Oracle
• RedPrairie
• SAP

基本上不考慮有以下幾個原因：

• 太貴！這個蕭條時刻，動輒上千萬的咚咚還是別碰為妙，因為太貴案子根本不會被核准. 另外，貴在產品本身也就算了，這些套裝產品顧問導入費用更是驚人，搞不好還大老遠請個新加坡或印度的顧問，貴得要死又難溝通.
  
• 根據前年導入SAP的經驗，這些產品功能雖然完成，但多半強調所謂的Best Practice，客製的能力又多半不強. 以本公司特殊的代工商業流程，導進來憋手蹩腳. 使用者和IT都痛苦.
• 基本上，既然方才談到SCM是ERP的延伸，和既有SAP的介面會是整個專案的重點，這又會增加套裝軟體客製的EFFORT（我家的SAP已被客製到不行）.
  
  

2. 也因此決定將觸角轉進同集團其他公司已導入中的本土企業軟體產品, 台塑網. 這裡將幾個本公司會用到的SCM範疇和使用者的問題和台塑網的SOLUTION 整理出來.

SCM 範疇	遇到的問題	台塑網
採購標案管理(Quotation management)	目前工廠的標案僅由採購員做詢議比價的動作後將最後結果上傳至SAP. 和供應商之間的交易過程無法追蹤， 整個過程不夠透明化.	公司人和和供應商在WEB介面上進行詢議比價的過程，完成後回傳SAP. 缺點是，系統是封閉性的就是架在公司內部，而非台塑網強調的電子市集，所以對採購人員Sourcing的需求幫助不大.
採購單追蹤(PO Tracking)	在採購單發出給供應商後, 供應商如何確認, 如何更新交期等, 必須有一個系統平台供公司和供應商互動.	採購單開立，改版和供應商確認都在WEB上進行，透過和SAP的介面，資訊透明.
交貨管理(Shipment Management)	在供應商要出貨時如何通知公司各部門作相關準備, 資訊流如何連結,如何在正確的時間提交正確的數量其實是一門大學問. 如何避免供應商塞貨或晚出貨都是大問題.	透過交貨提示，ASN開立和催交功能，避免交貨提早或延遲.
庫存管理(Inventory Management)	供應商可透過WEB查詢收貨狀況, Consign庫存狀況. 也可採用VMI(Vendor Management Inventory)模式, 由公司提供庫存高低水位, 供應商自動補貨.	公司和供應商都透過各自系統提供庫存資料，庫存資訊透明.
貨況管理	將供應鍊管理延伸至 Forwarder和Broker, 將進口的貨物的資訊流連結以利進出口人員追蹤. 或在離開供應商或的狀況，我方人員可以一目瞭然.	透過Forwarder, Broker的資訊和ASN資料連結，可以清楚知道貨況.
貨款管理	將前述活動產生的費用予以有效管理.	貨款和運費的管理，提供報表供財務人員查詢.

總得來說，目前和台塑網的案子正處於洽詢階段，根據供應鍊管理的定義，希望系統的導入將公司存貨成本和人員效率透過SCM予以最佳化.

參考文件：

Wiki: 供應鏈
http://www.business-software.com/erp-solutions/supply-chain-management/index.php

[IT Architecture] Starbucks 買咖啡 VS Design Pattern

昉間有不少文章和書針對在StarBucks買咖啡的過程比較起軟體開發的Design Pattern. Design Pattern對從事MIS的人員有點像烏托邦, 因為MIS的工作, 以老闆對時程的要求大概不會允許你從Design Pattern開始一步一步設計系統, 但是IT人員總有個夢希望在程式變成如蜘蛛網般難讀之前還是可以有一個機制去將需求概念化並用圖示的方式去呈現. 對Design Pattern在下懂得不多不過還是從幾篇文章針對這個主題整理出一些心得,希望對日後的系統分析有一些幫助, 下次去StarBucks喝咖啡除了聊天看小姐還多一些正經事可以做!

事情就從踏入Starbucks店門開始吧, 當你點完你的咖啡後, 拿到發票, 此時服務生會拿起咖啡杯並在上面做標示. 之後就將此咖啡杯放入等待序(Queue)中. 這個設計就是系統分析時所謂的分離(Decouple), 就是將處裡訂單的服務生和煮咖啡的服務生工作分開, 如此一來, 在客人變多時, 處裡訂單的服務生還是可以專心處裡訂單. 另外, 如果等待序(Queue)的單子太多, 也可以透過增加煮咖啡的服務生來加快處理速度. 這也是常見的非同步處理(asynchronous processing).

但非同步處理並不是沒有缺點, 最明顯的就是咖啡完成的順序未必和訂單順序相同. 例如當煮咖啡的服務生為加快速度可能將不同訂單中同樣的咖啡一起處理或者有些煮咖啡機器煮的時間較長, 服務生要特別考慮. 但問題是同一張訂單的咖啡還是要一起給人客啊, 這時Starbucks用的方式是用人客的姓來區隔. "來賓王先生你的咖啡好了", 這時, 王先生的訂單不管幾杯都會一起交給王先生.

問題又來了, 客人臨時換單或機器出問題, Starbucks如何處理呢? 一個最簡單的方式就是認賠殺出, 人客說她點的是熱的但做出來的是冷的, 很多時候服務生會再做一杯熱的給客人, 做錯的就倒掉. 還有一個方式就是重試, 客人說糖不夠就再加一點, 當然前提是這是一個可以重複的動作. 最後一個就是全部回到原點,一個情形就是訂單在還沒煮以前就取消, 這時當然就是退錢給客戶將交易退回(Rollback).

如果Starbucks是用傳統的方式, 點一杯做一杯付一杯的錢, 我們應該會看到Starbucks櫃檯前永遠大排長龍, 因為一段時間內可以服務的客戶數目會降低. 當然傳統的方式, 訂單出錯的方式降低很多, 客戶臨時換單或機器出狀況都比較容易處理.

生活中其實充滿一些同步也有一堆非同步的動作, 有時停下腳步好好觀察一下也許會有一些不同的收穫喔!

參考文件:

http://eaipatterns.com/docs/IEEE_Software_Design_2PC.pdf

http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html

http://www.springerlink.com/content/r72253p030411878/