แผนกของฉันมีความเชี่ยวชาญในการแปลงข้อมูลลูกค้าเป็นสคีมาฐานข้อมูลของเราเพื่อให้พวกเขาสามารถใช้ซอฟต์แวร์ของเราได้

ตอนนี้เรามีแอปพลิเคชั่น C # ที่ใช้เวลาIDataReader(99% ของเวลาทั้งหมดSqlDataReader) ทำการทำความสะอาดและทำแผนที่แทรกเข้าไปในDataRowวัตถุแล้วใช้ a SqlBulkCopyเพื่อแทรกเข้าไปในฐานข้อมูลของเรา

บางครั้ง (โดยเฉพาะอย่างยิ่งเมื่อฐานข้อมูลต้นทางมีรูปภาพเป็นvarbinaryวัตถุ) กระบวนการนี้สามารถชะงักงันได้ด้วยการถ่ายโอน SQL จากเซิร์ฟเวอร์ไปยังแอปเพื่อให้เลี้ยวขวาแล้วกลับไปที่เซิร์ฟเวอร์

ฉันรู้สึกว่าถ้าเราเขียนการแปลงใหม่เป็นแพ็คเกจ SSISมันสามารถเพิ่มความเร็วได้มากขึ้น อย่างไรก็ตามสิ่งกีดขวางที่ใหญ่ที่สุดที่ฉันยังคงดำเนินต่อไปคือเมื่อเจ้านายของฉันในแบบที่ไม่ได้รับการประดิษฐ์ที่นี่ผลักดันกลับและพูดว่า "จะเกิดอะไรขึ้นถ้า Microsoft หยุดให้การสนับสนุน SSIS เราจะมีรหัสล้าสมัย

นี่ไม่ใช่ครั้งแรกที่ฉันกด "จะเกิดอะไรขึ้นถ้าพวกเขาลบคุณลักษณะนั้น ... ?" ตอบจากหัวหน้าของฉัน ฉันไม่มีเวลาเขียนการแปลงแบบเก่าสอนตัวเอง SSIS และเขียนวิธีใหม่ในการสาธิต / ทดสอบผลประโยชน์ (เราไม่มีคนใช้ SSIS ดังนั้นจะมีช่วงเวลาที่เราจะ ต้องเรียนรู้วิธีใช้)

ฉันควรทำอย่างไรในสถานการณ์เช่นนี้? หยุดผลักดันเทคโนโลยีใหม่หรือไม่ รอจนกว่าเขาจะออกจากแผนก (ฉันเป็นคนที่สองมากที่สุดในแผนกหลังจากเขา แต่อาจเป็นปีก่อนที่เขาจะลาออก / เกษียณ)? ค้นหาวิธีใหม่ในการทำให้เขาหยุดกลัวเครื่องมือของบุคคลที่สามใช่ไหม

ฉันจะแยกจากจุดยืนของผู้บริหาร แต่จำไว้ว่าฉันรู้ว่าฉันไม่มีรายละเอียดทั้งหมด ฉันจะสรุปสิ่งที่ฉันเห็น:

1. ผู้พัฒนาระดับกลางเราจะเรียกเขาว่า "สก็อตต์" แนะนำให้เขียนรหัสเดิมลงใน SSIS เพื่อปรับปรุงประสิทธิภาพของกระบวนการที่สำคัญ ProcessA
2. ProcessA กำลังทำงานในสถานะการทำงานโดยไม่ทราบประเด็นสำคัญ
3. ProcessA เขียนด้วยเครื่องมือที่เป็นกรรมสิทธิ์โดยใช้ความรู้ทั่วไปหรือที่อาจเกี่ยวกับเผ่าเพื่อรักษา
4. การแนะนำให้เขียนใหม่จะต้องใช้เครื่องมือใหม่ในการสนับสนุน
5. พนักงานปัจจุบันไม่มีประสบการณ์ / ความรู้ที่เป็นเอกสารด้วยเครื่องมือใหม่
6. เครื่องมือใหม่เป็นเครื่องมือที่ใช้แทนเครื่องมือรุ่นเก่าและการสนับสนุนเครื่องมือเหล่านี้อาจเปลี่ยนแปลงได้ภายใน 4 ไตรมาสธุรกิจ

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

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

