Service-Oriented Architecture and Enterprise Architecture Part1

September 7th, 2010 by champillon 11 comments »

PS. อ้างอิงและสรุปจาก Link นี้ครับ —> http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise1/index.html

ซึ่ง Article ในชุดนี้มี 3 ตอนครับ และผู้แปลไม่ได้ใส่ความเห็นลงไปใน Article นี้เลย

Part1: A framework for understanding how SOA and Enterprise Architecture work together

แนวคิด SOA และ EA นั้นเป็นแนวคิดที่มีการมองระบบไอทีในภาพรวมเหมือนกัน แต่แตกต่างกันที่มุมมอง

ซึ่งบทความนี้พยายามแสดง เปรียบเทียบ ชี้นำปัญหาและเสนอแนวทางการแก้ปัญหา ในการประยุกต์ใช้ร่วมกันของ 2แนวคิดนนี้

โดยประเด็นหลักๆที่เกิดขึ้นในการประยุกต์ใช้ 2แนวคิดนี้ร่วมกันก็อย่างเช่น

- ขอบเขตของ EA และ SOA และจุดที่ทับซ้อนกัน

- ความสัมพันธ์ระหว่าง SOA Center of Excellent (CoE) และ EA governance boards

- ความรับผิดชอบและผู้ดูแลของ SOA Infrastructure เช่น ESB นั้นควรจัดอยู่ในส่วนไหนของ Enterprise Infrastructure และมันควรใช้เฉพาะ SOA หรือไม่

ก่อนจะกล่าวถึงความเหมือนและแตกต่างของ 2แนวคิดนี้นั้น ขอเริ่มด้วยการอธิบายนิยามและมุมมองของ 2แนวคิดนี้ก่อนครับ

» Read more: Service-Oriented Architecture and Enterprise Architecture Part1

Starbucks ไม่ใช้ 2-phase-commit

August 25th, 2010 by roofimon 2 comments »

