Jump to content


Windows Server 2012

- - - - -

ช่วยอธิบายเรื่อง Enterprise Architecture หน่อยค่ะ


  • Please log in to reply
20 replies to this topic

#1 rabbitnuch

rabbitnuch

    Newbie

  • Members
  • Pip
  • 4 posts

Posted 28 April 2011 - 10:20 AM

Enterprise Architecture คือโมเดลที่นำเอายุทธศาสตร์และเป้าหมายมาวางแผนIT ทั้งองค์กร ใช่หรือเปล่าค่ะ
แล้วเครื่องมือที่จะใช้สำหรับการทำ Enterprise Architecture นี้ ได้แก่อะไรค่ะ  หากองค์กรจะนำมาใช้บ้างจะยุ่งยากหรือต้องปรับเปลี่ยนอะไรขนาดไหนค่ะ

#2 nohc

nohc

    Star

  • Star
  • 266 posts

Posted 29 April 2011 - 11:11 AM

View Postrabbitnuch, on 28 April 2011 - 10:20 AM, said:

Enterprise Architecture คือโมเดลที่นำเอายุทธศาสตร์และเป้าหมายมาวางแผนIT ทั้งองค์กร ใช่หรือเปล่าค่ะ
แล้วเครื่องมือที่จะใช้สำหรับการทำ Enterprise Architecture นี้ ได้แก่อะไรค่ะ  หากองค์กรจะนำมาใช้บ้างจะยุ่งยากหรือต้องปรับเปลี่ยนอะไรขนาดไหนค่ะ

ใช่ครับ tool ที่นิยมใช้กันมากที่สุดได้แก่ Zachman's framework กับ TOGAF ครับ
ตัว Zachman's framework จะอธิบายแค่ว่าควรจะต้องมีอะไรบ้าง แต่ไม่ได้เจาะลึกถึงขนาดว่าต้องทำอะไรแบบไหน
ต่างกับ TOGAF ที่ลงลึกและมีรายละเอียดทุกอย่าง

หากจะนำมาใช้ผมว่ายุ่งยากมากเลยครับกับองค์กรที่ไม่เคยมีแบบแผนมาก่อนอาจถึงขั้นต้องปรับเปลี่ยนทั้งองค์กร
ส่วนตัวผมว่า Zachman เข้าใจง่ายกว่า TOGAF ครับ แต่ถ้าความเป็นสากลและ practical ตัว TOGAF จะมีมากกว่า

http://en.wikipedia....chman_Framework
http://en.wikipedia.org/wiki/TOGAF

ผมแค่เคยสนใจเลยศึกษามาหน่อยนึงครับ อาจจะบอกรายละเอียดไม่ได้มาก :rolleyes:

#3 up1

up1

    Topgun

  • Topgun
  • 2750 posts

Posted 29 April 2011 - 12:04 PM

เพิ่งไปฟังสัมมนาของ software park เรื่องนี้มา  เขาบอกว่า ถ้าจะทำ EA นั้น ต้อง

1. ต้องใช้คนที่มีอำนาจในบริษัท หรือ ผู้ที่สามารถฟันธงได้ ลงมาเล่นหรือทำ EA ด้วย
2. ในกลุ่มที่ทำ EA ห้ามมีแต่คนใน IT
3. ต้องทำงานเป็น Team

ถ้ามีทั้ง 3 ข้อที่ว่านี้แล้ว EA ก็ไม่ท่าทางว่าจะสำเร็จครับ


ปล. ผลของการทำ EA คือ Standard ของ process  แต่  EA จะดีหรือไม่ อยู่ที่การนำไปใช้งานครับ

#4 นายข้าวโพดหวาน

นายข้าวโพดหวาน

    Committee

  • Committee
  • 7138 posts

Posted 30 April 2011 - 08:25 PM

สงสัยว่าในเมืองไทยมีองค์กรไหนใช้ TOGAF หรือ Zachman's framework จริงจังบ้าง และ framework ทั้งสองตัวนี้เหมาะสมกับการนำไปใช้กับกระบวนการพัฒนาสมัยใหม่อย่าง Scrum, Lean อย่างไร ใครมีประสพการณ์ช่วยมาแชร์ให้ฟังได้ไหมครับ

#5 nohc

nohc

    Star

  • Star
  • 266 posts

Posted 03 May 2011 - 12:36 PM

View Postนายข้าวโพดหวาน, on 30 April 2011 - 08:25 PM, said:

สงสัยว่าในเมืองไทยมีองค์กรไหนใช้ TOGAF หรือ Zachman's framework จริงจังบ้าง และ framework ทั้งสองตัวนี้เหมาะสมกับการนำไปใช้กับกระบวนการพัฒนาสมัยใหม่อย่าง Scrum, Lean อย่างไร ใครมีประสพการณ์ช่วยมาแชร์ให้ฟังได้ไหมครับ

เคยเป็นตัวแทนไปร่วมประชุม IASA Thailand ครั้งนึงครับ ในที่ประชุมพูดถึงทุกคน หลัก ๆ ก็มี TOT, AIS แต่ทุกองค์กรพูดเหมือนกันว่าทำไม่ได้ครับ เนื่องจากผู้บริหารไม่เข้าใจว่าทำไปทำไม และเป็นการยากที่จะให้คนในองค์กรเข้าใจครับ อย่าง TOT นี่บอกเลยว่าผู้บริหารสั่งมาว่าให้ไปทำ EA แต่พอศึกษาแล้วกลับไปเสนอผู้บริหารว่าต้องทำยังไง กลับกลายเป็นว่าไม่เข้าใจครับว่าทำไมต้องทำอย่างนี้

ผมอัดเสียงตอนที่มีโอกาสได้ฟัง Zachman ตัวจริงบรรยายเรื่องของ Zachman's framework ไว้ยาวสองชั่วโมง (พูดอภิมหาเร็ว) ใครอยากลองเอาไปฟังไหมครับ ดูรูป Zachman's framework ประกอบก็พอ
(ถ้าเผยแพร่นี่ผิดกฏหมายไหมเนี่ย ค่าตัวพี่แกก็แพงเหลือเกิน)

#6 นายข้าวโพดหวาน

นายข้าวโพดหวาน

    Committee

  • Committee
  • 7138 posts

Posted 05 May 2011 - 10:14 AM

ขอบคุณที่มาเล่าให้ฟังครับ ส่วนเรื่องเผยแพร่ที่อัดเสียงไว้ ถ้ายังไม่ได้รับการอนุญาตจากเจ้าตัว อย่าเพิ่งโพสต์เลยครับ เดี๋ยวจะผิดลิขสิทธิ์

ผมสนใจมุมมองของการนำ EA มาใช้กับกระบวนการ agile อย่าง Lean หรือ Scrum ไม่แน่ใจว่ามันจะส่งเสริมหรือขัดแย้งกันหรือเปล่า ยังไม่ได้มีโอกาสได้ทำงานในองค์กรที่ใช้ TOGAF หรือ Zachman เลย

#7 minimalist

minimalist

    Star

  • Star
  • 895 posts

Posted 06 May 2011 - 03:00 AM

มาแจมครับเพราะทำทางด้านนี้อยู่ ขออธิบายแบ่งเป็นสองส่วนนะครับ

1. Introduction to Enterprise Architecture (EA)

John A. Zachman เป็นผู้เริ่มใช้คำนี้ครั้งแรกเมื่อหลายปีก่อน ตั้งแต่สมัยทำงานอยู่ที่ IBM คิดค้นเฟรมเวิร์กหนึ่งขึ้นมา โดยใช้ชื่อตัวเองว่า 'Zachman Framework' เป็นการอธิบายองค์กรผ่านมุมมอง (enterprise view) ทั้งหมด 36 มุมมอง ใน 2 มิติ คือแนวตั้ง 6 และแนวนอน 6 หรือกล่าวอีกอย่างคือ มี level of abstraction อยู่ 6 ระดับ โดย Zachman Frameowrk เป็นการอธิบาย EA หรือสถาปัตยกรรมองค์กรออกมาผ่านมุมมองทั้ง 36 มุมมองนั่นเอง ซึ่งสามารถใช้กับองค์กรที่ดำเนินธุรกิจใดๆ ก็ได้ ไม่จำเป็นต้องเป็นองค์กรไอทีเท่านั้น

แต่เนื่องจาก Zachman Framework มีข้อจำกัดหลักคือ หนังสือมีน้อย ไฟล์เอกสารต่างๆ มีน้อยมากบนเว็บ หรือกล่าวอีกอย่างคือ John A. Zachman เขาออกจาก IBM มาเปิดบริษัทของตนเองในการให้คำปรึกษาและจัดอบรมและสัมมนา การศึกษา Zachman Framework จึงมีข้อจำกัดเพราะมันไม่ฟรี! ข้อมูลต่างๆ จึงมีเผยแพร่น้อย

