流程控 PM 福音 Amazon Honeycode 不用寫程式就能打造應用程式之第一印象

(圖說:人們簇擁著大英國協各地蜜蜂所生產製造的各種蜂蜜產出,而當碼農產出程式碼之於蜜蜂產出蜂蜜代表著?!圖片來源:Ernest Chiang 攝於英國倫敦 FORTNUM & MASON 蜂蜜專櫃。)

前言

幾個小時前看到 Jeff Barr 在 AWS Blog 發布了一篇「Introducing Amazon Honeycode – Build Web & Mobile Apps Without Writing Code」,看到新產品發布通常是興奮的,看著新產品照著曾經推演過的脈絡被發布,更是興奮。

AWS 的首席傳教士 Jeff Barr 在文章開頭第一個字就提了 1979 年發布的 VisiCalc,在當時可在個人電腦上(例如 Apple II)運行的試算表軟體。我則是接觸了其稍後的 Lotus 1-2-3,然後稍後陸續迎接了 Microsoft Excel、Google Sheets 等試算表工具。在開始看 Amazon Honeycode 之前,來回顧一下過去發生了哪些故事 :)



三件事情

人們發明了個人電腦想要解決人們手邊的大大小小的事情或問題,而整體電腦的架構設計也圍繞著儲存、運算、輸入與輸出三件事情。在這裡將這三點列出來,方便稍後交互參照:

- A. 儲存
- B. 運算
- C. 輸入與輸出 (I/O)

類似一個倉庫,提供了儲存空間、加上存放歸類的運算邏輯、進而讓各種貨物得以遵循定義好的規則進進出出,放好放滿且找的到貨。對照前述:

- A. 倉庫提供了儲存空間
- B. 倉庫定義了哪種貨物存放在哪一區哪一層貨架
- C. 倉庫定義貨物進出的規則、存取權限

試算表

試算表,依循著兩個常見的限制條件:

- 當代常見顯示器或印刷品的物理限制(平面),
- 以及人們大部分僅能處理兩個維度的資訊(表格),

許多資料庫系統也圍繞著兩個維度的表格作為儲存空間。所以這是試算表的 A.。

有了儲存空間(將資料存放在試算表或是資料庫中),接下來定義 B. 資料進出與運算的規則(例如有一筆資料進來則加上一個當下的時間標記、或是總資料筆數加一),最後 C. 處理資料進進出出的方式(輸入與輸出),例如:

- 提供輸入介面,讓使用者方便鍗輸入資料。(例如試算表的表格 (sheet)、特定 CRM/ERP 場景的處理流程 (procedure))、
- 提供輸出界面,讓使用者依照不同場景,方便取得所需資訊。(例如試算表的表格 (sheet)、加上過濾器 (filter) 或提供排序功能 (sorting))。

在小型複雜度的問題或應用場景中,使用試算表形式,搭配試算表軟體本身自帶的公式或開發工具,已可滿足。

資料庫系統

但隨著複雜度增加,例如:定義角色與權限、資料數量增加、相同原始資料但是不同應用場景或脈絡,試算表的下一步走向將「試算表軟體本身自帶的公式或開發工具」分切出來或是包成介面(例如 API),於是成為以資料庫為基底,加上更多程式開發工具的資料庫系統。例如: FoxPro, Visual FoxProMicrosoft Access、或是更大型規模的 Microsoft SQL Server 等等。大部分工具與商業邏輯,都包含在前述的 B. 運算當中,最後需要 C. 的協助,讓使用者得以進出存取資料。

C. 的資料輸入輸出方式,則視當時市場產品而定,例如當年 HP 曾將 Lotus 1-2-3 放進掌上型電腦

(By W. T. Shymanski - Own work (Original text: self-made), Public Domain, https://commons.wikimedia.org/w/index.php?curid=8713914)

進而加上模板範例以供開發人員參考,例如 Visual Basic 當年提供元件可以快速串接 Microsoft Access,縮短開發時間,加速產品上市。

以當下市場 Mobile First 來看,需要有個方便的輸入輸出界面來客製化適合自己組織作業流程與資料結構的場景。

以上這些夢到的邏輯套用到當今的市場現況,如有巧合,或許就不難推測為什麼 AWS 會推出 Amazon Honeycode 這項新產品、新服務了。

Amazon Honeycode

直接看影片最快,可以看到 Amazon Honeycode 的主要操作流程:

更多 Amazon Honeycode 操作細節畫面,可以參考 Jeff Barr 的文章,他有一步一步帶著做:「Introducing Amazon Honeycode – Build Web & Mobile Apps Without Writing Code」。

收費方式

  • 免費:最多 20 位成員,以及每個 workbook 最多可達 2,500 行,無限制 workbook 數量。
  • PLUS 方案:包含 20 位成員,以及每個 workbook 最多可達 10,000 行,無限制 workbook 數量。額外成員每位每月加收費用。
  • PRO 方案:包含 20 位成員,以及每個 workbook 最多可達 100,000 行,無限制 workbook 數量。額外成員每位每月加收費用。

(螢幕截圖自產品官網)

從收費方式來觀察,應該是個鼓勵中小型組織、部門使用的產品線規劃。

(By ErnestChiang.com)

先用 PLUS 方案簡單試算,用滿 20 人時,每人每月 $1 美金 (約 台幣 NT$30),滿有吸引力的。就算組織長大到 50 人,每人每月費用也才來到 $6.4 美金 (約 台幣 NT$192),對一些 SaaS 服務商應該會感到壓力。

如果組織內部有許多自定義、非典型、高度客製的商業流程,這套 AWS 全託管 low-code/no-code 開發工具,應該會有不錯的誘因使用。舉 20 人的組織為例子來看,一個月花費 $19.99 美金 (約 台幣 NT$600),一年 12 個月約 $240 美金 (約 台幣 NT$7,200),藉由簡單學習 Amazon Honeycode,滿直覺地將自家試算表或 CSV 檔案匯入,然後設定商業流程與通知,就可以省下客製化 app 上萬至數十台幣的預算(先不討論高度複雜的使用情境)以及省下溝通、開發的時間,加速商業運用,想做修改時也可以自行立即修改商業流程,還可以跨平台,這樣一個月只要台幣 NT$600,不需要的時候隨時可以停掉,很實用。

接下來可以觀察,大家寫好的 Honeycode app 能不能上架到 AWS Marketplace 或是任何市集,大家可以可以很快速套用與分享。

今天先簡單寫到這邊,之後有新的觀察再誤續補上,或是會整理到我的 AWS 學習筆記中。

歡迎大家留言補充更多過往歷史與現今當代軟體發展的對比資訊,相信這樣的分享會讓更多人有所收穫 :)

後記: Namespace

我看到新聞後,不斷地在思考為什麼這個 Amazon Honeycode 新產品會掛上 Amazon namespace 而不是 AWS namespace。或許配合長尾理論,當 B2B/Enterprise 企業市場壅擠時,儘早將長尾末端的 SME 市場掌握在自己手上,類似當年 Amazon 剛成立時,藉由線上書店接觸長尾末端市場的這個邏輯,或許是個出入,再繼續觀察看看。

後記:Ney

Honey 的 ney 也有 no 的意思。我是這樣記「Ha no-code」,參考看看,別太認真 XD

Loading comments…