แปลมาจาก Starbucks Doesn’t use two phase commit
Hotto Cocoa o Kudasai
ผมเพิ่งกลับมาจากทริปญี่ปุ่นได้สองสัปดาห์ ระหว่างการเดินทางที่ญี่ปุ่นครั้งนี้มีสิ่งหนึ่งที่ผมคุ้นตามากมันคือสัญลักษณ์รูป ทรงกลมเขียวอันเป็นเอกลักษณ์ของ Starbucks นั่นเองโดยเฉพาะแถวๆเขต Shinjuku และ Roppongi และระหว่างที่ผม รอรับเครื่องดื่ม “Hotto Cocoa” ของผมผมก็สังเกตเห็นอะไรบางอย่างในกระบวนการจัดการ Order ของ Starbucks แนวคิดหลักของ Starbucks และธุรกิจอื่นๆคือการรับ Order ให้ได้มากที่สุดเท่าที่จะมากได้เพราะยิ่งรับ Order มากเท่าไหร่มันหมายถึงรายได้ที่เพิ่มขึ้นมาตามจำนวน นั่นเป็นสาเหตุให้ Starbucks เลือกใช้กระบวนการจัดการ Order แบบ Asynchornous ถ้าเราลองนึกภาพตามการสั่งกาแฟที่ Starbucks จะเริ่มจากเราสั่งกาแฟที่ cashier จากนั้น cashier จะจดรายการนั้นลงไปที่แก้วแล้ววางไว้ที่ Queue ระหว่างเครื่องชงซึ่ง Queue นี้เป็นปัจจัยหลักที่ทำให้ Cashier สามารถทำงานเป็นอิสระ (Decouple) จาก Barista ซึ่งจะทำให้ Cashier สามารถรับ Order ต่อไปได้เรื่อยๆโดยไม่ต้องสน ใจว่า Barista จะยุ่งขนาดไหนหรือเราสามารถมีจำนวน Barista ที่เพิ่มขึ้นได้ในกรณีที่ร้านยุ่งมากๆ
Correlation
อย่างไรก็ตามในเมื่อ Starbucks สามารถใช้ประโยชน์ของการจัดการ Order แบบ Asynchronus แล้ว Starbucks เองก็ยังต้องแก้ปัญหาที่มีมากับการทำงานแบบ Async เช่นเรื่องของ Correlation เนื่องจากกาแฟที่เราสั่งไปไม่สามารถทำ ให้เสร็จได้ที่ cashier เลยนั่นหมายความว่ามันต้องถูกส่งต่อไปให้ Barista เป็นคนทำ และในกรณีที่เรามี Barista หลายๆคนแต่ละคนก็อาจจะต้องทำงานกับเครื่องชงกาแฟหลายๆแบบผมที่ตามมาคือระยะเวลาในการทำจะไม่ท่ากันเช่นกาแฟที่ต้อง Blend ต้องใช้เวลานากว่ากาแฟสำเร็จ หรือ Barista อาจจะทำการรวบ Order หลายๆอันมาทำในครั้งเดียว กันเพื่อเพิ่มความเร็วในการทำงาน ผลคือปัญหาเรื่อง Correlation จะเกิดขึ้นเพราะการส่งกาแฟออกมาจะไม่ตรงตาม ลำดับของการสั่ง ซึ่ง Starbucks แก้ปัญหานี้ด้วยการใช้ pattern ที่อยู่ในกลุ่มของ messaging architecture นั่นคือ Correlation Identifier เราจะเห็นได้จากจังหวะการสั่งพนักงานที่ cashier จะจดชื่อของเราลงไปบนแก้วและจะเรียกชื่อเจ้า ของเมื่อ order เสร็จแต่ในบางประเทศอาจใช้ชื่อเครื่องดื่มแทน แต่ยังยังไม่พอยังมีอย่างอื่นอีกนั่นคือ Exception Handling
Exception Handling
การทำ Exception Handling ในมุมของ Async เป็นเรื่องยากระดับคลาสสิค ดังนั้นเพื่อให้เคสนี้ต่อเนื่องกันเราจะมาดูวิธี การจัดการกับ Exception ของ Starbucks กัน เร่ิมจากการยกตัวอย่าง พนักงานจะทำอย่างไรถ้าเราไม่สามารถจ่ายเงินได้ ? การแก้ปัญหาคือเททิ้งถ้ากาแฟแก้วนั้นทำเสร็จแล้ว หรือถ้ายังก็ทำแค่เพียงดึงแก้วออกจาก Queue แต่ถ้ากาแฟถูก ทำผิดไม่ตรงตามคำสั่งพนักงานก็ทำใหม่ แต่ถ้าเครื่องทำกาแฟพังก็ไม่ยาก “คืนเงิน” นี่เป็น Scenario มาตรฐานที่เกิดเสมอในร้านกาแฟแต่ถ้าเราจัดกลุ่มการทำงานเราจะพบว่าเราสามารถจำแนกได้ตามนี้
1.Write-off – นี่เป็นการจัดการกับปัญหาที่ตรงไปตรงมาและง่ายที่สุดคือ “ปล่อยมันไป” แนวทางนี้นิยมมากกับปัญหาที่ไม่ส่งผลกระทบกับรายได้มากนักและไม่คุ้มที่จะสร้างระบบที่ใช้จัดการ Exception ยกตัวอย่างเช่น ISP บางเจ้าจะไม่สนใจ Error ที่เกิดขึ้นในขั้นตอนของการทำ Billing/Provisioning ดังนั้นจึงมีความเป็นไปได้ที่ลูกค้าจะได้ใช้บริการโดยไม่ถูกเรียกเก็บเงิน เนื่องจากรายได้ที่เสียไปไม่กระทบกับภาพ รวมของระบบทั้งหมด อย่างไรก็ตามสุดท้ายจะมีการสร้าง report สำหรับการทำ reconciliation ตามเวลาที่กำหนดเพื่อปิดบริการฟรีเหล่านั้น
2.Retry – order ใหญ่เกิดขึ้นจากการประกอบของ order ย่อยๆ เรามีทางเลือกสองทางคือหนึ่งยกเลิกอันที่ทำไปแล้ว หรือพยายามทำอันที่ล้มเหลวจนสำเร็จ ทางแรกเป็นทางเลือกที่ดีในกรณีที่ความเป็นไปได้ในการทำใหม่ให้สำเร็จ สูงมาก ซึ่งเราสามารถนำเอาแนวคิดเรื่อง Idempotent Receiver เข้ามาใช้ได้คือไม่ว่าเราจะพยายามทำ order เก่าซ้ำกันกี่ครั้งก็ตาม เราจะไม่เจอปัญหาเรื่อง duplicate message เลย
3.Compensating Action – ทางเลือกสุดทายคือ undo งานที่ทำเสร็จแล้วเพื่อทำให้ ระบบย้อนกลับไปสู่สถานะเดิม ทางเลือกนี้เหมาะสมกับระบบที่รองรับการทำานในเรื่องของการทำ re-credit ได้