ในอีกทางหนึ่งมีองค์กรอิสระหนึ่งสร้างเฟรมเวิร์กด้าน EA ขึ้นมาแล้วเผยแพร่ฟรี! นั่นคือ 'TOGAF' (The Open Group Architecture Framework) มีเอกสาร ไฟล์ข้อมูล template มากมายให้ดาวน์โหลดไปอ่านกันฟรีๆ หรือจะซื้อหนังสือไปอ่านก็มีขาย

TOGAF แบ่ง level of abstraction (หรือจะเรียกว่าแต่ละ level หรือ layer ว่า perspective ก็ได้) โดยแต่ละ level เรียกว่า 'layer' โดยชั้นบนสุดคือ Business Architecture ตามด้วย Information System Architecture ซึ่งประกอบด้วย Data Architecture และ Application Architecture โดยมีชั้นสุดท้ายคือ Technology Architecture

TOGAF ได้รับความนิยมมากด้วยเหตุผลที่มีข้อมูล (content) สนับสนุนเยอะ คนเลยศึกษาได้ง่าย ประกอบกับมีสปอนเซอร์อย่างเวนเดอร์เจ้าใหญ่ๆ และองค์กรใหญ่ๆ สนับสนุน และ software tool ทางด้าน EA ส่วนมากมักรองรับ TOGAF

TOGAF ประกอบด้วยแนวทางจัดการต่างๆ เพื่อสนับสนุนการทำ EA อาทิ Architecture Repository, Architecture Governance, Architecture Building Block, Solution Building Block, Risk Management, Change Management, Communication Planning และอีกมากมาย


แล้วตกลง EA จริงๆ มันคืออะไร เอาง่ายๆ ครับ คือ 'การสังคายนาและปรับปรุงองค์กรอย่างต่อเนื่อง' ขออธิบายเป็นข้อๆ
  • EA เป็นภารกิจระดับยุทธศาสตร์องค์กร ไม่ใช่ระดับไอที แต่ผู้อิมพลีเม้นต์ EA คือฝ่ายไอที หรือมักเป็นฝ่ายไอที (อย่างงกันนะ :) ) แต่ผมไม่เห็นด้วยนะ ควรมีหน่วยงานหรือทีมงานเฉพาะขึ้นมาจริงๆ
  • EA เป็นงานระดับองค์กรจึงไม่ใช่งานระดับไอที หน่วยงานและบุคลากรภายในองค์กรต้องร่วมด้วยช่วยกัน ไม่ใช่ให้ฝ่ายไอทีทำอยู่ฝ่ายเดียว แต่หน่วยงานต่างๆ ต้องร่วมดำเนินการด้วย อาทิ ให้ข้อมูลสนับสนุน ร่วมเป็น domain expert (หรือ subject matter expert) ร่วมระดมสมอง ให้ข้อคิดเห็น และ...ร่วมรับผิดชอบ!
  • EA ควรอิมพลีเม้นต์แบบ Top-Down เพราะต้องวิเคราะห์และวางแผนจากระดับยุทธศาสตร์และแผนเชิงธุรกิจลงมา
  • EA ต้องอธิบายรายละเอียดขององค์กรออกมา อาทิ แผนธุรกิจ ทรัพย์สิน แผนยุทธศาสตร์ แผนการตลาด แผนการเงิน แผนบริหารบุคคล แผนต่างๆ และแผนไอที นอกจากอธิบายก็ต้องอธิบายรายละเอียดอื่นๆ ขององค์กรด้วย Zachman Framework ใช้คำได้ดีมากโดยเรียกว่าการศึกษา 'Ontology' ขององค์กร ซึ่ง Ontology เน้นการอธิบาย 'What' เพราะ architecture ใดๆ (software, IT, network, hardware, ฯลฯ) ต้องเน้นอธิบาย 'What' ก่อน 'How' เสมอ ซึ่งตรงข้ามกับ 'Methodology' ที่เน้นอธิบาย 'How' ดังนั้น Zachman Framework จึงเป็นเฟรมเวิร์กที่เน้นตรงจุดนี้ ขณะที่ TOGAF เน้น How (มากไปหน่อย) 'What' ในองค์กรมีมากมายไม่ใช่แค่แผนต่างๆ ยกตัวอย่างคำถามที่ EA ต้องตอบให้ได้ในเวลาอันสั้น อาทิ เมื่อเครื่องเซิร์ฟเวอร์รหัส ABC00123 เกิดล่มขึ้นมา จะส่งผลกระทบต่อระบบไอทีใดบ้าง? ส่งผลกระทบต่อข้อมูลใดบ้าง? ส่งผลกระทบต่อสินค้าและบริการใดบ้าง? ส่งผลกระทบต่อกลยุทธ์ขององค์กรใดบ้าง? ส่งผลกระทบต่อลูกค้ากลุ่มใดและรายใดบ้าง? ส่งผลกระทบต่อรายได้จากช่องทางใดบ้าง? ส่งผลกระทบต่อพนักงานคนใดบ้าง? ส่งผลกระทบต่อหน่วยงานใดในองค์กรบ้าง? ส่งผลกระทบต่อหน่วยงานใดภายนอกองค์กรบ้าง? ส่งผลกระทบต่อโครงการใดของหน่วยงานใดบ้าง? ส่งผลกระทบต่อ business process ใดบ้าง? ส่งผลกระทบต่อ application service ใดบ้าง? ส่งผลกระทบต่อ data service ใดบ้าง? ส่งผลกระทบต่อ infrastructure service ใดบ้าง?  นอกจากนี้ระบบที่ได้รับผลกระทบอยู่ที่ใดบ้าง? กระจายตัวอยู่ที่ใดบ้าง ส่งผลกระทบต่อแอพพลิเคชั่นเซิร์ฟเวอร์ ดาต้าเบสเซิร์ฟเวอร์ ใดบ้าง?... ยังมีอีกมากมายหลายคำถามที่การล่มของเซิร์ฟเวอร์เครื่องหนึ่งจะต้องตอบให้ได้ภายในเวลาอันสั้น
  • EA คือ การอธิบายสิ่งต่างๆ ขององค์กรออกมาในสภาวะปัจจุบัน (Baseline Architecture) แล้วนำมาวิเคราะห์เพื่อกำหนด Target Architecture ที่ต้องการจะให้เป็น แล้วมาวิเคราะห์ช่องโหว่ (Gap Analysis) จากนั้นจึงวิเคราะห์เพื่อกำหนดโอกาสและแนวแก้ไข (Opportunities & Solutions) จากนั้นจึงนำ Solutions ที่ได้ไปประเมิน (ทำการศึกษาความเป็นไปได้ หรือ Feasibility Study) แล้วคัดเลือก Solutions ที่คุ้มค่าที่เป็นไปได้ไปวางแผนดำเนินการ (Migration Planning) จากนั้นจึงกำหนดแนวทางติดตาม กำกับ ดูแล การดำเนินการ (Implementation Governance) จากนั้นก็ดำเนินการโดยมีการติดตาม กำกับ ดูแล อย่างใกล้ชิด ซึ่งควรมีกระบวนการคู่ขนานด้วยการเก็บสะสมโอกาส อุปสรรค แนวแก้ไข ฯลฯ ต่างๆ ระหว่างดำเนินการเพื่อนำไปสร้างและสะสมฐานความรู้ (Knowledge Base) เพื่อใช้ปรับปรุง Enterprise Architectural Process ในอนาคตให้มัน 'Agile' มากขึ้นๆ เพราะวัตถุประสงค์สำคัญประการหนึ่งของการทำ EA คือ การสร้าง 'Organizational Agility' ดังนั้นกระบวนการในการดำเนินการก็ต้องมี 'Agility' ด้วย กลับมาต่อครับ เมื่อดำเนินการ (อิมพลีเม้นต์) เรียบร้อยแล้ว ก็จบวัฏจักร (cycle) หนึ่งของการทำ EA ซึ่งปกติมักจบด้วยการทำ Architecture Change Management
  • EA ไม่ได้ทำครั้งเดียว แต่ทำเรื่อยๆ และก็ใช้งบประมาณเรื่อยๆ เพราะบอกแล้วไงว่า EA คือ การสังคายนาและปรับปรุงองค์กรอย่างต่อเนื่อง! และรายละเอียดในองค์กรมีปริมาณมาก ทั้งสินค้า บริการ กระบวนการทางธุรกิจ ข้อมูล ระบบไอที ฮาร์ดแวร์ ฯลฯ ในโครงการ EA หนึ่งๆ จึงต้องมีการทำ Architecture Vision เพื่อกำหนดวิสัยทัศน์และขอบเขตของการทำ EA ในโครงการนั้นๆ ว่าจะมุ่งเน้นปรับปรุงสินค้า บริการ กระบวนการทางธุรกิจ ระบบไอที ฯลฯ ใด อาทิ องค์กรมีบริการทั้งสิ้น 30 บริการ ในโครงการ EA แรกอาจหยิบบริการสัก 4 บริการมาทำ โดยขอบเขตต้องระบุให้ได้ด้วยว่า 4  บริการนี้เกี่ยวข้องกับอะไรบ้าง อาทิ กระบวนการทางธุรกิจใด? บุคลากรใด? หน่วยงานใด? กลยุทธ์ใด? แผนใด? สินค้าใด? ลูกค้ากลุ่มใด? ข้อมูลใด? ระบบไอทีใด? ฮาร์ดแวร์ใด? เครือข่ายใด? เป็นต้น?
  • EA คือ การใช้ไอทีเชิงรุก ฝ่ายธุรกิจและไอทีต้องร่วมมือกันหรือบูรณาการกันมากขึ้น (Business and IT Integration หรือ Business and IT Alignment) ต้องไปด้วยกัน ช่วยกันคิด ช่วยกันวิเคราะห์ปัญหา ช่วยกันหาแนวแก้ไข ช่วยกันทำงาน และ...ช่วยกันรับผิดชอบ
  • EA คือ การทำให้องค์กรมีภูมิคุ้มกันด้านไอทีที่ดี สามารถพึ่งพาตนเองได้ในระดับหนึ่ง
  • EA ไม่จำเป็นและไม่ต้องการ 'World Class Standard' หรือแม้แต่ 'World Class Best Practices' ใดๆ เพราะมาตรฐานและสูตรลับ...องค์กรต้องสร้างมันขึ้นมาเอง อาจอ้างอิงเฟรมเวิร์กต่างๆ ได้ แต่ต้องนำมาปรับปรุง (customize) ก่อน ไม่ใช่ใช้ดื้อๆ แบบเห็นช้างขี้ก็ขี้ตามช้าง
  • จะทำ EA ต้องสร้างพิมพ์เขียว (Enterprise Architecture Blueprint) ขององค์กรขึ้นมาก่อนเสมอ แล้วต้องดูแล (maintain) อย่างต่อเนื่อง สร้างเสริม ปรับปรุง ต่อยอด เพิ่มพูน วิธีที่ง่ายที่สุดคือการนำเฟรมเวิร์กมาปรับ อาทิ นำ TOGAF มาปรับให้เข้ากับองค์กร โดย blueprint ที่ดีควรประกอบด้วย กระบวนการดำเนินการ (process), ตัวอย่าง, template เอกสารต่างๆ, คำศัพท์และสัญลักษณ์มาตรฐาน และแนวทางดำเนินการ (guideline) สิ่งเหล่านี้องค์กรต่างๆ ต้องมีเป็นของตนเอง จะไปหยิบยืมใครมาใช้ตรงๆ ไม่ได้ หรือถ้าจะหยิบยืมมาก็ต้องนำมาปรับให้เข้ากับองค์กรก่อน
  • EA จะสำเร็จเมื่อไหร่ วัดจากการลงทุนด้านไอทีคุ้มค่ามากขึ้น นั่นคือไอทีเข้าไปขับเคลื่อนธุรกิจหรือกิจกรรมต่างๆ ขององค์กรได้อย่างมีประสิทธิภาพ ไม่ใช่แค่เข้าไปสนับสนุนเท่านั้น เมื่อไอทีเข้าไปขับเคลื่อนมากขึ้นองค์กรก็ดำเนินการได้อย่างคล่องตัว (agile) มากขึ้น ฟังแล้วอาจดูนามธรรมหน่อย แต่นี่ล่ะ...EA
  • EA มีอุปสรรคสำคัญในการดำเนินการโดยเฉพาะในเมืองไทยนั่นคือ ประเด็นด้านการเมือง วัฒนธรรมองค์กร โครงสร้างองค์กร (เพราะองค์กรส่วนใหญ่มีโครงสร้างแบบ Silo และการทำ EA มักต้องมีการปรับโครงสร้างองค์กรด้วย ไม่มากก็น้อย) การสื่อสาร การสร้างความร่วมมือ การสร้างการรับรู้และให้ความรู้
  • EA ไม่ต้องใช้เครื่องมือหรือ software tool ใดๆ เลยก็ได้!!!!!!!!!! หากการสื่อสารมีประสิทธิภาพ จัดเก็บข้อมูลมีประสิทธิภาพ กระบวนการต่างๆ มีประสิทธิภาพ มีการจัดการธรรมาภิบาลที่ดี และที่สำคัญที่สุดคือ...มีผู้บริหารที่ดี มีวิสัยทัศน์ดี มีความาสามารถเหมาะสมกับสายงานรับผิดชอบ และมีภาวะผู้นำที่ดี
  • ในการทำ EA ช่วง 1-3 ปีแรกแทบไม่ต้องซื้อ software tool ใดๆ เลย เครื่องมือที่ดีที่สุดคือกระดาษ ปากกา ดินสอ หรืออย่างมากก็โปรแกรมออฟฟิศและ modeling tool
  • Modeling Language ที่เหมาะสมกับการอธิบายมุมมองต่างๆ ใน EA คือ ArchiMate ซึ่งประยุกต์มาจาก UML และ BPMN อีกที แต่ง่ายกว่าเยอะและมีสัญลักษณ์น้อยกว่ามาก เพราะโมเดลในระดับ EA ไม่ต้องละเอียดมากในเชิงลึก และต้องอธิบายภาพรวมได้ เพราะ architecture ใดๆ เน้นการบูรณาการ (การเชื่อมต่อ) และโมเดลต้องอ่านง่ายเข้าใจง่าย เพราะต้องถูกใช้โดยบุคลากรหลายด้าน (ไม่ใช่แค่ไอที) ดังนั้น UML จึงไม่เหมาะสมเพราะวาดยาก รายละเอียดเยอะ สัญลักษณ์เยอะ
  • EA มีประโยชน์สำคัญคือ ทำให้ผู้บริหารเข้าใจองค์กรมากขึ้น เห็นภาพรวมและผลกระทบระหว่างสิ่งต่างๆได้รวดเร็วและแม่นยำมากขึ้น วางแผนและตัดสินใจรวดเร็วและแม่นยำมากขึ้น


