Mô hình hóa dữ liệu trong môi trường nhanh

Bởi nhân viên Techopedia, ngày 16 tháng 11 năm 2016

Takeaway: Người dẫn chương trình Eric Kavanagh thảo luận về tầm quan trọng của mô hình hóa dữ liệu trong phát triển nhanh với Robin Bloor, Dez Blanchfield và IDERA's Ron Huizenga.

Bạn hiện chưa đăng nhập. Vui lòng đăng nhập hoặc đăng ký để xem video.

Eric Kavanagh: Được rồi, thưa quý vị và các bạn. Chào mừng trở lại một lần nữa. Đó là thứ Tư lúc 4:00 EST. Điều đó có nghĩa là đã đến lúc cho các công nghệ nóng. Vâng, thực sự. Tên tôi là Eric Kavanagh, tôi sẽ là chủ nhà của bạn.

Đối với chủ đề ngày nay, đó là một oldie nhưng là một goodie. Nó đang trở nên tốt hơn mỗi ngày bởi vì nó định hình thế giới quản lý dữ liệu của chúng tôi, Mô hình dữ liệu trong môi trường linh hoạt. Có một slide về bạn thật sự, đánh tôi trên Twitter @eric_kavanagh. Chúng ta thực sự nên đặt nó trên slide đó. Tôi sẽ phải làm điều đó.

Vì vậy, năm nóng. Mô hình dữ liệu đã tồn tại mãi mãi. Nó thực sự là trung tâm và linh hồn của doanh nghiệp quản lý thông tin, thiết kế mô hình dữ liệu, cố gắng hiểu mô hình kinh doanh và sắp xếp chúng theo mô hình dữ liệu của bạn. Đó thực sự là những gì bạn đang cố gắng để làm, phải không?

Mô hình dữ liệu đại diện cho doanh nghiệp một cách cơ bản, vậy làm thế nào tất cả các nguồn dữ liệu mới này thay đổi trò chơi? Chúng ta sẽ tìm hiểu về điều đó. Chúng tôi sẽ tìm hiểu làm thế nào bạn có thể đứng đầu mọi thứ một cách nhanh nhẹn. Và tất nhiên, đó là từ của năm.

Robin Bloor cùng với chúng tôi, nhà phân tích chính của chúng tôi, Dez Blanchfield gọi từ Sydney, Úc và Ron Huizenga, Giám đốc sản phẩm cao cấp từ IDERA - người bạn lâu năm của tôi, diễn giả xuất sắc trong không gian này, biết công cụ của anh ấy, vì vậy đừng ngại, hãy hỏi Những câu hỏi khó, folks, những câu hỏi khó. Với điều đó, tôi sẽ biến Robin thành người dẫn chương trình, và mang nó đi.

Tiến sĩ Robin Bloor: Được rồi. Vâng cảm ơn bạn vì điều đó, Eric. Tôi phải nói về mô hình mà tôi nghĩ, tôi thực sự đã ở trong thế giới CNTT trước khi nó tồn tại, theo nghĩa mà tôi nhớ trong công ty bảo hiểm mà tôi làm việc, rằng chúng tôi có một chàng trai đến và cho chúng tôi một loại của hội thảo về cách mô hình hóa dữ liệu. Vì vậy, chúng tôi đang xem xét khoảng 30 năm, là 30 năm? Có thể còn lâu hơn thế, có thể 35 năm trước. Một người mẫu lâu năm, thực sự là một phần của ngành công nghiệp và tất nhiên nó không liên quan gì đến các quý cô trên sàn catwalk.

Điều mà tôi muốn nói, bởi vì những gì chúng ta thường làm, là tôi và Dez nói về những điều khác nhau và tôi chỉ nghĩ rằng tôi sẽ đưa ra cái nhìn tổng quát về mô hình, nhưng có một thực tế cho thấy điều này, giờ đây đã trở nên rõ ràng.

Chúng ta có, thực tế dữ liệu lớn, chúng ta có nhiều dữ liệu hơn, nhiều nguồn dữ liệu hơn, chúng ta đã có các luồng dữ liệu đã đi vào phương trình trong ba hoặc bốn năm qua và bắt đầu có phần lớn hơn của nó, và có nhu cầu lớn hơn để hiểu dữ liệu và tăng tốc độ thay đổi đó là thêm dữ liệu được thêm vào và cũng có nhiều cấu trúc dữ liệu được sử dụng.

Đó là một thế giới khó khăn. Đây là hình ảnh của nó, thực sự là thứ chúng tôi đã vẽ cách đây ba năm nhưng về cơ bản, một khi bạn đưa vào phát trực tuyến và bạn có ý tưởng về nhà máy lọc dữ liệu, trung tâm dữ liệu, liên kết dữ liệu hoặc bất cứ điều gì, bạn thấy rằng có dữ liệu đó Thực sự là lúc nghỉ ngơi, theo nghĩa là nó không di chuyển nhiều. Và sau đó là dữ liệu, các luồng và bạn đã có tất cả các ứng dụng giao dịch, cộng với ngày nay bạn đã có các sự kiện, các cơ sở dữ liệu sự kiện xảy ra trong các ứng dụng và có thể cần, và ngày nay với kiến ​​trúc lambda mà mọi người đang nói đến, thực sự là có tác động đến toàn bộ lĩnh vực dữ liệu.

Và ngày nay nghĩ về việc có một lớp dữ liệu. Lớp dữ liệu tồn tại theo một cách ảo, theo nghĩa là một phần tốt của nó có thể ở trên đám mây và nó có thể được trải rộng trên các trung tâm dữ liệu, nó có thể tồn tại trên các máy trạm. Ở một mức độ nào đó, ở một mức độ nào đó, ở mọi nơi và theo nghĩa đó, có những quy trình ở khắp mọi nơi đang cố gắng bằng cách này hay cách khác để xử lý dữ liệu và di chuyển dữ liệu về. Nhưng cũng biết nó là gì khi bạn di chuyển nó, là một vấn đề lớn.

Nếu chúng ta nhìn vào mô hình hóa dữ liệu theo nghĩa chung nhất, ở dưới cùng của loại ngăn xếp này, bạn có các tệp và cơ sở dữ liệu. Bạn có các thành phần dữ liệu, có các khóa, định nghĩa thành phần, bí danh, từ đồng nghĩa, định dạng vật lý cụ thể và sau đó chúng tôi có lớp siêu dữ liệu này.

Điều thú vị về siêu dữ liệu là siêu dữ liệu hoàn toàn là cách dữ liệu có ý nghĩa của nó. Nếu bạn không thực sự có siêu dữ liệu, thì tốt nhất bạn có thể đoán được ý nghĩa của dữ liệu, nhưng bạn sẽ gặp rất nhiều khó khăn. Siêu dữ liệu cần phải ở đó, nhưng ý nghĩa có cấu trúc. Tôi không muốn đi vào triết lý về ý nghĩa, nhưng ngay cả trong cách chúng ta đối phó với dữ liệu, có rất nhiều sự tinh tế trong suy nghĩ của con người và ngôn ngữ của con người, vốn không dễ dàng thể hiện trong dữ liệu. Nhưng ngay cả về mặt dữ liệu mà chúng ta thực sự xử lý trên thế giới, siêu dữ liệu có ý nghĩa và cấu trúc của siêu dữ liệu - một phần dữ liệu liên quan đến dữ liệu khác và điều đó có nghĩa là gì khi chúng được đặt cùng nhau và điều đó có nghĩa là gì khi chúng ' tái tham gia với các dữ liệu khác, yêu cầu chúng tôi mô hình hóa nó. Nó không đủ tốt để chỉ ghi các thẻ siêu dữ liệu vào mọi thứ, bạn thực sự phải ghi lại ý nghĩa cho mỗi cấu trúc và mối quan hệ giữa các cấu trúc.

Sau đó, chúng ta có lớp trên cùng, các định nghĩa nghiệp vụ, thường là lớp cố gắng chuyển ý nghĩa giữa siêu dữ liệu, là một dạng định nghĩa dữ liệu phù hợp với cách thức tổ chức dữ liệu trên máy tính và ý nghĩa của con người. Vì vậy, bạn có các thuật ngữ kinh doanh, định nghĩa, mối quan hệ, khái niệm cấp thực thể tồn tại trong lớp đó. Và nếu chúng ta sẽ có một sự không thống nhất giữa các lớp này, thì chúng ta phải có mô hình hóa dữ liệu. Nó không thực sự là tùy chọn. Bạn càng thực sự có thể làm điều đó trong việc tự động hóa nó, thì càng tốt. Nhưng bởi vì nó có ý nghĩa, nên thực sự khó thay thế. Thật dễ dàng để bắt siêu dữ liệu trong một bản ghi và có thể lấy nó từ một loạt các ý nghĩa, nhưng nó không cho bạn biết cấu trúc của các bản ghi hoặc ý nghĩa của bản ghi hoặc bối cảnh của bản ghi.

Vì vậy, đây là những gì mô hình hóa dữ liệu, theo tôi, là về. Những điểm cần lưu ý: vũ trụ dữ liệu càng trở nên phức tạp, bạn càng cần phải mô hình hóa nó. Nói cách khác, nó giống như việc chúng ta thêm không chỉ nhiều trường hợp vào thế giới, tương ứng với các bản ghi dữ liệu, mà chúng ta còn thực sự bổ sung thêm ý nghĩa cho thế giới bằng cách thu thập dữ liệu trên nhiều thứ hơn. Nó ngày càng trở nên phức tạp hơn mà chúng ta phải hiểu.

Về lý thuyết, có một vũ trụ dữ liệu và chúng ta cần một cái nhìn về nó. Trong thực tế, siêu dữ liệu thực tế là một phần của vũ trụ dữ liệu. Vì vậy, nó không phải là một tình huống đơn giản. Bắt đầu mô hình là từ trên xuống và từ dưới lên. Bạn cần xây dựng theo cả hai hướng và lý do là, dữ liệu có ý nghĩa với máy tính và quy trình, phải xử lý nó, nhưng nó có ý nghĩa theo đúng nghĩa của nó. Vì vậy, bạn cần một ý nghĩa từ dưới lên, thỏa mãn phần mềm cần truy cập dữ liệu và bạn cần ý nghĩa từ trên xuống để con người có thể hiểu được. Việc xây dựng các mô hình siêu dữ liệu không phải và không bao giờ có thể là một dự án; đó là một hoạt động đang diễn ra - nên là một hoạt động đang diễn ra trong mọi môi trường mà chúng tồn tại. May mắn thay, có rất nhiều môi trường, trong đó thực sự không phải là trường hợp và mọi thứ vượt khỏi tầm kiểm soát tương ứng.

Trong tương lai, mô hình tăng lên với tầm quan trọng khi công nghệ tiến lên. Đó là ý kiến ​​của tôi. Nhưng nếu bạn nhìn vào IoT, chúng ta có thể hiểu về điện thoại di động nhiều hơn trước đây, mặc dù nó đã giới thiệu các chiều mới: kích thước của vị trí với thiết bị di động. Khi bạn truy cập IoT, chúng tôi sẽ xem xét các vấn đề dữ liệu đặc biệt mà trước đây chúng tôi chưa bao giờ phải làm và chúng tôi cần, bằng cách này hay cách khác, để hiểu chính xác những gì chúng tôi có, chính xác là chúng tôi có thể tổng hợp nó như thế nào, những gì chúng ta có thể làm về mặt nhận được ý nghĩa từ tổng hợp, và tất nhiên, những gì chúng ta có thể làm với nó, khi chúng ta xử lý nó.

Tôi nghĩ rằng tôi đã nói đủ rồi. Tôi sẽ chuyển sang Dez Blanchfield, người sẽ nói điều gì đó hoàn toàn khác.

Dez Blanchfield: Cảm ơn bạn. Luôn luôn là một hành động khó khăn để tuân theo, nhưng đây là một chủ đề chúng tôi đã đồng ý và nói về vấn đề này một cách ngắn gọn trong bài diễn văn trước, và nếu bạn quay số sớm, có lẽ bạn đã bắt gặp cả đống đá quý tuyệt vời. Một trong những điều đáng tiếc, và tôi không muốn đánh cắp sấm sét của người đặc biệt này, nhưng một trong những điều đó từ lời nói đùa của chúng tôi mà tôi muốn chia sẻ, trong trường hợp bạn không bắt được nó, chỉ xoay quanh chủ đề hành trình của dữ liệu và khiến tôi thực sự viết nó ra khi nghĩ về hành trình mà dữ liệu thực hiện trong một bối cảnh khác nhau xung quanh đời sống thế hệ - năm, tháng, tuần, ngày, giờ, phút, giây - và bối cảnh xung quanh dữ liệu định vị trong bối cảnh đó. Cho dù tôi là nhà phát triển đang chạy mã hay tôi là chuyên gia dữ liệu và tôi đang suy nghĩ về cấu trúc cũng như định dạng và siêu dữ liệu xung quanh từng yếu tố hoặc cách các hệ thống và doanh nghiệp tương tác với nó.