โง่ในขณะที่ฟังบางครั้งวิธีที่ "ดีที่สุด" ไม่ใช่วิธีที่ดีที่สุด

แก้ไข: เพื่อตอบสนองต่อการอัปเดตของคำถามฉันจะโพสต์การแก้ไขเล็กน้อยในคำตอบของฉัน

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

การทำลายสิ่งต่าง ๆ เป็นทักษะ

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

ต้องใช้ทักษะและประสบการณ์ในการทำลายสิ่งต่าง ๆ

ทีมพัฒนาที่เล่นอย่างปลอดภัยเสมอเป็นสิ่งที่ง่ายที่สุดสำหรับคู่แข่งที่จะก้าวข้าม เฉพาะทีมที่ล้มเหลวทำผิดพลาดและสิ่งที่เสียหายเท่านั้นที่สามารถทำการประเมินความเสี่ยงอย่างแท้จริง

การรักษาสภาพที่เป็นอยู่

ในขณะที่มันเป็นจริงระบบปัจจุบันตรงกับความต้องการทางธุรกิจในปัจจุบัน นั่นไม่เป็นความจริงสำหรับการเปลี่ยนแปลงข้อกำหนดที่คาดไม่ถึงในอนาคต ดังที่ภาษิตเก่ากล่าวว่า "โชคลาภชอบคนที่เตรียมไว้"

คำถามนี้ไม่เกี่ยวข้องกับ SQL หรือประสิทธิภาพ มันเกี่ยวกับการถามคำถาม "มีวิธีที่ดีกว่านี้หรือไม่?" และไม่กลัวที่จะลองทางเลือกอื่น

เจ้านายของคุณทนทุกข์ทรมานจากกรณีการรักษาสถานะที่เป็นอยู่

ชาวมายัน

ไม่มีอะไรทำงานได้อย่างสมบูรณ์แบบอย่างแท้จริง

ชาวมายันยังคงเติบโตอาหารของพวกเขาที่ด้านข้างของภูเขา จนกว่าสารอาหารทั้งหมดจะถูกชะล้างออกไปและพวกเขาก็ไม่มีทางที่จะเลี้ยงคนของพวกเขา พวกเขายังคงทำสิ่งเดียวกันจนกว่ามันจะสายเกินไป

สมมติว่าคุณมีเวลาที่จะแก้ไขปัญหาเมื่อปัญหานำเสนอตัวเองเป็นความผิดพลาด

จะทำอย่างไร?

เจ้านายของคุณต้องทนทุกข์ทรมานจากกรณีของการปรับอากาศ ผู้ที่ยอมรับสถานะที่เป็นอยู่มักจะทำเช่นนั้นเพราะพวกเขาขาดความสามารถในการตัดสินใจที่ยากลำบาก เมื่อเผชิญกับความท้าทายพวกเขามักจะเลือกตัวเลือกที่ใกล้เคียงกับสิ่งที่พวกเขาคุ้นเคย

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

คุณต้องนำเสนอแนวคิดด้วยวิธีที่ไม่ขัดแย้งกัน พยายามหาจุดร่วมทั่วไประหว่างสิ่งที่คุณต้องการจะทำกับสิ่งที่เป็นอยู่แล้วสภาพที่เป็นอยู่ นำเสนอข้อโต้แย้งที่ลดความกลัวต่อการเปลี่ยนแปลงของเขาและเสนอการรับรองที่คุณต้องการทำงานที่ไม่ทำให้เกิดการเปลี่ยนแปลงที่สำคัญ

ทำตามขั้นตอนเด็ก

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

ต้องใช้เวลา

ประสบการณ์ของฉันได้รับความเสี่ยงที่ทำให้โครงการย้ายและเฝ้าสภาพที่เป็นเหมือนกำแพงอิฐ ความคงทนเป็นทางเลือกเดียวของคุณในการทำลายอุปสรรคของพวกเขา คาดหวังว่าจะได้รับการไต่สวนไม่มีการสอบถามของคุณ

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