2. ข้อคิดเห็นเสริม
  • เร็วๆ นี้เมืองไทยจะมีสมาคมสถาปนิกเทคโนโลยีสารสนเทศขึ้น โดยเป็นคล้ายกับสมาคมสถาปนิกสยามฯ เป็นสมาคมวิชาชีพ เป็นองค์กรอิสระ ซึ่งเกิดจาก IASA Thailand ที่ก่อตั้งมานานแล้วกำลังจะปรับตัวไปเป็นสมาคมฯ เพื่อให้ชัดเจนมากขึ้นและจริงจังเข้มข้นมากขึ้น
  • การประชุมบอร์ดของ IASA ผมก็เข้าไปร่วมรับฟังความคิดเห็นอยู่บ้าง เร็วๆนี้ก็จะได้เข้าไปร่วมด้วยช่วยกันมากขึ้น
  • การทำ EA ไม่ใช่มีตังค์แล้วก็ทำได้ ระวังพวกเวนเดอร์ไว้ดีๆ software tool ด้านนี้ในบ้านเรามีไม่กี่ยี่ห้อ หรือถ้าให้สั้นๆ คือประมาณ 2-3 ยี่ห้อเท่านั้น เด่นๆ เลยคือมียี่ห้อเดียว ถ้าจะซื้อแบบสมบูรณ์ๆ โมดูลครบๆ ก็เป็นหลักร้อยล้านบาท ไหนจะค่าซัพพอร์ต อบรม ที่ปรึกษา ดูแล อีก (เวลาจะซื้อ tool ด้าน EA ให้ถามบริษัทที่เป็นตัวแทนจำหน่ายด้วยว่า..."คุณใช้ของของคุณเป็นไหม? และคุณมีความรู้ที่เกี่ยวข้องกับของที่คุณขายแค่ไหน?" ไม่ใช่ขายอย่างเดียว หรือใช้ tool เป็น แต่ไม่รู้ EA เท่าไรนัก ?!?!!?)

    การทำ EA ต้องสร้าง blueprint ก่อน แต่ไม่มีบริษัทไอทีหรือเวนเดอร์ที่รับทำเจ้าไหนมาบอกลูกค้าหรอกว่าต้องทำ เพราะว่าการทำ blueprint มันไม่ต้องใช้ tool! ใช้แต่คน! คน..คือ..tool...ที่สำคัญที่สุดในการทำ EA และการทำ EA ต้องทำโดยคนภายในองค์กร ไม่ใช่คนภายนอกองค์กร คนนอกมีหน้าที่แค่เป็น expert เข้ามาช่วย เช่น จัดอบรมให้ความรู้คนภายใน เป็นที่ปรึกษา เป็นโค้ช เป็นผู้ประเมิน เป็นต้น
  • EA จึงไม่ได้ทำแค่ครั้งเดียว เกิดตั้งงบประมาณก้อนโตในโครงการแรก พอโครงการต่อไปๆ จะทำอีกแล้วไงต่อ?​ ​EA ต้องทำเรื่อยๆ ตราบที่องค์กรยังต้องอยู่รอดและเติบโตต่อไป วันนี้ใครๆ ก็เรียกมันว่า 'Enterprise Architecture' ก็ฟังดูเท่ๆ เหมือน Cloud Computing และ SOA น่ะ ก็แค่ไอทีแบบโพสโมเดิร์นที่จับนู่นนี่นั่นมาผสมผสานปั่นๆๆๆๆ ใส่ความทันสมัยเข้าไป แล้วนิยามมันใหม่ตั้งชื่อใหม่ให้เพราะพริ้ง ดังนั้นวันหนึ่งข้างหน้าคำว่า 'Enterprise Architecture' อาจตายจากไปหรือฟังไม่เท่แล้ว หรือเชยนั่นเอง แต่องค์กรก็ยังต้องทำ EA อยู่ งั้นก็เรียกมันว่าคือการสังคายนาและปรับปรุงองค์กรอย่างต่อเนื่องแหละดีที่สุด!
  • สำหรับ TOGAF แม้ว่าเป็นเฟรมเวิร์กด้าน EA ที่ดีก็จริง แต่ไม่ดีที่สุด และไม่มีเฟรมเวิร์กด้านนี้ที่ดีที่สุด เฟรมเวิร์กที่ดีที่สุดคือเฟรมเวิร์กที่องค์กรนั้นๆ ต้องสร้างขึ้นเอง ซึ่งนั่นคือการนำเฟรมเวิร์กต่างๆ ที่มีอยู่แล้วมาผสมผสานและปรับปรุงให้เหมาะกับองค์กรตนเองนั่นเอง
  • TOGAF มีช่องโหว่อยู่หลายจุดที่ไม่สมบูรณ์ อาทิ Architecture Governance, Risk Management, Change Management, Gap Analysis, Business Case Analysis ฯลฯ แต่...อย่างที่กล่าวข้างต้นยาวเหยียด EA มันเป็นเรื่องขององค์กรทั้งองค์กร จะให้มีเฟรมเวิร์กอะไรสักตัวที่อธิบายเสียละเอียดยิบในการจัดการต่างๆ คงไม่มีในโลก ส่วนตัวผมจึงไม่ได้โทษ TOGAF แต่อยากฝากไว้ว่าอย่าไปบ้าตาม TOGAF เป๊ะๆ ชนิดเห็นช้างขี้ท่าไหนก็ไปขี้ท่านั้นตามมัน
  • องค์กรในบ้านเราส่วนมากใช้ TOGAF กันทั้งนั้นครับและมักใช้โซลูชั่นของ IBM ครับ ผมเดาว่าประมาณ 80% เลย ที่เหลือก็ Oracle, HP, Microsoft  และเวนเดอร์ที่กล่าวมาทุกเจ้าเน้น TOGAF ครับ
  • องค์กรในบ้านเรามักทำแบบ Bottom-Up เพราะหน่วยงานไอทีในองค์กรส่วนใหญ่ในบ้านเรามักไม่ค่อยมี 'power' จะไปงัดกับฝ่ายธุรกิจหรือระดับบริการระดับสูงน่ะครับ จึงออกมากลายเป็นการปรับปรุงไอทีเสียแทน ซึ่งการทำ EA แบบ Bottom-Up อาจทำให้หลงทางได้ครับ อาทิ ไปทำกับระบบไอทีและฮาร์ดแวร์ที่ไม่เกิดประโยชน์มากต่อธุรกิจ กระบวนการทางธุรกิจ และบริการที่สำคัญขององค์กร และองค์กรมากมายในบ้านเราเป็นองค์กรที่ใช้ไอทีเชิงรับ ไม่ใช่เชิงรุก หน่วยงานไอทีจึงไม่ค่อยมีบทบาทมากนัก แต่แปลกที่การ initiate ด้าน EA มักเกิดจากหน่วยงานไอที แต่คนไอทีมีข้อเสียคือขายของไม่เป็น ขายไอเดียไม่เก่ง (ต้องไปอ่านหนังสือที่ พี่ 'นายข้าวโพดหวาน' เคยแนะนำครับ ชื่อ Fearless Change: Patterns for Introducing New Ideas ซึ่งแจ๋วจริงๆ) เพราะคนไอทีพูดเก่งแต่เรื่องคุณภาพ (qualitative) แต่ผู้บริหารมักสนใจปริมาณ (quantitative)...ครับ