Đó là một điều thú vị nho nhỏ chỉ cần lưu ý, nhưng dù sao, hãy để tôi đi sâu vào. Đặc biệt, thiết kế dữ liệu là cụm từ mà tôi sử dụng để nói về tất cả mọi thứ dữ liệu và đặc biệt là phát triển ứng dụng hoặc cơ sở hạ tầng cơ sở dữ liệu. Tôi nghĩ rằng thiết kế dữ liệu là một thuật ngữ chỉ nắm bắt nó rất tốt trong tâm trí của tôi. Ngày nay khi chúng ta nói về thiết kế dữ liệu, chúng ta nói về thiết kế dữ liệu nhanh nhẹn hiện đại và quan điểm của tôi là cách đây không lâu, các nhà phát triển và chuyên gia dữ liệu đã làm việc một mình; họ đã ở trong các silo của riêng mình và các thiết kế đã đi từ silo này sang silo khác. Nhưng tôi rất quan điểm những ngày này, đó không chỉ là trường hợp đã thay đổi, mà nó còn phải thay đổi; đó là một điều cần thiết và đó là ứng dụng - nhà phát triển và bất cứ điều gì liên quan đến phát triển liên quan đến dữ liệu, các nhà thiết kế thực hiện các yếu tố thiết kế có liên quan của lược đồ và trường và hồ sơ và hệ thống cơ sở dữ liệu và cơ sở dữ liệu, mô hình hóa và toàn bộ quản lý thách thức xung quanh đó. Đó là một môn thể thao đồng đội bây giờ và do đó hình ảnh của tôi về một nhóm người nhảy ra khỏi máy bay đóng vai trò là một đội để thể hiện hình ảnh trực quan thú vị đó của những người rơi trên bầu trời.

Thứ ba, những gì đã xảy ra để mang điều này về? Vâng, có một bài báo vào năm 1986 được viết bởi một vài quý ông có tên mà tôi đã cố gắng hết sức để thực thi công lý, Hirotaka Takeuchi và Ikujiro Nonaka, tôi nghĩ rằng nó được phát âm, đã tạo ra một bài báo mà họ có tựa đề là Di chuyển xuống Scrum Downfield. ý tưởng về phương pháp chiến thắng một trận bóng bầu dục bắt nguồn từ hoạt động scrum này, nơi mọi người đều ở một nơi và hai đội về cơ bản khóa đầu trong một thứ gọi là scrum để thử và kiểm soát bóng và chơi trên sân để đến đường thử và chạm đất với quả bóng và nhận được một điểm, được gọi là trine, và bạn lặp lại quá trình này và bạn nhận được nhiều điểm hơn cho đội.

Bài viết này được xuất bản năm 1986 trên Tạp chí Harvard Business Review, và thật kỳ lạ là nó thực sự đã được chú ý rất nhiều. Nó đã nhận được rất nhiều sự chú ý bởi vì nó đã giới thiệu các khái niệm mới tuyệt vời và đây là một ảnh chụp màn hình mặt trước của nó. Vì vậy, họ đã đưa khái niệm scrum này ra khỏi trò chơi bóng bầu dục và họ đã đưa nó vào kinh doanh và đặc biệt là trong trò chơi thiết kế và phân phối dự án, đặc biệt là phân phối dự án.

Scrum đã làm gì đã cho chúng ta một phương pháp mới so với các phương pháp PRINCE2 hoặc PMBOK mà trước đây chúng ta đã sử dụng trong phương pháp thác nước, bạn biết, làm điều này và điều này và điều này và theo dõi chúng theo trình tự và kết nối tất cả các dấu chấm xung quanh, tùy thuộc vào những gì bạn đã có, hoặc không làm phần hai cho đến khi bạn hoàn thành phần một vì nó phụ thuộc vào phần một. Những gì nó mang lại cho chúng tôi là một phương pháp mới để nhanh nhẹn hơn một chút, đó là thuật ngữ xuất phát từ đâu, về cách chúng tôi phân phối mọi thứ, và cụ thể là về thiết kế và phát triển dự án cơ sở.

Một số người thuê chính - chỉ để tôi tiếp tục với điều này - là xung quanh những người thuê chính của scrum. Nó đưa ra ý tưởng xây dựng sự bất ổn, rằng hiệu quả nếu bạn nghĩ về nỗi sợ hỗn loạn, thế giới tồn tại trong tình trạng hỗn loạn, nhưng hành tinh hình thành, rất thú vị, vì vậy xây dựng sự bất ổn, khả năng nảy lên một chút và vẫn thực sự làm cho mọi thứ hoạt động, các nhóm dự án tự tổ chức, ủng hộ chồng chéo thông qua phát triển rất có trách nhiệm, các loại hình học tập và kiểm soát khác nhau thông qua hành trình giao dự án, chuyển giao tổ chức học tập. Vậy làm cách nào để chúng tôi lấy thông tin từ một bộ phận của doanh nghiệp và chuyển nó sang một bộ phận khác từ những người có ý tưởng nhưng không phát triển mã hoặc không phát triển cơ sở dữ liệu và cơ sở hạ tầng, nhưng dữ liệu cho những người đó? Và đặc biệt kết quả thời gian đóng hộp. Nói cách khác, chúng ta hãy làm điều này trong một khoảng thời gian, một ngày như trong 24 giờ, hoặc một tuần hoặc một vài tuần và xem những gì chúng ta có thể làm và sau đó lùi lại và xem xét nó.

Và vì vậy, nếu bạn tha thứ cho trò chơi chữ, đây thực sự là một trò chơi mới trong phân phối dự án và ba thành phần cốt lõi sẽ có ý nghĩa khi chúng ta đi xa hơn một chút ở đây - có sản phẩm: tất cả những người này đều có ý tưởng và có một nhu cầu để có được một cái gì đó được thực hiện và câu chuyện xung quanh họ. Các nhà phát triển hoạt động theo mô hình nhanh nhẹn để có được câu chuyện của họ và thông qua các cuộc trò chuyện hàng ngày bằng phương pháp scrum để thảo luận về nó và hiểu những gì họ cần làm, sau đó chỉ cần tiếp tục và thực hiện nó. Sau đó, mọi người, chúng tôi đã nghe nói về các bậc thầy scrum, người giám sát toàn bộ điều này và hiểu rõ phương pháp này đủ để điều khiển nó. Tất cả chúng ta đã nhìn thấy những hình ảnh mà tôi có ở phía bên phải của bức tường và bảng trắng đầy những ghi chú Post-It và chúng được phục vụ như những bức tường Kanban. Nếu bạn không biết Kanban là ai, tôi mời bạn đến Google, ông Kanban là ai và tại sao đó là một sự thay đổi trong cách chúng ta di chuyển mọi thứ từ bên này sang bên kia trong một bức tường theo nghĩa đen nhưng trong một dự án.

Nhìn thoáng qua, quy trình làm việc của Scrum thực hiện điều này: nó đưa ra một danh sách những việc mà một tổ chức muốn làm, điều hành chúng thông qua một loạt những điều chúng ta gọi là chạy nước rút được chia thành các giai đoạn 24 giờ, thời gian kéo dài hàng tháng và chúng ta có được loạt đầu ra gia tăng này. Đó là một thay đổi đáng kể đối với cách thức phân phối các dự án, đã được chuyển đến giai đoạn đó bởi vì một phần của dòng chảy như quân đội Hoa Kỳ, người có một phần lớn trong việc phát triển một thứ gọi là PMBOK, giống như ý tưởng không đưa xe tăng vào lĩnh vực này cho đến khi bạn đặt viên đạn vào điều đó bởi vì nếu một chiếc xe tăng trên cánh đồng không có viên đạn, nó sẽ vô dụng. Vì vậy, phần một là đặt đạn vào xe tăng, phần hai là đặt xe tăng vào hiện trường. Thật không may, mặc dù, những gì đã xảy ra với các nhà phát triển trong thế giới phát triển bằng cách nào đó đã nắm bắt được phương pháp nhanh nhẹn này và chạy theo nó, nếu bạn tha thứ cho trò chơi chữ, ở giai đoạn nước rút.

Luôn luôn xảy ra những gì đã xảy ra, khi chúng ta nghĩ về sự nhanh nhẹn, chúng ta thường nghĩ về các nhà phát triển chứ không phải cơ sở dữ liệu và bất cứ điều gì để làm với thế giới của cơ sở dữ liệu. Đó là một kết quả đáng tiếc vì thực tế là nhanh nhẹn không giới hạn ở các nhà phát triển. Trong thực tế, thuật ngữ nhanh nhẹn theo quan điểm của tôi thường liên quan sai đến các nhà phát triển phần mềm và không phải là nhà thiết kế cơ sở dữ liệu và kiến ​​trúc sư. Luôn luôn có những thách thức tương tự mà bạn gặp phải trong phát triển phần mềm và ứng dụng phải đối mặt với tất cả những gì phải làm với thiết kế và phát triển và vận hành và bảo trì, do đó là cơ sở hạ tầng dữ liệu và đặc biệt là cơ sở dữ liệu. Các tác nhân trong dàn dữ liệu cụ thể này bao gồm các kiến ​​trúc sư dữ liệu, nhà tạo khuôn, quản trị viên, người quản lý cơ sở hạ tầng cơ sở dữ liệu và cơ sở dữ liệu thực tế cho đến các nhà phân tích và kiến ​​trúc sư kinh doanh và hệ thống, những người ngồi và suy nghĩ về cách các hệ thống và hoạt động kinh doanh và làm thế nào chúng ta có được luồng dữ liệu thông qua những điều này.

Đó là một chủ đề mà tôi thường xuyên đưa ra bởi vì đó là một sự thất vọng liên tục của tôi ở chỗ tôi rất cho rằng các chuyên gia dữ liệu phải - không nên - bây giờ phải liên quan mật thiết đến mọi thành phần của phân phối dự án, thực sự, đặc biệt là phát triển. Đối với chúng tôi thì không, sau đó chúng tôi thực sự không cho mình cơ hội tốt nhất cho một kết quả tốt. Chúng ta thường phải quay lại và có suy nghĩ khác về những điều này bởi vì có một kịch bản, chúng ta có một ứng dụng đang được xây dựng và chúng ta phát hiện ra các nhà phát triển không phải lúc nào cũng là chuyên gia dữ liệu. Làm việc với cơ sở dữ liệu đòi hỏi các kỹ năng rất chuyên môn, đặc biệt là về dữ liệu và xây dựng trải nghiệm. Bạn không ngay lập tức trở thành một chuyên gia cơ sở dữ liệu hoặc chuyên gia kiến ​​thức dữ liệu qua đêm; đây thường là một cái gì đó xuất phát từ trải nghiệm cả đời và chắc chắn với những người như Tiến sĩ Robin Bloor trên Code Today, người khá giàu có đã viết cuốn sách này.

Trong nhiều trường hợp - và thật không may nhưng đó là thực tế - rằng có hai phần của đồng tiền này, đó là các nhà phát triển phần mềm tự mình làm chuyên gia cơ sở dữ liệu và xây dựng các kỹ năng bạn cần trong mô hình thiết kế cơ sở dữ liệu, phát triển mô hình chỉ là nền tảng cho kỹ thuật của các bậc thầy về cách thức dữ liệu xuất hiện và cách tổ chức hành trình cần thực hiện và không nên trông như thế nào, hoặc chắc chắn đã ăn sâu và hiểu rằng đó thường là những kỹ năng bản địa dành cho các nhà phát triển phần mềm. Và một số thách thức phổ biến mà chúng ta gặp phải, chỉ cần đặt nó trong bối cảnh, bao gồm việc chỉ tạo và bảo trì và quản lý cơ bản thiết kế cơ sở dữ liệu cốt lõi, ghi lại dữ liệu và cơ sở hạ tầng cơ sở dữ liệu, sau đó sử dụng lại các tài sản dữ liệu đó, thiết kế lược đồ, tạo các lược đồ, quản trị và bảo trì lược đồ và sử dụng chúng, chia sẻ kiến ​​thức về lý do tại sao lược đồ này được thiết kế theo một cách cụ thể và các điểm mạnh và điểm yếu đi kèm theo đó gây ra thay đổi dữ liệu theo thời gian, mô hình hóa dữ liệu và các loại của các mô hình chúng tôi áp dụng cho các hệ thống và dữ liệu chúng tôi chảy qua chúng. Tạo mã cơ sở dữ liệu và nó tiếp tục tích hợp và sau đó mô hình hóa dữ liệu xung quanh chúng và sau đó truy cập nhanh hơn để kiểm soát bảo mật xung quanh dữ liệu, tính toàn vẹn của dữ liệu là chúng tôi di chuyển dữ liệu xung quanh khi chúng tôi giữ được tính toàn vẹn của nó, có đủ siêu dữ liệu xung quanh Nó, nên bán hàng xem tất cả các hồ sơ trong bảng hoặc họ chỉ nên xem địa chỉ, tên, họ gửi cho bạn công cụ trong bài? Và dĩ nhiên, thách thức lớn nhất của tất cả là mô hình hóa các nền tảng cơ sở dữ liệu hoàn toàn là một cuộc trò chuyện khác nhau.