เราจะเห็นว่าการรับมือกับ Exception แบบนี้ต่างกับ two-phase commit เนื่องจาก asynchronous จะทำการแยก prepare และ excecute ออกจากกันถ้าดังนั้นถ้าเรามองกลับไปที่ Starbucks เราจะพบว่าเราจต้องรอที่ cashier พร้อมกับ reciept และเงินจนกว่ากาแฟจะชงเสร็จ ซึ่งจะเห็นได้ว่าในกรณีนี้ทั้ง cashier และลูกค้าจะไม่มีใครสามารถละจากตำแหน่ง ของตัวเองได้เลยจนกว่า Transaction นั้นจะสำเร็จ ซึ่งถ้า Starbucks เลือกใช้เทคนิคแบบ Two-Phase-Commit กับธุรกิจ ตัวเองมันอาจจะส่งผลให้เกิดการขาดทุนหรือล้มเหลวได้สูงมากเนื่องจากระบบจะไม่สามารถรองรับจำนวนลูกค้าได้เป็นปริมาณมากๆ นี่จึงเป็นอีกหนึ่งตัวอย่างที่เราจะเห็นได้ว่า Two-Phase-Commit ทำใหชีวิตเราง่ายขึ้นแต่มันก็ทำให้เราไม่ สามารถเป็นอิสระจากกระบวนการส่ง message ได้เนื่องจากเราต้องจัดการ state ของระบบไปตลอดเวลา
Conversations
ตัวอย่างของการมีปฎิสัมพันธ์กันในร้านกาแฟเป็นตัวอย่างที่เหมาะกับ Conversation Pattern มากๆซึ่งเราจะเห็นได้ว่าจริงๆแล้วการสื่อสารระหว่างคนสองกลุ่มนี้ประกอบไปด้วย Short Synchronous เช่นการทำ order และการจ่ายเงินและอีกส่วนคือ Long Asynchronous เช่น การทำกาแฟและการรับกาแฟ ซึ่งเราสามารถนำกระบวนการที่เกิดขึ้นนี้ไปประยุกติ์ใช้กับการทำธุรกรรมแบบอื่นๆอีกก็ได้เช่นกันเช่น การสร้าง order ใน amazon เราจะเห็น short synchronous เช่นการกำหนด Order Number ส่วนกระบวนการที่เหลือจะกลายเป็น Asynchronous ทั้งหมดไม่ว่าจะเป็น charging, packaging และ shipping หลังจากนั้นเราจะได้รับอีเมล์ยืนยันจาก amazon ทันทีเมื่อการทำ Transaction สำเร็จลง และในกรณีที่เกิดปัญหานั้น Amazon จะแจ้งเตือนเราผ่าน email (Async) หรือแม้กระทั่งกระบวนการ Refund ก็ทำในลักษณะเดียวกันไม่ว่าจะเป็นการจ่ายเงินคืนหรือการพยายามส่งสินค้าชิ้นใหม่แทนชิ้นเก่าที่ส่งไม่สำเร็จ
สรุปว่าในโลกแห่งความเป็นจริงเราจะเห็น Scenario ต่างๆที่เป็น Asynchronous มีมากมาย ในกระบวนทำงานต่างๆของเราไม่ว่าจะเป็นการอ่าน การตอบ email การซื้อกาแฟ ดังนั้น asynchronous messaging architecture จึงเป็นรูปแบบที่สามารถนำไปใช้งานได้อย่างเป็นธรรมชาติมากกว่า เราสามารถนำเอากระบวนการในชีวิตประจำวันของเรามาช่วยเพื่อให้เกิดความสำเร็จในการออกแบบเรื่องของ messaging ได้เป็นอย่างดี “Domo arigato gozaimasu! ”

สร้าง RESTFul WS ด้วย Spring MVC3

August 10th, 2010 by roofimon No comments »

Introduction
ไม่ recap เรื่อง REST แล้วนะครับเพราะเขียนเรื่องแนวคิดไปสองสามบทความแล้วครับเราเข้าเรื่องกัน เลยว่านอก จากการใช้ RESTEasy, Jersey แล้วเรายังสามารถใช้ SpringMVC3 เพื่อสร้าง RESTFul Service ได้เหมือนกันครับ
ก่อนอื่น sourcecode ทั้งหมดอยู่ที่นี่ครับ https://restfulspringmvc3.googlecode.com/svn/trunk/
Spring 3 REST support
ก่อนที่ Spring จะรองรับการทำ REST เราสามารถเลือกใช้ Framework อื่นๆเช่น Restlet, RestEasy, และ Jersey เพื่อนำมาสร้าง RESTFul ws ขึ้นมาโดยที่ Framework เหล่านี้จะ implement อยู่บนมาตรฐาน JAX-RS (JSR 311)
ปัจจุบัน Spring3 ได้ทำการรวมเอาความสามารถเรื่อง RESTFul WS เข้ามาไว้ในตัวเรียบร้อยแต่วิธีการสร้าง REST ของ Spring3 จะไม่เป็นไปตามมาตรฐาน JAX-RS ซึ่งทีมสร้างเองยืนยันว่า Spring3 มีความสามารถมากกว่า JAX-RS เช่นการ intergrate เข้ากับ SpringMVC แบบ seamless สิ่งที่เราต้องทำมีเพียงแค่ใส่ Annotation เข้าไปที่ Controller เช่น:

  • Annotations, @RequestMapping และ @PathVariable, ถูกเตรียมไว้สำหรับการทำ resource identification และ URI mappings
  • ContentNegotiatingViewResolver มีไว้สำหรับการสร้าง representations ที่เหมาะสมกับ MIME/content types
  • Integrate กับ Spring Web MVC ได้อย่างสวยงาม