มีข้อแนะนำและไอเดียเสริมอีกเพียบเลย...ใครสนใจก็ถามๆ มาละกันครับ หรือไว้มีเวลาจะเขียนบทความให้กระชับและละเอียดๆ อีกทีครับ


ดังนั้น

Quote

Enterprise Architecture คือโมเดลที่นำเอายุทธศาสตร์และเป้าหมายมาวางแผนIT ทั้งองค์กร ใช่หรือเปล่าค่ะ
?
คำตอบคือ...ไม่ใช่ครับ Enterprise Architecture ไม่ใช่โมเดล แต่เป็นการสร้างโมเดลเพื่ออธิบายองค์กรและประกอบการดำเนินการ และ การเป็นนำยุทธศาสตร์และเป้าหมายทั้งด้านธุรกิจและไอทีมาวิเคราะห์ร่วมกัน ทั้งยุทธศาสตร์และเป้าหมายด้านธุรกิจต้องสะท้อนไอที และยุทธศาสตร์และเป้าหมายไอทีก็ต้องสะท้อนธุรกิจ โดยต้องดำเนินการไปร่วมกัน ในประโยคคำถามข้างต้น 'นำยุทธศาสตร์และเป้าหมายมาวางแผน IT' จึงมองได้สองมุม
มุมหนึ่ง: ผิดครับ หากคุณ rabbitnuch มองแบบนี้ จะกลายเป็นว่าไอทีต้องตามธุรกิจ แต่ไม่จำเป็นบางสถานการณ์ไอทีอาจต้องนำ เช่น ใช้ผลการวิเคราะห์แนวโน้มเทคโนโลยีมาไกด์แผนธุรกิจเพื่อปรับปรุงหรือคิดค้นสินค้าหรือบริการใหม่ๆ ให้แก่องค์กร
อีกมุมหนึ่ง: ถูกครับ หากคุณ rabbitnuch มองว่าเป็นลักษณะ 'Business-Driven' เพราะ การทำ EA ต้องทำแบบ Top-Down เพียงแต่ในระดับ Business Architecture ต้องมียุทธศาสตร์ เป้าหมาย แผน และ business process ด้านไอทีอยู่ด้วย แต่รายละเอียดในแง่ information system และเทคโนโลยี จะอยู่ในเลเยอร์ล่างๆ

จากนั้น

Quote

แล้วเครื่องมือที่จะใช้สำหรับการทำ Enterprise Architecture นี้ ได้แก่อะไรค่ะ หากองค์กรจะนำมาใช้บ้างจะยุ่งยากหรือต้องปรับเปลี่ยนอะไรขนาดไหนค่ะ
หากอ่านข้างต้นไปแล้ว tool ที่ดีที่สุดคือ คน และอุปกรณ์ง่ายๆ อย่างดินสอ ปากกา กระดาษ โปรแกรมออฟฟิศ และอาจใช้พวก modeling tool ประกอบการวาดรูปโมเดลต่างๆ ถ้าให้แนะนำง่ายๆ นะครับคือ ศึกษา TOGAF ให้เข้าใจ แล้วสอนบุคลากรต่างๆ ในองค์กรให้เข้าใจ (ไม่ใช่แค่คนไอทีเท่านั้นนะครับ) แล้วลองสร้าง blueprint ขององค์กรขึ้นมาครับ รายละเอียดไม่ต้องมาก เอารายละเอียดเชิงกว้าง แต่ไม่ต้องลึกมาก ให้เห็นภาพรวม


การเริ่มต้นทำ EA ด้วยการซื้อ Enterprise Architecture Tool จะพบจุดจบแน่นอนครับ  หากมีงบประมาณจะเอาไปทำอะไรดี... ขอแนะนำว่าสิ่งที่ลงทุนแล้วคุ้มค่าที่สุดในการทำ EA คือ...การลงทุนกับคนภายในองค์กรครับ ต้องกำหนดตัวชี้วัด (KPI) ของบุคลากรที่เกี่ยวข้องในการทำ EA ให้ชัดเจน มีการให้รางวัลในรูปแบบต่างๆ สนับสนุน เอางบฯ ไปจัดอบรม จ้างที่ปรึกษาดีๆที่ทำงานเป็น! มาช่วย ซื้อ modeling tool ง่ายๆ มาใช้ ยังไม่ต้องใช้ tool ดีมากใหญ่มาก พอทำคล่องแล้ว เริ่มคุ้นเคยโครงการต่อไปค่อยซื้อของดีๆ แพงๆ ใช้ครับ คือ โครงการแรกๆ มันคือการสร้างตัวต่อเลโก้ (architecture building block) น่ะครับ พอสร้างไปมากเข้าๆ ก็จะมีตัวต่อเลโก้มาก แล้ว tool มันจะมาช่วยจัดการไงครับ ดังนั้นหากมี tool แต่แรกก็ยังไม่ได้ใช้มันสักเท่าไหร่หรอกครับ เพราะตัวต่อเลโก้ยังไม่มี หรือมีน้อยเกินไป