Tôi rất quan điểm rằng với tất cả những điều này trong tâm trí để làm cho bất kỳ điều gì có thể xảy ra, điều cực kỳ quan trọng là cả chuyên gia dữ liệu và nhà phát triển đều có các công cụ phù hợp và những công cụ đó có khả năng phân phối dự án tập trung vào nhóm, thiết kế, phát triển và bảo trì hoạt động liên tục. Bạn biết đấy, những thứ như hợp tác giữa các dự án giữa các chuyên gia dữ liệu và nhà phát triển phần mềm, một điểm chân lý hoặc một nguồn sự thật duy nhất cho tất cả mọi thứ xung quanh tài liệu của chính cơ sở dữ liệu, dữ liệu, lược đồ, nơi các bản ghi đến, chủ sở hữu của các bản ghi đó . Tôi nghĩ trong thời đại ngày nay nó cực kỳ quan trọng, chúng ta sẽ có được niết bàn dữ liệu này để trở thành vua, rằng các công cụ phù hợp phải được đặt ra vì thách thức bây giờ quá lớn đối với chúng ta khi thực hiện thủ công và nếu mọi người di chuyển vào và ra khỏi một tổ chức, thật quá dễ dàng để chúng ta không tuân theo cùng một quy trình hoặc phương pháp mà một người có thể thiết lập là tốt và không nhất thiết phải chuyển những kỹ năng và khả năng đó về phía trước.

Với ý nghĩ đó, tôi sẽ tìm đến người bạn tốt của chúng tôi tại IDERA và nghe về công cụ đó và cách nó giải quyết những điều này.

Ron Huizenga: Cảm ơn bạn rất nhiều và cảm ơn cả Robin và Dez vì đã thực sự thiết lập sân khấu tốt, và bạn sẽ thấy một chút trùng lặp trong một vài điều mà tôi đã nói về. Nhưng họ thực sự đã đặt nền tảng rất vững chắc cho một số khái niệm mà tôi sẽ nói về từ góc độ mô hình hóa dữ liệu. Và rất nhiều điều họ nói đã lặp lại trải nghiệm của chính tôi khi tôi là một nhà tư vấn làm việc trong mô hình hóa dữ liệu và kiến ​​trúc dữ liệu, cùng với các đội - cả hai thác nước trong những ngày đầu và phát triển thành các sản phẩm hiện đại hơn với các dự án mà chúng tôi đang sử dụng nhanh nhẹn phương pháp để đưa ra giải pháp.

Vì vậy, những gì tôi sẽ nói hôm nay dựa trên những kinh nghiệm đó cũng như quan điểm về các công cụ và một số khả năng trong các công cụ mà chúng tôi sử dụng để giúp chúng tôi theo hành trình đó. Những gì tôi sẽ trình bày rất ngắn gọn là, tôi sẽ không đi sâu vào chi tiết; chúng tôi chỉ có một cái nhìn tổng quan thực sự tốt về những gì nó là. Tôi sẽ nói về nó theo mô hình, mô hình dữ liệu là gì và nó thực sự có ý nghĩa gì với chúng ta? Và làm thế nào để chúng tôi kích hoạt khái niệm người lập mô hình dữ liệu nhanh trong các tổ chức của chúng tôi, về cách chúng tôi tham gia vào người lập mô hình dữ liệu, sự tham gia của người lập mô hình và kiến ​​trúc sư trong giai đoạn nước rút, loại hoạt động nào họ nên tham gia và, như một nền tảng cho điều đó, một vài khả năng của công cụ mô hình hóa quan trọng mà chúng ta sử dụng để thực sự giúp công việc đó dễ dàng hơn là gì? Sau đó, tôi sẽ đi sâu vào một chút và chỉ nói một chút về một số giá trị kinh doanh và lợi ích của việc có một người lập mô hình dữ liệu tham gia, hoặc cách tôi thực sự sẽ kể câu chuyện là, các vấn đề về việc không có một người lập mô hình dữ liệu tham gia đầy đủ vào các dự án và tôi sẽ cho bạn thấy rằng dựa trên kinh nghiệm và biểu đồ khiếm khuyết của một hình ảnh trước và sau của một dự án thực tế mà tôi đã tham gia nhiều năm trước. Và sau đó chúng tôi sẽ tóm tắt thêm một vài điểm và sau đó có câu hỏi và câu trả lời thêm vào đó.

Rất ngắn gọn, ER Studio là một bộ rất mạnh mẽ có rất nhiều thành phần khác nhau. Data Architect, nơi các nhà mô hình hóa và kiến ​​trúc sư dành phần lớn thời gian của họ để thực hiện mô hình dữ liệu của họ. Ngoài ra còn có các thành phần khác mà chúng ta sẽ không nói đến ngày hôm nay, chẳng hạn như Kiến trúc sư kinh doanh, nơi chúng tôi thực hiện mô hình hóa và Kiến trúc sư phần mềm, cho một số mô hình UML. Sau đó, có Kho lưu trữ, nơi chúng tôi đăng ký và chúng tôi chia sẻ các mô hình và chúng tôi cho phép các nhóm cộng tác trên đó và xuất bản chúng ra máy chủ nhóm để nhiều khán giả tham gia vào một dự án thực sự có thể nhìn thấy các tạo tác mà chúng tôi ' đang tạo ra từ góc độ dữ liệu cũng như những thứ khác mà chúng tôi đang thực hiện trong chính phân phối dự án.

Những gì tôi sẽ tập trung vào hôm nay sẽ là một vài điều mà chúng ta sẽ thấy về Kiến trúc sư dữ liệu và bởi vì điều thực sự quan trọng là chúng ta có sự cộng tác của các khía cạnh dựa trên Kho lưu trữ. Đặc biệt khi chúng ta bắt đầu nói về các khái niệm như quản lý thay đổi bắt buộc, không chỉ các dự án phát triển nhanh, mà bất kỳ loại phát triển nào trong tương lai.

Vì vậy, hãy nói về Trình mô hình dữ liệu Agile một lát. Như chúng ta, loại, đã được đề cập trước đó trong bài thuyết trình, rằng bắt buộc chúng ta phải có các nhà tạo mô hình dữ liệu và / hoặc các kiến ​​trúc sư tham gia đầy đủ vào các quy trình phát triển nhanh. Bây giờ, những gì đã xảy ra trong lịch sử là, vâng, chúng tôi đã thực sự nghĩ về sự nhanh nhẹn từ góc độ phát triển, và có một vài điều đã xảy ra thực sự đã gây ra điều đó. Một phần của nó là do bản chất của cách phát triển mở ra. Khi sự phát triển nhanh nhẹn bắt đầu và chúng tôi bắt đầu với khái niệm về các nhóm tự tổ chức này, nếu bạn uống Kool-Aid một chút quá thuần khiết và bạn ở khía cạnh lập trình cực đoan của mọi thứ, có một sự giải thích rất chính xác về những thứ như Các nhóm tự tổ chức, mà rất nhiều người giải thích, tất cả những gì chúng ta cần là một nhóm các nhà phát triển có thể xây dựng toàn bộ giải pháp. Cho dù nó có nghĩa là phát triển mã, cơ sở dữ liệu hoặc kho dữ liệu đằng sau nó và mọi thứ đã được chuyển xuống cho các nhà phát triển. Nhưng những gì xảy ra với điều đó là bạn mất đi những khả năng đặc biệt mà mọi người có. Tôi đã thấy rằng các đội mạnh nhất là những đội bao gồm những người từ các nền tảng khác nhau. Chẳng hạn như sự kết hợp của các nhà phát triển phần mềm mạnh mẽ, kiến ​​trúc sư dữ liệu, nhà mô hình dữ liệu, nhà phân tích kinh doanh và các bên liên quan kinh doanh, tất cả hợp tác với nhau để đưa ra giải pháp cuối cùng.

Điều tôi cũng đang nói hôm nay là, tôi sẽ thực hiện điều này trong bối cảnh dự án phát triển nơi chúng tôi đang phát triển một ứng dụng rõ ràng là cũng sẽ có thành phần dữ liệu liên quan đến nó. Mặc dù vậy, chúng tôi cần phải lùi một bước trước khi thực hiện điều đó, bởi vì chúng tôi cần nhận ra rằng có rất ít dự án phát triển Greenfield ngoài đó chúng tôi tập trung hoàn toàn vào việc tạo và tiêu thụ dữ liệu chỉ giới hạn trong chính dự án phát triển đó . Chúng ta cần lùi một bước và nhìn vào quan điểm tổ chức tổng thể từ góc độ dữ liệu và quan điểm quá trình. Bởi vì những gì chúng tôi tìm ra là thông tin mà chúng tôi đang sử dụng có thể đã tồn tại ở đâu đó trong các tổ chức. Là những người xây dựng mô hình và kiến ​​trúc sư, chúng tôi đưa điều đó ra ánh sáng để chúng tôi biết nơi lấy nguồn thông tin đó từ chính các dự án. Chúng tôi cũng biết các cấu trúc dữ liệu có liên quan vì chúng tôi có các mẫu thiết kế giống như các nhà phát triển có các mẫu thiết kế cho mã của họ. Và chúng ta cũng cần phải có quan điểm tổ chức tổng thể đó. Chúng ta không thể chỉ nhìn vào dữ liệu trong ngữ cảnh của ứng dụng mà chúng ta đang xây dựng. Chúng ta cần mô hình hóa dữ liệu và đảm bảo rằng chúng ta ghi lại dữ liệu vì nó tồn tại lâu hơn chính các ứng dụng. Các ứng dụng đó đến và đi, nhưng chúng ta cần có thể xem dữ liệu và đảm bảo rằng nó mạnh mẽ và có cấu trúc tốt, không chỉ cho ứng dụng mà còn cho các quyết định báo cáo hoạt động, báo cáo BI và tích hợp với các ứng dụng khác, nội bộ và bên ngoài để tổ chức của chúng tôi là tốt. Vì vậy, chúng ta cần xem xét toàn bộ bức tranh lớn về dữ liệu và vòng đời của dữ liệu đó là gì và hiểu hành trình của các mẩu thông tin trong toàn tổ chức từ cái nôi đến nấm mồ.

Bây giờ trở lại với chính các đội thực tế và cách chúng ta thực sự cần làm việc, phương pháp thác nước được coi là quá chậm để đưa ra kết quả. Bởi vì, như đã chỉ ra với ví dụ về xe tăng, nó đã hết bước này đến bước khác và thường mất quá nhiều thời gian để đưa ra kết quả khả thi. Những gì chúng ta làm bây giờ là chúng ta cần có một phong cách làm việc lặp đi lặp lại trong đó chúng ta đang phát triển dần dần các thành phần của nó và xây dựng nó theo thời gian nơi chúng ta sản xuất mã có thể sử dụng hoặc các tạo tác có thể sử dụng, tôi sẽ nói, cho mỗi lần chạy nước rút. Điều quan trọng là sự hợp tác giữa các bên liên quan kỹ thuật trong nhóm và các bên liên quan kinh doanh khi chúng tôi hợp tác để đưa những câu chuyện của người dùng đó vào một tầm nhìn có thể thực hiện được của mã và dữ liệu cũng hỗ trợ mã đó. Và chính Trình tạo mô hình dữ liệu Agile thường sẽ thấy rằng chúng ta không có đủ trình tạo mô hình trong các tổ chức để một người lập mô hình dữ liệu hoặc kiến ​​trúc sư có thể đồng thời hỗ trợ nhiều nhóm.

Và khía cạnh khác của điều đó là, ngay cả khi chúng tôi có nhiều nhà tạo mô hình, chúng tôi cần đảm bảo rằng chúng tôi có một bộ công cụ mà chúng tôi đang sử dụng cho phép cộng tác của nhiều dự án đang hoạt động cùng lúc và chia sẻ những dự án đó tạo tác dữ liệu và khả năng nhận và trả phòng. Tôi sẽ giải quyết vấn đề này rất nhanh vì chúng tôi đã trình bày nó trong phần trước. Tiền đề thực sự của nhanh nhẹn là bạn dựa trên những điều tồn đọng, về những câu chuyện hoặc yêu cầu. Trong các lần lặp, chúng tôi hợp tác thành một nhóm. Thông thường, một cuộc chạy nước rút hai tuần hoặc một tháng, tùy thuộc vào tổ chức, là rất phổ biến. Và cũng có các cuộc họp đánh giá và chờ đợi hàng ngày để chúng tôi loại bỏ các trình chặn và đảm bảo rằng chúng tôi sẽ di chuyển mọi khía cạnh về phía trước mà không bị dừng lại ở các khu vực khác nhau khi chúng tôi đi qua. Và trong những lần chạy nước rút đó, chúng tôi muốn đảm bảo rằng chúng tôi đang sản xuất các sản phẩm có thể sử dụng được như một phần của mỗi lần chạy nước rút.

Chỉ khác một chút về điều đó, mở rộng hơn nữa, scrum là phương pháp mà tôi sẽ nói cụ thể hơn ở đây và về cơ bản chúng tôi đã tăng cường hình ảnh trước đó với một vài khía cạnh khác. Thông thường có tồn đọng sản phẩm và sau đó tồn đọng nước rút. Vì vậy, chúng tôi có một hồ sơ tồn đọng tổng thể rằng, vào đầu mỗi lần lặp lại nước rút, chúng tôi không muốn nói gì nữa, chúng tôi sẽ xây dựng cuộc đua nước rút này như thế nào? Sau đó, chúng tôi chia nhỏ các nhiệm vụ có liên quan đến điều đó và chúng tôi thực hiện trong các lần chạy nước rút từ một đến bốn tuần với những đánh giá hàng ngày đó. Khi chúng tôi đang làm điều đó, chúng tôi đang theo dõi tiến trình của mình thông qua các biểu đồ ghi điểm và biểu đồ chi tiết để theo dõi về cơ bản những gì còn lại để xây dựng so với những gì chúng tôi đang xây dựng để thiết lập những thứ như tốc độ phát triển của chúng tôi, chúng tôi sẽ tạo ra lịch trình, tất cả những loại điều. Tất cả những thứ đó được xây dựng liên tục trong giai đoạn nước rút thay vì đi vài tháng và phát hiện ra rằng bạn sẽ đi ngắn và bạn cần phải kéo dài lịch trình dự án. Và rất quan trọng, là một phần của nó, toàn bộ các đội, có phần đánh giá nước rút ở cuối và hồi cứu nước rút, vì vậy trước khi bạn bắt đầu lần lặp tiếp theo, bạn sẽ xem lại những gì bạn đã làm và bạn đang tìm cách mà bạn có thể cải thiện trong thời gian tới thông qua.