ฉันรู้สึกว่าถ้าเราเขียนการแปลงใหม่เป็นแพ็คเกจ SSIS มันสามารถเพิ่มความเร็วได้มากขึ้น อย่างไรก็ตามสิ่งกีดขวางที่ใหญ่ที่สุดที่ฉันยังคงดำเนินต่อไปคือเมื่อเจ้านายของฉันในแบบที่ไม่ได้รับการประดิษฐ์ที่นี่ผลักดันกลับและพูดว่า "จะเกิดอะไรขึ้นถ้า Microsoft หยุดให้การสนับสนุน SSIS เราจะมีรหัสล้าสมัย

ในความคิดของฉันความสงสัยเกี่ยวกับ SSIS นั้นถูกต้อง

• ผู้พัฒนาที่มีประสบการณ์เกลียดกล่องดำและมีเวทมนตร์มากมายที่เกิดขึ้นภายในแพ็คเกจ SSIS
• การสนับสนุนการควบคุมแหล่งที่มาสำหรับแพ็คเกจ SSIS ขาดอย่างมาก การกระจายและการรวมไฟล์ SSIS dtsx อาจเป็นฝันร้ายหากแพ็คเกจ dtsx ของคุณไม่ได้เป็นแบบแยกส่วนได้เพียงพอ
  • ในทางตรงกันข้ามแอปพลิเคชันคอนโซล C # มีความโปร่งใสมาก คุณสามารถติดตามรหัสเพื่อดูว่ามีอะไรผิดปกติหรือไม่

นอกจากนี้ให้พิจารณาด้วยว่าเจ้านายของคุณกำลังขออยู่หากมีอะไรผิดพลาด

• ดังนั้นเขามีสิทธิ์ที่จะมีความเห็น / เอาชนะความคิดเห็นในเรื่องนี้เท่านั้น

ฉันไม่มีเวลาเขียนการแปลงแบบเก่าสอนตัวเอง SSIS และเขียนวิธีใหม่ในการสาธิต / ทดสอบผลประโยชน์ (เราไม่มีคนใช้ SSIS ดังนั้นจะมีช่วงเวลาที่เราจะ ต้องเรียนรู้วิธีใช้)

ฉันควรทำอย่างไรในสถานการณ์เช่นนี้? หยุดผลักดันเทคโนโลยีใหม่หรือไม่ รอจนกว่าเขาจะออกจากแผนก (ฉันเป็นคนที่สองมากที่สุดในแผนกหลังจากเขา แต่อาจเป็นปีก่อนที่เขาจะลาออก / เกษียณ)? ค้นหาวิธีใหม่ในการทำให้เขาหยุดกลัวเครื่องมือของบุคคลที่สามใช่ไหม

ผมขอแนะนำให้คุณเรียนรู้ SSIS ดีพอเพื่อให้คุณสามารถแสดงให้เห็นถึงผลประโยชน์ของตน

และถ้าหลังจากเรียนด้วยตนเองคุณจะพบว่า SSIS มีข้อได้เปรียบที่สำคัญกว่าวิธีการแบบ "ดั้งเดิม" มากกว่าและคุณยังคงไม่สามารถโน้มน้าวให้เจ้านายของคุณเปลี่ยนหลักสูตรได้ฉันขอแนะนำให้คุณหางานอื่นที่คุณสามารถทำได้ ใช้ SSIS

คำตอบที่คุณมักจะได้รับจากผู้จัดการส่วนใหญ่มักเป็นสิ่งที่ชอบ:

"มันไม่คุ้มค่าใช้งานได้ในขณะนี้และจะใช้เวลาในการเปลี่ยนแปลง"

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

คุณต้องตรวจสอบว่าไม่ได้มีการคิดค้นที่นี่จริง ๆ ก่อนที่จะตัดสินใจว่าจะทำอย่างไร เทคโนโลยีภายในอาจได้รับการเขียนขึ้นสำหรับเหตุผล

สัญญาณว่าเทคโนโลยีได้รับการเขียนใหม่ด้วยเหตุผล:

