Solution Architect လမ်းညွှန် — နိဒါန်း

Standalone Applications တွေ ရေးတဲ့ အခါ Device (Computer) တစ်ခုတည်းပေါ်မှာပဲ အခြေပြုပြီး စဉ်းစားပြီး ရေးရပါတယ်။

Device တစ်ခုပေါ်မှာ run ဖို့ပဲ ဆိုတော့ User Interface (UI), Application Logic, Data, Programming language စတာလောက်ပဲ စဉ်းစားရတယ်။ တစ်ချို့ application တွေဆို data ပိုင်းတောင် စဉ်းစားစရာမလိုဘူး။ UI, Logic နဲ့ Language အပိုင်းလောက်ပဲ လိုတယ်။ Command Line Interface application တွေ ဆို Logic နဲ့ Language ပဲ။ ပထမဆုံး ကိုယ့်ဘာသာ စရေးဖူးတဲ့ application တစ်ခု ဆို မှတ်မှတ်ရရ IP Subnet တွေတွက်တဲ့ Application။ Java နဲ့ Swing UI သုံးပြီးရေးခဲ့တာ။

2007 လောက်က UCSY ဒုတိယနှစ် မှာ အပြင်က Networking သင်တန်း တက်ဖြစ်တော့ IP Subneting အပိုင်းတွေ သင်ရတယ်။ ဘယ် Subnet မှာ IP Address ဘယ်နှစ်ခု ရတယ်ဆိုတာကို လက်နဲ့ တွက်ကြည့်ရတယ်။ အဲ့ တွက်တဲ့ Logic ကို application မှာ ထည့်ပြီး ရေးကြည့်တာ။ IP နံပါတ်ထည့် Subnet Mask ကို ရွေးလိုက်တာနဲ့ သုံးလို့ရတဲ့ IP Address တွေ တွက်ပြီး ဘယ်နှစ်ခု၊ ဘာတွေပါ ဆိုပြီး တန်းပေါ်လာတယ်။ UI, Logic နဲ့ implement လုပ်မယ့် Programming Language ဒါပဲ။

Business application တွေဆိုရင်တော့ UI, Logic, Data နဲ့ Language စတာတွေအပြင် computer နဲ့ တိုက်ရိုက်ချိတ်ထားတဲ့ scanner, printers စတဲ့ connected device တွေနဲ့ တွဲလုပ်ဖို့ ပိုစဉ်းစားရတယ်။

2008 ကျောင်းပြီးတော့ Networking ပိုင်းနဲ့ ZTE မှာ ၂ နှစ်လောက် လုပ်ပြီးတော့၊ 2010 လောက်မှာ အလုပ်ကထွက်ပြီး Software ရေးတဲ့ အလုပ် စတယ်။ အဲ့တုန်းက ရွှေဆိုင် တစ်ဆိုင်အတွက် ကျပ်၊ပဲ၊ရွေး တွက်ပြီး အရောင်းစာရင်းသွင်း၊ ဘောင်ချာထုတ် တဲ့ Application မှာစပြီး Data ပိုင်း နဲ့ Connected Device တွေပါလာတယ်။ Application ကို C# နဲ့ ရေး၊ Data ကို Microsoft Access သုံး၊ ဘောင်ချာ နဲ့ Report စာရွက်တွေ ထုတ်ဖို့ Crystal Report မှာ document design လုပ်၊ Windows မှာ printer driver သွင်း … စဉ်းစားရတဲ့ အပိုင်းက ဒီဘောင်ထဲမှာပဲ။

Network Applications တွေ ရေးဖို့ ကြတော့ အပြန်အလှန် ဆက်သွယ်ထားတဲ့ တစ်ခုထက် ပိုတဲ့ Device တွေ ပါလာပြီ။ ဆက်သွယ်ထားတဲ့ Device အရေအတွက်၊ အရွယ်အစား LAN, WAN, Internet စတာတွေ ထည့်သွင်း စဉ်းစားရပြန်ပါတယ်။ နောက် Data Communication ပိုင်း၊ Data တွေ က Device တစ်ခုနဲ့ တစ်ခုစီ အရွှေအပြောင်း လုပ်တဲ့ကိစ္စတွေ၊ အရွှေအပြောင်းလုပ်တဲ့အခါမှာ Data တွေ မပျက်စီးရအောင် စသဖြင့် ပိုစဉ်းစား လာရပါတယ်။

2011 နောက်ပိုင်းလောက်မှာ ဈေးဆိုင်ကြီးတွေအတွက် Point of Sale နဲ့ Inventory ပိုင်း သုံးဖို့ Application တွေ စရေးတဲ့ အခါကြတော့ UI၊ Logic ပိုင်းကို Application သုံးတဲ့ Device/Computer တွေမှာ ထားပြီး Data ကို Centralized Server တစ်လုံး ခွဲထားတဲ့ ပုံစံ စပြောင်းရေးရပါတယ်။ UI နဲ့ Logic ပိုင်း ပါတဲ့ Application ကို Terminal Computer တွေမှာ Run ပြီး Centralized Database server ကို လှမ်းချိတ်ပြီး သုံးရတဲ့ ပုံစံပါ။ Database Server ထည့်သွင်းတဲ့ အပိုင်းတွေ Application ကနေ Database Server ကိုလှမ်းချိတ်ပြီး Data အထည့်အသွင်း လုပ်တဲ့ အပိုင်းတွေ၊ Logic တစ်ခုမှာ Data Manipulation Operation တစ်ခုထက် ပိုပါလာတဲ့ အခါ (ဥပမာ — Table တစ်ခုထဲ Data Insert လုပ် ပြီး နောက် Table တစ်ခုကို Update လုပ်တဲ့ပုံစံ) Database Transaction handle လုပ်တဲ့ အပိုင်းတွေပါ ပိုပြီး စဉ်းစားလာရပါတယ်။