Về mặt phân phối, về cơ bản, đây là một slide tóm tắt các loại điển hình của những thứ diễn ra trong nước rút. Và nó rất tập trung vào phát triển, vì vậy rất nhiều thứ chúng ta thấy ở đây, chẳng hạn như, thiết kế chức năng và trường hợp sử dụng, thực hiện kiểm tra mã thiết kế, khi chúng ta nhìn vào các hộp này ở đây, và tôi sẽ không xem qua chúng ở bất kỳ mức độ chi tiết nào, chúng đều rất định hướng phát triển. Và chôn vùi bên dưới đây là một thực tế rằng chúng ta cũng cần phải có những dữ liệu có thể cung cấp cùng với điều này để hỗ trợ nỗ lực này. Vì vậy, mỗi khi chúng ta thấy những thứ như tồn đọng, yêu cầu và câu chuyện của người dùng, khi chúng ta trải qua, chúng ta cần xem xét những phần phát triển chúng ta phải làm là gì, những phần phân tích chúng ta cần làm là gì, về thiết kế dữ liệu hoặc mô hình dữ liệu, còn những thứ như thuật ngữ kinh doanh để chúng ta có thể liên kết ý nghĩa kinh doanh với tất cả các tạo phẩm mà chúng ta đang sản xuất thì sao? Bởi vì chúng tôi cần phải sản xuất những sản phẩm có thể sử dụng được trong mỗi lần chạy nước rút.

Một số người sẽ nói rằng chúng tôi cần sản xuất mã có thể sử dụng vào cuối mỗi lần chạy nước rút. Điều đó không nhất thiết phải như vậy, đó là ở góc độ phát triển thuần túy nhất, nhưng khá thường xuyên - đặc biệt là vào lúc bắt đầu - chúng ta có thể có một cái gì đó giống như nước rút không, nơi chúng ta tập trung hoàn toàn vào việc đứng lên, làm những việc như chiến lược thử nghiệm của chúng ta địa điểm. Một thiết kế cấp cao để bắt đầu trước khi chúng tôi bắt đầu điền thông tin chi tiết và đảm bảo rằng chúng tôi có một bộ câu chuyện hoặc yêu cầu bắt đầu rõ ràng trước khi chúng tôi bắt đầu thu hút khán giả khác và sau đó tiến lên như một đội khi chúng tôi tiến lên. Luôn luôn có một chút thời gian chuẩn bị, vì vậy khá thường xuyên chúng ta sẽ có một lần chạy nước rút bằng 0 hoặc thậm chí chạy nước rút bằng không và một. Có thể là một chút của giai đoạn khởi động trước khi chúng tôi đạt được chuyến bay đầy đủ trong việc cung cấp giải pháp.

Chúng ta hãy nói về các mô hình dữ liệu trong bối cảnh này rất ngắn gọn. Khi mọi người nghĩ về các mô hình dữ liệu, họ thường nghĩ về một mô hình dữ liệu giống như một bức tranh về cách các phần thông tin khác nhau liên kết với nhau - đó chỉ là phần nổi của tảng băng chìm. Để thể hiện đầy đủ tinh thần về cách bạn thực sự muốn tiếp cận mô hình hóa dữ liệu - cho dù đó là sự phát triển nhanh và những thứ khác - bạn cần nhận ra rằng mô hình dữ liệu đó, nếu được thực hiện đúng, sẽ trở thành đặc điểm kỹ thuật đầy đủ của bạn về ý nghĩa của dữ liệu đó trong tổ chức và Làm thế nào nó được triển khai trong cơ sở dữ liệu phụ trợ. Khi tôi nói cơ sở dữ liệu, ý tôi không chỉ là cơ sở dữ liệu quan hệ mà chúng ta có thể đang sử dụng, mà trong các kiến ​​trúc ngày nay nơi chúng ta có dữ liệu lớn hoặc nền tảng NoQuery, vì tôi thích gọi chúng hơn. Ngoài ra, những cửa hàng dữ liệu lớn đó bởi vì chúng tôi có thể kết hợp rất nhiều kho dữ liệu khác nhau về việc tiêu thụ thông tin và đưa nó vào các giải pháp cũng như cách chúng tôi kiên trì hoặc lưu thông tin đó ra khỏi các giải pháp của mình.

Chúng tôi có thể làm việc với nhiều cơ sở dữ liệu hoặc nguồn dữ liệu đồng thời trong bối cảnh của một ứng dụng nhất định. Điều rất quan trọng là chúng ta muốn có một đặc tả kỹ thuật đầy đủ, vì vậy một đặc tả logic về ý nghĩa của điều này đối với quan điểm tổ chức chạy nước rút, các cấu trúc vật lý là gì về cách chúng ta thực sự xác định dữ liệu, các mối quan hệ giữa nó trong cơ sở dữ liệu của bạn, các ràng buộc toàn vẹn tham chiếu của bạn, kiểm tra các ràng buộc, tất cả các phần xác nhận mà bạn thường nghĩ về. Các siêu dữ liệu mô tả là vô cùng quan trọng. Làm thế nào để bạn biết làm thế nào để sử dụng dữ liệu trong các ứng dụng của bạn? Trừ khi bạn có thể định nghĩa nó và biết ý nghĩa của nó hoặc biết nó đến từ đâu để đảm bảo bạn đang tiêu thụ dữ liệu chính xác trong các ứng dụng đó - đảm bảo rằng chúng tôi có các quy ước đặt tên chính xác, định nghĩa đầy đủ, có nghĩa là không phải từ điển dữ liệu đầy đủ các bảng nhưng các cột bao gồm các bảng đó - và ghi chú triển khai chi tiết về cách chúng tôi sử dụng điều đó bởi vì chúng tôi cần xây dựng cơ sở kiến ​​thức này bởi vì ngay cả khi ứng dụng này được thực hiện, thông tin này sẽ được sử dụng cho các sáng kiến ​​khác vì vậy chúng tôi cần đảm bảo rằng chúng tôi có tất cả những gì được ghi nhận cho việc thực hiện trong tương lai.

Một lần nữa, chúng ta đi xuống những thứ như kiểu dữ liệu, khóa, chỉ mục, bản thân mô hình dữ liệu thể hiện rất nhiều quy tắc kinh doanh đi kèm. Các mối quan hệ không chỉ là ràng buộc giữa các bảng khác nhau; chúng thường giúp chúng tôi mô tả các quy tắc kinh doanh thực sự xung quanh cách dữ liệu đó hoạt động và cách thức hoạt động cùng nhau như một đơn vị gắn kết. Và tất nhiên, hạn chế giá trị là rất quan trọng. Bây giờ, tất nhiên, một trong những điều chúng ta liên tục phải đối phó, và nó ngày càng trở nên phổ biến hơn, là những thứ như quản trị dữ liệu. Vậy từ góc độ quản trị dữ liệu, chúng ta cũng cần xem xét, những gì chúng ta đang xác định ở đây? Chúng tôi muốn xác định những thứ như phân loại bảo mật. Những loại dữ liệu chúng ta đang đối phó? Điều gì sẽ được coi là quản lý dữ liệu chủ? Các cửa hàng giao dịch mà chúng tôi đang tạo ra là gì? Dữ liệu tham khảo nào chúng ta đang sử dụng trong các ứng dụng này? Chúng ta cần đảm bảo rằng nó được chụp đúng trong các mô hình của chúng ta. Và cũng xem xét chất lượng dữ liệu, có một số thông tin nhất định quan trọng đối với một tổ chức hơn những người khác.

Tôi đã tham gia vào các dự án nơi chúng tôi đã thay thế hơn một chục hệ thống cũ bằng các quy trình kinh doanh mới và thiết kế các ứng dụng và kho dữ liệu mới để thay thế chúng. Chúng tôi cần phải biết thông tin đến từ đâu. Đối với những thông tin quan trọng nhất, từ góc độ kinh doanh, nếu bạn nhìn vào slide mô hình dữ liệu cụ thể mà tôi đã có ở đây, bạn sẽ thấy các hộp dưới cùng trong các thực thể cụ thể này, chỉ là một tập hợp con nhỏ, tôi Thực sự đã có thể nắm bắt được giá trị kinh doanh. Cho dù cao, trung bình hay thấp đối với các loại điều này cho các cấu trúc khác nhau trong tổ chức. Và tôi cũng đã nắm bắt được những thứ như các lớp dữ liệu chủ, cho dù chúng là bảng chính, cho dù chúng là tham chiếu, nếu chúng là giao dịch. Vì vậy, chúng tôi có thể mở rộng siêu dữ liệu trong các mô hình của mình để cung cấp cho chúng tôi nhiều đặc điểm khác ngoài dữ liệu, điều này thực sự giúp chúng tôi với các sáng kiến ​​khác bên ngoài các dự án ban đầu và đưa nó về phía trước. Bây giờ đó là rất nhiều trong một slide, tôi sẽ đi qua phần còn lại khá nhanh.

Bây giờ tôi sẽ nói rất nhanh về những gì một người lập mô hình dữ liệu làm khi chúng ta trải qua những lần chạy nước rút khác nhau. Trước hết, một người tham gia đầy đủ trong các phiên lập kế hoạch chạy nước rút, nơi chúng tôi sẽ lấy câu chuyện của người dùng, cam kết những gì chúng tôi sẽ cung cấp trong lần chạy nước rút đó và tìm ra cách chúng tôi sẽ cấu trúc và phân phối nó. Điều tôi cũng đang làm với tư cách là người lập mô hình dữ liệu là tôi biết tôi sẽ làm việc ở các khu vực riêng biệt với các nhà phát triển khác nhau hoặc với những người khác nhau. Vì vậy, một trong những đặc điểm quan trọng mà chúng ta có thể có là khi chúng ta đang thực hiện một mô hình dữ liệu, chúng ta có thể chia mô hình dữ liệu đó thành các khung nhìn khác nhau, cho dù bạn gọi chúng là các lĩnh vực chủ đề hay mô hình con, là thuật ngữ của chúng ta. Vì vậy, khi chúng tôi xây dựng mô hình, chúng tôi cũng thể hiện nó theo các quan điểm của mô hình phụ khác nhau này để các đối tượng khác nhau chỉ nhìn thấy những gì có liên quan đến họ để họ có thể tập trung vào những gì họ đang phát triển và đưa ra. Vì vậy, tôi có thể có ai đó làm việc trên một phần lập lịch trình của ứng dụng, tôi có thể có ai đó đang làm việc trên một mục nhập đơn hàng nơi chúng tôi đang làm tất cả những điều này trong một lần chạy nước rút, nhưng tôi có thể cung cấp cho họ các quan điểm thông qua các mô hình con đó áp dụng cho khu vực mà họ đang làm việc. Và sau đó, chúng cuộn lên mô hình tổng thể và toàn bộ cấu trúc của các mô hình con để cung cấp cho các đối tượng khác nhau những gì họ cần xem.

Nguyên tắc cơ bản từ quan điểm mô hình hóa dữ liệu mà chúng ta muốn có là, luôn có một đường cơ sở mà chúng ta có thể quay trở lại bởi vì một trong những điều chúng ta cần có thể làm là, cho dù đó là vào cuối cuộc đua nước rút hay cuối cùng trong một số lần chạy nước rút, chúng tôi muốn biết chúng tôi đã bắt đầu từ đâu và luôn có một đường cơ sở để biết đâu là đồng bằng hoặc sự khác biệt của những gì chúng tôi tạo ra trong một lần chạy nước rút nhất định. Chúng tôi cũng cần đảm bảo rằng chúng tôi có thể có một sự thay đổi nhanh chóng. Nếu bạn tham gia với tư cách là người lập mô hình dữ liệu nhưng trong vai trò người gác cổng truyền thống là nói Không, không, bạn không thể làm điều đó trước tiên, chúng tôi phải làm tất cả những thứ này trước, bạn sẽ bị loại khỏi nhóm khi bạn thực sự cần trở thành người tham gia tích cực trong tất cả các nhóm phát triển nhanh. Điều đó có nghĩa là một số thứ rơi ra khỏi chiếc xe đang chạy nước rút và bạn chọn chúng trong những lần chạy nước rút sau.