พี่ 'นายข้าวโพดหวาน' ถามเกี่ยวกับ Lean, Scrum, Agile หากอ่านข้างต้น (ถ้าอดทนอ่านไหว :D) ก็คงพอเห็นภาพละ แต่ขอสรุปสั้นๆ ละกันครับ คือทำ EA ต้องค่อยๆ ปรับกระบวนการฯ ให้มัน Agile หรือ Lean ขึ้นเรื่อยๆ ดังนั้นในการทำ EA จึงมีการประเมิน Maturity Level กันด้วย สำหรับ level สูงสุดคือ Agile สุดๆ ครับ คือระดับ Optimization Level และการทำ EA กระบวนการฯ ต้อง Lean ผมจึงเน้นให้ปรับเฟรมเวิร์กต่างๆ ที่สนใจโดยปรับให้เข้ากับองค์กร ค่อยๆ ปรับ อย่าปรับทีเดียว คือต้องใช้ไปปรับไป ส่วนมากที่เจอคือบ้าทฤษฏี ตามเขาเป๊ะๆ แล้วบ่นว่ายากว่าเยอะ ต้องลองผิดลองถูก ทำไปปรับไปๆๆๆๆๆๆ แล้ววัด(ประเมิน) performance เรื่อยๆ สะสม knowledge base ให้มากขึ้นๆ

ส่วน Scrum คงต้องโมดิฟายพอสมควรเพราะการทำ EA ไม่ใช่แค่การพัฒนาระบบ แต่มันไปเกี่ยวกับกิจกรรมที่ไม่ใช่ไอทีเยอะมาก เยอะกว่ากิจกรรมด้านไอทีเสียอีก แต่ทำได้ครับโดยการกำหนดช่วงการทำ Scrum ให้ไป map กับ business process หรือเฉพาะบางจังหวะ/ขั้นตอน/activity ใน business process ที่คิดว่าจะมีการทำ Scrum แล้วขยายผลต่อไปจาก business process ว่าส่วนอื่นๆ ที่เกี่ยวข้องกับ business process ที่เลือก จะต้องร่วมหรือได้รับผลกับการทำ Scrum อย่างไร ถ้าให้ง่ายขึ้นพี่ลองดูภาพของ Zachman Framework ประกอบ ที่มี 36 มุมมอง แต่ละมุมมองสัมพันธ์กับแนวตั้งและแนวนอน ซึ่งต้องออกแบบการทำ Scrum ให้เข้ากับกิจกรรมที่สัมพันธ์กับแต่ละมุมมองน่ะครับ อาทิ การทำ Scrum ในมิติแนวตั้ง ในมิติแนวนอน ในมิติผสมผสานทั้งแนวตั้งและนอน เพราะสุดท้ายทั้ง 36 มุมมองมันต้องลิงค์กันได้หมด


ฝากไว้เท่านี้ก่อนละกันครับ ไม่ได้พิมพ์อะไรยาวๆ ใน narisa.com นานละ งานเยอะมากมาย :D

Edited by minimalist, 15 May 2011 - 05:32 PM.


#8 nohc

nohc

    Star

  • Star
  • 266 posts

Posted 06 May 2011 - 11:22 AM

อยากให้ Narisa กด like ได้จังจะได้กด like ข้างบน อธิบายได้ชัดเจนครับ :lol:

#9 Pusit

Pusit

    Newbie

  • Members
  • Pip
  • 4 posts

Posted 13 May 2011 - 06:04 PM

สุดยอดครับ คุณ minimalist

#10 นายข้าวโพดหวาน

นายข้าวโพดหวาน

    Committee

  • Committee
  • 7138 posts

Posted 14 May 2011 - 09:25 PM

ขอบคุณสำหรับคำอธิบายอย่างละเอียดครับ ทำไมอ่านแล้วรู้สึกเหมือนว่า EA มีไว้สำหรับให้เวนเดอร์ขายของแพงๆให้กับบริษัทใหญ่ๆนะ

ยังรู้สึกว่า EA เป็นนามธรรมพอสมควร สงสัยคงต้องหาข้อมูลเพิ่มเพื่อทำความเข้าใจว่าเค้าวัด ROI จากการทำ EA กันยังไง

#11 minimalist

minimalist

    Star

  • Star
  • 895 posts

Posted 15 May 2011 - 05:14 PM

Quote

ขอบคุณสำหรับคำอธิบายอย่างละเอียดครับ ทำไมอ่านแล้วรู้สึกเหมือนว่า EA มีไว้สำหรับให้เวนเดอร์ขายของแพงๆให้กับบริษัทใหญ่ๆนะ
ถูกต้องแล้วครับพี่ :) ใคร (เวนเดอร์) ที่ได้โครงการ EA ขององค์กร (ลูกค้า) ไปทำเปรียบเสมือนได้เขมือบทรัพยากรไอทีของลูกค้าไปมหาศาล ในทางกลับกันลูกค้าเปรียบเหมือนเป็นการยกทรัพยากรไอทีจำนวนมากให้เวนเดอร์(หรือซอฟต์แวร์ของเวนเดอร์)ดูแล ซึ่งมีโอกาสสุ่มเสี่ยงที่จะโดน vendor lock-in สูงมาก เพราะปกติทำ EA มักทำกับทรัพยากรไอทีส่วนสำคัญๆ ขององค์กร

จะสังเกตได้ชัดเจนว่าไม่กี่ปีมานี้เวนเดอร์เจ้ายักษ์ๆ ไล่กว้านซื้อบริษัทซอฟต์แวร์เล็กใหญ่กันมากมาย เพราะโซลูชั่นของพวกเขาจะใหญ่ขึ้นๆ ทุกรายต่างมุ่งสู่ enterprise solution กันทั้งสิ้น อย่างเช่น SOA, EA, Cloud Computing, Enterprise System Management การทำ EA แบบใจร้อนและรู้เท่าไม่ถึงการณ์จึงเสี่ยงมากๆ

กรณีศึกษาของโอกาส อุปสรรค จุดดี จุดเสีย ของการร่วมมือกันระหว่างเวนเดอร์กับองค์กรลูกค้ารายใหญ่ คงต้องหยิบกรณี ธนาคารกสิกรไทยกับไอบีเอ็ม มาเป็นกรณีศึกษาครับ จะสังเกตได้ว่าปัจจุบันธนาคารกสิกรไทย ตีตัวออกห่างจากไอบีเอ็มมากขึ้นๆ แม้ตัดความสัมพันธ์กันไม่ได้ เพราะข้อดีก็ยังมีอยู่และติดเงื่อนไขปัจจัยบางประการ แต่ก็ทำให้ธนาคารกสิกรไทยมีอิสระและคล่องตัวมากขึ้น ธนาคารกสิกรไทยยังถือเป็นกรณีศึกษาขององค์กรที่ทำ EA เป็นรายแรกๆ และประสบความสำเร็จในระดับหนึ่งได้ดีทีเดียว ซึ่งก็ต้องยอมรับอีกเช่นกันว่าส่วนหนึ่งก็ได้ความช่วยเหลือจากไอบีเอ็มด้วยเช่นกัน รายละเอียดอื่นๆ ไว้ค้นคว้ากันเองนะครับ ขอไม่กล่าวถึงมากไปกว่านี้


Quote

ยังรู้สึกว่า EA เป็นนามธรรมพอสมควร สงสัยคงต้องหาข้อมูลเพิ่มเพื่อทำความเข้าใจว่าเค้าวัด ROI จากการทำ EA กันยังไง
สำหรับตรงนี้ ขอสรุปอีกทีครับเพราะ EA มันกว้างจริงๆ คือ EA เป็นการทำความเข้าใจกับองค์กร โดยอธิบายข้อมูลองค์กรในด้านต่างๆ ออกมาผ่านมุมมอง (enterprise view) จากนั้นก็วิเคราะห์ดูว่าจุดใดที่มีปัญหา ส่งผลต่อรายได้และประสิทธิภาพขององค์กรเป็นอุปสรรคต่อความก้าวหน้าและเติบโตขององค์กร ก็ทำการปรับปรุงและสร้างเสริมจุดนั้นให้ดีขึ้น...นั่นเองครับ