เรามาเริ่มกันเลยดีกว่าครับอันดับแรกให้ สร้าง Spring Web Project ด้วย Eclipse ก่อน (หาทำเอาเองนะครับ) อันดับแรกเราจะสร้าง model ก่อนซึ่งในที่นี้คือ class Employee โดยมีรายละเอียดดังนี้

@XmlRootElement(name="employee")
public class Employee {
   private long id;
   private String name;
   private String email;

   public Employee() {}

   public Employee(long id, String name, String email) {
      this.id = id;
      this.name = name;
      this.email = email;
   }
   .. get/set...

ส่วนต่อไปคือการสร้าง ส่วนที่เรียกว่า Utility Class ที่ทำหน้าที่ื Wrap Employee อีกชั้นหนึ่ง

@XmlRootElement(name="employees")
public class EmployeeList {
   private int count;
   private List<Employee> employees;

   public EmployeeList() {}

   public EmployeeList(List<Employee> employees) {
      this.employees = employees;
      this.count = employees.size();
   }

   public int getCount() {
      return count;
   }

   public void setCount(int count) {
      this.count = count;
   }

   @XmlElement(name="employee")
   public List<Employee> getEmployees() {
      return employees;
   }
   public void setEmployees(List<Employee> employees) {
      this.employees = employees;
   }

เมื่อเราได้ model และ util class แล้วต่อไปเราจะสร้าง service ขึ้นมาครอบสองสิ่งนี้ไว้และเราจะผูก service นี้เข้ากับ controller เพื่อรับหน้าที่จัดการการข้อมูลของ employee ทั้งหมดที่จะมีอยู่

public class EmployeeDS {

	private static Map<Long, Employee> allEmployees;
	static {
		allEmployees = new HashMap<Long, Employee>();
		Employee e1 = new Employee(1L, "Huang Yi Ming", "huangyim@cn.ibm.com");
		Employee e2 = new Employee(2L, "Wu Dong Fei", "wudongf@cn.ibm.com");
		allEmployees.put(e1.getId(), e1);
		allEmployees.put(e2.getId(), e2);
	}

	public void add(Employee e) {
		allEmployees.put(e.getId(), e);
	}

	public Employee get(long id) {
		return allEmployees.get(id);
	}

	public List<Employee> getAll() {
		List<Employee> employees = new ArrayList<Employee>();
		for( Iterator<Employee> it = allEmployees.values().iterator(); it.hasNext(); ) {
			Employee e = it.next();
			employees.add(e);
		}
		return employees;
	}

	public void remove(long id) {
		allEmployees.remove(id);
	}

	public void update(Employee e) {
		allEmployees.put(e.getId(), e);
	}

ส่วนต่อมาคือสิ่งที่สำคัญมากๆ เราจะสร้าง Controller ขึ้นมาพื่อทำหน้าที่รองรับ request จากผั่ง client ซึ่งใน application นี้เราออกแบบให้ระบบของเรารองรับการทำงานผ่าน URI ทั้งหมด 5 แบบดังนี้

  • GET /enployees = เอาข้อมูล employee ออกมาทั้งหมด
  • GET /employee/id = เอาข้อมูล employee ที่มี่ id ตามที่ต้องการออกมา
  • PUT /employee/id = แก้ไขข้อมูล employee ที่มี id ตามที่ต้องการ
  • POST /employee = สร้าง employee ใหม่
  • DELETE /employee/id = ลบข้อมูล employee ที่มี id ตามที่ต้องการ

ดังนั้นเราจะสร้าง controller ขึ้นมาให้มีรายละเอียดการทำงานได้ปรมาณนี้ครับ ซึ่งเราสามารถทำได้ง่ายมาก


@Controller
public class EmployeeController {

	private EmployeeDS employeeDS;

	public void setEmployeeDS(EmployeeDS ds) {
		this.employeeDS = ds;
	}

	private Jaxb2Marshaller jaxb2Mashaller;

	public void setJaxb2Mashaller(Jaxb2Marshaller jaxb2Mashaller) {
		this.jaxb2Mashaller = jaxb2Mashaller;
	}

	private static final String XML_VIEW_NAME = "employees";

	@RequestMapping(method=RequestMethod.GET, value="/employee/{id}")
	public ModelAndView getEmployee(@PathVariable String id) {
		Employee e = employeeDS.get(Long.parseLong(id));
		return new ModelAndView(XML_VIEW_NAME, "object", e);
	}