Ví dụ, bạn có thể tập trung vào các cấu trúc dữ liệu chỉ để phát triển, ví dụ như phần nhập đơn hàng mà tôi đang nói đến. Trong lần chạy nước rút sau, bạn có thể quay lại và điền dữ liệu như một số tài liệu cho từ điển dữ liệu xung quanh một số tạo tác mà bạn đã tạo. Bạn sẽ không hoàn thành định nghĩa đó trong một lần chạy nước rút; bạn sẽ tiếp tục phát triển các sản phẩm của mình dần dần bởi vì sẽ có lúc bạn có thể điền thông tin đó làm việc với các nhà phân tích kinh doanh khi các nhà phát triển bận rộn xây dựng các ứng dụng và sự kiên trì xung quanh các cửa hàng dữ liệu đó. Bạn muốn tạo điều kiện và không phải là nút cổ chai. Có nhiều cách khác nhau mà chúng tôi làm việc với các nhà phát triển. Đối với một số thứ chúng tôi có các mẫu thiết kế để chúng tôi là người tham gia đầy đủ, vì vậy chúng tôi có thể có một mẫu thiết kế nơi chúng tôi sẽ nói rằng chúng tôi sẽ đưa nó vào mô hình, chúng tôi sẽ đẩy nó ra cơ sở dữ liệu hộp cát của nhà phát triển và sau đó họ có thể bắt đầu làm việc với nó và yêu cầu thay đổi điều đó

Có thể có những lĩnh vực khác mà các nhà phát triển đang làm việc, họ có thứ gì đó họ đang làm và họ đang tạo ra một số thứ để họ thử một số thứ trong môi trường phát triển của chính họ. Chúng tôi lấy cơ sở dữ liệu mà họ đã làm việc, đưa nó vào công cụ lập mô hình của chúng tôi, so sánh với các mô hình mà chúng tôi có và sau đó giải quyết và đẩy các thay đổi trở lại để chúng có thể cấu trúc lại mã của chúng để chúng tuân theo cấu trúc dữ liệu phù hợp mà chúng ta cần. Bởi vì họ có thể đã tạo ra một số thứ mà chúng tôi đã có ở nơi khác, vì vậy chúng tôi đảm bảo rằng họ đang làm việc với các nguồn dữ liệu phù hợp. Chúng tôi chỉ tiếp tục lặp lại tất cả các cách này để chạy nước rút để chúng tôi có được các dữ liệu cung cấp đầy đủ, tài liệu đầy đủ và định nghĩa của tất cả các cấu trúc dữ liệu mà chúng tôi đang sản xuất.

Các dự án nhanh nhẹn thành công nhất mà tôi đã tham gia về mặt giao hàng rất tốt là, chúng tôi đã có một triết lý, mô hình hóa tất cả các thay đổi đối với đặc tả cơ sở dữ liệu vật lý đầy đủ. Về bản chất, mô hình dữ liệu trở thành cơ sở dữ liệu được triển khai mà bạn đang làm việc với bất kỳ thứ gì mới mà chúng tôi đang tạo và có các tài liệu tham khảo đầy đủ về các cửa hàng dữ liệu khác nếu chúng tôi đang tiêu thụ từ các cơ sở dữ liệu bên ngoài khác. Là một phần trong đó chúng tôi đang tạo ra các kịch bản gia tăng so với việc tạo ra một thế hệ đầy đủ mọi lúc. Và chúng tôi đang sử dụng các mẫu thiết kế của mình để mang đến cho chúng tôi sự gia tăng nhanh chóng về mặt mọi thứ đang diễn ra trong giai đoạn nước rút với các nhóm phát triển khác nhau mà chúng tôi đang làm việc.

Trong các hoạt động chạy nước rút cũng vậy, một lần nữa là cơ sở để so sánh / hợp nhất, vì vậy chúng ta hãy lấy ý tưởng mô hình hóa từng thay đổi. Mỗi khi chúng tôi thực hiện một thay đổi, điều chúng tôi muốn làm là chúng tôi muốn mô hình hóa sự thay đổi và điều rất quan trọng, điều còn thiếu từ mô hình dữ liệu cho đến gần đây, trên thực tế, cho đến khi chúng tôi giới thiệu lại, là khả năng liên kết mô hình hóa các tác vụ và các sản phẩm của bạn với các câu chuyện của người dùng và các tác vụ thực sự gây ra những thay đổi đó xảy ra. Chúng tôi muốn có thể kiểm tra các thay đổi mô hình của mình, giống như cách các nhà phát triển kiểm tra mã của họ, tham khảo các câu chuyện người dùng mà chúng tôi có để chúng tôi biết lý do tại sao chúng tôi thực hiện thay đổi ngay từ đầu, đó là điều chúng tôi làm. Khi chúng tôi làm điều đó, chúng tôi tạo ra các tập lệnh DDL gia tăng của chúng tôi và đăng chúng để chúng có thể được chọn với các phân phối phát triển khác và được kiểm tra vào giải pháp xây dựng của chúng tôi. Một lần nữa, chúng tôi có thể có một mô hình hoặc làm việc với nhiều nhóm. Và như tôi đã nói, một số thứ được tạo ra bởi nhà mô hình dữ liệu, những thứ khác được tạo ra bởi các nhà phát triển và chúng tôi gặp nhau ở giữa để đưa ra thiết kế tổng thể tốt nhất và đẩy nó về phía trước và đảm bảo nó được thiết kế đúng trong chúng tôi cấu trúc dữ liệu tổng thể. Chúng ta phải duy trì kỷ luật đảm bảo rằng chúng ta có tất cả các cấu trúc phù hợp trong mô hình dữ liệu của mình khi chúng ta tiến lên, bao gồm những thứ như giá trị null và không null, các ràng buộc tham chiếu, về cơ bản kiểm tra các ràng buộc, tất cả những điều chúng ta thường nghĩ về .

Bây giờ chúng ta hãy nói về một vài ảnh chụp màn hình của một số công cụ giúp chúng ta làm điều này. Điều tôi nghĩ là quan trọng là có kho lưu trữ hợp tác đó, vì vậy những gì chúng ta có thể làm với tư cách là người lập mô hình dữ liệu - và đây là một phần của mô hình dữ liệu trong nền - là khi chúng ta đang làm việc trên những thứ chúng ta muốn đảm bảo rằng chúng ta có thể chỉ làm việc với các đối tượng mà chúng ta cần để có thể thay đổi, thực hiện sửa đổi, tạo tập lệnh DDL của chúng tôi cho những thay đổi mà chúng tôi đã thực hiện khi kiểm tra lại mọi thứ. Vì vậy, những gì chúng tôi có thể làm là, trong ER Studio là một ví dụ, chúng ta có thể kiểm tra các đối tượng hoặc nhóm đối tượng để làm việc, chúng ta không phải kiểm tra toàn bộ mô hình hoặc mô hình con, chúng ta có thể kiểm tra chỉ những điều mà chúng ta quan tâm. Những gì chúng tôi muốn sau đó là lúc trả phòng hoặc thời gian nhận phòng - chúng tôi thực hiện cả hai cách vì các nhóm phát triển khác nhau làm việc theo những cách khác nhau. Chúng tôi muốn đảm bảo rằng chúng tôi liên kết rằng với câu chuyện hoặc tác vụ người dùng đang thúc đẩy các yêu cầu cho điều này và đó sẽ là cùng một câu chuyện hoặc nhiệm vụ người dùng mà các nhà phát triển sẽ phát triển và kiểm tra mã của họ.

Vì vậy, đây là một đoạn rất nhanh của một vài màn hình của một trong những trung tâm quản lý thay đổi của chúng tôi. Điều này làm gì, tôi sẽ không đi sâu vào chi tiết ở đây, nhưng những gì bạn đang thấy là câu chuyện hoặc tác vụ của người dùng và được thụt vào bên dưới mỗi một trong số những bạn đang xem các bản ghi thay đổi thực tế - chúng tôi đã tạo một bản ghi thay đổi tự động khi chúng tôi thực hiện đăng ký và trả phòng và chúng tôi cũng có thể mô tả thêm về hồ sơ thay đổi đó. Nó được liên kết với nhiệm vụ, chúng tôi có thể có nhiều thay đổi cho mỗi nhiệm vụ, như bạn mong đợi. Và khi chúng ta đi vào hồ sơ thay đổi đó, chúng ta có thể xem xét nó và quan trọng hơn là, chúng ta đã thực sự thay đổi điều gì? Đối với câu chuyện cụ thể này, câu chuyện nổi bật ở đó tôi có một loại thay đổi đã được thực hiện và khi tôi nhìn vào bản ghi thay đổi thực tế, nó đã xác định các phần riêng lẻ trong mô hình đã thay đổi. Tôi đã thay đổi một vài thuộc tính ở đây, đánh giá lại chúng và nó mang lại cho các chế độ xem cần phải thay đổi phụ thuộc vào các thuộc tính đó để chúng sẽ được tạo trong DLL tăng dần. Nó không chỉ mô hình hóa trên các đối tượng cơ sở, mà một công cụ mô hình hóa công suất cao như thế này cũng phát hiện các thay đổi phải được gợn qua các đối tượng phụ thuộc trong cơ sở dữ liệu hoặc mô hình dữ liệu.

Nếu chúng tôi đang làm việc với các nhà phát triển và chúng tôi làm điều này trong một vài điều khác nhau, đó là làm một cái gì đó trong hộp cát của họ và chúng tôi muốn so sánh và xem sự khác biệt ở đâu, chúng tôi sử dụng các khả năng so sánh / hợp nhất ở bên phải và bên trái bên. Chúng ta có thể nói, Đây là mô hình của chúng tôi ở bên trái, đây là cơ sở dữ liệu của họ ở bên phải, cho tôi thấy sự khác biệt. Sau đó, chúng tôi có thể chọn và chọn cách chúng tôi giải quyết những khác biệt đó, cho dù chúng tôi có đẩy mọi thứ vào cơ sở dữ liệu hay không có một số thứ họ có trong cơ sở dữ liệu mà chúng tôi đưa vào mô hình. Chúng ta có thể đi hai chiều để có thể đồng thời cập nhật cả hai hướng và nguồn và sau đó tạo ra các tập lệnh DDL gia tăng để triển khai các thay đổi đó ra chính môi trường cơ sở dữ liệu, điều này cực kỳ quan trọng. Những gì chúng ta cũng có thể làm là chúng ta cũng có thể sử dụng khả năng so sánh và hợp nhất này tại bất kỳ thời điểm nào, nếu chúng ta đang chụp nhanh trên đường đi, chúng ta luôn có thể so sánh sự bắt đầu của một lần chạy nước rút để bắt đầu hoặc kết thúc cuộc chạy nước rút khác để chúng ta có thể thấy sự thay đổi hoàn toàn của những gì đã được thực hiện trong một lần chạy nước rút phát triển nhất định hoặc qua một loạt các lần chạy nước rút.

Đây là một ví dụ rất nhanh về tập lệnh thay đổi, bất kỳ ai trong số các bạn đang làm việc với cơ sở dữ liệu đều sẽ thấy loại điều này, đây là điều chúng ta có thể rút ra khỏi mã dưới dạng tập lệnh thay đổi để chúng tôi chắc chắn rằng chúng tôi chắc chắn rằng giữ lại những thứ ở đây Những gì tôi rút ra ở đây, chỉ để giảm sự lộn xộn, là những gì chúng tôi cũng làm với các tập lệnh thay đổi này là chúng tôi giả sử cũng có dữ liệu trong các bảng đó, vì vậy chúng tôi cũng sẽ tạo ra DML sẽ lấy thông tin của các bảng tạm thời và cũng đẩy nó trở lại vào các cấu trúc dữ liệu mới để chúng tôi đang xem xét không chỉ các cấu trúc mà cả dữ liệu mà chúng tôi có thể đã có trong các cấu trúc đó.

Sẽ nói rất nhanh về các hệ thống xây dựng tự động bởi vì khi chúng tôi thực hiện một dự án nhanh, chúng tôi thường làm việc với các hệ thống xây dựng tự động, nơi chúng tôi cần kiểm tra các sản phẩm khác nhau để đảm bảo rằng chúng tôi không phá vỡ các bản dựng của mình. Điều đó có nghĩa là chúng tôi đồng bộ hóa các sản phẩm phân phối, những kịch bản thay đổi mà tôi đã nói về tập lệnh DDL cần phải được kiểm tra, mã ứng dụng tương ứng cần phải được kiểm tra cùng lúc và rất nhiều nhà phát triển hiện nay không phải là được thực hiện với SQL trực tiếp đối với cơ sở dữ liệu và loại điều đó. Chúng tôi thường xuyên sử dụng các khung kiên trì hoặc xây dựng các dịch vụ dữ liệu. Chúng tôi cần đảm bảo rằng các thay đổi cho các khung hoặc dịch vụ đó được kiểm tra cùng một lúc. Họ đi vào một hệ thống xây dựng tự động trong một số tổ chức và nếu việc xây dựng bị phá vỡ, theo phương pháp nhanh, tất cả sẽ sẵn sàng sửa chữa bản dựng đó trước khi chúng tôi tiến lên để chúng tôi biết rằng chúng tôi có giải pháp làm việc trước khi chúng tôi tiến xa hơn. Và một trong những dự án mà tôi đã tham gia, chúng tôi đã thực hiện điều này đến mức cực đoan - nếu việc xây dựng bị phá vỡ, chúng tôi thực sự đã gắn với một số máy tính trong khu vực của chúng tôi, nơi chúng tôi được sử dụng cho người dùng doanh nghiệp, chúng tôi có đèn đỏ nhấp nháy Giống như đầu xe cảnh sát. Và nếu công trình bị phá vỡ, những ánh sáng nhấp nháy màu đỏ đó bắt đầu tắt và chúng tôi biết đó là tất cả trên tay: sửa chữa công trình và sau đó tiến hành những gì chúng tôi đang làm.