เพียงแต่ว่าแนวคิดและเฟรมเวิร์ก EA ต่างๆ มักกล่าวถึงไอทีและให้ความสำคัญกับไอทีมาก กลายเป็นอธิบายว่าจุดใดที่ไอทีเข้าไปสนับสนุนและขับเคลื่อนยังไม่ดีพอก็ทำการปรับปรุงทรัพยากรไอทีที่มีอยู่ หรือพัฒนา/จัดหาทรัพยากรไอทีที่มีประสิทธิภาพเหมาะสมเข้ามาใช้งาน หรือถ้ากล่าวอย่างสั้นสุดๆ ก็คือ การนำไอทีไปสนับสนุนและขับเคลื่อนกิจกรรมทางธุรกิจให้มีประสิทธิภาพโดยมององค์กรเป็นศูนย์กลาง ไม่ใช่โฟกัสที่กิจกรรมใดกิจกรรมหนึ่ง หรือหน่วยงานใดหน่วยงานหนึ่ง เพราะ EA ต้องมองภาพรวมต้องบูรณาการส่วนต่างๆเข้าด้วยกัน...

ขอเปรียบเทียบเช่น หากผมอยากเป็นนักวิ่ง 100 เมตร โค้ชของผมจะให้ผมปรับปรุงกล้ามเนื้อขาให้แข็งแรงอย่างเดียวไม่ได้ ต้องดูความสัมพันธ์กับส่วนอื่นๆ ด้วยว่า การจะวิ่ง 100 เมตรโดยใช้เวลาน้อยที่สุด ต้องอาศัยกลไกใดในร่างกายบ้าง แล้วปรับปรุงอย่างบูรณาการ วิเคราะห์และติดตามผลกระทบระหว่างกัน เช่น หัวใจ ปอด กล้ามเนื้อ ประสาทหู ระบบหายใจ ระบบกล้ามเนื้อ ระบบประสาท เป็นต้น

แต่ก่อนๆ ในอดีตจนกระทั่งปัจจุบันที่มักทำกันคือ มักปรับปรุงไอทีเป็นจุดๆ เช่น งานบัญชีมีปัญหาก็หาระบบบัญชีหรือปรับปรุงระบบบัญชีที่มีอยู่ แทนที่จะดูแบบภาพรวม ดังนั้นหัวใจสำคัญของ EA คือต้องมองภาพรวมของทั้งองค์กรให้ออก

ดังนั้นในความคิดเห็นของผม Enterprise Architecture จึงไม่ใช่เรื่องไอทีครับ เพียงแต่มองไอทีเป็นเครื่องมือในการสนับสนุนและขับเคลื่อนองค์กรเท่านั้น ฉะนั้นใน EA จึงมีการบริหารจัดการต่างๆ นานาเยอะมาก อาทิ Balanced Scorecard, Strategy Map, Risk Management, Change Management, IT Governance, Business Scenario & Case Analysis, Career Path, Performance Management เป็นต้น


ผมขอยกตัวอย่าง Zachman Framework ในเลเยอร์บนสุดนะครับ สิ่งที่องค์กรต้องตอบคำถามและอธิบายออกมาคือ
1. หากองค์กรจะอยู่รอดและเติบโตต่อไปในธุรกิจ มีปัจจัยใดเกี่ยวข้องบ้าง? (Business Things)
เมื่อทราบแล้วว่ามีปัจจัยใดบ้างก็ต่อด้วย...
2. องค์กรต้องทำอะไรบ้างเพื่อให้อยู่รอดและเติบโตต่อไป? (Business Functions หรือผมชอบเรียกว่า Business Mechanisms แล้วอธิบายขั้นตอนออกมากเป็น Business Process)
เมื่อทราบแล้วว่ามีกลไกสำคัญใดบ้างที่มีผลต่อองค์กรก็ต่อด้วย...
3. แต่ละขั้นตอนของแต่ละกลไกเหล่านั้นปฏิบัติรับผิดชอบโดยหน่วยงานใด? (Business Organizations)
4. แต่ละหน่วยงานปฏิบัติงานอยู่ที่ไหน? (Logical & Physical Locations)
5. เงื่อนเวลา, cycle, constraints และเหตุการณ์สำคัญ ในการปฏิบัติงานคืออะไร? (Business Events)
6. เป้าหมายและยุทธศาสตร์ขององค์กรคืออะไร? (Business Goals & Strategies) ข้อนี้สำคัญมาก เพราะเป็นการตอบ 'why' ว่าทำไมถึงต้องการจะอยู่รอดและเติบโตต่อไป

เพียงแค่ 6 เลเยอร์บน ก็ทำให้ทราบได้แล้วว่าองค์กรมากมายไม่สามารถตอบได้ชัดเจนเลย หรือหลายองค์กรอาจตอบว่าสิ่งเหล่านี้ "เรามี" "เราทราบ" แต่ไม่มีหลักฐาน ไม่มีข้อมูลชัดเจน หรือมีข้อมูลแต่ลิงค์หรือบูรณาการกันไม่ได้เลย
ที่เหลือในเลเยอร์ต่างๆ ก็ค่อยเจาะลึกลงไปในรายละเอียดในส่วนต่างๆ

ดังนั้น EA จึงมีขอบเขตและกิจกรรมเกี่ยวข้องที่กว้างมากยิ่งกว่า Six Sigma และ Balanced Scorecard เสียอีกครับ หรือในอีกทางอาจมองว่า EA คือเครื่องมือหนึ่งเพื่อสนับสนุนการทำ Six Sigma ก็ได้ เพราะสองสิ่งนี้มันไปด้วยกันได้ดี   องค์กรต่างๆ โดยเฉพาะในต่างประเทศจึงมอง EA ว่าเป็นงานระดับบริหารจัดการ เป็นงานระดับองค์กร ไม่ใช่แค่งานไอที กำลังมีการนำ EA ไปใช้กับองค์กรมากมาย ด้วยสมมติฐานที่ว่า 'องค์กรที่ดีต้องมีสถาปัตยกรรมองค์กร'

เพราะหัวใจหนึ่งของงานสถาปัตยกรรมใดๆ ก็ตามคือ การเชื่อมโยง (บูรณาการ) ปัจจัยสำคัญต่างๆ ที่ส่งผลต่อภาพรวมของตัวผลิตภัณฑ์ (บ้าน เครื่องจักร ระบบไอที องค์กร ฯลฯ)


หลายคนชอบเข้าใจ EA ผิดครับ อย่าง Sun เองก็เคยเป็น เพราะผมเป็น Sun Certified Enterprise Architect อยู่ สอบผ่านเมื่อเกือบ 9 ปีที่แล้ว แนวทางของซันฯ ใช้คำว่า Enterprise Architecture ก็จริง แต่จริงๆ เป็น Enterprise System Architecture มากกว่า เพราะเน้นทางด้านไอทีและระบบมากเกินไป ซึ่งจริงๆ EA เน้นการจัดการแบบภาพรวมมากๆ อย่างแนวทางของ IBM, Oracle, Microsoft มีขอบเขตและความชัดเจนกว่ามาก

ดังนั้นทุกวันนี้หลายคนพอได้ยิน EA ก็มักเข้าใจไปเป็น Enterprise System Architecture กันทั้งนั้น พอดีผมสอนหนังสือหัวข้อนี้อยู่ด้วยน่ะครับ สอนมาหลายปีแล้ว ผู้เรียนเป็นองค์กรต่างๆ ในบ้านเรา พบว่ามีจำนวนไม่น้อยทีเดียวที่เข้าใจ EA เป็นลักษณะนี้กัน พอมาเรียนแล้วพบว่า EA จริงๆ แล้วมีขอบเขตที่กว้างและลึกมาก ผู้เรียนก็อ้าปากหวอและมึนกลับไป เพราะคนส่วนมากที่มาเรียนคือคนไอที แต่การเรียน EA จริงๆ มันต้องเอาตัวแทนจากหน่วยงานต่างๆ ในองค์กรมาเรียนกัน! ไม่ใช่แค่ไอที และอีกอย่างคอร์สผมสอนแค่ Introduction เพราะเน้นจิตวิทยาเล็กน้อยคือสอดแทรกการสร้าง awareness เข้าไปและอื่นๆ อีก และไม่สามารถสอนลึกได้เพราะการจะสอนลึกต้องสร้างความเข้าใจและความพร้อมให้คนในองค์กรก่อนโดยเฉพาะผู้บริหาร ไม่งั้นเรียนไปก็เสียตังค์เสียเวลาเปล่าๆ เปลี้ยๆ