• เทคโนโลยีที่คุณกำลังขายยังเป็นผลิตภัณฑ์ หากคุณเป็นผู้จำหน่ายฐานข้อมูลโดยใช้รหัส MySQL ไม่ว่าจะประหยัดเวลาเท่าใดมันเป็นความคิดที่อันตรายด้วยเหตุผลหลายประการ
• เทคโนโลยีภายในได้รับการบำรุงรักษาอย่างดีและแก้ไขข้อบกพร่องของโซลูชั่นนอกชั้นวางได้อย่างมีประสิทธิภาพในขณะที่ยังคงให้ฟังก์ชันการทำงานพื้นฐานที่เทียบเท่า
• เทคโนโลยีปรับปรุงประสิทธิภาพการผลิตของทีมพัฒนาทั้งหมดและนักพัฒนาใหม่ขายได้ง่ายในเหตุผลที่ใช้งานอยู่
• มีตัวอย่างอื่น ๆ ที่ บริษัท ได้ประสบความสำเร็จเป็นที่นำเทคโนโลยีภายนอกอื่น ๆ
• ธุรกิจของคุณจะได้รับผลกระทบทันทีและอย่างจริงจังหากโซลูชัน OTS ถูกยกเลิกหรือแตกหัก
• ธุรกิจมีขนาดใหญ่มากมีทรัพยากรในการเขียนเครื่องมือคุณภาพสูงในราคาต่ำ (ตัวอย่างเช่น Google อาจจะสามารถเขียนฐานข้อมูลที่มีราคาน้อยกว่าใบอนุญาต MS SQL $ 1,000 / ที่นั่ง)

กล่าวอีกนัยหนึ่งทีมเข้าใจถึงข้อเสียของการแก้ไขปัญหาที่แก้ไขแล้ว แต่แก้ไขข้อยกเว้นที่เหมาะสมจากมุมมองทางธุรกิจ

สัญญาณของ "ไม่ได้คิดค้นที่นี่":

• ดูเหมือนว่าทุกอย่างอยู่ภายในและมีข้อแก้ตัวสำหรับทุกสิ่ง: "เอ่อมันช้าเกินไป", "เอ่อเป็น Microsoft เราเกลียด Microsoft", "เอ่อมันดูยากที่จะใช้" ฯลฯ
• สำหรับกรณีที่มีการใช้เทคโนโลยีภายนอกคุณจะได้ยิน "ใช่มันมีกลิ่นและเราวางแผนที่จะเขียนของเราเองในที่สุด "
• เจ้าของส่วนประกอบเหล่านี้ไม่มีงานอื่นที่สามารถทำงานได้
• คุณเห็นนักพัฒนาใหม่ส่วนใหญ่ที่เข้ามาพร้อมชุดทักษะที่ยอมรับอย่างกว้างขวาง แต่ต้องใช้เวลาพอสมควรในการพัฒนาเครื่องมือภายใน
• หลังจากวิเคราะห์อย่างระมัดระวังจะเห็นได้ว่าการเปลี่ยนจากโซลูชัน OTS เป็นโซลูชันที่กำหนดเองหรือ OTS อื่น ๆ ใน"จะเกิดอะไรขึ้นถ้าหยุดใช้!" สถานการณ์จะมีผลกระทบต่อธุรกิจน้อยที่สุด ตัวอย่างเช่นหากString.Join()ถูกลบออกจาก. NET Framework การดำเนินการตามStringJoin()วิธีที่กำหนดเองอีกครั้งจะไม่สำคัญ

กล่าวอีกนัยหนึ่ง NIH เป็นรูปแบบของความล้มเหลวในการรักษาวัตถุประสงค์และความเป็นจริงในกรณีที่มีการใช้เทคโนโลยีภายนอกแทนรหัสของตัวเอง

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

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

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

(หมายเหตุด้านข้าง: ใน บริษัท ส่วนใหญ่มักมีองค์ประกอบของ NIH อยู่เสมอ แต่อยู่ในระดับที่ยอมรับได้และตราบใดที่พวกเขาทบทวนรหัสและแนวทางปฏิบัติของพวกเขาเป็นประจำในระยะยาวเราทุกคนมีความผิดในระดับหนึ่ง แต่ ไม่เคยเป็นปัญหาเลย)