	@RequestMapping(method=RequestMethod.PUT, value="/employee/{id}")
	public ModelAndView updateEmployee(@RequestBody String body) {
		Source source = new StreamSource(new StringReader(body));
		Employee e = (Employee) jaxb2Mashaller.unmarshal(source);
		employeeDS.update(e);
		return new ModelAndView(XML_VIEW_NAME, "object", e);
	}

	@RequestMapping(method=RequestMethod.POST, value="/employee")
	public ModelAndView addEmployee(@RequestBody String body) {
		Source source = new StreamSource(new StringReader(body));
		Employee e = (Employee) jaxb2Mashaller.unmarshal(source);
		employeeDS.add(e);
		return new ModelAndView(XML_VIEW_NAME, "object", e);
	}

	@RequestMapping(method=RequestMethod.DELETE, value="/employee/{id}")
	public ModelAndView removeEmployee(@PathVariable String id) {
		employeeDS.remove(Long.parseLong(id));
		List<Employee> employees = employeeDS.getAll();
		EmployeeList list = new EmployeeList(employees);
		return new ModelAndView(XML_VIEW_NAME, "employees", list);
	}

	@RequestMapping(method=RequestMethod.GET, value="/employees")
	public ModelAndView getEmployees() {
		List<Employee> employees = employeeDS.getAll();
		EmployeeList list = new EmployeeList(employees);
		return new ModelAndView(XML_VIEW_NAME, "employees", list);
	}
}

ส่วนที่น่าสนใจสำหรับ Controller คือ @RequestMapping เราจะใช้มันเป็นตัวกำหนดหน้าที่ของแต่ละ function ให้ controller ไม่ว่าจะเป็น HTTP Method หรือ URI ที่จะใช้ร่วมกันซึ่งถึงตรงนี้เราได้องค์ประกอบพื้นฐานทั้งหมดครบแล้วไม่ว่าจะเป็น model, util, controller ต่อไปเราจะต้อง config ทั้งสามสิ่งให้ทำงานร่วมกันผ่าน configuration file ของ spring โดยผมใช้ชื่อ application-context.xml

<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation=...
	<bean id="employeeDS" class="dw.spring3.rest.ds.EmployeeDS" />
</beans>

ส่วนต่อไปคือการกำหนดรายละเอียดการทำงานของ controller โดยเราจะกำหนดไฟล์ rest-servlet.xml

	<bean id="jaxbMarshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
		<property name="classesToBeBound">
			<list>
				<value>dw.spring3.rest.bean.Employee</value>
				<value>dw.spring3.rest.bean.EmployeeList</value>
			</list>
		</property>
	</bean>

	<bean id="employees" class="org.springframework.web.servlet.view.xml.MarshallingView">
		<constructor-arg ref="jaxbMarshaller" />
	</bean>