Tôi muốn nói về những thứ khác, và đây là một khả năng độc đáo của ER Studio, nó thực sự hữu ích khi chúng tôi cố gắng xây dựng các tạo phẩm này với tư cách là nhà phát triển cho các ranh giới bền bỉ này, chúng tôi có một khái niệm gọi là đối tượng dữ liệu kinh doanh và những gì cho phép chúng tôi làm là nếu bạn xem mô hình dữ liệu rất đơn giản này làm ví dụ, nó cho phép chúng ta gói gọn các thực thể hoặc nhóm thực thể cho các ranh giới bền vững. Trường hợp chúng ta với tư cách là người lập mô hình dữ liệu có thể nghĩ về một cái gì đó giống như tiêu đề đơn đặt hàng và thứ tự sắp xếp và các bảng chi tiết khác sẽ liên kết với nó theo cách chúng ta xây dựng nó và các nhà phát triển dịch vụ dữ liệu của chúng ta cần biết mọi thứ tồn tại như thế nào với những dữ liệu khác nhau đó cấu trúc. Các nhà phát triển của chúng tôi đang nghĩ về những thứ như đơn đặt hàng như một đối tượng tổng thể và hợp đồng của họ với cách họ tạo ra các đối tượng cụ thể đó. Chúng tôi có thể tiết lộ chi tiết kỹ thuật đó để mọi người xây dựng máy chủ dữ liệu có thể thấy những gì bên dưới nó và chúng tôi có thể bảo vệ các đối tượng khác khỏi sự phức tạp để họ chỉ nhìn thấy các đối tượng cấp cao khác nhau, cũng hoạt động rất tốt để giao tiếp với doanh nghiệp các nhà phân tích và các bên liên quan kinh doanh khi chúng ta đang nói về sự tương tác của các khái niệm kinh doanh khác nhau là tốt.

Điều tốt đẹp về điều đó cũng là chúng tôi mở rộng và thu gọn những thứ này để chúng tôi có thể duy trì mối quan hệ giữa các đối tượng bậc cao hơn mặc dù chúng bắt nguồn từ các cấu trúc có trong chính các đối tượng dữ liệu kinh doanh đó. Bây giờ là một người lập mô hình, đi đến cuối cuộc đua nước rút, vào cuối cuộc đua nước rút, tôi có rất nhiều việc cần làm, mà tôi gọi là việc dọn phòng của mình cho lần chạy nước rút tiếp theo. Mỗi lần chạy nước rút tôi tạo ra cái mà tôi gọi là Bản phát hành có tên - điều đó mang lại cho tôi cơ sở của tôi cho những gì tôi có bây giờ khi kết thúc bản phát hành. Vì vậy, điều đó có nghĩa là đó là đường cơ sở của tôi trong tương lai, tất cả các đường cơ sở hoặc Bản phát hành được đặt tên mà tôi tạo và lưu trong kho lưu trữ của mình, tôi có thể sử dụng để so sánh / hợp nhất để tôi luôn có thể so sánh với bất kỳ đầu chạy nước rút nào từ bất kỳ lần chạy nước rút nào khác, mà là rất quan trọng để biết những thay đổi của bạn đối với mô hình dữ liệu của bạn trên đường đi qua hành trình của nó.

Tôi cũng tạo một tập lệnh DDL delta bằng cách sử dụng so sánh / hợp nhất lại từ đầu đến cuối nước rút. Tôi có thể đã kiểm tra trong một loạt các kịch bản gia tăng, nhưng nếu tôi cần nó bây giờ tôi có một kịch bản mà tôi có thể triển khai để đứng lên các hộp cát khác để tôi có thể nói đây là những gì chúng tôi đã có khi bắt đầu chạy nước rút, đẩy thông qua đó, xây dựng cơ sở dữ liệu như một hộp cát để bắt đầu cho lần chạy nước rút tiếp theo và chúng ta cũng có thể sử dụng những thứ đó để làm những việc như các trường hợp QA nổi bật và cuối cùng tất nhiên chúng ta muốn đẩy các thay đổi của mình ra sản xuất để chúng ta có nhiều thứ đang diễn ra đồng thời. Một lần nữa, chúng tôi tham gia đầy đủ vào kế hoạch chạy nước rút và hồi tưởng, quá trình hồi tưởng thực sự là những bài học kinh nghiệm và điều đó cực kỳ quan trọng, bởi vì bạn có thể đi rất nhanh trong khi nhanh nhẹn, bạn cần dừng lại và ăn mừng những thành công, như bây giờ. Tìm hiểu điều gì là sai, làm cho nó tốt hơn vào lần tới, nhưng cũng ăn mừng những điều đã đi đúng và xây dựng chúng khi bạn tiếp tục tiến về phía trước trong những lần chạy nước rút tiếp theo.

Bây giờ tôi sẽ nói rất nhanh về giá trị kinh doanh. Có một dự án mà tôi đã tham gia từ nhiều năm trước, bắt đầu như một dự án nhanh, và đó là một dự án cực đoan, vì vậy đó là một nhóm tự tổ chức thuần túy, nơi chỉ có các nhà phát triển đang làm mọi thứ. Tóm lại, dự án này đã bị đình trệ và họ thấy rằng họ đã dành nhiều thời gian hơn cho việc khắc phục và sửa chữa các khiếm khuyết đã được xác định so với việc họ đẩy mạnh nhiều chức năng hơn và trên thực tế, khi họ nhìn vào nó trên các biểu đồ chi tiết, họ sẽ phải kéo dài dự án sáu tháng với chi phí rất lớn. Và khi chúng tôi xem xét nó, cách để khắc phục vấn đề là sử dụng một công cụ mô hình hóa dữ liệu phù hợp với một người lập mô hình dữ liệu lành nghề có liên quan đến chính dự án.

Nếu bạn nhìn vào thanh dọc này trên biểu đồ cụ thể này, thì nó đang hiển thị các khuyết tật tích lũy so với các đối tượng tích lũy và tôi đang nói về các đối tượng dữ liệu hoặc các cấu trúc được tạo như các bảng có các ràng buộc và các loại điều đó, nếu bạn nhìn vào trước khi trình mô hình hóa dữ liệu được giới thiệu, số lượng lỗi thực sự vượt quá và bắt đầu tạo ra một khoảng cách so với số lượng đối tượng thực tế được tạo ra cho đến thời điểm đó. Sau tuần 21, đó là khi người lập mô hình dữ liệu bước vào, tái cấu trúc mô hình dữ liệu dựa trên những gì cần sửa chữa một số thứ và sau đó bắt đầu mô hình hóa như một phần của nhóm dự án trong tương lai, những thay đổi khi dự án đó được đẩy mạnh . Và bạn đã thấy một sự thay đổi rất nhanh rằng trong khoảng một nửa nước rút, chúng ta đã thấy một sự gia tăng lớn về số lượng các đối tượng và cấu trúc dữ liệu đang được tạo và xây dựng bởi vì chúng ta đang tạo ra một công cụ mô hình hóa dữ liệu thay vì một nhà phát triển xây dựng chúng trong một môi trường và chúng đúng bởi vì chúng có tính toàn vẹn tham chiếu thích hợp và các cấu trúc khác cần có. Mức độ khuyết tật chống lại những người gần như bằng phẳng. Bằng cách thực hiện hành động thích hợp đó và đảm bảo rằng mô hình hóa dữ liệu đã được tham gia đầy đủ, dự án đã được phân phối đúng thời gian với mức chất lượng cao hơn nhiều, và trên thực tế, nó sẽ không được thực hiện nếu các bước đó không diễn ra. Có rất nhiều thất bại nhanh nhẹn ngoài kia, cũng có rất nhiều thành công nhanh nhẹn nếu bạn có được đúng người trong các vai trò phù hợp. Tôi là một người ủng hộ nhanh nhẹn như một môn học hoạt động, nhưng bạn cần chắc chắn rằng bạn có kỹ năng của tất cả các nhóm phù hợp tham gia với tư cách là nhóm dự án của bạn khi bạn tiến lên một loại nỗ lực nhanh nhẹn.

Để tóm tắt, kiến ​​trúc sư dữ liệu và người lập mô hình phải tham gia vào tất cả các dự án phát triển; chúng thực sự là chất keo kết dính mọi thứ lại với nhau vì như các nhà mô hình hóa và kiến ​​trúc sư chúng ta hiểu, không chỉ các cấu trúc dữ liệu của dự án phát triển nhất định, mà còn là nơi dữ liệu tồn tại trong tổ chức và nơi chúng ta có thể lấy dữ liệu đó từ đó và cả cách thức dữ liệu sẽ được sử dụng và sử dụng bên ngoài ứng dụng cụ thể mà chúng tôi đang làm việc. Chúng tôi hiểu các mối quan hệ dữ liệu phức tạp và điều tối quan trọng là có thể tiến lên và cũng từ góc độ quản trị để ánh xạ tài liệu và hiểu toàn cảnh dữ liệu của bạn trông như thế nào.

Nó giống như sản xuất; Tôi đến từ một nền tảng sản xuất. Cuối cùng, bạn không thể kiểm tra chất lượng vào thứ gì đó - bạn cần xây dựng chất lượng cho thiết kế của mình và trên đường đi, và mô hình hóa dữ liệu là cách xây dựng chất lượng đó vào thiết kế theo cách hiệu quả và tiết kiệm chi phí . Và một lần nữa, một điều cần nhớ - và điều này không phải là trite, nhưng đó là sự thật - các ứng dụng đến và đi, dữ liệu là tài sản quan trọng của công ty và nó vượt qua tất cả các ranh giới ứng dụng đó. Mỗi khi bạn đưa vào một ứng dụng, có lẽ bạn sẽ được yêu cầu bảo vệ dữ liệu khỏi các ứng dụng khác trước đây, vì vậy chúng tôi chỉ cần nhớ rằng đó là tài sản quan trọng của công ty mà chúng tôi vẫn duy trì theo thời gian.

Và đó là nó! Từ đây chúng tôi sẽ đưa ra nhiều câu hỏi hơn.

Eric Kavanagh: Được rồi, tốt, hãy để tôi ném nó cho Robin trước. Và sau đó, Dez, tôi chắc chắn bạn có một vài câu hỏi. Mang nó đi, Robin.

Tiến sĩ Robin Bloor: Được rồi. Thành thật mà nói, tôi chưa bao giờ có bất kỳ vấn đề nào với các phương pháp phát triển nhanh và dường như với tôi những gì bạn đang làm ở đây có ý nghĩa nổi bật. Tôi nhớ rằng đã nhìn vào một cái gì đó vào những năm 1980, thực sự chỉ ra rằng vấn đề mà bạn thực sự gặp phải trong điều kiện của một dự án vượt khỏi tầm kiểm soát, là bình thường nếu bạn để một sai lầm tồn tại ngoài một giai đoạn cụ thể. Việc khắc phục sẽ trở nên ngày càng khó khăn hơn nếu bạn không thực hiện đúng giai đoạn đó, vì vậy một trong những điều bạn đang làm ở đây - và tôi nghĩ đây là slide - nhưng là một trong những điều bạn đang làm ở đây trong nước rút số 0, theo ý kiến ​​của tôi, là hoàn toàn quan trọng bởi vì bạn thực sự đang cố gắng để các sản phẩm giao hàng được ghim ở đó. Và nếu bạn không nhận được các sản phẩm được ghim, thì các sản phẩm đó sẽ thay đổi hình dạng.

Đó là, ý kiến ​​của tôi. Đó cũng là ý kiến ​​của tôi - Tôi thực sự không có bất kỳ tranh luận nào với ý tưởng rằng bạn phải đưa mô hình hóa dữ liệu đến một mức độ chi tiết nhất định trước khi bạn trải qua. Những gì tôi muốn bạn thử và làm bởi vì tôi không hiểu hoàn toàn về nó, chỉ mô tả một trong những dự án này về quy mô của nó, về cách thức nó chảy, về mặt ai, bạn biết, Trường hợp các vấn đề được cắt lên, họ đã được giải quyết? Bởi vì tôi nghĩ rằng slide này là khá nhiều trái tim của nó và nếu bạn có thể giải thích thêm một chút về điều đó, tôi sẽ rất biết ơn.

Ron Huizenga: Chắc chắn, và tôi sẽ sử dụng một vài dự án ví dụ. Một trong số đó, đã đi ra khỏi đường ray được đưa trở lại bằng cách thực sự có đúng người tham gia và thực hiện mô hình dữ liệu và mọi thứ thực sự là một cách để đảm bảo rằng thiết kế được hiểu rõ hơn và rõ ràng chúng tôi có thiết kế triển khai tốt hơn trên đường đi bằng cách mô hình hóa nó. Bởi vì khi bạn mô hình hóa nó, bạn biết, bạn có thể tạo DDL của mình và mọi thứ từ phía sau và ra khỏi công cụ thay vì phải gắn kết xây dựng như mọi người thường làm bằng cách đi thẳng vào môi trường cơ sở dữ liệu. Và những điều điển hình sẽ xảy ra với các nhà phát triển là họ sẽ đến đó và họ sẽ nói, được thôi, tôi cần những bảng này. Hãy nói rằng chúng tôi đang thực hiện các mục nhập đơn hàng. Vì vậy, họ có thể tạo tiêu đề đơn hàng và các bảng chi tiết đơn hàng và các loại điều đó. Nhưng họ sẽ thường xuyên quên hoặc bỏ qua để đảm bảo rằng các ràng buộc ở đó để thể hiện các mối quan hệ khóa ngoài. Họ có thể không có chìa khóa chính xác. Các quy ước đặt tên cũng có thể bị nghi ngờ. Tôi không biết bao nhiêu lần tôi đã đi vào một môi trường, ví dụ, nơi bạn thấy một loạt các bảng khác nhau với các tên khác nhau, nhưng sau đó các tên cột trong các bảng đó giống như ID, Tên hoặc bất cứ thứ gì, vì vậy chúng Tôi thực sự đã mất bối cảnh mà không có bảng chính xác đó là gì.