ทุกอย่างเกี่ยวกับการวิเคราะห์ต้นทุน / ผลประโยชน์

สิ่งที่คุณจะได้รับจากการเขียนใหม่เป็น SSIS ความเร็ว? มันสำคัญไหม หากเป็นกระบวนการที่ดำเนินการใน GUI และเสียเวลาให้กับทุกคนใช่มันอาจเป็นความคิดที่ดีที่จะเร่งความเร็วเพราะเงินที่ใช้ไปการเปลี่ยนแปลงจะได้รับเงินคืนจากลูกค้าที่มีความสุขหรือพนักงานภายในที่ทำงานแทน กำลังรอซอฟต์แวร์ แต่ถ้าเป็นชุดกลางคืนที่เริ่มเวลา 12.00 น. และมันจะสิ้นสุดที่ 1am แทน 6 โมงเช้า ... ไม่มีอะไรมาก ใช่มันเร็วกว่า 6 เท่า แต่ไม่มีใครจะรู้สึกถึงความแตกต่าง

และเจ้านายของคุณมีจุดดี Microsoft มักจะละทิ้งเทคโนโลยีบางอย่าง VB6, Linq-to-SQL, ASP classic, COM + ... นี่คือความเสี่ยงกับซอฟต์แวร์โอเพนซอร์ซที่ไม่ใช่โอเพ่นซอร์ส (และซอฟต์แวร์โอเพนซอร์ซที่ใหญ่เกินไปสำหรับองค์กรของคุณในกรณีที่ไม่มีการอัพเดท) หากเป็นศูนย์กลางของแอปพลิเคชันของคุณคุณควรควบคุมให้แน่น

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

พัฒนา POC (Proof of Concept) จากนั้นสาธิตให้กับหัวหน้าของคุณ POC ควรช่วยคุณกำหนดประโยชน์ที่แท้จริงของเทคโนโลยีที่คุณกำลังเสนอ จากนั้นคุณและหัวหน้าของคุณสามารถพูดคุยเกี่ยวกับเทคโนโลยีและพัฒนาข้อดีข้อเสียเพื่อนำไปใช้

คุณอาจต้องใช้เวลาเพิ่มเติมนอกเวลาทำงานปกติเพื่อพัฒนา POC

ในฐานะที่เป็นข้อความด้านข้างจากมุมมองของ SSIS ฉันได้ใช้มันและได้พัฒนาแพ็คเกจ SSIS เราแทนที่กระบวนการโหลดที่เป็นกรรมสิทธิ์โดยใช้แพคเกจ SSIS เราทำสิ่งนี้เพราะลูกค้าจริงบ่นเรื่องเวลาโหลด เวลาในการโหลดลดลงอย่างมากด้วย SSIS และทุกคนมีความสุขมากขึ้น

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

คำตอบที่ดี หากยังไม่พังอย่าแก้ไข ฉันจะเพิ่ม

• แม้ว่าความกังวลเรื่องประสิทธิภาพอาจเป็นจริง แต่คำว่า "อาจ" เป็นธงสีแดง ฉันจะทำการวินิจฉัยประสิทธิภาพก่อนดังนั้นฉันจะต้องพิสูจน์ว่าปัญหาด้านประสิทธิภาพคืออะไรก่อนที่จะมอบทรัพยากรใด ๆ ให้กับที่อยู่

• เมื่อพิจารณาถึง "วิธีแก้ปัญหา" ล่าสุดจาก Microsoft คุณควรพิจารณาว่าผู้คนจำนวนมากถูกเผาโดยสิ่งที่ MS เคยชักชวน แต่ไม่ได้รับการสนับสนุนในภายหลังและยกเลิกการสนับสนุนแล้ว หากคุณต้องการให้ซอฟต์แวร์ทำงานเป็นเวลา 10 หรือ 20 ปีโดยไม่มีการบันทึกซ้ำครั้งใหญ่คุณควรระมัดระวังอย่างยิ่ง บริษัท ของเราได้รับบาดเจ็บอย่างรุนแรง

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