	<bean id="employeeController" class="dw.spring3.rest.controller.EmployeeController">
		<property name="employeeDS" ref="employeeDS" />
		<property name="jaxb2Mashaller" ref="jaxbMarshaller" />
	</bean>

ส่วนที่น่าสนใจมีสามส่วนคือส่วนที่เรากำหนด class สองคลาส Employee, EmployeeList ให้กับ jaxbMarshaller เนื่องจากเราจต้องการทำทั้งการ Bind และ Unbind ทั้งสองนี้ในระหว่างการทำงานตลอดเวลา ส่วนที่สองคือการกำหนด jaxbMarshaller ให้กับ employess และการผูก employeeDS และ jaxb2Mashaller ให้กับ employeeController เมื่อเราทำได้ทั้งหมดนี้แล้วต่อไปคือเราจะทดสอบกันแล้วว่ามันทำงานได้จริงไหมด้วยการเขียน main class ง่ายๆ

public class App {
    public static void main(String[] args) throws IOException {
        DefaultHttpClient client = new DefaultHttpClient();
        HttpGet get = new HttpGet("http://localhost:8080/service/employee/2");
        get.addHeader("accept", "application/xml");
        HttpResponse response = client.execute(get);
        if (response.getStatusLine().getStatusCode() != 200) {
            throw new RuntimeException("Operation failed: "
                    + response.getStatusLine().getStatusCode());
        }
        System.out.println("Content-Type: "
                + response.getEntity().getContentType().getValue());
        BufferedReader reader = new BufferedReader(new InputStreamReader(response.getEntity().getContent()));
        String line = reader.readLine();
        while (line != null) {
            System.out.println(line);
            line = reader.readLine();
        }
        client.getConnectionManager().shutdown();
    }
}

ที่เหลือไปเขียนเอาเองนะครับ :) เพราะ work แน่นอน ง่ายจริงๆ

Introduction to Master Data Management

July 14th, 2010 by roofimon 8 comments »

ที่มาของเอกสารนี้มาจาก http://www.dataflux.com ผมอ่านและสรุป ตัดออกบ้าง
เกริ่นก่อ

ในโลกยุคปัจจุบันที่เป็นยุคแห่งการแข่งขันเรื่องข้อมูลข่าวสาร การแลกเปลี่ยนข้อมูลข่าวสารระหว่าง แผนก,องค์กร เป็นเรื่องที่เกิดขึ้นกันเป็นปกติเนื่องจากยิ่งมีการเชื่อมต่อระหว่างพันธมิตรมีมากเท่าไหร่ก็ทำให้เรามีความได้เปรียบทางการ แข่งขันมากขึ้นเท่านั้น แต่อย่างไรก็ตาม เราพบว่ายิ่งเราพยายามแบ่งปันข้อมูลมากขึ้นและการแยกการประมวลผลข้อมูลของแต่ละกลุ่มของ ธุรกิจให้อิสระต่อกันให้มากขึ้น สองสิ่งนี้นำเราไปสู่การสร้างกลุ่มของการประมวลผลที่ผูกติดแน่นต่อกัน โดยที่แต่ละกลุ่มจะมีข้อมูลบางชุดที่ใช้งานเหมือนๆกันโดยที่แต่ละกลุ่มเองก็จะมีโครงสร้าง definition,dictionary ที่เป็นของตัวเองโดยอิงกับความต้องการทางธุรกิจของตัวเอง
ผลสืบเนื่องต่อมาอีกคือในองค์กรขนาดใหญ่เราจะพบว่าจะมีการเก็บข้อมูลที่ดูเหมือนว่าจะเป็นข้อมูลของสิ่งๆเดียวกันในหลายๆที่ โดยที่แต่ละที่จะมีองค์ประกอบของข้อมูลที่แตกต่างกันเล็กน้อย และมีซ้ำกันทั้งใน Operational และ Analytical process และตอบไม่ได้ว่าถ้าเราต้องการข้อมูลที่ถูกต้องที่สุดเราต้องไปหยิบจากระบบไหน
ดังนั้นเพื่อเป็นการแก้ปัญหานีองค์กรเหล่านั้นจะต้องหาวิธีที่จะนำมาใช้สำหรับ การแยกแยะข้อมูล อธิบายมุมมองของการใช้งานข้อมูลในกลุ่มธุรกิจต่างๆ รวมไปถึงการควบรวมข้อมูลเหล่านั้นเพื่อให้ข้อมูลเหล่านั้นสามารถถูกนำกลับไปใช้งานโดยหน่วยงานต่างๆได้เหมือนเดิม ซึ่งจะส่งผลให้องค์กรมีความสามารถในการ จัดการและบริหารข้อมูลได้อย่างมีประสิทธิภาพมากขึ้น
อย่างไรก็ตามหลังจากโลกไอทีของเราย้ายฝั่งไปที่ฝั่ง Distributed ระยะหนึ่งตอนนี้มันกำลังย้ายกลับมาที่ฝั่งของ Centralized เราเริ่มเห็นแนวโน้มแล้วจากระบบที่เป็นหัวใจสำคัญเช่น Data Warehouse ที่มีการปล่อยให้ข้อมูลเกือบทั้งหมดขององค์กรไหลเข้าสู่ระบบ DW และทำการ Transform และ Cleansing เพื่อนำไปทำการออก Analytical Report แต่อย่างไรก็ตามกระบวนการ Transform และ Cleansing นั้นส่งผลกระทบให้ข้อมูลที่นำไปใช้ออก Report ไม่สอดคล้องกับข้อมูลต้นทาง นี่จึงเป็นอีกเหตุผลที่ส่งเสริมให้องค์กรควรจะสร้างสิ่งที่เรียกว่า Single Source of Truth สำหรับข้อมูลบางกลุ่มขึ้นมาสำหรับทุกๆส่วนขององค์กร ไม่ใช่เพียงเพื่อทำ Analytical Report เท่านั้นและนี่เองเป็นจุดเริ่มต้นของการทำ Master Data Mangement
เพื่อให้เห็นภาพมากขึ้นเราจะดูตัวอย่างเพื่อให้เห็นภาพมากขึ้นเช่นเราลองนึกภาพถึงเรื่องของ customers เรามักจะพบเสมอว่าจะมีการใช้งาน customers กระจายไปใน domain ต่างๆของธุรกิจไม่ว่าจะเป็น Sales, Finance, Customer Services โดยที่คำว่า Customers ในแต่ละ Domain จะมีลักษณะการมองและรายละเอียดที่แตกต่างกันบ้าง นอกจากนี้ customers ในบางกรณีก็ไปเกี่ยวเนื่องกับมุมอื่นอีกเช่นบางครั้งอาจจะไปเป็น Vendors, Suppliers ดังนั้นจากความแตกต่างที่กล่าวขึ้นมา ทำให้เกิดข้อแม้สองข้อในการทำงานคือ หนึ่งเราจะรู้ได้อย่างไรว่าการทำงาน ของเราจะไม่เกิดความผิดพลาด จากกรณีที่มีความแตกต่างของข้อมูลของ Customers ในจุดต่างๆและข้อมูลต่างๆเหล่า นั้นจะถูกต้องหรือไม่เมื่อเรานำมันไปประมวลผลเพื่ออก Report
ดังนั้นในเมื่อการบันทึกธุรกรรมต่างๆนั้นถูกกระทำไปโดยมองจากมุมของธุรกิจที่แตกต่างกัน ดังนั้นเพื่อแก้ไขปัญหาเรา สามารถสรุปทางออกได้สองข้อ
1 ทำการ intergrate ข้อมูลชุดต่างๆที่ใช้ร่วมกันเข้ามาให้เหลือเพียงจุดเดียว (หรือเสมือนจุดเดียว)
2 ทำให้ application ต่างๆมองเห็นข้อมูลในมุมมองเดียวกันทั้งระบบ
ต่อไปเราจะมาดูกันว่าคำว่า “Master Data” ทีแท้แล้วคืออะไรถ้าให้อธิบายแบบง่ายที่สุด Master Data คือชุดของข้อมูลที่ถูกใช้งานข้ามระบบในองค์กรเช่น Customer, Product, Service, Part, Suppliers, Location ยกตัวอย่างเช่นถ้าหนึ่ง Transaction ที่เกิดขึ้นในระบบสามารถเขียนได้เป็นคำพูดดังนี้ “David Loshin purchased seat 15B on US Airways flight 238 from Baltimore(BWI) to San Francisco(SFO) on July 20, 2010” เราอาจจะแยกเอา Master Data ออกมาได้หลายตัวจาก Transaction นี้เช่น
Customer: David Loshin
Product: seat 15B
Flight: 239
Location: BWI
Location: SFO

ถ้าเราหยิบแค่ Customer มาดูในระบบเราอาจะมี David Loshin ในหลายๆที่และหลายมุมมองด้วยเช่น

แล้ว Master Data Management คืออะไร
MDM คือส่วนประกอบของ Business Application, Methods และ Tools สามสิ่งนี้ทำให้เกิด Policies, Procedures และ Infrastructures เพื่อทำให้เกิดการรวมศูนย์ข้อมูลในองค์กรและทุกๆส่วนขององค์กรสามารถเข้าถึงข้อมูลที่ถูกต้อง มีความเที่ยงตรง มีขนาดกระทัดรัดได้เหมือนกัน

ดังนั้นเราจะมอง MDM ไม่ใช่เป็นแค่เทคโนโลยีเพียงอย่างเดียวมันคือกระบวนการที่ประกอบไปด้วยขั้นตอนหลักๆดังนี้
ประเมินและสำรวจการใช้งาน Core Information Object, Data Value Domain และ Business Rules ของ Application ที่สำคัญๆ(ก่อน) ของทั้งองค์กร