Vì vậy, thông thường khi chúng tôi lập mô hình dữ liệu, chúng tôi sẽ đảm bảo rằng chúng tôi sẽ áp dụng các quy ước đặt tên phù hợp cho tất cả các tạo phẩm được tạo ra trong DDL. Nhưng để cụ thể hơn về bản chất của các dự án, nói chung, tôi đang nói về những sáng kiến ​​khá lớn. Một trong số đó là dự án chuyển đổi kinh doanh trị giá 150 triệu đô la, nơi chúng tôi đã thay thế hơn một chục hệ thống cũ. Chúng tôi đã có năm đội nhanh nhẹn khác nhau diễn ra cùng một lúc. Tôi có một nhóm kiến ​​trúc dữ liệu đầy đủ, vì vậy tôi có các nhà lập mô hình dữ liệu từ nhóm của mình được nhúng vào mỗi nhóm trong khu vực ứng dụng khác và chúng tôi đã làm việc với sự kết hợp của các chuyên gia kinh doanh nội bộ biết vấn đề này, đang làm câu chuyện của người dùng cho các yêu cầu chính họ. Chúng tôi đã có các nhà phân tích kinh doanh trong mỗi nhóm thực sự mô hình hóa quy trình kinh doanh, với sơ đồ hoạt động hoặc sơ đồ quy trình kinh doanh, giúp làm rõ hơn câu chuyện của người dùng với người dùng trước khi họ bị tiêu thụ bởi nhóm còn lại.

Và sau đó, tất nhiên, các nhà phát triển đang xây dựng mã ứng dụng trên đó. Và chúng tôi cũng đang làm việc với nhau, tôi nghĩ rằng đó là bốn nhà cung cấp tích hợp hệ thống khác nhau đang xây dựng các phần khác nhau của ứng dụng cũng như một nhóm đang xây dựng các dịch vụ dữ liệu, nhóm kia đang xây dựng logic ứng dụng trong một lĩnh vực, một nhóm khác có chuyên môn trong một lĩnh vực kinh doanh khác là xây dựng logic ứng dụng trong lĩnh vực đó. Vì vậy, chúng tôi đã có một sự hợp tác của những người đang làm việc trong dự án này. Trong đó, cụ thể là chúng tôi có 150 người trên bờ trong đội và 150 tài nguyên khác ở ngoài khơi trong đội đang hợp tác chạy nước rút hai tuần để loại bỏ thứ này. Và để làm được điều đó, bạn cần đảm bảo rằng bạn đang bắn vào tất cả các xi-lanh và mọi người đều được đồng bộ hóa tốt về mặt sản phẩm của họ, và bạn đã đặt lại thường xuyên để đảm bảo rằng chúng tôi đã hoàn thành việc cung cấp tất cả các vật phẩm cần thiết vào cuối mỗi lần chạy nước rút.

Tiến sĩ Robin Bloor: Thật ấn tượng. Và chỉ để biết thêm một chút chi tiết về điều đó - bạn đã kết thúc với một bản hoàn chỉnh, tôi sẽ gọi gì, bản đồ MDM của toàn bộ khu vực dữ liệu ở cuối dự án đó?

Ron Huizenga: Chúng tôi đã có một mô hình dữ liệu hoàn chỉnh đã bị phá vỡ với sự phân tách giữa tất cả các lĩnh vực kinh doanh khác nhau. Các từ điển dữ liệu về các định nghĩa đầy đủ giảm một chút ngắn. Chúng tôi đã có hầu hết các bảng được xác định; chúng tôi đã có hầu hết các cột được định nghĩa là chính xác những gì chúng có nghĩa. Có một số thứ không có ở đó và thật thú vị, rất nhiều trong số đó là những thông tin đến từ các hệ thống cũ, sau khi kết thúc phạm vi dự án, nó vẫn được ghi nhận là một bộ chuyển tiếp Các hiện vật, như nó đã được, bên ngoài dự án, bởi vì đó là thứ cần được duy trì bởi tổ chức trong tương lai. Vì vậy, cùng lúc đó, tổ chức đã tăng quan điểm về tầm quan trọng của quản trị dữ liệu bởi vì chúng tôi đã thấy rất nhiều thiếu sót trong các hệ thống cũ và những nguồn dữ liệu kế thừa mà chúng tôi đang cố gắng sử dụng vì chúng không được ghi nhận. Trong rất nhiều trường hợp, chúng tôi chỉ có cơ sở dữ liệu mà chúng tôi phải đảo ngược kỹ sư và cố gắng tìm ra những gì ở đó và thông tin đó để làm gì.

Tiến sĩ Robin Bloor: Nó không làm tôi ngạc nhiên, khía cạnh đặc biệt của nó. Quản trị dữ liệu là, hãy gọi nó là một mối quan tâm rất hiện đại và tôi nghĩ, thực sự, có rất nhiều công việc mà, giả sử, nên được thực hiện trong lịch sử về quản trị dữ liệu. Không bao giờ là vì bạn có thể, loại, không thể làm điều đó. Nhưng khi tài nguyên dữ liệu tăng lên và phát triển, cuối cùng bạn không thể.

Dù sao, tôi sẽ chuyển qua Dez vì tôi nghĩ rằng tôi đã có thời gian quy định. Dez?

Dez Blanchfield: Vâng, cảm ơn bạn. Thông qua toàn bộ điều này, tôi đang theo dõi và nghĩ với bản thân mình rằng chúng ta đang nói về việc nhìn thấy sự nhanh nhẹn được sử dụng trong sự tức giận theo nhiều cách. Mặc dù điều đó có ý nghĩa tiêu cực; Tôi có nghĩa là theo một cách tích cực. Có thể bạn có thể chỉ cho chúng tôi một kịch bản, ý tôi là, có hai nơi tôi có thể thấy đây là một bộ hoàn hảo: một là những dự án mới cần được thực hiện từ ngày đầu tiên, nhưng tôi nghĩ, theo kinh nghiệm của tôi, nó thường xuyên trường hợp khi các dự án đủ lớn để điều này là cần thiết theo nhiều cách, có một thách thức thú vị giữa việc dán hai thế giới, phải không? Bạn có thể cung cấp cho chúng tôi bất kỳ cái nhìn sâu sắc nào về một số câu chuyện thành công mà bạn đã thấy khi bạn tham gia vào một tổ chức, điều rõ ràng là họ đã có một cuộc đụng độ nhẹ giữa hai thế giới và bạn đã có thể đặt thành công Điều này tại chỗ và mang các dự án lớn lại với nhau, nơi họ có thể đã đi trên đường ray? Tôi biết đó là một câu hỏi rất rộng nhưng tôi chỉ tự hỏi liệu có một trường hợp cụ thể nào mà bạn có thể, sắp xếp, chỉ ra nơi bạn nói, bạn biết đấy, chúng tôi đã đặt tất cả những điều này và nó đã mang tất cả nhóm phát triển cùng với nhóm dữ liệu và chúng tôi, sắp xếp, đã giải quyết một cái gì đó có thể đã chìm thuyền?

Ron Huizenga: Chắc chắn, và trên thực tế, một dự án tình cờ là một dự án đường ống là dự án mà tôi đã đề cập đến nơi tôi chỉ ra biểu đồ đó với các khiếm khuyết trước và sau khi mô hình hóa dữ liệu có liên quan. Rất thường xuyên, và có những khái niệm định sẵn, đặc biệt là nếu mọi thứ xuất hiện từ góc độ phát triển hoàn toàn, đó chỉ là các nhà phát triển tham gia vào các dự án nhanh nhẹn này để cung cấp các ứng dụng. Vì vậy, những gì đã xảy ra ở đó, tất nhiên, là họ đã thoát ra khỏi đường ray và các vật phẩm dữ liệu của họ nói riêng, hoặc các sản phẩm cung cấp dữ liệu mà họ đang sản xuất, không đạt được chất lượng và thực sự giải quyết mọi thứ nói chung. Và thường có quan niệm sai lầm rằng các nhà lập mô hình dữ liệu sẽ làm chậm các dự án và họ sẽ làm nếu nhà mô hình dữ liệu không có thái độ đúng đắn. Giống như tôi nói, bạn phải mất đi - đôi khi có những người lập mô hình dữ liệu có thái độ người gác cổng truyền thống đó, ở đây, chúng tôi ở đây để kiểm soát cấu trúc dữ liệu trông như thế nào, và tâm lý đó phải biến mất. Bất kỳ ai tham gia vào phát triển nhanh, và đặc biệt là người lập mô hình dữ liệu, phải đảm nhận vai trò là người hỗ trợ để thực sự giúp các nhóm tiến lên. Và cách tốt nhất để minh họa điều đó là rất nhanh chóng cho các đội thấy họ có thể làm việc hiệu quả như thế nào bằng cách mô hình hóa các thay đổi trước tiên. Và một lần nữa, đó là lý do tại sao tôi nói về sự hợp tác.

Có một số điều mà chúng ta có thể mô hình hóa đầu tiên và tạo DDL để đẩy ra cho các nhà phát triển. Chúng tôi cũng muốn đảm bảo rằng họ không cảm thấy như bị hạn chế. Vì vậy, nếu có những thứ họ đang làm việc, hãy để họ tiếp tục làm việc trong các hộp cát phát triển của họ, bởi vì đó là nơi các nhà phát triển đang làm việc trên máy tính để bàn của họ hoặc cơ sở dữ liệu khác để thực hiện một số thay đổi khi họ đang thử nghiệm mọi thứ. Và cộng tác với họ và nói rằng, Được rồi, làm việc với điều đó. Họ sẽ mang nó vào công cụ, chúng tôi sẽ giải quyết nó và sau đó chúng tôi sẽ đẩy nó về phía trước và đưa cho bạn các kịch bản mà bạn có thể triển khai để cập nhật nó cơ sở dữ liệu để nâng cấp chúng lên quan điểm sản xuất thực sự bị xử phạt thực tế của nó sẽ như thế nào khi chúng ta tiếp tục tiến lên. Và bạn có thể xoay chuyển điều đó một cách nhanh chóng. Tôi thấy rằng những ngày của tôi đã được lấp đầy khi tôi chỉ lặp đi lặp lại với các nhóm phát triển khác nhau, xem xét các thay đổi, so sánh, tạo tập lệnh, đưa chúng đi và tôi có thể theo kịp bốn nhóm phát triển một cách dễ dàng khi chúng tôi đạt được một động lực.

Dez Blanchfield: Một trong những điều khiến tôi suy nghĩ đó là, bạn biết đấy, rất nhiều cuộc trò chuyện mà tôi có hàng ngày là về chuyến tàu chở hàng này đến với chúng tôi, về loại máy này -machine và IoT. Và nếu chúng ta nghĩ rằng chúng ta đã có rất nhiều dữ liệu trên các môi trường hiện tại của chúng ta trong doanh nghiệp, bạn biết đấy, nếu chúng ta bỏ kỳ lân sang một bên trong một khoảnh khắc mà chúng ta biết rằng Googles và Facebook và Ubers có petabyte dữ liệu, nhưng trong một doanh nghiệp truyền thống, chúng ta đang nói về hàng trăm terabyte và rất nhiều dữ liệu. Nhưng theo tôi, chuyến tàu chở hàng này đến các tổ chức, theo quan điểm của tôi và Tiến sĩ Robin Bloor đã ám chỉ nó trước đó, về IoT. Bạn biết đấy, chúng ta đã có rất nhiều lưu lượng truy cập web, chúng ta đã có lưu lượng truy cập xã hội, giờ chúng ta đã có tính di động và thiết bị di động, đám mây đã, sắp xếp, bùng nổ, nhưng giờ chúng ta đã có cơ sở hạ tầng thông minh, thành phố thông minh và toàn bộ thế giới dữ liệu này đã bùng nổ.

Đối với một tổ chức hàng ngày, một tổ chức vừa và lớn đang ngồi đó và nhìn thấy thế giới đau khổ này đến với họ và không có kế hoạch ngay lập tức, một số vấn đề, chỉ trong một vài câu, mà bạn đặt ra đối với họ khi nào và ở đâu họ cần bắt đầu suy nghĩ một cách đàm thoại về việc đưa một số phương pháp này vào vị trí. Làm thế nào sớm để họ bắt đầu lên kế hoạch gần như ngồi dậy và chú ý và nói rằng đây là thời điểm thích hợp để có một số công cụ tại chỗ và làm cho nhóm được đào tạo và có được một cuộc trò chuyện về vocab xung quanh thử thách này? Làm thế nào muộn trong câu chuyện là quá muộn hoặc khi quá sớm? Điều đó trông như thế nào đối với một số tổ chức bạn đang thấy?