EA กำลังจะกลายเป็น...สิ่งที่แทบทุกองค์กรต้องทำครับ โดยอีกไม่นานอย่างในบ้านเราองค์กรที่ทำหน้าที่ตรวจสอบและประเมินผลประสิทธิภาพองค์กรต่างๆ อย่าง TRIS (Thai Rating and Information Service: http://www.tris.co.th) อาจนำ EA เข้าไปเป็นตัวชี้วัดหนึ่งในการวัดประสิทธิภาพองค์กรต่างๆ ก็ได้ครับ และจะไปรวมอยู่ในระเบียบข้อบังคับของกลุ่มอุตสาหกรรม ธุรกิจต่างๆ ด้วยครับ

แต่สุดท้ายอยากฝากหลายๆ ท่านไว้ว่าอย่าไปบ้าจี้กับ 'Enterprise Architecture' กันนัก ให้มองว่ามันคือการปรับปรุงองค์กรอย่างต่อเนื่อง...ด้วยการนำไอทีเข้าไปสนับสนุนและขับเคลื่อนธุรกิจ...แค่นั้นเอง


ผมขอแนะนำเว็บหนึ่งครับ 'Institute for Enterprise Architecture Developments' (http://enterprise-architecture.info) ไม่ใช่เว็บด้าน EA ที่ดีที่สุด แต่มีลิงค์เยอะดี ที่พี่ข้าวโพดหวานถามถึงการวัด ROI ลองดูลิงค์นี้นะครับ พูดถึงการประเมินผลการทำ EA เรียกว่า 'EA Scorecard' (http://enterprise-ar...ore Card UK.htm) เป็นตัวอย่างคร่าวๆ ส่วนการจะวัด ROI กับการลงทุนด้านไอทีจริงๆ สมัยนี้นิยมการวิเคราะห์ทางด้าน Earned Value Analysis, Value Creation, Value-Chain Analysis เป็นต้น เพราะทรัพยากรไอที (ไม่นับฮาร์ดแวร์) มีความเป็นนามธรรมสูงมาก (เหมือนเพลงและภาพยนตร์) จึงวัด ROI เป๊ะๆ ยาก

Edited by minimalist, 15 May 2011 - 08:26 PM.


#12 duckinbank

duckinbank

    Newbie

  • Members
  • Pip
  • 5 posts

Posted 15 February 2012 - 10:33 PM

อยากรู้ว่า นอกจาก Kbank แล้วมีธนาคาร หรือ องค์กรใหญ่ๆที่ไหนทำEA บ้างแล้วครับ

#13 minimalist

minimalist

    Star

  • Star
  • 895 posts

Posted 15 February 2012 - 11:36 PM

ขนาด KBank เองก็ยังไม่ได้อิมพลีเม้นต์ EA เต็มที่เท่าไหร่ครับ เพราะองค์กรใหญ่มาก ต้องค่อยเป็นค่อยไป

องค์กรอื่นๆ ในบ้านเราเยอะครับ  คือ ถ้าแต่ก่อนผมก็บอกได้ว่ามีใครบ้าง แต่ตอนนี้บอกไม่ได้จริงๆ ครับ มันเป็นความลับในหลายองค์กรครับ ไม่อยากเอ่ยชื่อในที่สาธารณะ เอาเป็นว่าเป็นพวกเทเลคอม ธนาคาร ฟู้ด หรือถ้าให้ง่ายลองค้นคว้าดูครับ องค์กรไทยที่มีการใช้ไอทีเยอะๆ หนักๆ ทันสมัยๆ อ้อ...ตัดพวกบริษัทซอฟต์แวร์เฮ้าส์ บริษัทไอทีออกไปเลยนะครับ! ไม่ว่าจะบริษัทไทย บริษัทนอก

ส่วนภาครัฐน้อยครับ ภาคเฮลธ์แคร์ก็น้อย แต่ก็มีเริ่มบ้างแล้วบางแห่ง


ก่อนจะทำ EA องค์กรต้องสร้าง Enterprise Architect จากคนภายในขององค์กรขึ้นมาให้ได้ก่อนครับ สิ่งที่หลายองค์กรเริ่มแล้วไปต่อไม่ได้ส่วนหนึ่งคือ ไม่มี Enterprise Architect หรือมีน้อยมากเกินไป กอปรกับองค์กรบ้านเราจำนวนไม่น้อยมีโครงสร้างองค์กรแบบ silo ใครทำ EA เป็นต้องเจอปัญหาการเมืองกับวัฒนธรรมองค์กรกันทั้งนั้นล่ะครับ ^_^ คนไทยเราก็ไม่ค่อยมีวินัย ผู้บริหารส่วนมากก็ไม่ค่อยเข้าใจไอที วิสัยทัศน์ก็สั้นเกินไปบ้าง ยาวเกินไปบ้าง ยิ่งถ้าจะทำ EA ยิ่งต้องทำ IT Governance ควบคู่กัน ไม่มีไม่ได้ ก็ยิ่งเลยเถิดไปกันใหญ่เพราะยากทั้งคู่
ส่วนเวนเดอร์ก็พึ่งไม่ได้สักเจ้าหรอกครับ :) มีแต่พวกรู้เรื่องแต่ทำไม่เป็น กับพวกทำพอเป็นแต่ไม่รู้เรื่อง? สุดท้ายลูกค้าก็โดดหลอกขายของ หรือโดนล้างสมอง ปีหนึ่งๆ มีเงินไหลออกไปนอกประเทศจากค่าไลเซนส์ซอฟต์แวร์และค่าฮาร์ดแวร์น่าจะเป็นแสนล้าน ภาครัฐก็หน่อมแน้ม ภาคการศึกษายิ่งแล้วใหญ่



พึ่งพาตนเองดีที่สุดครับ หากใครอยากทำ EA อย่าไปเที่ยวหาตัวอย่าง ไม่ต้องไปเที่ยวหา case study, best practices, templates อะไรนักหรอกครับ หากคิดจะทำ EA ต้องเลิกมองออกไปนอกองค์กร แต่ต้องหันกลับเข้ามามองภายในองค์กร! มองให้กว้างและให้ลึกที่สุด!

ลอง search ใน google  หาคำว่า IASA Thailand ดูครับ หาเบอร์ติดต่อแล้วโทรฯ ไปสอบถามดูครับ ว่ามีใครกำลังทำ EA อยู่บ้าง... หากได้ข้อมูลมาแล้วอย่าตกใจว่ามีหลายแห่ง ให้เอาความจริงมาหารด้วย 2 หรือ 3 ก่อน :)

#14 duckinbank

duckinbank

    Newbie

  • Members
  • Pip
  • 5 posts

Posted 16 February 2012 - 07:08 AM

ขอบคุณมากครับคุณminimalist ผมอยากหาข้อมูลและกำลังmapภาพabstract ในframework เป็น physical อยู่ครับ

ที่คุณminimalist บอกว่าทำEA ต้องค่อยเห็นค่อยไป อาจเป็นไปได้มั้ยครับว่าภาพ target architect ภาพแรกเป็นเพียงแค่ส่วนหึ่งขององค์กร และrequirement ไม่ครบ และเมื่อเราขยายขอบเขตของEA ก็จะรู้ถึงข้อบกพร่องของaภาพtarget architect แรก

ผมเข้าใจถูกมั้ยครับว่า processการทำEA เป็นการเน้นที่การทำการdesign แบบองค์รวมก่อนที่จะไปหาvendor เราต้องเข้าใจความต้องทางด้านprocess info และsystem ก่อน ซึงปกติถ้าไม่มีการทำEA ขั้นตอนการdesignจะเกิดหลัง จากการทำRFP

Edited by duckinbank, 16 February 2012 - 08:44 AM.


#15 minimalist

minimalist

    Star

  • Star
  • 895 posts

Posted 17 February 2012 - 02:38 AM

คุณ duckinbank เข้าใจเกือบถูกแล้วครับ งานด้าน architecture มีจุดยากมากๆ จุดหนึ่งคือ 'การระบุขอบเขต' หรือ boundary ที่แน่ชัดของงาน เพราะต้องดูทั้งอดีต ปัจจุบัน และต้องคาดการณ์ถึงอนาคต

ผมขอยกตัวอย่างเปรียบเทียบนะครับ เช่น องค์กรของเราชื่อประเทศไทย ภาพ architecture ให้นึกถึงรูปแผนที่ประเทศไทยบนกระดาษ A4 ซึ่งเราคงมองไม่เห็นบ้านของเราแน่ๆ แต่การเริ่มต้นทำ EA ต้องรวบรวมองค์ประกอบและเชื่อมโยงภาพรวมทั้งหมดให้ได้ก่อน ซึ่งอาจจะกว้างๆ เหมือนรูปแผนที่ประเทศไทยบนกระดาษ A4 จากนั้นพิจารณาความจำเป็นทางธุรกิจและความเสี่ยงมิติต่างๆ เช่น เวลา คน เงิน ว่าเราควรจะ 'เริ่ม' ทำเจาะตรงจุดไหนก่อนดี เช่น เราจะลงมือที่ business process ที่ชื่อว่า 'คมนาคม' ให้นึกถึงรูปแผนที่คมนาคมเส้นทางต่างๆ ทางเรือ รถไฟ รถยนต์ เครื่องบิน เราก็จะเห็นเส้นทางคมนาคมเป็นเส้นสีต่างๆ ลอยเด่นขึ้นมาบนรูปแผนที่เดิมบนกระดาษ A4 แต่มันก็ยังคงเล็กมากๆ อยู่ดี คราวนี้ตีกรอบโจทย์ให้แคบลงอีก โดยเจาะเฉพาะ 'คมนาคมขนส่งทางรถไฟสายใต้ตั้งแต่จังหวัดเพชรบุรีลงไป' ภาพแผนที่ก็จะซูมลงไปใช่ไหมครับ ในอีกทางหนึ่งคือ ภาพแผนที่บริเวณตั้งแต่เพชรบุรีลงไปจะยิ่งชัดขึ้น ละเอียดขึ้น และเราจะเห็นเส้นทางเดินรถไฟชัดขึ้น