  • ทำการระบุ Master Data โดยการเลือกเอา Business Process ที่สำคัญต่อองค์กรหลายๆตัวเป็นหลักและดูว่าส่วนไหนที่ทำ เป็น Centralize แล้วจะเกิดประโยชน์สูงสุด
  • ทำการร่าง Standard Model โดยการหาส่วนที่ซ้ำกันของ Data จาก Business Process และ Application ที่เราเลือกไว้
  • ข้อมูลที่เป็น Master Data จะต้องถูกจัดการให้สามารถเข้าถึงได้ จากทุกส่วนขององค์กรที่มีความจำเป็นต้องใช้งานและ กำหนดให้มันเป็นหนึ่งในเครื่องมือของการทำ Consolidation
  • สร้างถังเก็บข้อมูลกลาง โดยการทำการรวบรวมและ Harmonize เพื่อสร้าง unique instance
  • ทำการ integrate ข้อมูลที่ถูก harmonized แล้วเข้ากับ application เดิมที่มีอยู่หรือ application ใหม่ที่กำลังจะถูกสร้าง ผ่านทาง Service Oriented Architecture
  • ข้อสุดท้ายที่สำคัญที่สุดคือการสร้างกฎและข้อบังคับขึ้นในระดับองค์กรในเรื่องของการใช้งาน Master Data เพื่อให้มันทำ หน้าทีรักษาความถูกต้องของข้อมูลต่อไปในอนาคต

Architecture Approach to MDM
หลังจากที่เราได้เห็นขั้นตอนและกระบวนการทำ MDM แล้วส่วนต่อมาคือพิจรณา Architecture Approach ที่เหมาะสมกับองค์กรของเราซึ่งปัจจุบันนี้มีอยู่ 3 approaches ด้วยกันคือ Central Master Data System, Mapped Master System และ Hub Repository เรามาดูตัวแรกกันก่อน
Central Master Data System: วิธีการนี้จะเป็นการนำเอา attributes ต่างๆของข้อมูลที่่ถูกใช้ร่วมกันในองค์กร มารวมกันไว้ในที่ที่เดียวเป็น Master System และเจ้า Master system นี้จะทำหน้าที่ publish ข้อมูลออกไปให้กับระบบ ต่างๆที่ต้องการใช้ข้อมูล โดยระบบปลายทางมีหน้าที่ที่จะต้องจัดการ attributes อื่นๆที่ไม่อยู่ในกลุ่มของ Master Data เอง ในกรณีของการสร้างข้อมูลใหม่นั้นจะถูกทำที่ระบบปลายทางและหลังจากนั้นจะต้องมีการ Sync ข้อมูลกลับมาที่ Master System เสมอและข้อมูลทั้งหมดจะต้องสามารถถูกอ้างได้ถึงกันหมดผ่าน Global ID

Mapped Master System: วิธีการนี้จะแตกต่างจากแบบแรกคือเราจะต้องตัดสินใจเลือกก่อนว่าระบบใดจะเป็นเจ้าของ ข้อมูลก่อนเช่น CRM เป็นเจ้าของข้อมูล Customer และ Product ดังนั้นกรพบวนการสร้างข้อมูลสองอย่างนี้ต้องทำที่ CRM ก่อนแล้วจะทำการ Publish ออกไปให้กับระบบปลายทางใช้งานแต่อีกสิ่งหนึ่งที่ทำให้แตกต่างจาก Central Master คือวิธีแบบนี้จะไม่มี Global ID ระบบจะทำการ transform ข้อมูลที่จะส่งไปให้กับระบบปลายทางให้อยู่ในรูปแบบที่ต้องการ นอกจากนี้ระบบปลายยังสามารถเพิ่ม attributes ที่ตัวเองต้องการเข้าไปได้อีกเช่นกัน

Hub Repository: วิธีการนี้เป็นแบบ Extreme คือมีที่เก็บข้อมูลที่เดียวคือ Master Data Hub และจะไม่มีการ Replicate ข้อมูลไปที่ระบบอื่นๆเลยดังนั้นการสร้างการแก้ไขใด้ๆก็ตามต้องส่งมาทำที่ Hub เท่านั้น

อย่างไรก็ตามสามวิธีการนี้เป็นแนวทางที่เป็นที่นิยมในปัจจุบันซึ่งจริงๆแล้วยังมีวิธีการทำ MDM อีกสองถึงสามวิธีแต่ไม่ขอ กล่าวถึงในเอกสารนี้
ความท้าทายในการทำ DMD ในองค์กร
เนื่องจากว่าการทำ MDM ต้องถูกมองให้เป็น Program หรือแผนแม่บท มันไม่สามารถถูกมองให้เป็นระบบได้ดังนั้น เพื่อเป็นการป้องกันความล้มเหลวในการทำ MDM ขอให้ทำตามขั้นตอนด้านล่าง