คุณสามารถชี้ให้เจ้านายของคุณเห็นว่าจริง ๆ แล้วเทคโนโลยี SSIS นั้นเป็นเลเยอร์เทคโนโลยีเก่ากว่า. NET Framework หากคุณกลับไปสู่รากของมันในฐานะ "Data Transformation Framework" ของ SQL 7.0

ที่หัวหน้าของคุณอาจมีจุดอยู่ในข้อเท็จจริงที่ว่า SSIS เป็นเพียงส่วนหนึ่งของ Microsoft SQL Server รุ่น Standard และ Enterprise นั่นเป็นการเปลี่ยนแปลงครั้งใหญ่สำหรับลูกค้าของคุณที่จะเปลี่ยนไปเมื่อแอปพลิเคชันของคุณในสถานการณ์ธุรกิจขนาดเล็กอาจใช้งานได้ดีกับ Sql Express (หรือ MySQL สำหรับเรื่องนั้นซึ่งทำงานได้กับ ADO.NET แต่ไม่สามารถทำได้ ใช้การรวม SSIS)

ตอนนี้ให้ฉันชัดเจนอย่างสมบูรณ์; IMO, NIH แทบจะไม่เคยเป็นสิ่งที่ดีสำหรับบ้านพัฒนาซอฟต์แวร์ มันล็อคคุณจากเครื่องมือและบริการที่ทรงพลังจำนวนมาก มันยังหน้าซื่อใจคดบนใบหน้าของมัน; บริษัท ของคุณเขียน Visual Studio ไหม . NET Framework เป็นอย่างไร เซิร์ฟเวอร์ sql Windows? ไม่คุณสร้างซอฟต์แวร์ด้วยเครื่องมือและแพลตฟอร์มที่คุณมีอยู่แล้ว (รวมถึงลูกค้าของคุณด้วย) ดังนั้นหากคุณเห็นเครื่องมือที่ได้รับการยอมรับโดยทั่วไปและอาจเป็นประโยชน์ในการดำเนินธุรกิจหลักของคุณคุณยอมรับและเรียนรู้ที่จะอยู่กับความเสี่ยงที่คุณจะต้องดำเนินการเพื่อให้ทันกับการใช้งานล่าสุด เวอร์ชันของเครื่องมือเหล่านั้นหรือแม้กระทั่งแทนที่ ฉันพนันได้เลยว่าหัวหน้าของคุณพัฒนาซอฟต์แวร์ให้ทำงานบน Windows 95/98 หรือราว ๆ นั้น (ถ้าไม่นาน)ก่อนหน้านั้นเช่น 3.0 / 3.1) ถ้าเป็นเช่นนั้นเขาเห็นว่าระบบปฏิบัติการ Windows เวิร์กสเตชันของ Windows มาถึงแล้วครึ่งโหลและต้องอัปเดตซอฟต์แวร์ของเขาเพื่อให้ทำงานบนแพลตฟอร์มที่ใหม่กว่าและเขาต้องเผชิญกับอีกทางหนึ่งด้วย XP EOLed อย่างเป็นทางการ ในขณะที่เขาอาจบ่นนั่นเป็นเพียงค่าใช้จ่ายในการทำธุรกิจ

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

ฉันไม่มีเวลาเขียนการแปลงแบบเก่าสอนตัวเอง SSIS และเขียนวิธีใหม่ในการสาธิต / ทดสอบผลประโยชน์ (เราไม่มีคนใช้ SSIS ดังนั้นจะมีช่วงเวลาที่เราจะ ต้องเรียนรู้วิธีใช้)

นั่นเป็นปัญหาใช่มั้ย คุณกำลังขอให้คนอื่นเสี่ยงต่อความสามารถในการผลิตของพวกเขาในความคิดของคุณและคุณไม่เต็มใจที่จะออกไปข้างนอกเพื่อแสดงให้พวกเขาเห็นว่ามันคุ้มค่า ความเป็นผู้นำทางเทคนิคต้องการความเสี่ยงต่อชื่อเสียงหรือเวลาว่างของคุณเพื่อแสดงให้เห็นว่าความคิดของคุณมีค่า

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