ถ้าเราบอกว่าจังหวัดต่างๆ คือ หน่วยงานในองค์กร หากเรามองกดลงไป หรือลองจินตนาการเป็นภาพ 3 มิติดูครับ มองกดแบบเฉียงๆ เราจะเห็นทรัพยากรภายในแต่ละจังหวัด เช่น เราบอกว่า 'กรุงเทพฯ' และ 'แม่ฮ่องสอน' คือ Data Center ดังนั้นในสองจังหวัดนี้ก็ประกอบด้วยทรัพยากรไอทีจำนวนมาก

คราวนี้เราต้องดูแผนธุรกิจขององค์กร 'ประเทศไทย' ว่ามีวิสัยทัศน์มองไกลออกไปกี่ปี เช่น ในอนาคตข้างหน้าไม่เกิน 5 ปี เราจะขยายองค์กรออกไปด้วยการไป take over องค์กรกัมพูชา ลาว มาเลเซีย พม่า และสิงคโปร์ มันก็จะกลายเป็นว่าการทำ EA จะขยายวงออกไปครอบคลุมกว้างขึ้น คราวนี้ปัญหาคือ ตอนที่เริ่มต้นทำเราทราบแผนการณ์ของผู้บริหารที่จะขับเคลื่อนองค์กรต่อไปในอนาคตหรือไม่ เขาจะไปอย่างไร จะแผ่กว้างออกไป (horizontal) หรือจะเพ่ิมระดับความซับซ้อนในกรอบแนวนอนเท่าเดิมแต่สูงขึ้นไปและลึกลงไป (vertical) (คล้ายกับเพิ่มศักยภาพและคุณภาพขององค์กรให้มากขึ้น แต่ขอบเขตเท่าเดิม)

แล้วคิดดูว่าหากเราไม่ทราบว่าผู้บริหารคิดจะขยายไปถึงกัมพูชา ลาว มาเลเซีย พม่า และสิงคโปร์ และหากเราคิดว่าเราจะเริ่มทำส่วน 'คมนาคมขนส่งทางรถไฟสายใต้ตั้งแต่จังหวัดเพชรบุรีลงไป' ก่อน โดยเจาะลงไปขอบเขตส่วนนี้แต่แรกเลย โดยไม่มองภาพกว้างของประเทศไทยก่อน บางทีเราอาจลืมไปว่าพื้นที่ตั้งแต่จังหวัดเพชรบุรีลงไปมันไม่ได้มีแต่ 'รางรถไฟ' และตั้งแต่เพชรบุรีขึ้นไปจนถึงเชียงใหม่ เชียงราย มันมีกิจกรรม ทรัพย์สิน บุคลากร สินค้า บริการ ฯลฯ อะไรมากมาย และที่สำคัญคือมี coupling กับจังหวัดตั้งแต่เพชรบุรีลงไปด้วยมากมายมหาศาล เช่น business process และ IT process ที่เกี่ยวกับการท่องเที่ยว เกษตรกรรม ป่าไม้ อุตสาหกรรม ประมง การศึกษา สาธารณูปโภค ฯลฯ ที่ต่างยึดโยงกับไปหมดทั้ง 77 จังหวัด (77 หน่วยงาน)

แต่หากจะมองเก็บรายละเอียดทั้ง 77 จังหวัดตั้งแต่ต้นก็คงไม่ทันกิน งั้นก็ต้องมองภาพให้ abstract ขึ้น เป็นภาพเชิงซ้อนหลายภาพซ้อนกันมากขึ้น เช่น แบ่งพื้นที่ออกเป็นภาคแทน จาก 77 ก็ลดเหลือแค่ 5-6 เท่านั้น (เปลี่ยนจากการพิจารณาแบบ fine-grained เป็น  coarse-grained เพราะงานด้าน architecture มักพิจารณาแบบ coarse-grained มากกว่า)... แต่การแบ่งจังหวัดหรือภาคมันเป็นแค่แนวทางหนึ่ง เราอาจต้องแบ่งตามลักษณะภูมิศาสตร์ประกอบ หรือลักษณะภูมิอากาศ หรือวัฒนธรรม สังคม ฯลฯ ประกอบ เป็นภาพเชิงซ้อน (พยายามมองให้เป็น 3 มิติ) หากฝึกสร้างมุมมองแบบนี้ให้คล่อง พอไปมององค์กรจริงๆ จะง่ายขึ้นมาก เหมือนเฟรมเวิร์ก Zachman ที่แบ่ง Architecture View ออกเป็น 36 มุมมองไงครับ คือทั้ง 36 วิว (36 ภาพ) มันซ้อนกันอยู่นั่นเอง เหลื่อมๆ กันบ้าง ซ้อนๆ กันบ้าง...

สิ่งที่กล่าวมาเป็นการเปรียบเทียบ เผื่อให้เรามองภาพกว้างและเข้าใจ interoperation + impact ของระหว่างส่วนต่างๆ ในองค์กรแบบกว้างๆ abstractๆ ก่อน แล้วค่อยวาง Roadmap ว่าจะเจาะทำ EA ตรงไหนและเมื่อไหร่ดี แล้วจากนั้นค่อยทำเจาะที่ละจุดตาม Roadmap แล้วเริ่มจากวิเคราะห์สถานะปัจจุบัน (baseline หรือ as-is) แล้วระบุภาพในอนาคตที่อยากให้เป็นเมื่อผ่านการปรับปรุงแล้ว (target หรือ to-be) จากนั้นก็วิเคราะห์ gap แล้วมองหาโอกาส (opportunities) แล้วกำหนดโซลูชั่นที่เป็นไปได้ (หมายถึงน่าจะทำสำเร็จภายใต้ข้อจำกัดต่างๆ) จากนั้นก็วางแผนแล้วก็อิมพลีเม้นต์...

ตอนก่อนที่จะเริ่มอิมพลีเม้นต์ก็อาจทำ COTS Analysis ซึ่ง COTS หมายถึง Component Off-The-Shelf หรือ Commercial Off-The-Shelf ว่า จุดนี้เราจะทำเองดี หรือจ้างเขาดี อย่างไหนคุ้มกว่า มีประสิทธิภาพกว่า

ซึ่ง

Quote

ผมเข้าใจถูกมั้ยครับว่า processการทำEA เป็นการเน้นที่การทำการdesign แบบองค์รวมก่อนที่จะไปหาvendor เราต้องเข้าใจความต้องทางด้านprocess info และsystem ก่อน ซึงปกติถ้าไม่มีการทำEA ขั้นตอนการdesignจะเกิดหลัง จากการทำRFP
คุณ duckinbank เข้าใจถูกต้องแล้วครับ โครงการไอทีที่ทุกวันนี้มันชอบมีปัญหาเพราะชอบเขียน RFP หรือ TOR กันลวกๆ ยังไม่ได้วิิเคราะห์อะไรกันเท่าไหร่เลย... ขอบเขตแท้จริงมันเลยไม่ชัดเจน ไอ้ที่จบแบบไม่สวยมีฟ้องร้องกัน หรือมี change request ระหว่างโครงการตลอดก็เพราะสาเหตุนี้นี่แหละครับ

ให้มองว่าก่อนจะสร้างบ้าน เราก็ต้องหาสถาปนิกมาออกแบบมาปรับแบบมาประเมินราคากันก่อน จากนั้นค่อยหาผู้รับเหมา ซึ่งเขาก็มีทั้งวิศวกรและช่างก่อสร้างมาออกแบบรายละเอียด (detailed design) และสร้างกลไก (โมดูล) ต่างๆ แล้วจบลงด้วยการตกแต่งภายใน แต่งานไอทีดันไม่ค่อยมีงานตกแต่งภายใน ส่วนมากที่ทำกันคือ 'รื้อ' ระบบที่ทำเสร็จแล้วมันต้องตกแต่งได้ทั้งภายนอกภายใน โดยไม่ไปกระทบโครงสร้างหลัก เพื่อจะได้ serve กับ business need ที่อาจเปลี่ยนไปมาได้ และมักชอบเปลี่ยนรวดเร็วแล้วมาขอให้ไอทีปรับเร็วๆ ตาม :)

ตอบแบบอ้อมๆ หน่อยนะครับ คงพอเป็นไอเดียได้ :)

Edited by minimalist, 17 February 2012 - 02:56 AM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users