  • Organization Preparedness: เนื่องจากการทำ MDM จะเป็นการเปลี่ยนมุมมองของข้อมูลจากที่เคยเป็น Loosely Couple กันแต่ละระบบให้เป็นแบบ Tightly-Couple กับ Master Data มากขึ้น เพื่อเป็นการป้องกันการเข้าใจผิด องค์กรควรจัดการสัมมนาหรือเทรนเรื่อง MDM Concept ให้กับผู้ที่มีส่วนเกี่ยวข้องทั้งหมดก่อน
  • Data Governance: กระบวนการสำคัญอีกข้อสำหรับ MDM คือการสร้าง Policies และ Procedures ขึ้นมาเพื่อใช้สำหรับ ควบคุมคุณภาพของ Master Data ดังนั้นระหว่างที่เราทำการเผยแพร่ข้อมูลนี้และทำการเก็บความคิดเห็นของส่วนต่างทั้ง องค์กรเราจะสามารถสร้าง Stewartship Framework ขึ้นมาได้เพื่อใช้สำหรับการทำ Data Transition ในองค์กรของเรา
  • Technology Integration: เตรียมพร้อมเรื่องของการ Integrate Technology เข้ากับ Process แทนที่การปรับ Process ให้เข้ากับ Technology เพื่อหลีกเลี่ยงปัญหาการผูกติดเทคโนโลยีเข้ากับ product package
  • Anticipating Change: การสร้าง MDM ขึ้นมาในองค์กรย่อมทำให้เกิดการเปลี่ยนแปลงขึ้นมากมาย ดังนั้นอีกสิ่งที่สำคัญ คือเราต้องท้าทายให้พนักงานที่เกี่ยวข้องกับ MDM มีใจยอมรับความเปลี่ยนแปลงและคิดว่าเป็นการเรียนรู้สิ่งใหม่ๆ