ถ้าความเร็วเป็นคุณสมบัติคุณจะต้องหาวิธีอื่นในการเร่งความเร็ว มิฉะนั้นถ้าความเร็วสำคัญกับคุณมากกว่าลูกค้าของคุณฉันพูดได้ว่าวางทิ้งไว้และลืมมันไป

ในขณะที่มีบุญที่ "ไม่แก้ไขสิ่งที่ไม่แตก" ฉันไม่เห็นด้วยกับคำตอบที่ยอมรับ

คำตอบที่ยอมรับนั้นมาจากมุมมองที่ว่าปัญหาไม่ได้ขาด จากมุมมองของผู้บริหารระดับกลางนี่เป็นเรื่องจริง หากการวิเคราะห์ต้นทุนต้องทำในเวลาที่นักพัฒนาใช้ในการสร้างและรักษาโซลูชัน ETL ใน C # เปรียบเทียบกับการซื้อโซลูชันนอกกรอบจะแสดงว่าโซลูชัน C # ใช้เวลาในการสร้างนานกว่า 3 ถึง 4 เท่า และบำรุงรักษาและค่าใช้จ่ายให้มากขึ้นอีก 10 เท่า (ฉันค้นหาหมายเลขอ้างอิง แต่ฉันหามันไม่เจอ)

ความสามารถหลักของ บริษัท นั้นมีเหตุผลน้อยมากที่จะเขียนและดูแลรักษาการแปลงข้อมูลใน C # โซลูชันพื้นบ้านจะช้าจะมีข้อผิดพลาด (เช่นข้อมูลเสียหาย) จะมีกรณีขอบจะมีการใช้ซ้ำเล็กน้อยระหว่างคลาส ETL และจะมีความเปราะบาง สุจริตนักพัฒนาสิ่งที่ต้องการใช้ / วันของเขา / เธอเขียนและรักษา ETL ใน C #? ฉันได้ทำมัน. มันเป็นเรื่องไร้สาระ มันเกี่ยวกับงานสร้างสรรค์ที่ไกลที่สุดเท่าที่จะทำได้

ใช้เครื่องมือเช่น Informatica บริษัท ที่มี ETL พวกเขาแก้ไขปัญหานี้มานานกว่า 15 ปีแล้ว พวกมันแก้ปัญหาได้แล้ว เครื่องมือของพวกเขาคือการลากและวางการใช้งานซ้ำได้นั้นมีอยู่ในตัวเช่นเดียวกับประสิทธิภาพ ทุกคนส่วนใหญ่ (เช่นนักพัฒนายังไม่มี) สามารถสร้าง ETL ด้วยเครื่องมือ Informatica ฉันไม่ได้พยายามขาย Informatica ใช้เครื่องมือใด ๆ อย่าเพิ่งประดิษฐ์วงล้อใหม่

ในระยะยาวการซื้อเครื่องมือเช่น Informatica หรือการใช้ SSIS จะช่วยให้ บริษัท มีศักยภาพหลายล้านรายการในระยะยาว และที่ดีที่สุดคือคุณจะไม่ต้องรักษา ETL หรือรับผิดชอบเมื่อมันหยุด

ฉันได้ลอง SSIS เพื่อทำงานง่ายๆก่อนหน้านี้

อาจเป็นเรื่องที่น่ารำคาญมากเพราะแม้แต่งานง่าย ๆ ก็ให้กำเนิดไดอะแกรมความซับซ้อนระดับต่ำถึงระดับกลาง (ไม่ไม่มีวิธีอื่นในการ "โค้ด" ยกเว้นไดอะแกรม) และปัญหาการควบคุมแหล่งที่มาโดยคำตอบของจิมฉันไม่รู้

ปัญหาด้านข้าง: ดังนั้นเพื่อเร่งความเร็วผมขอแนะนำให้ลดขนาดของการทำธุรกรรมให้ภาพของคุณนูน บอกเด็ก ๆ ว่าทุก ๆ 800 แทนที่จะเป็น 5,000 คน มันสามารถลดขนาดของ I / O ที่จำเป็นเพื่อรองรับการทำธุรกรรมนั้น