Ron Huizenga: Tôi sẽ nói với hầu hết các tổ chức rằng nếu họ chưa thực hiện và điều chỉnh mô hình dữ liệu và kiến ​​trúc dữ liệu bằng các công cụ mạnh mẽ như thế này, thì thời gian họ cần làm là ngày hôm qua. Bởi vì thật thú vị, ngay cả ngày nay, khi bạn xem dữ liệu trong các tổ chức, chúng tôi có rất nhiều dữ liệu trong các tổ chức của chúng tôi và nói chung, dựa trên một số khảo sát mà chúng tôi đã thấy, chúng tôi sử dụng ít hơn năm phần trăm dữ liệu đó một cách hiệu quả khi chúng ta nhìn qua các tổ chức. Và với IoT hay thậm chí NoQuery, dữ liệu lớn - ngay cả khi đó không chỉ là IoT, mà chỉ là dữ liệu lớn nói chung - nơi chúng ta hiện đang bắt đầu tiêu thụ nhiều thông tin có nguồn gốc từ bên ngoài các tổ chức của mình, thách thức đó ngày càng lớn hơn mọi lúc Và cách duy nhất chúng ta có cơ hội có thể giải quyết đó là giúp chúng ta hiểu dữ liệu đó là về cái gì.

Vì vậy, trường hợp sử dụng là một chút khác nhau. Những gì chúng tôi thấy mình đang làm là khi chúng tôi xem dữ liệu đó, chúng tôi đang thu thập nó, chúng tôi cần thiết kế ngược lại, xem những gì trong đó, cho dù đó là trong hồ dữ liệu của chúng tôi hoặc thậm chí trong cơ sở dữ liệu trong nhà của chúng tôi, tổng hợp những gì dữ liệu là, áp dụng ý nghĩa của nó và định nghĩa cho nó để chúng ta có thể hiểu dữ liệu là gì. Bởi vì cho đến khi chúng tôi hiểu nó là gì, chúng tôi không thể đảm bảo rằng chúng tôi đang sử dụng nó một cách chính xác hoặc đầy đủ. Vì vậy, chúng tôi thực sự cần phải xử lý dữ liệu đó là gì. Và phần khác của điều đó là, đừng làm điều đó bởi vì bạn có thể, về mặt tiêu thụ tất cả dữ liệu bên ngoài này, đảm bảo rằng bạn có một trường hợp sử dụng hỗ trợ tiêu thụ dữ liệu bên ngoài này. Tập trung vào những thứ bạn cần thay vì chỉ cố gắng kéo và sử dụng những thứ mà bạn có thể cần sau này. Tập trung vào những điều quan trọng trước tiên và khi bạn thực hiện theo cách của mình, sau đó bạn sẽ tiêu thụ và cố gắng hiểu các thông tin khác từ bên ngoài.

Một ví dụ hoàn hảo về điều đó là, tôi biết chúng ta đang nói về IoT và các cảm biến, nhưng loại vấn đề tương tự đã thực sự xảy ra ở nhiều tổ chức trong nhiều năm, thậm chí trước cả IoT. Bất kỳ ai có hệ thống kiểm soát sản xuất, cho dù họ là công ty đường ống, sản xuất, bất kỳ công ty dựa trên quy trình nào có những thứ mà họ thực hiện nhiều tự động hóa với điều khiển và họ đang sử dụng luồng dữ liệu và những thứ tương tự, đều có những dữ liệu dữ liệu mà họ đang cố gắng uống để tìm ra, những sự kiện đã xảy ra trong thiết bị sản xuất của tôi để báo hiệu - chuyện gì đã xảy ra và khi nào? Và trong số các luồng dữ liệu khổng lồ này, chỉ có những mẩu thông tin hoặc thẻ cụ thể mà họ quan tâm đến việc họ cần sàng lọc, tổng hợp, mô hình hóa và hiểu. Và họ có thể bỏ qua phần còn lại của nó cho đến khi thực sự hiểu nó, và sau đó họ có thể mở rộng phạm vi của mình để kéo ngày càng nhiều điều đó vào phạm vi, nếu điều đó có ý nghĩa.

Dez Blanchfield: Nó thực sự. Có một câu hỏi mà tôi sẽ dẫn đến từ một người đàn ông tên Eric, và chúng tôi đã trò chuyện về nó một cách riêng tư. Tôi vừa mới xin phép anh ấy, mà anh ấy đã cho, để hỏi về bạn. Bởi vì nó dẫn đến kết quả tốt đẹp này, chỉ để kết thúc, bởi vì chúng ta sẽ đi một chút theo thời gian và tôi sẽ quay lại với Eric. Nhưng câu hỏi từ một Eric khác là, có hợp lý không khi cho rằng chủ sở hữu của một startup đã quen thuộc và hiểu những thách thức độc đáo xung quanh thuật ngữ mô hình hóa và vì vậy, hay nó nên được trao cho người khác để giải thích? Vì vậy, nói cách khác, một startup có nên có khả năng và sẵn sàng và sẵn sàng và có thể tập trung vào và cung cấp về điều này? Hoặc đó có phải là thứ mà họ có lẽ nên mua sắm và đưa các chuyên gia lên tàu với?

Ron Huizenga: Tôi đoán câu trả lời ngắn gọn là nó thực sự phụ thuộc. Nếu đó là một công ty khởi nghiệp không có ai đó là kiến ​​trúc sư dữ liệu hoặc người lập mô hình thực sự hiểu cơ sở dữ liệu, thì cách nhanh nhất để bắt đầu là đưa ai đó có nền tảng tư vấn rất thành thạo trong không gian này và có thể có được họ đi Bởi vì những gì bạn sẽ tìm thấy - và trên thực tế, tôi đã thực hiện điều này trên rất nhiều cam kết mà tôi đã làm trước khi tôi gặp phải điều tối kỵ trong quản lý sản phẩm - là tôi sẽ tham gia vào các tổ chức với tư cách là cố vấn, lãnh đạo các nhóm kiến ​​trúc dữ liệu của họ, để họ có thể, loại, tập trung lại bản thân và huấn luyện người dân của họ về cách làm những loại việc này để họ duy trì nó và tiếp tục thực hiện sứ mệnh. Và sau đó tôi sẽ tiếp tục tham gia, nếu điều đó có ý nghĩa. Có rất nhiều người làm điều đó, có kinh nghiệm dữ liệu rất tốt có thể khiến họ đi.

Dez Blanchfield: Đó là một điểm tuyệt vời và tôi hoàn toàn đồng ý với điều đó và tôi chắc chắn rằng Tiến sĩ Robin Bloor cũng sẽ như vậy. Đặc biệt trong một công ty khởi nghiệp, bạn tập trung vào việc trở thành một doanh nghiệp vừa và nhỏ về giá trị cụ thể của đề xuất mà bạn đang tìm cách xây dựng như một phần của chính doanh nghiệp khởi nghiệp của mình và có lẽ bạn không cần phải là một chuyên gia về mọi thứ, vì vậy lời khuyên tuyệt vời. Nhưng cảm ơn bạn rất nhiều, một bài thuyết trình tuyệt vời. Câu trả lời và câu hỏi thực sự tuyệt vời. Eric, tôi sẽ quay lại với bạn vì tôi biết chúng ta đã đi khoảng mười phút theo thời gian và tôi biết bạn muốn bám sát cửa sổ thời gian của chúng tôi.

Eric Kavanagh: Không sao đâu. Chúng tôi có ít nhất một vài câu hỏi hay. Hãy để tôi ném một cho bạn. Tôi nghĩ rằng bạn đã trả lời một số người khác. Nhưng một quan sát và câu hỏi rất thú vị từ một người tham dự viết, đôi khi các dự án nhanh nhẹn có người lập mô hình dữ liệu không có toàn bộ hình ảnh dài hạn và vì vậy họ kết thúc việc thiết kế một cái gì đó trong nước rút một và sau đó phải thiết kế lại trong nước rút ba hoặc bốn. Điều này có vẻ không phản tác dụng? Làm thế nào bạn có thể tránh những điều đó?

Ron Huizenga: Đó chỉ là bản chất của sự nhanh nhẹn mà bạn sẽ không có được mọi thứ hoàn toàn đúng trong một lần chạy nước rút. Và đó thực sự là một phần của tinh thần nhanh nhẹn, là: làm việc với nó - bạn sẽ thực hiện tạo mẫu trong đó bạn đang làm việc với mã trong một lần chạy nước rút nhất định và bạn sẽ thực hiện các sàng lọc cho nó. Và một phần của quá trình đó là khi bạn đang cung cấp những thứ mà người dùng cuối nhìn thấy và nói, đó là gần, nhưng tôi thực sự cần phải làm thêm một chút nữa. Để không chỉ ảnh hưởng đến thiết kế chức năng của chính mã nhưng khá thường xuyên chúng ta cần sửa đổi hoặc thêm nhiều cấu trúc dữ liệu bên dưới những thứ nhất định này để cung cấp những gì người dùng muốn. Và đó là tất cả các trò chơi công bằng và đó là lý do tại sao bạn thực sự muốn sử dụng các công cụ mạnh mẽ bởi vì bạn có thể nhanh chóng mô hình hóa và thực hiện thay đổi đó trong một công cụ mô hình hóa và sau đó tạo DDL cho cơ sở dữ liệu mà các nhà phát triển có thể làm việc để cung cấp điều đó thay đổi nhanh hơn nữa Bạn đang cứu họ khỏi phải thực hiện mã hóa tay, như đã từng, về cấu trúc dữ liệu và để họ tập trung vào logic lập trình hoặc ứng dụng mà họ thành thạo nhất.

Eric Kavanagh: Điều đó hoàn toàn có ý nghĩa. Chúng tôi đã có một vài người khác chỉ hỏi những câu hỏi cụ thể xung quanh làm thế nào để tất cả những thứ này gắn lại với công cụ. Tôi biết bạn đã dành thời gian để xem qua các ví dụ và bạn đã hiển thị một số ảnh chụp màn hình về cách bạn thực sự tung ra một số nội dung này. Xét về toàn bộ quá trình chạy nước rút này, bạn có thường thấy rằng chơi trong các tổ chức so với mức độ thường xuyên bạn thấy các quy trình truyền thống hơn, nơi mọi thứ chỉ, loại, chạy theo và mất nhiều thời gian hơn? Làm thế nào phổ biến là cách tiếp cận phong cách nước rút từ quan điểm của bạn?

Ron Huizenga: Tôi nghĩ rằng chúng ta đang nhìn thấy nó ngày càng nhiều hơn. Tôi biết rằng, tôi có thể nói, có lẽ trong 15 năm qua, đặc biệt, tôi đã thấy nhiều hơn về việc nhận con người nhận ra rằng họ thực sự cần phải thực hiện giao hàng nhanh hơn. Vì vậy, tôi đã thấy ngày càng nhiều tổ chức nhảy vào nhóm nhạc nhanh nhẹn. Không nhất thiết phải hoàn toàn; họ có thể bắt đầu với một vài dự án thí điểm để chứng minh rằng nó hoạt động, nhưng có một số dự án vẫn còn rất truyền thống và họ thực hiện theo phương pháp thác nước. Tất nhiên, tin tốt là, các công cụ này hoạt động rất tốt trong các tổ chức đó cũng như các loại phương pháp đó, nhưng chúng tôi có khả năng thích ứng trong công cụ để những người nhảy lên tàu có các công cụ trong hộp công cụ đầu ngón tay của họ. Những thứ như so sánh và hợp nhất, những thứ như khả năng kỹ thuật đảo ngược, vì vậy họ có thể thấy các nguồn dữ liệu hiện có là gì, vì vậy họ thực sự có thể so sánh và tạo ra các tập lệnh DDL gia tăng rất nhanh. Và khi họ bắt đầu nắm lấy điều đó và thấy rằng họ có thể có năng suất, xu hướng của họ để nắm lấy sự nhanh nhẹn thậm chí còn tăng hơn nữa.

Eric Kavanagh: Chà, đây là công cụ tuyệt vời, thưa các bạn. Tôi vừa đăng một liên kết đến các slide ở đó trong cửa sổ trò chuyện, vì vậy hãy kiểm tra xem; đó là một chút của Bitly trong đó cho bạn. Chúng tôi có tất cả các webcast để xem sau. Hãy chia sẻ chúng với bạn bè và đồng nghiệp của bạn. Và Ron, cảm ơn bạn rất nhiều vì thời gian của bạn ngày hôm nay, bạn luôn cảm thấy dễ chịu khi tham gia chương trình - một chuyên gia thực sự trong lĩnh vực này và rõ ràng là bạn biết công cụ của mình. Vì vậy, cảm ơn bạn và cảm ơn IDERA và, tất nhiên, cho Dez và Robin Bloor của chúng ta.

Và với điều đó, chúng tôi sẽ chào tạm biệt bạn, folks. Cảm ơn một lần nữa cho thời gian và sự chú ý của bạn. Chúng tôi đánh giá cao việc bạn gắn bó khoảng 75 phút, đó là một dấu hiệu khá tốt. Những người thể hiện tốt, lần sau chúng ta sẽ nói chuyện với bạn. Tạm biệt.