Integrated Applications တွေ ဖြစ်တဲ့ Web/Mobile စတဲ့ Modern Application တွေ မှာတော့ စဉ်းစားရတဲ့ ပုံစံတွေဟာ ပိုပြီးရှုပ်ထွေး လာပါပြီ။ UI/UX, API, Third-Party Service စတဲ့ ပုံစံတွေ ပေါ်လာပြီး တစ်ချို့ Application တွေဆို သုံးမယ့် Device ထဲမှာ မရှိတော့ဘယ် Internet ပေါ်က Server (Cloud) ပေါ် ရောက်လာပါတယ်။

2022 Onenex အစမှာ Heal by Pun Hlaing ကို Architecture ပိုင်း စဉ်းစားတဲ့ အခါကြတော့ ပိုကျယ်ပြန့်လာပါတယ်။ စဉ်းစားရတဲ့ အချက်တွေထဲမှာ နည်းပညာပိုင်းထက် ပိုစဉ်းစား လာရပါတယ်။ Project Management ပိုင်း၊ Development Team အပိုင်း၊ Quality Assurance ပိုင်း DevOps/SRE ပိုင်း စတာတွေပါ ထပ်ပါလာပါတယ်။

အရင်ဆုံး Project Team ကို စဖွဲ့ဖို့စဉ်းစားရပါတယ်။ အောက်ပါ ပုံ ကို ကြည့်ပါ။

Project Team ထဲမှာ Development Team ထပ်ခွဲ၊ Team Member တစ်ယောက်ချင်းစီရဲ့ Role နဲ့ Responsibilities တွေကို ရှင်းရှင်း လင်းလင်းသိအောင် Project Initiation Document မှာ ရေးထားရပါတယ်။ PO က ဘာတာဝန်၊ BA/Designer/PM/Architects/… စတာတွေက ဘာတာဝန်။

နောက် Project Management (PM) / Software Development Life Cycle (SDLC) ပုံစံ စဉ်းစားရပါတယ်။ Waterfall/Agile/Scrum/Hybrid/… တကယ့် လက်တွေ့ Development မှာ Scrum/PRINCE2/PMP/… စတဲ့ Project Framework တွေအတိုင်း အတိအကျလုပ်ဖို့ ခက်ပါတယ်။ Stakeholder တွေနဲ့ နားလည်မှုရယူပြီး စီမံမယ့် ပုံစံ နဲ့ အလုပ်လုပ်မယ့် ပုံစံတစ်ခုကို standard framework တွေက က guideline တွေ နဲ့ PM ရဲ့ အတွေ့အကြုံ ပေါင်းစပ်ပြီး ဖော်ထုတ်ရပါတယ်။ အဲ့ဒါမှ Client/PO ဘက်ကရော Vendor/Developer ဘက်ကရော လျှောလျှောရှူရှူ Project ပြီးတယ်လို့ သတ်မှတ်လို့ ရမှာပါ။ အောက်ပါ ပုံကို ကြည့်ပါ။

နောက် BA က အတိအကျ Business Requirement တွေ ကောက်ရာမှာ Reference လုပ်ဖို့အတွက် Guideline Format တစ်ခု စဉ်းစားပေးရပါတယ်။ အောက်ပါ ပုံကိုကြည့်ပါ။

Integrated Applications တွေဟာ Digital Platform ပုံစံ ဖြစ်လေ့ရှိပါတယ်။ Business Purpose တစ်ခုအတွက် ဘယ် channel တွေကနေ ဘယ် user တွေဆီကို ဘယ်လို service တွေ deliver လုပ်မလဲ ဆိုတာကို အခြေခံစဉ်းစားရပါတယ်။

ဒါတွေစဉ်းစားပြီးတော့မှ Development အတွက် Overall Architecture Diagram၊ သုံးမယ့် Tech Stack၊ Third-Party external integrations, System Designs, UI/UX Designs, … စတာတွေ ဆက်စဉ်းစားရပါတယ်။

Integrated Applications တွေကို ရေးဆွဲ ဖန်တီးတဲ့အခါ Solution Architect Role ဟာ မဖြစ်မနေ လိုလာပါတယ်။ Business Purpose ကနေ စပြီး နောက်ဆုံး Production Ready Application အနေအထားထိ လှမ်းမြင်နိုင်မယ့် Vision ကို Solution Architect က Project Team တစ်ခုလုံးကို လမ်းပြပေးဖို့လိုပါတယ်။

Aung Kyaw Minn