От служители на Techopedia, 28 септември 2016 г.
Отнемане: Домакинът Ребека Йозвяк обсъжда решения за архитектура на данни с Ерик Литъл от OSTHUS, Малкълм Чисхолм от Първи партньори в Сан Франциско и Рон Хуйзенга от IDERA.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Ребека Йозвяк: Дами и господа, привет и добре дошли в горещите технологии на 2016 г. Днес обсъждаме „Изграждане на архитектура на данни, управлявана от бизнес“, определено гореща тема. Казвам се Ребека Йозвяк, ще бъда ваш домакин за днешното излъчване в мрежата. Правим чуруликане с хештег от # HotTech16, така че ако вече сте в Twitter, не се колебайте да се присъедините и към това. Ако имате въпроси по всяко време, моля, изпратете ги в панела за въпроси и отговори в долната дясна част на вашия екран и ние ще се погрижим да получат отговор. Ако не, ще се погрижим нашите гости да ги получат за вас.
Така че днес имаме наистина завладяващ състав. Много тежки нападатели днес с нас. Имаме Ерик Литъл, вицепрезидент на науката за данни от OSTHUS. Имаме Малкълм Чисхолм, главен директор по иновациите, което е наистина страхотно заглавие, за First San Francisco Partners. И ние имаме Рон Хуйзенга, старши продуктов мениджър от IDERA. И, знаете ли, IDERA има наистина пълен набор от решения за управление и моделиране на данни. И днес той ще ни демонстрира как работи решението му. Но преди да стигнем до това, Ерик Литъл, ще ти предам топката.
Ерик Литъл: Добре, много благодаря. Така че ще прегледам няколко теми тук, които мисля, че ще се отнасят малко до беседите на Рон и се надявам да поставим сцената и за някои от тези теми, някои въпроси и отговори.
Така че нещото, което ме интересуваше с това, което прави IDERA, е, че според мен те правилно подчертават, че сложните среди наистина в момента водят много бизнес ценности. И под сложни среди имаме предвид сложни среди за данни. И технологиите наистина се движат бързо и е трудно да се поддържа в днешната бизнес среда. Така че тези хора, които работят в технологични пространства, често ще виждат, че имате клиенти, които работят с проблеми, „Как да използвам големи данни? Как да включа семантиката? Как да свържа някои от тези нови неща с по-старите си данни? “И така нататък, и този вид ни води в днешно време в тези четири v на големи данни, с които много хора са добре запознати, и разбирам, че може да има повече от четири понякога - виждал съм цели осем или девет - но обикновено, когато хората говорят за неща като големи данни или ако говорите за големи данни, тогава обикновено разглеждате нещо, което е от типа на корпоративния мащаб. И така хората ще кажат, добре, добре, помислете за обема на вашите данни, който обикновено е фокусът - точно толкова имате. Скоростта на данните е свързана или с това колко бързо мога да ги преместя, или с колко бързо мога да ги питам или да получа отговорите и т.н. И лично аз смятам, че лявата страна на това е нещо, което се решава и се справя сравнително бързо с много различни подходи. Но от дясната страна виждам много възможности за усъвършенстване и много нови технологии, които наистина излизат на преден план. И това наистина е свързано с третата колона, разнообразието от данни.
Така че с други думи, повечето компании в днешно време гледат на структурирани, полуструктурирани и неструктурирани данни. Данните за изображения започват да стават гореща тема, така че да можете да използвате компютърно зрение, да гледате пиксели, да можете да изстържете текст, NLP, извличане на образувания, имате графична информация, която излиза или от статистически модели, или излиза от семантичен модели, имате релационни данни, които съществуват в таблици и т.н. И така събирането на всички тези данни заедно и всички тези различни видове наистина представлява голямо предизвикателство и ще видите това в, знаете, в Gartner и други хора, които някак следват тенденциите в индустрията.
И тогава последното нещо, за което хората говорят в големите данни, често е това понятие за гласност, което наистина е несигурността на вашите данни, неясността на тях. Колко добре знаете за какво се отнасят вашите данни, колко добре разбирате какво има там и знаете ли? Възможността за използване на статистически данни и възможността да се използва някакъв вид информация около това, което може би знаете или да използвате някакъв контекст, може да бъде от полза там. И така възможността да гледате на данните по този начин от гледна точка на това колко имате, колко бързо трябва да ги премествате или да ги получавате, всички видове данни, които може да имате във вашето предприятие и колко сте сигурни къде това е, какво е, в какво качество е и т.н. Това наистина изисква големи, координирани усилия сега между много хора за ефективно управление на данните им. Следователно моделирането на данни е все по-важно в днешния свят. Така че добрите модели данни наистина водят до много успех в корпоративните приложения.
Имате източници на данни от различни източници, както казахме, което наистина изисква много различни видове интеграция. Така че извличането на всичко заедно е наистина полезно, за да можете да стартирате заявки, например, в многобройни видове източници на данни и да изтегляте информация обратно. Но за да направите това, се нуждаете от добри стратегии за картографиране и така картографирането на тези видове данни и поддържането на тези карти може да бъде истинско предизвикателство. И тогава имате този проблем за, добре как да свържа наследените си данни с всички тези нови източници на данни? Да предположим, че имам графика, вземам ли всичките си релационни данни и ги поставям в графика? Обикновено това не е добра идея. И така, как е възможно хората да управляват всички тези модели данни, които се случват? Анализът наистина трябва да се извършва на много от тези различни видове източници на данни и комбинации. Така че отговорите, които излизат от това, отговорите, от които хората се нуждаят, за да вземат наистина добри бизнес решения, са критични.
Така че не става въпрос само за изграждане на технология в името на технологията, а всъщност, какво ще правя, какво мога да направя с нея, какъв анализ мога да правя и способността, следователно, както вече съм говорим за това, да се съберат тези неща заедно, да се интегрират това е наистина, наистина важно. И един от тези видове анализи след това работи върху неща като федерално търсене и заявки. Това наистина става задължително. Обикновено вашите запитвания трябва да бъдат насочвани към различни източници и да изтеглят информация надеждно.
Единственият ключов елемент, който често, особено хората ще гледат на ключови неща като семантични технологии - и това е нещо, за което се надявам Рон да говори малко за подхода на IDERA - е как да отделите или управлявате моделен слой на вашите данни от самия слой данни, от тези сурови данни? Така долу в слоя данни може да имате бази данни, може да имате данни за документи, може да имате данни от електронни таблици, може да имате данни за изображения. Ако сте в области като фармацевтичната индустрия, имате огромно количество научни данни. И тогава отгоре на това хората обикновено търсят начин за изграждане на модел, който им позволява бързо да интегрират тези данни и наистина когато търсите данни сега не искате да изтеглите всички данни във вашия моделен слой, това, което търсите в моделния слой, е да ви даде приятно логическо представяне на нещата, какви са нещата, общи речници, общи типове субекти и взаимоотношения и способността наистина да влезете в данните там, където се намират. Така че тя трябва да каже какво е и трябва да каже къде е и трябва да каже как да го донесе и да го върне.
Това беше подход, който беше доста успешен в придвижването на семантичните технологии напред, което е област, в която работя много. Така че въпросът, който исках да задам на Ron и който мисля, че ще бъде полезен в раздела за въпроси и отговори, е да видя как се постига това от платформата IDERA? Значи слойът на модела всъщност е отделен от слоя данни? По-интегрирани ли са? Как става това и какви са някои от резултатите и ползите, които виждат от своя подход? Следователно референтните данни наистина стават също критични. Така че, ако ще имате такива модели данни, ако ще можете да федерализирате и търсите в нещата, наистина трябва да имате добри референтни данни. Но проблемът е, че референтните данни могат да бъдат наистина трудни за поддържане. Така че често назоваването на стандарти сами по себе си е трудно предизвикателство. Една група ще извика нещо X и една група ще извика нещо Y и сега имате проблема как някой намира X и Y, когато търси този тип информация? Тъй като не искате да им предоставите само част от данните, искате да им предоставите всичко свързано. В същото време условията се променят, софтуерът се оттегля и т.н., как поддържате и поддържате тези референтни данни във времето?
И отново, семантичните технологии, по-специално използване на неща като таксономии и речници, речници с данни, предоставиха стандартен космически начин за това, който е наистина много здрав, той използва определени видове стандарти, но общността на базата данни е направила това за дълго време също, само по различни начини. Мисля, че един от ключовете тук е да помислим за това как да използваме може би модели на връзки между субектите, как да използваме може би графични модели или някакъв тип подход тук, който наистина ще ви даде надявам се стандартен разположен начин за обработка на вашите референтни данни. И след това, разбира се, след като разполагате с референтните данни, стратегиите за картографиране трябва да управляват голямо разнообразие от имена и образувания. Затова експертите по въпросите често обичат да използват собствените си термини.
Така че предизвикателството винаги е това, как давате на някого информация, но я правите уместна за начина, по който говорят за нея? Така че една група може да има един начин да погледне нещо, например, може да сте химик, който работи върху наркотици, и може да сте структурен биолог, работещ върху едно и също лекарство, и може да имате различни имена за едни и същи типове образувания които са свързани с вашето поле. Трябва да измислите начини да обедините тези персонализирани терминологии, тъй като другият подход е, че трябва да принудите хората да изоставят термина си и да използват чуждо, което често не им харесва. Друг момент тук е, че боравенето с голям брой синоними става трудно, така че има много различни думи в данните на много хора, които могат да се отнасят към едно и също нещо. Имате проблем с препратката там, използвайки набор от много към един. Специализираните термини варират от индустрията до индустрията, така че ако ще излезете с някакво всеобхватно решение за този тип управление на данни, колко лесно е преносимото от един проект или едно приложение към друго? Това може да бъде още едно предизвикателство.
Автоматизацията е важна и също е предизвикателство. Ръчно справянето с референтни данни е скъпо. Скъпо е да се налага ръчното картографиране и е скъпо да се накара специалистите по темите да спрат да вършат ежедневните си задачи и да се налага да влизат и постоянно да оправят речници с данни и да актуализират отново дефиниции и т.н., и така нататък. Репликируемите речници наистина показват голяма стойност. Така че често това са речници, които можете да намерите външни за вашата организация. Ако например работите в суров петрол, ще има някои видове речници, които можете да заемате от пространства с отворен код, същите с фармацевтичните продукти, същото с банковата индустрия и финансовите, същото с много от тези области. Хората въвеждат речници за многократна употреба, подлежащи на повторение, за да ги използват хората.
И отново, като гледам инструмента IDERA, ми е любопитно да видя как се справят с това по отношение на използването на видове стандарти. В света на семантиката често виждате неща като SKOS модели, които осигуряват стандарти поне по-широки от / по-тесни от взаимоотношенията и тези неща могат да бъдат трудни за изпълнение в ER модели, но, знаете ли, не е невъзможно, просто зависи колко от това машини и това свързване, с което можете да се справите в тези видове системи.
И накрая, аз просто исках да направя сравнение с някои семантични двигатели, които виждам в индустрията, и да попитам Рон и да го накараме да поговори малко за това как може да се използва системата на IDERA във връзка с всякакви семантични технологии. Способен ли е да бъде интегриран с тройни магазини, графични бази данни? Колко лесно е да използвате външни източници, защото тези видове неща в семантичния свят често могат да бъдат взаимствани чрез SPARQL Endpoints? Можете да импортирате RDF или OWL модели директно във вашия модел - обърнете се към тях - така например генната онтология или протеиновата онтология, които могат да живеят някъде в собственото си пространство със собствена структура на управление и мога просто да импортирам всички или част от това, тъй като имам нужда от моите собствени модели. И ми е любопитно да знам как IDERA подхожда към този проблем. Трябва ли да поддържате всичко вътрешно или има ли начини да използвате други видове стандартизирани модели и да ги дръпнете вътре и как става това? И последното, което споменах тук, е колко ръчна работа наистина е ангажирана за изграждането на речниците и хранилищата на метаданните?
Така че знам, че Рон ще ни покаже някои демонстрации на такива неща, които ще бъдат наистина интересни. Но проблемите, които често виждам при консултиране с клиенти, е, че се появяват много грешки, ако хората пишат в собствените си определения или в своите метаданни. Така че получавате правописни грешки, получавате грешки с дебели пръсти, това е едно. Можете също така да получите хора, които могат да вземат нещо от, знаете, просто Wikipedia или източник, който не е непременно от качеството, което може да искате във вашата дефиниция, или вашата дефиниция е само от гледна точка на един човек, така че не е пълна и не е ясно тогава как работи процеса на управление. Управлението, разбира се, е много, много голям проблем всеки път, когато говорите за референтни данни и всеки път, когато говорите как това може да се впише в нечия основни данни, как ще използват метаданните им и скоро.
Така че просто исках да поставя някои от тези теми там. Това са неща, които виждам в бизнес пространството в много различни консултантски ангажименти и в много различни пространства и наистина ми е интересно да видя какво ще ни покаже Рон с IDERA, за да посочим някои от тези теми, Така че много ви благодаря
Ребека Йозвяк: Благодаря много, Ерик, и много ми харесва твоят коментар, че могат да възникнат много грешки, ако хората пишат свои собствени определения или метаданни. Знам, че в света на журналистиката има мантра, че "много очи правят малко грешки", но когато се стигне до практически приложения, твърде много ръце в буркана с бисквитки са склонни да ви оставят с много счупени бисквитки, нали?
Ерик Литъл: Да, и микроби.
Ребека Йозвяк: Да. С това ще продължа напред и ще го предам на Малкълм Чисхолм. Малкълм, подът е твой.
Малкълм Чисхолм: Благодаря ви много, Ребека. Бих искал да разгледам малко това, за което говори Ерик, и да добавя, към някои наблюдения, на които, знаете ли, Рон може и да реагира, като говори за „Насочена към бизнес архитектура на данни ”- какво означава да се ръководи от бизнеса и защо това е важно? Или това е просто някаква форма на свръх? Не мисля, че е така.
Ако погледнем какво се случва, тъй като знаете, компютрите с мейнфрейм наистина станаха достъпни за компаниите - да речем, около 1964 г. - до днес можем да видим, че е имало много промени. И тези промени бих обобщил като изместване от процесно центриране към центриране на данни. И това прави архитектурата на данни за бизнеса толкова важна и толкова актуална за днес. И мисля, знаете ли, това не е просто модна дума, а нещо, което е абсолютно реално.
Но можем да го оценим малко повече, ако се потопим в историята, така че да се върнем назад във времето, назад към 60-те години на миналия век и известно време след това доминираха мейнфреймите. След това те отстъпиха на персонални компютри, където всъщност сте се бунтували на потребителите, когато влязоха компютрите. Бунтът срещу централизираните ИТ, които според тях не отговаряха на техните нужди, не бяха достатъчно пъргави. Това бързо породи разпределени изчисления, когато компютрите бяха свързани. И тогава интернет започна да се случва, което размива границите на предприятието - сега може да взаимодейства с страни извън себе си по отношение на обмен на данни, което не се беше случвало преди. И сега отидохме в ерата на облачните и големи данни, където облакът е платформи, които наистина комодитизират инфраструктура и затова оставяме, както трябва, ИТ на необходимостта да стартираме големи центрове за данни, защото, знаете ли, ние разполагаме с капацитета на облака, който ни е на разположение и съпътстващ тези големи данни, които Ерик знае, толкова красноречиво обсъждани. И като цяло, както виждаме, с настъпването на промяна в технологиите, тя стана по-ориентирана към данните, ние повече се грижим за данните. Както в интернет, как се обменят данни. При големи данни, четирите или повече v от самите данни.
В същото време, а може би и по-важното, случаите на бизнес използване се изместиха. Когато компютрите бяха представени за първи път, те бяха използвани за автоматизиране на неща като книги и записи. И всичко, което беше ръчен процес, включващо книги или подобни неща, беше програмирано по същество. Това се измести през 80-те към наличието на оперативни пакети. Нямаше нужда да пишете своя собствена ведомост, можете да си купите нещо, което го направи. Това доведе до значително намаляване на времето или преструктуриране в много ИТ отдели. Но тогава се появи бизнес разузнаване, с неща като складове за данни, най-вече през 90-те години. Следват бизнес модели на dotcom, които, разбира се, бяха голяма ярост. Тогава MDM. С MDM започвате да виждате, че не мислим за автоматизация; ние всъщност се фокусираме върху събирането на данни като данни. И след това аналитика, представляваща стойността, която можете да извлечете от данните. А в рамките на аналитиката виждате компании, които са много успешни, чийто основен бизнес модел се върти около данни. Google, Twitter, Facebook биха били част от това, но бихте могли да спорите и че Walmart е.
И така бизнесът сега наистина мисли за данни. Как можем да извлечем стойност от данните? Как данните могат да управляват бизнеса, стратегията и ние сме в златната ера на данните. И така като се има предвид, какво се случва по отношение на нашата архитектура на данни, ако данните вече не се считат само за ауспуха, който излиза от задния край на приложенията, но наистина е централен за нашите бизнес модели? Е, част от проблема, който имаме в постигането на ИТ, е наистина заседнал в миналото с жизнения цикъл на развитието на системите, който беше следствие от бързата работа с тази фаза на автоматизация на процесите в ранна възраст на ИТ и работа в проекти е подобно нещо. За ИТ - и това е малко карикатура - но това, което се опитвам да кажа, е, че някои от бариерите пред получаването на бизнес архитектура на данни са, защото ние някак безкритично сме приели култура в ИТ което произлиза от отминала епоха.
Така че всичко е проект. Кажете ми подробно вашите изисквания. Ако нещата не работят, това е защото не ми казахте вашите изисквания. Е, това не работи днес с данни, защото не започваме с неавтоматизирани ръчни процеси или техническа конверсия на бизнес процеси, ние започваме много често с вече съществуващи производствени данни, които се опитваме за да получите стойност от. Но никой, който спонсорира проект, ориентиран към данни, наистина не разбира тези данни в дълбочина. Трябва да направим откриване на данни, трябва да направим анализ на изходните данни. И това всъщност не съвпада с развитието на системите, знаете - водопад, жизнен цикъл на SDLC - от които бих поддържал Agile, че е един вид по-добра версия на това.
И това, върху което се фокусира, е технологията и функционалността, а не данните. Например, когато правим тестване във фаза на тестване, обикновено това е, дали функционалността ми работи, да речем моята ETL, но ние не тестваме данните. Ние не тестваме нашите предположения за изходните данни, които идват. Ако го направихме, ние бихме били в по-добра форма и като някой, който е направил проекти за съхранение на данни и е пострадал от промени нагоре по веригата, сривайки моите ETL, аз бих оценил това. И всъщност това, което искаме да видим, е тестване като предварителна стъпка към непрекъснат мониторинг на качеството на производствените данни. Така че тук имаме много нагласи, при които е трудно да се постигне ориентирана към бизнеса архитектура на данни, защото ние сме обусловени от ерата на концентрираност на процесите. Трябва да направим преход към центрираност на данните. И това не е пълен преход, нали знаете, че има още много работа за работа, но ние всъщност не мислим по отношение на данните, когато трябва, и обстоятелствата, които се случват, когато сме наистина задължен да направи това.
Сега бизнесът осъзнава стойността на данните, те искат да отключат данните, така че как ще направим това? И така, как да направим прехода? Е, ние поставяме данните в основата на процесите на развитие. И оставяме бизнеса да води с информационни изисквания. И ние разбираме, че никой не разбира съществуващите източници в началото на проекта. Можете да спорите, че структурата на данните и самите данни са стигнали там съответно чрез ИТ и операции, така че трябва да знаем това, но всъщност не го правим. Това е ориентирано към данни развитие. Така че трябва да мислим къде и как да правим моделиране на данни в ориентиран към данните свят, трябва да имаме контури за обратна връзка към потребителите по отношение на прецизиране на техните информационни изисквания, както правим откриване на данни и профилиране на данни., предвиждаме анализ на източниците на данни и тъй като постепенно получаваме все по-голяма сигурност за нашите данни. И сега говоря за по-традиционен проект като MDM хъб или склад за данни, а не непременно големите проекти за данни, въпреки че това все още, поддържам, е доста близо до това. И така тези контури за обратна връзка включват моделарите на данни, знаете, постепенно напредват техния модел на данни и взаимодействат с потребителите, за да се гарантира, че изискванията за информация са прецизирани въз основа на това, което е възможно, какво е налично, от изходните данни, тъй като те по-добре го разбират, вече не е случай моделът на данни да е в състояние, което или не е там, или е напълно готово, това е постепенно привеждане във фокус на него.
По същия начин, по-надолу от това имаме осигуряване на качеството, където разработваме правила за тестване на качеството на данните, за да сме сигурни, че данните са в рамките на параметрите, за които правим предположения. Влизайки, Ерик имаше предвид промените в референтните данни, които може да се случат. Не искате да бъдете жертва надолу по веригата на някаква, неуправляема промяна в тази област, така че правилата за осигуряване на качество могат да преминат в следпроизводствено, непрекъснато наблюдение на качеството на данните. Така че можете да започнете да виждате дали ще бъдем ориентирани към данни, как правим разработка, ориентирана към данни, е съвсем различна от SDLC и Agile, базирани на функционалност. И тогава трябва да обърнем внимание и на бизнес гледните точки. Имаме - и това отново озвучава това, което казваше Ерик - имаме модел на данни, определящ план за историята на данните за нашата база данни, но в същото време се нуждаем от онези концептуални модели, онези бизнес гледки на данни, които традиционно не са правени в миналото. Мисля, че понякога сме мислили, че моделът данни може да направи всичко, но трябва да имаме концептуалния изглед, семантиката и да надникнем в данните, да го направим през абстракционен слой, който превежда модела на съхранение в бизнеса видите. И отново всичко, за което Ерик говори по отношение на семантиката, става важно за това, така че всъщност имаме допълнителни задачи за моделиране. Мисля, че това е, знаете, интересно, ако сте попаднали в редиците като моделиер на данни като мен, и отново нещо ново.
И накрая бих искал да кажа, че по-голямата архитектура също трябва да отразява тази нова реалност. Традиционният MDM за клиенти, например, е вид, добре, нека да вкараме нашите клиентски данни в хъб, където можем, знаете, да го осмислим по отношение на наистина просто качество на данните за бек офис приложения. Което от гледна точка на бизнес стратегията е вид прозявка. Днес обаче разглеждаме MDM хъбовете на клиентите, които имат допълнителни данни за потребителски профил в тях, а не само статичните данни, които след това наистина имат двупосочен интерфейс с приложения за транзакции на клиента. Да, те все още поддържат бек офиса, но сега знаем и за това поведение на нашите клиенти. Това е по-скъпо за изграждане. Това е по-сложно за изграждане. Но се ръководи от бизнеса по начин, по който традиционният MDM за клиенти не е такъв. Вие търгувате с ориентация към бизнеса срещу по-лесни проекти, които са по-лесни за изпълнение, но за бизнеса това е, което искат да видят. Наистина сме в нова ера и мисля, че има редица нива, на които трябва да реагираме на архитектурата на данните за управление на бизнеса и мисля, че е много вълнуващо време да правим нещата.
Така че благодаря, обратно към теб Ребека.
Rebecca Jozwiak: Благодаря Малкълм, и наистина ми хареса това, което казахте за моделите данни, трябва да подхрани бизнес изгледа, защото, за разлика от това, което казвахте, където ИТ държеше юздите толкова дълго и просто е нещо не така вече и че културата наистина трябва да се измести. И съм почти сигурен, че на заден план имаше куче, което се съгласи с теб на 100%. И с това ще предам топката на Рон. Наистина съм развълнуван да видя демото ти. Рон, подът е твой.
Рон Huizenga: Благодаря ви много и преди да скочим в това, ще прегледам няколко слайда и след това малко демонстрация, защото, както Ерик и Малкълм посочиха, това е много широка и задълбочена тема, и с това, за което говорим днес, просто остъргваме повърхността му, защото има толкова много аспекти и толкова много неща, които наистина трябва да разгледаме и разгледаме от бизнес ориентирана архитектура. И нашият подход е наистина да направим тази модел базирана и да извлечем истинска стойност от моделите, защото можете да ги използвате като средство за комуникация, както и като слой за активиране на други системи. Независимо дали правите ориентирана към услуги архитектура или други неща, моделът наистина се превръща в основата на живота на случващото се с всички метаданни около него и данните, които имате във вашия бизнес.
Това, за което искам да говоря, обаче, почти прави тази стъпка назад, защото Малкълм се беше докоснал до част от историята на начина, по който са се развили решенията и този тип неща. Един от начините наистина да отбележа колко важно е да имате стабилна архитектура на данните е случай на употреба, с който се сблъсквах много често, когато се консултирах, преди да вляза в ролята на управление на продуктите, и това беше, бих влязъл в организации дали правят бизнес трансформация или просто заменят някои съществуващи системи и подобен тип и много бързо стана ясно как лошо организациите разбират собствените си данни. Ако вземете конкретен случай като този, независимо дали сте консултант, или може би това е човек, който току-що е стартирал с организация, или вашата организация е създадена през годините с придобиване на различни компании, с какво завършвате е много сложна среда много бързо, с редица нови различни технологии, както и наследени технологии, ERP решения и всичко останало.
Така че едно от нещата, които наистина можем да направим с нашия подход за моделиране, е да отговорим на въпроса как да осмисля всичко това? Наистина можем да започнем да споделяме информацията заедно, така че бизнесът да може да използва информацията, която имаме правилно. И излиза, какво имаме там в тези среди? Как мога да използвам моделите, за да прогоня информацията, която ми е необходима, и да разбера по-добре тази информация? И тогава имаме традиционните видове метаданни за всички различни неща като моделите на релационните данни и сме свикнали да виждаме неща като дефиниции и речници на данни, знаете ли, типове данни и този тип неща. Но какво да кажем за допълнителни метаданни, които искате да заснемете, за да им дадете наистина повече значение? Като например, кои субекти наистина са кандидатите, които трябва да бъдат референтни обекти за данни, които трябва да бъдат главни обекти за управление на данни и тези видове неща и да ги свържат заедно. И как информацията протича през организацията? Данните протичат от начина, по който се консумират както от гледна точка на процеса, но също така и от линията на данни по отношение на пътуването на информацията през нашите бизнеси и как тя проправя път през различните системи или през хранилищата на данни, така че знаем когато изграждаме I-решенията или тези видове неща, които всъщност консумираме точната информация за задачата, която се работи.
И тогава е много важно как можем да накараме всички тези заинтересовани страни да си сътрудничат, и по-специално бизнес заинтересованите страни, защото те са тези, които ни дават истинския смисъл на това, което представляват тези данни. В края на деня бизнесът притежава данните. Те предоставят определенията за речниците и нещата, за които Ерик говори, така че имаме нужда от място, където да свържем всичко това заедно. И начинът, по който го правим, е чрез нашето моделиране на данни и архитектури на хранилища на данни.
Ще се докосна до няколко неща. Ще говоря за ER / Studio Enterprise Team Edition. Основно ще говоря за продукта за архитектура на данни, където правим моделиране на данни и този тип неща, но има много други компоненти на пакета, които просто ще се докосна съвсем накратко. Ще видите един фрагмент от Бизнес архитекта, където можем да правим концептуални модели, но можем също да правим модели на бизнес процеси и да свържем тези модели на процеси, за да свържем действителните данни, които имаме в нашите модели данни. Наистина ни помага да обединим тази вратовръзка. Софтуерният архитект ни позволява да правим допълнителни конструкции като някои UML моделиране и тези видове неща, за да дадем поддържаща логика на някои от онези други системи и процеси, за които говорим. Но много важно, когато се движим надолу, имаме хранилището и сървъра за екип и ще говоря за това като за две половини на едно и също нещо. Хранилището е мястото, където съхраняваме всички моделирани метаданни, както и всички бизнес метаданни по отношение на бизнес речниците и термините. И тъй като имаме тази среда, базирана на хранилище, можем след това да свържем всички тези различни неща в същата среда и тогава всъщност можем да ги направим достъпни за консумация, не само за техническите хора, но и за бизнесмените. И така всъщност започваме да управляваме колаборацията.
И тогава последното парче, за което ще говоря накратко, е, когато влезете в тези среди, там не са само базите данни. Ще имате редица бази данни, хранилища на данни, вие също ще имате много, както бих нарекъл, наследени артефакти. Може би хората са използвали Visio или други диаграми, за да очертаят някои неща. Може би са имали други инструменти за моделиране и такива неща. Така че това, което можем да направим с MetaWizard, всъщност е да извлечем част от тази информация и да я внесем в нашите модели, да я направим актуална и да можем да я използваме, да я консумираме по текущ начин отново, а не просто да я караме да седи там. Сега тя става активна част от нашите работещи модели, което е много важно.
Когато влезете в организация, както казах, много различни системи са там, много ERP решения, несъответстващи решения на отделите. Много организации също използват SaaS решения, които също са външно контролирани и управлявани, така че ние не контролираме базите данни и тези типове неща в хостовете на тях, но все пак трябва да знаем как изглеждат тези данни и, разбира се, метаданните около това. Това, което също откриваме, е много остарели наследствени системи, които не са изчистени поради онзи, базиран на проекти подход, за който Малкълм говори. Удивително е как през последните години организациите ще въртят проекти, ще заменят система или решение, но често няма достатъчно бюджет на проекта за извеждане от експлоатация на остарелите решения, така че сега те просто са на път. И трябва да разберем от какво всъщност можем да се отървем в нашата среда, както и какво е полезно напред. И това е свързано с лошата стратегия за извеждане от експлоатация. Това е част от същото това нещо.
Това, което също откриваме, тъй като много организации са изградени от всички тези различни решения, е, че виждаме много интерфейси от точка до точка с много данни, които се движат на много места. Трябва да сме в състояние да рационализираме това и да разберем тази линия от данни, която накратко споменах по-рано, за да можем да имаме по-сплотена стратегия, като използване на сервизно ориентирана архитектура, корпоративни сервизни шини и подобни неща, за да предоставим правилната информация на тип модел за публикуване и абониране, който правилно използваме в целия ни бизнес. И тогава, разбира се, все още трябва да правим някакъв вид анализи, независимо дали използваме хранилища за данни, данни от традиционните ETL или използваме някои от новите данни. Всичко се свежда до едно и също нещо. Всичко това са данни, независимо дали са големи данни, независимо дали това са традиционни данни в релационни бази данни, ние трябва да съберем всички тези данни, за да можем да ги управляваме и да знаем с какво се занимаваме в нашите модели.
Отново, сложността, която ще направим е, че имаме редица стъпки, които искаме да можем да направим. На първо място, вие влизате вътре и може да нямате онези планове как изглежда този информационен пейзаж. В инструмент за моделиране на данни като ER / Studio Data Architect първо ще правите много обратна инженерия по отношение на нека да насочим към източниците на данни, които са там, да ги въведете и след това всъщност да ги свържете в по-представителни модели, които представляват целия бизнес. Важното е, искаме ли да можем да разложим тези модели и по бизнес линии, така че да можем да се свържем с тях на по-малки парчета, към които могат да се отнасят и нашите бизнесмени, и нашите бизнес анализатори и други заинтересовани страни, които работят върху него.
Стандартите за именуване са изключително важни и тук говоря по два различни начина. Именуване на стандарти по отношение на начина, по който именуваме нещата в нашите модели. Това е доста лесно да се направи в логически модели, където имаме добра конвенция за именуване и добър речник за данни за нашите модели, но след това също виждаме различни конвенции за именуване на много от тези физически модели, които въвеждаме. Когато ние обратен инженер, доста често виждаме съкратени имена и този тип неща, за които ще говоря. И ние трябва да ги преведем обратно в смислени английски имена, които имат значение за бизнеса, за да можем да разберем какви са всички тези данни, които имаме в околната среда. И тогава универсалните карти са как ги зашиваме заедно.
На всичкото отгоре ще документираме и дефинираме по-нататък и там можем да класифицираме допълнително данните си с нещо, наречено „Прикачени файлове“, което ще ви покажа няколко слайда. И след това затваряйки веригата, ние искаме да приложим това бизнес значение, което е мястото, където ние обвързваме в нашите бизнес речници и можем да ги свържем с нашите различни артефакти на модела, така че знаем, когато говорим за определен бизнес термин, където това е внедрени в нашите данни в цялата организация. И накрая, накрая, вече говорих за факта, че трябва всичко това да бъде хранилище, основано на много възможности за сътрудничество и публикуване, така че нашите заинтересовани страни да могат да го използват. Ще говоря за обратното инженерство доста бързо. Вече ви дадох много бърз акцент на това. Ще ви покажа това в действителна демонстрация, само за да ви покажа някои от нещата, които можем да внесем там.
И искам да говоря за някои от различните типове модели и диаграми, които бихме произвели при този тип сценарии. Очевидно ще направим концептуалните модели в много случаи; Няма да отделя много време за това. Наистина искам да говоря за логически модели, физически модели и специализирани видове модели, които можем да създадем. И е важно, че можем да създадем всичко това в една и съща платформа за моделиране, така че да можем да ги зашиваме заедно. Това включва модели, както и модели, които използват някои от новите източници на данни, като например NoSQL, който ще ви покажа. И тогава, как изглежда моделът на линията на данни? И как да зашием тези данни в модел на бизнес процес, е какво ще говорим по-нататък.
Тук ще премина към среда за моделиране, само за да ви дам един много висок и бърз преглед. И вярвам, че трябва да можете да виждате екрана ми сега. На първо място искам да говоря само за традиционен тип данни. И начинът, по който искаме да организираме моделите, когато ги въвеждаме, е, че искаме да можем да ги разложим. Това, което виждате тук отляво, е, че имаме логически и физически модели в този конкретен модел на файла. Следващото нещо е, можем ли да го разделим по време на декомпозицията на бизнеса, така че затова виждате папките. Светлосините са логични модели, а зелените - физически модели. И ние също можем да разгледаме, така че в ER / Studio, ако имате разлагане на бизнес, можете да отидете на толкова нива или под-модели, колкото искате, и промените, които правите на по-ниските нива, автоматично се отразяват на по-високите нива. Така тя става много мощна среда за моделиране много бързо.
Нещо, което също искам да отбележа, че е много важно да започнем да обединяваме тази информация, е, че можем да имаме множество физически модели, които съответстват и на един логичен модел. Доста често може да имате логичен модел, но може да имате физически модели на различни платформи и такъв тип неща. Може би един е екземпляр от SQL Server от него, може би друг е екземпляр на Oracle. Имаме възможността да свържем всичко това заедно в една и съща среда за моделиране. И тук отново имам действителен модел за съхранение на данни, който отново може да бъде в същата среда за моделиране или можем да го имаме в хранилището и да го свържем в различни неща.
Това, което наистина исках да ви покажа по този въпрос, са някои от другите неща и други варианти на моделите, в които влизаме. Така че, когато попаднем в традиционен модел на данни като този, сме свикнали да виждаме типичните образувания с колоните и метаданните и този тип неща, но тази гледна точка варира много бързо, когато започнем да се занимаваме с някои от тези по-нови технологии на NoSQL или както някои хора все още обичат да ги наричат, големите технологии за данни.
Така че сега да кажем, че ние също имаме Hive в нашата среда. Ако обърнем инженер от среда на Hive - и можем да препратим и обърнем инженер от Hive с този същият инструмент за моделиране - виждаме нещо, което е малко по-различно. Все още виждаме всички данни като конструкции там, но нашите TDL са различни. Тези от вас, които са свикнали да виждат SQL, това, което бихте виждали сега, е Hive QL, който е много подобен на SQL, но извън същия инструмент, който вече можете да започнете да работите с различните езици за скриптове. Така че можете да моделирате в тази среда, да я генерирате в околната среда на кошера, но също толкова важно, в сценария, който описах, можете да върнете инженерно всичко в него и да го осмислите и да започнете да го свързвате заедно,
Нека вземем още един, който е малко по-различен. MongoDB е друга платформа, която поддържаме местно. И когато започнете да навлизате в JSON типове среди, в които имате складове за документи, JSON е различно животно и в това има конструкции, които не съответстват на релационни модели. Скоро започвате да се занимавате с понятия като вградени обекти и вградени масиви от обекти, когато започнете да разпитвате JSON и тези понятия не съществуват в традиционните релационни обозначения. Това, което направихме тук, е, че всъщност сме разширили нотацията и нашия каталог, за да можем да се справим с това в същата среда.
Ако погледнете отляво тук, вместо да виждате неща като единици и таблици, ние ги наричаме обекти. И виждате различни обозначения. Все още виждате типичните типове референтни обозначения тук, но тези сини единици, които показвам в тази конкретна диаграма, всъщност са вградени обекти. И показваме различни кардиналности. Диамантената кардиналност означава, че това е обект от едната страна, но кардиналността на един означава, че ние имаме в рамките на издателя, ако следваме тази връзка, имаме вграден адресен обект. При разпит на JSON открихме, че е точно същата структура на обектите, която е вградена в патрон, но всъщност е вградена като масив от обекти. Ние виждаме това не само чрез самите конектори, но ако погледнете действителните елементи ще видите, че виждате адреси под патрон, което също го класифицира като масив от обекти. Получавате много описателна гледна точка за това как можете да го направите.
И отново, сега това, което видяхме досега само за няколко секунди, са традиционните релационни модели, които са многостепенни, можем да направим същото с Hive, можем да направим същото с MongoDB и други големи източници на данни като добре. Това, което можем също да направим, и аз просто ще ви го покажа това много бързо, говорих за факта, че нещата се доставят от други различни области. Предполагам, че ще импортирам модел от база данни или ще го обърна обратно, но ще го въведа от външни метаданни. Само за да ви дадем много бърза гледка към всички различни видове неща, които можем да започнем да въвеждаме.
Както виждате, имаме безброй неща, с които реално можем да внесем метаданните в нашата моделна среда. Започвайки с неща като дори Amazon Redshift, Cassandra, много от другите големи платформи за данни, така че виждате много от изброените. Това е по азбучен ред. Виждаме много големи източници на данни и такъв тип неща. Също така виждаме много традиционни или по-стари модели за моделиране, чрез които реално можем да пренесем тези метаданни. Ако премина тук - и няма да отделя време за всяка една от тях - виждаме много различни неща, от които можем да го внесем, по отношение на моделиране на платформи и платформи за данни. И нещо, което е много важно да разберем тук, е друга част, която можем да направим, когато започнем да говорим за родово предаване на данни, в Enterprise Team Edition можем също да разпитаме ETL източници, независимо дали става дума за неща като Talend или SQL Server. всъщност довеждаме до това, за да стартираме и нашите диаграми на линейни данни и да нарисуваме картината на случващото се в тези трансформации. Общо извън кутията имаме над 130 от тези различни мостове, които всъщност са част от продукта Enterprise Team Edition, така че наистина ни помага да съберем всички артефакти в една моделна среда много бързо.
Не на последно място, искам да говоря и за факта, че не можем да изгубим от поглед факта, че имаме нужда от другите видове конструкции, ако правим съхранение на данни или каквито и да било видове анализи. Все още искаме да имаме способността да правим неща като размерни модели, където имаме таблици с факти и имаме размери и тези типове неща. Едно нещо, което искам да ви покажа също е, че можем да имаме и разширения към нашите метаданни, които ни помагат да категоризираме какви са типовете измерения и всичко останало. Така че, ако разгледам раздела за измерените данни тук, например, на един от тях, той всъщност автоматично ще открие, въз основа на модела, който вижда, и ще ви даде отправна точка дали смята, че е измерение или таблица с факти. Но освен това, това, което можем да направим, е в измеренията и този тип неща, ние дори имаме различни типове измерения, които можем да използваме, за да класифицираме и данните в среда за съхранение на данни. Толкова много мощни възможности, с които ние шием всичко това.
Ще скоча в тази, тъй като в момента съм в демо средата и ще ви покажа няколко други неща, преди да се върна обратно към слайдовете. Едно от нещата, които наскоро добавихме към ER / Studio Data Architect е, че сме попаднали в ситуации - и това е много често използван случай, когато работите по проекти - разработчиците мислят по отношение на обектите, докато нашите данни моделистите са склонни да мислят по отношение на таблици и субекти и този тип неща. Това е много опростен модел на данни, но той представя няколко основни концепции, където разработчиците или дори бизнес анализаторите или бизнес потребителите могат да ги мислят за различни обекти или бизнес концепции. Досега беше много трудно да ги класифицираме, но това, което всъщност направихме в ER / Studio Enterprise Team Edition, в изданието 2016 г., имаме ли концепция, наречена Business Data Objects. И това, което ни позволява да правим е, че ни позволява да капсулираме групи от субекти или таблици в истински бизнес обекти.
Например, това, което имаме тук в този нов изглед, е заглавката на поръчката за поръчка и редът за поръчка вече са събрани заедно, те са капсулирани като обект, бихме мислили за тях като за единица работа, когато поддържаме данните и ние ги обединяваме, така че сега е много лесно да се свърже това с различни аудитории. Те могат да се използват многократно в цялата моделна среда. Те са истински обект, а не просто рисуваща конструкция, но имаме и допълнителното предимство, че когато всъщност общуваме от гледна точка на моделирането, можем избирателно да ги сринем или разширим, за да можем да създадем обобщен изглед за диалози с определени заинтересовани аудитории, и можем, разбира се, да запазим по-подробния изглед, както виждаме тук за повече техническа аудитория. Това наистина ни дава наистина добро средство за комуникация. Това, което виждаме сега, е да комбинираме няколко различни моделни типа, да ги допълним с концепцията за обектите на бизнес данни, а сега ще говоря за това как всъщност прилагаме някакво по-голямо значение към тези типове неща и как ги свързваме заедно в нашите цялостна среда.
Просто се опитвам да намеря своя WebEx тук, така че да мога да го направя. И там се връщаме, обратно към слайдовете Hot Tech. Просто ще прескоча напред няколко слайда тук, защото вече сте ги виждали в самата демонстрация на модела. Искам да говоря за именуване на стандарти много бързо. Искаме да приложим и наложим различни стандарти за именуване. Това, което искаме да направим, е, че имаме възможност всъщност да съхраняваме шаблони за именуване на стандарти в нашите хранилища, за да изградим основно това значение чрез думи или фрази или дори съкращения и да ги вържем към смислен английски тип дума. Ще използваме бизнес термини, съкращенията за всеки и можем да определим реда, случаите и да добавим префикси и наставки. Типичният случай на използване за това обикновено е, когато хората изграждат логически модел и всъщност продължават да създават физически модел, където може би са използвали абревиатури и всичко останало.
Красивото е, че е също толкова мощно, още по-мощно отзад, ако можем просто да кажем какви са тези стандарти за именуване в някои от тези физически бази данни, които сме разработили обратно, можем да вземем тези съкращения, да ги превърнем в по-дълги думи и ги върнете обратно в английски фрази. Всъщност сега можем да извлечем правилни имена за това, как изглеждат нашите данни. Както казвам, типичният случай на използване е, че ще се придвижим напред, логично към физическото и ще картографираме хранилищата на данни и този тип неща. Ако погледнете екрана от дясната страна, ще видите, че има съкратени имена от имената на източниците и когато приложихме шаблон за стандарти за именуване, всъщност имаме още пълни имена. И бихме могли да поставим интервали и всичко подобно, ако искаме, в зависимост от шаблона на стандартите за именуване, който използвахме. Можем да го направим да изглежда, но искаме да изглежда, за да влезе в нашите модели. Едва когато знаем как се нарича нещо, всъщност можем да започнем да привързваме към него определения, защото ако не знаем какво е, как можем да приложим значение към него?
Хубавото е, можем ли всъщност да се позовем на това, когато правим всякакви неща. Говорих за обратен инженеринг, всъщност можем да извикваме едновременно шаблони за именуване на стандарти, когато правим обратна инженерия. Така че в един набор от стъпки през съветника, това, което сме в състояние да направим, е, че ако знаем какви са конвенциите, можем да обърнем инженерна физическа база данни, тя ще я върне като физически модели в среда за моделиране и това е също ще прилага тези конвенции за именуване. Така ще видим какви са англоподобните представи на имена в съответния логически модел в средата. Можем също да го направим и да го комбинираме с генерирането на XML схеми, така че да можем да вземем модел и дори да го изтласкаме с нашите съкращения, независимо дали правим SOA рамки или този тип неща, така че след това можем да изтласкаме и различни конвенции за именуване че всъщност сме се съхранявали в самия модел. Дава ни много много мощни възможности.
Отново ето пример как би изглеждал, ако имах шаблон. Този всъщност показва, че имах EMP за „служител“, SAL за „заплата“, PLN за „план“ в конвенцията за стандартите за именуване. Мога да ги прилагам, за да ги накарат да работят интерактивно, докато изграждам модели и поставям нещата. Ако използвах това съкращение и въведох „План за заплати на служителите“ на името на субекта, той ще действа с шаблона на стандартите за именуване Дефинирах тук, щеше да ми даде EMP_SAL_PLN, докато създавах субектите и ми даваше съответните физически имена веднага.
Отново, много добре, когато проектираме и напредваме инженеринга. Имаме много уникална концепция и точно тук започваме да обединяваме тези среди. И се нарича Universal Mappings. След като внесем всички тези модели в нашата среда, какво можем да направим, като приемем, че сега сме приложили тези конвенции за именуване и те са лесни за намиране, сега можем да използваме конструкция, наречена Universal Mappings в ER / Studio. Можем да свържем субекти в различни модели. Където и да видим „клиент“ - вероятно ще имаме „клиент“ в много различни системи и много различни бази данни - можем да започнем да свързваме всички тези заедно, така че когато работя с него в един модел, можете да видите къде са проявите на клиентите в останалите модели. И тъй като имаме моделния слой, представляващ това, можем дори да го обвържем с източници на данни и да го сведем в нашите, където се използват запитвания, в кои бази данни се намират и тези. Наистина ни дава възможност да свържем всичко това много сплотено.
Показах ви обектите за бизнес данни. Искам също така да говоря много бързо за разширенията на метаданните, които наричаме Прикачени файлове. Това, което прави това, ни дава възможността да създаваме допълнителни метаданни за нашите модели обекти. Доста често бих настроил тези типове свойства, за да изгоня много различни неща от гледна точка на управлението на данните и качеството на данните, както и да ни помогна с главното управление на данните и политиките за запазване на данни. Основната идея е да създадете тези класификации и да ги прикачите, където искате, на ниво таблица, ниво колона, тези видове неща. Най-често срещаният случай на използване, разбира се, е, че субектите са таблици и тогава мога да определя: какви са моите обекти на основните данни, какви са моите референтни таблици, какви са моите транзакционни таблици? От гледна точка на качеството на данните мога да направя класификации по важност за бизнеса, така че да можем да приоритизирам усилията за почистване на данни и този тип неща.
Нещо, което често се пренебрегва, е каква е политиката за запазване на различните видове данни в нашата организация? Ние можем да ги настроим и всъщност можем да ги прикрепим към различните видове информационни артефакти в нашата моделна среда и, разбира се, и в нашето хранилище. Красотата е, че тези прикачени файлове живеят в нашия речник с данни, така че когато използваме речници за данни на предприятията в околната среда, можем да ги прикачим към множество модели. Ние трябва да ги дефинираме само веднъж и можем да ги използваме отново и отново в различните модели в нашата среда. Това е само бърза снимка на екрана, която показва, че всъщност можете да посочите кога да направите прикачен файл, какви са всички парчета, към които искате да го прикачите. И този пример тук всъщност е списък със стойности, така че когато влизат, можете да изберете от списък със стойности, имате много контрол в средата за моделиране на това, което е избрано, и дори можете да зададете това, което е по подразбиране стойност е, ако стойност не е избрана. Толкова много мощност там. Те живеят в речника на данните.
Нещо, което искам да ви покажа малко по-надолу на този екран, освен това виждате прикачените файлове да се показват в горната част, под него виждате информация за сигурност на данните. Всъщност можем да приложим политики за сигурност на данните и към различните части от информацията в околната среда. За различни съпоставяния за съответствие, класификации на защитата на данните, ние доставяме няколко от тях извън кутията, които можете просто да генерирате и да започнете да използвате, но можете също да определите вашите собствени карти и стандарти за съответствие. Независимо дали правите HIPAA или някоя от другите инициативи там. И наистина можете да започнете да изграждате този много богат набор от метаданни във вашата среда.
И след това Речникът и термините - тук е свързано значението на бизнеса. Ние често имаме речници с данни, които доста често една организация използва като отправна точка, за да започне да изгонва речници, но терминологията и словесността са често много технически. Така че това, което можем да направим, е, че ако желаем, можем да използваме тези като отправна точка, за да изгоним речници, но наистина искаме бизнесът да ги притежава. Това, което сме направили в средата на екипния сървър, е дадохме възможност на хората да създават дефиниции за бизнес и след това можем да ги свържем с различните артефакти на модела, на които съответстват и в средата за моделиране. Ние също така разпознаваме въпроса, който беше обсъден по-рано, който е: колкото повече хора пишете, толкова повече потенциал има човешка грешка. Това, което също правим в нашата речникова структура е, едно, ние поддържаме йерархия на речника, така че можем да имаме различни видове речници или различни видове неща в организацията, но също толкова важно е, ако вече имате някои от тези източници там с термините и всичко, дефинирано, всъщност можем да направим CSV импортиране, за да ги включим в нашата среда за моделиране, както и на нашия сървър за екип или нашия речник и след това да започнем да свързваме оттам. И всеки път, когато нещо бъде променено, има пълна следа за одит на това какви са били преди и след изображенията, по отношение на дефинициите и всичко останало, и това, което ще видите в близко бъдеще, също е повече от процеса на оторизация така че наистина можем да контролираме кой е отговорен за това, одобренията на комисиите или отделните лица и подобен тип неща, за да направим процеса на управление още по-стабилен с напредването си.
Това също прави за нас е, когато имаме тези терминологични термини в речника на нашия сървър за екип, това е пример за редактиране в субект в самия модел, който изложих тук. Може да има свързани термини, но това, което също правим, е ако има думи, които са в този речник, които се появяват в бележките или описанията на това, което имаме в нашите субекти тук, те автоматично се показват в по-светъл хиперсвързан цвят и ако ние мишката върху тях, всъщност можем да видим определението и от бизнес речника. Дори ни дава по-богата информация, когато консумираме самата информация, с всички термини за речника, които са там. Наистина помага да се обогатим в опита и да приложим значението на всичко, с което работим.
И така, отново, това беше много бърз полет. Очевидно бихме могли да прекараме дни в това, докато се задълбочим в различните части, но това е много бързо прелитане над повърхността. Това, което наистина се стремим е да разберем как изглеждат тези сложни среди за данни. Искаме да подобрим видимостта на всички тези артефакти на данни и да си сътрудничим, за да ги изгоним с ER / Studio. Искаме да дадем възможност за по-ефективно и автоматизирано моделиране на данни. И това са всички видове данни, за които говорим, независимо дали става въпрос за големи данни, традиционни релационни данни, магазини за документи или нещо друго. И отново постигнахме това, тъй като имаме мощни възможности за напред и назад инженеринг за различните платформи и другите инструменти, които може да имате там. И всичко е в споделянето и комуникацията в цялата организация с всички заинтересовани страни. Точно тук прилагаме смисъла чрез именуване на стандарти. След това прилагаме определения чрез нашите бизнес речници. И тогава можем да направим допълнителни класификации за всички наши други възможности за управление с разширенията за метаданни, като разширения за качество на данните, класификации за управление на главни данни или всякакви други видове класификации, които искате да приложите към тези данни. И тогава можем да обобщим по-нататък и да подобрим комуникацията още повече с обектите на бизнес данните, с различните заинтересовани групи, особено между моделиерите и разработчиците.
И отново, това, което е много важно в това, е, че зад всичко това стои интегрирано хранилище с много здрави възможности за управление на промените. Днес нямах време да го покажа, защото става доста сложен, но хранилището има много здрави възможности за управление на промените и одиторски пътеки. Можете да правите именани версии, можете да правите именани версии и ние също имаме възможност за онези от вас, които правят управление на промените, можем да свържем това право с вашите задачи. Днес ние имаме възможността да поставяме задачи и да свързваме промените на вашия модел със задачите, точно както разработчиците биха свързвали промените на кода си със задачите или потребителските истории, с които също работят.
Отново това беше много бърз преглед. Надявам се, че е достатъчно, за да развиете апетита си, така че да можем да водим много по-задълбочени разговори за разделянето на някои от тези теми, докато продължаваме в бъдеще. Благодаря ви за отделеното време и обратно към вас, Ребека.
Ребека Йозвяк: Благодаря, Рон, това беше фантастично и имам доста въпроси от публиката, но искам да дам шанс на нашите анализатори да потопят зъбите си в това, което трябваше да кажете. Ерик, ще продължа напред и може би ако искаш да се обърнеш към този слайд или друг, защо да не продължиш напред? Или друг въпрос.
Ерик Литъл: Разбира се. Съжалявам, какъв беше въпросът, Ребека? Искате да попитам нещо конкретно или …?
Ребека Йозвяк: Знам, че първоначално сте имали въпроси към Рон. Ако искате да поискате сега той да се обърне към някой от тях или някои от тях от вашия слайд или нещо друго, което предизвика интереса ви, който искате да попитате? За функционалностите на IDERA за моделиране.
Ерик Литъл: Да, така че едно от нещата, Рон, така, как момчета, изглежда, че диаграмите, които показвахте, са общи видове диаграми за взаимоотношения между образувания, които обикновено бихте използвали при изграждането на база данни, нали?
Рон Хуйзенга: Да, най-общо казано, но разбира се, имаме разширените типове за магазините за документи и за този тип неща. Ние всъщност се различаваме от чисто релационни обозначения, всъщност добавихме и допълнителни обозначения за тези други магазини.
Ерик Литъл: Има ли начин, момчета, да използвате графично базирани модели модели, така че има ли начин за интегриране, например, да предположим, че имам нещо като горен квадрант, композиторски инструмент TopBraid или съм направил нещо в Protégé или, знаете ли, като финансовите момчета във FIBO, те вършат много работа в семантиката, неща в RDF - има ли начин да включите в този инструмент този тип моделиране на графика за взаимоотношения между образувания и да използвате то?
Рон Хуйзенга: Всъщност разглеждаме как можем да обработваме графики. Днес ние не обработваме изрично базите данни с графики и този тип неща, но търсим начини, по които можем да направим това, за да разширим метаданните си. Искам да кажа, че можем да внесем нещата чрез XML и този тип неща точно сега, ако можем поне да направим някакво предаване на XML, за да го внесем като отправна точка. Но ние разглеждаме по-елегантни начини да го внесем.
Освен това ви показах и списъка с обратни инженерни мостове, който имаме и там, така че винаги търсим разширения към тези мостове и за конкретни платформи. Непрекъснато, непрекъснати усилия, ако това има смисъл, е да започнете да обхващате много от тези нови конструкции и различните платформи там. Но мога да кажа, че определено сме начело в това. Нещата, които показах, например, на MongoDB и този тип неща, ние сме първият продавач на модели за данни, който всъщност прави това в собствения си продукт.
Ерик Литъл: Добре, да. И така, другият въпрос, който имах към вас, беше по отношение на управлението и поддържането на - като когато използвате примера, когато показахте примера на човека, който е „служител“, аз вярвам, че това е „ заплата “и тогава имате„ план “, има ли начин, как да управлявате, например, различни видове хора, които може да има - да предположим, че имате голяма архитектура, нали, да предположим, че имате голямо предприятие и хората започват да теглят нещата заедно в този инструмент и тук имаш една група, която има думата „служител“, и една група тук, която има думата „работник“. И един човек тук казва „заплата“, а друг казва "работна заплата".
Как момчета примирявате и управлявате и управлявате тези различия? Тъй като знам как бихме го направили в графичния свят, знаете, бихте използвали списъци на синоними или бихте казали, че има една концепция и тя има няколко атрибута, или можете да кажете в модела SKOS, че имам предпочитан етикет и имам множество алтернативни етикети, които мога да използвам. Как правите това?
Рон Хуйзенга: Правим го по няколко различни начина и преди всичко нека първо да поговорим за терминологията. Едно от нещата, които правим, разбира се, е, че искаме да имаме определените или санкционирани условия и в бизнес речника очевидно е там, където ги искаме. И ние допускаме връзки към синоними в бизнес речника, така че това, което можете да направите, е да кажете, ето моят термин, но също така можете да определите какви са всички синоними за тях.
Интересното е, разбира се, че когато започнете да разглеждате този огромен пейзаж от данни с всички тези различни системи, които сте изкарали там, не можете просто да отидете там и да промените съответните таблици и тези видове неща на отговарят на този стандарт за именуване, защото това може да е пакет, който сте закупили, така че нямате контрол върху промяната на базата данни или изобщо нещо.
Това, което бихме могли да направим там, освен че можем да свържем определенията на речника, е чрез онези универсални карти, за които говорих, какво бихме направили и един вид препоръчителен подход, е да имаме всеобхватен логичен модел, който определя какво тези различни бизнес концепции са, за които говорите. Вържете термините на бизнес речника в тези неща и хубавото е, че вече имате тази конструкция, която представлява логично образувание, както е в състояние, можете да започнете да свързвате от това логическо образувание към всички реализации на това логическо образувание в различните системи.
Тогава, където трябва да направите това, можете да видите, о, "човек" тук се нарича "служител" в тази система. Тук в тази друга система „заплата“ се нарича „заплата“. Защото ще видите това, ще видите всички различни прояви на тези, защото сте ги свързали.
Ерик Литъл: Добре, чудесно, да. В този смисъл безопасно ли е да се каже, че това е нещо като някои от обектно-ориентираните подходи?
Рон Хуйзенга: Донякъде. Това е малко по-интензивно от това, предполагам, че бихте могли да кажете. Искам да кажа, че бихте могли да възприемете подхода за ръчно свързване и преминаване и проверка и извършване на всички тях. Единственото нещо, за което всъщност нямах възможност да говоря - защото отново имаме много възможности - имаме и пълен интерфейс за автоматизация в самия инструмент Data Architect. И макро способност, която наистина е език за програмиране в инструмента. Така че всъщност можем да правим неща като да пишем макроси, да го извадим и да разпитаме неща и да създадем връзки за вас. Ние го използваме за импортиране и експортиране на информация, можем да го използваме за промяна на неща или добавяне на атрибути, събитие, базирано на самия модел, или можем да го използваме за изпълнение на партиди, за да излезем и разпитваме нещата и всъщност да попълваме различни конструкции в модел. Така че има пълен интерфейс за автоматизация, от който хората могат да се възползват. И използването на универсалните карти с тези би било много мощен начин за това.
Ребека Йозвяк: Добре, благодаря на Рон и благодаря на Ерик. Това бяха страхотни въпроси. Знам, че бягаме малко покрай върха на часа, но бих искал да дам шанс на Малкълм да хвърли някои въпроси по пътя на Рон. Малкълм?
Малкълм Чисхолм: Благодаря, Ребека. Така че, Рон, много е интересно, виждам, че тук има много възможности. Една от областите, които ме интересуват е, да речем, ако имаме проект за разработка, как виждате модела на данни, използвайки тези възможности и работещи може би по-съвместно с бизнес анализатори, с профилер на данни, с анализатор за качество на данните и със бизнес спонсорите, които в крайна сметка ще отговарят за действителните изисквания към информацията в проекта. По какъв начин модела на данни наистина, знаете, прави проекта по-ефективен и ефикасен с възможностите, които разглеждаме?
Рон Хуйзенга: Мисля, че едно от първите неща, които трябва да направите там, е като моделатор на данни - и нямам предвид да изберете някои от моделарите, но така или иначе - все пак някои хора остават с впечатлението, че модела на данни наистина е тип на ролята на вратаря, ние определяме как работи, ние сме пазачите, които се уверяват, че всичко е правилно.
Сега има аспект на това, че трябва да сте сигурни, че дефинирате звукова архитектура на данни и всичко останало. Но по-важното е като модел на данни - и това съвсем очевидно открих, когато се консултирах - трябва ли да станете фасилитатор, така че трябва да съберете тези хора заедно.
Това няма да бъде проектиране отпред, генериране, изграждане на бази данни вече - това, което трябва да можете да направите е, че трябва да можете да работите с всички тези различни заинтересовани групи, да правите неща като обратен инженеринг, да внасяте информация, да имате други хора си сътрудничат, независимо дали става въпрос за речниците или документацията, всичко подобно - и бъдете фасилитатор, за да изтеглите това в хранилището и да свържете понятията заедно в хранилището и да работите с тези хора.
Това наистина е много по-скоро обща среда за сътрудничество, където дори чрез дефиниране на задачи или дори теми за дискусии или този тип неща, които имаме в екипния сървър, хората всъщност могат да си сътрудничат, да задават въпроси и да стигнат до крайните крайни продукти, които те нужда от тяхната архитектура на данни и тяхната организация. Този отговор ли отговори?
Малкълм Чисхолм: Да, съгласен съм. Знаеш ли, мисля, че умението за улесняване е нещо, което е наистина много желателно в моделите на данни. Съгласен съм, че не винаги виждаме това, но мисля, че това е необходимо и бих предположил, че има склонност понякога да останете в ъгъла си, като правите своето моделиране на данни, но наистина трябва да сте там, работещи с другите заинтересовани групи или просто не разбирате средата с данни, с която се занимавате, и мисля, че моделът страда в резултат. Но това е само моето мнение.
Рон Huizenga: И това е интересно, защото споменахте нещо по-рано в слайда си за историята за това как предприятията са отклонени от ИТ, защото не са доставяли решенията своевременно и тези видове неща.
Много интересно е, че в по-късните ми консултантски ангажименти, преди да станат продуктов мениджър, повечето от проектите, които правих през последните две години преди това, бяха спонсорирани от бизнеса, където всъщност беше бизнесът, който го управляваше, и архитектите на данни и моделиерите не бяха част от ИТ. Бяхме част от спонсорирана от бизнеса група и бяхме там като фасилитатори, работещи с останалите екипи по проекта.
Малкълм Чисхолм: Така че мисля, че това е много интересен момент. Мисля, че започваме да виждаме промяна в света на бизнеса, където бизнесът пита, или мислим може би, не толкова, колкото какво да правя, като се обработва, но те също започват да мислят какви са данните с които работя, какви са нуждите ми от данни, какви са данните, с които се занимавам като данни и до каква степен можем да получим продуктите и възможностите на IDERA за поддържане на тази гледна точка и смятам, че нуждите на бизнеса, дори въпреки че е все още малко зараждащо се.
Рон Хуйзенга: Съгласен съм с теб и мисля, че виждаме това да върви все повече и повече по този начин. Видяхме събуждане и сте го докоснали по-рано по отношение на важността на данните. Видяхме значението на данните в началото на ИТ или в еволюцията на базите данни, тогава както казвате, ние влязохме в целия този цикъл на управление на процесите - и процесът е изключително важен, не ме разбирайте погрешно - но сега какво се случи когато това се е случило, видът на изгубения фокус.
И сега организациите осъзнават, че данните наистина са основната точка. Данните представляват всичко, което правим в нашия бизнес, така че трябва да сме сигурни, че разполагаме с точни данни, за да можем да намерим точната информация, от която се нуждаем, за да вземем своите решения. Защото не всичко идва от определен процес. Част от информацията е страничен продукт на други неща и все още трябва да бъдем в състояние да я намерим, да знаем какво означава и да можем да преведем данните, които виждаме там, в крайна сметка в знания, които можем да използваме, за да стимулираме бизнеса си по-добре.
Малкълм Чисхолм: Точно така, а сега друга област, с която се мъчих, е това, което бих нарекъл жизнения цикъл на данните, който е, знаете, ако разгледаме вида верига за предоставяне на данни, преминаваща през предприятие, ще започнем с събиране на данни или събиране на данни, което може да бъде въвеждането на данни, но може също така да бъде, получавам данни извън предприятието от някакъв доставчик на данни.
И след това от улавяне на данни преминаваме към поддръжка на данни, където мисля да стандартизирам тези данни и да ги транспортирам до местата, където са необходими. И тогава използването на данни, действителните точки, където са данните, ще извлечете стойност от данните.
И в старите времена всичко това се прави в един индивидуален стил, но днес това може да бъде, например, знаете, аналитична среда, а след това, освен това, архив, магазин, в който поставяме данните, когато вече не сме имам нужда от него и накрая един процес на чистка. Как виждате моделирането на данни да се вписва в управлението на целия този жизнен цикъл на данните?
Рон Хуйзенга: Това е много добър въпрос и едно нещо, за което днес изобщо нямах време да задълбавам подробно, е това, за което всъщност започваме да говорим, е родословието на данните. Така че това, което всъщност можем да направим, е да имаме възможност за предаване на данни в нашите инструменти и, както казвам, всъщност можем да извлечем част от него от ETL инструменти, но можете също да го картографирате, като нарисувате и родословието. Всеки от тези модели данни или бази данни, които сме заснели и внедрили в модели, бихме могли да препратим конструктите от тази в нашата диаграма на линия на данни.
Това, което можем да направим, е да изготвим поток от данни, както казвате, от източник към цел и през целия жизнен цикъл на това как тези данни преминават през различните системи и какво ще намерите е да вземем служители „данни - това е един от любимите ми, базиран на проект, който направих преди години. Работих с организация, която имаше данни за служители в 30 различни системи. Това, което в крайна сметка направихме там - и Ребека изскочи слайда на линията за данни - това е доста опростен слайд от линейни данни тук, но това, което успяхме да направим, беше да въведем всички структури от данни, да ги препратим в диаграмата и след това ние може всъщност да започне да разглежда какви са потоците между тях и как тези различни субекти на данни са свързани заедно в един поток? И ние можем да надхвърлим и това. Това е част от диаграма на потока от данни или линия на родословието, които виждаме тук. Ако искате да надхвърлите това, ние също имаме бизнес архитекта част от този апартамент и същото нещо важи там.
Всяка от структурите от данни, които сме заснели в средата за моделиране на данни, те могат да бъдат посочени в инструмента за бизнес моделиране, така че дори в диаграмите на вашия бизнес модел или диаграмите на бизнес процесите можете да се позовавате на отделни хранилища на данни, ако искате да излезете средата за моделиране на данни и докато ги използвате в папките в модела на вашия бизнес процес, можете дори да зададете CRUD и на тях, за това как тази информация се консумира или произвежда, и тогава можем да започнем да генерираме неща като отчети и анализи на въздействието и диаграми от това.
Това, към което се стремим, и вече имаме много възможности, но едно от нещата, които имаме като нещо като целта, която гледаме, докато продължаваме да развиваме инструментите си напред, е в състояние да очертае тази линия от край до край на организацията на данни и пълния жизнен цикъл на данните.
Малкълм Чисхолм: Добре. Ребека, разрешен ли съм още един?
Ребека Йозвяк: Ще ви позволя още един, Малкълм, продължете напред.
Малкълм Чисхолм: Благодаря ви много. Като мислим за управлението на данните и мислим за моделиране на данни, как да накараме тези две групи да работят ефективно и да се разбират?
Ерик Литъл: Ами това е интересно, мисля, че наистина зависи от организацията и това се връща към по-ранната ми концепция е, че в онези организации, където инициативите бяха задвижвани от бизнеса, бяхме обвързани точно. Например, аз ръководех архитектура на данни екип, но ние бяхме обвързани точно с бизнес потребителите и всъщност им помагахме да отстояват своята програма за управление на данните. Отново по-скоро на консултативен подход, но всъщност това е повече от бизнес функция.
Това, което наистина трябва да можете да направите, е, че имате нужда от моделисти на данни и архитекти, които наистина разбират бизнеса, могат да се свържат с бизнес потребителите и след това да им помогнат да устояват процесите на управление около него. Бизнесът иска да го направи, но най-общо казано, ние имаме технологичните познания, за да можем да им помогнем да изпъкнат тези видове програми. Това наистина трябва да бъде колаборация, но трябва да е собственост на бизнес.
Малкълм Чисхолм: Добре, това е страхотно. Благодаря ти.
Д-р Ерик Литъл: Добре.
Ребека Йозвяк: Добре, много благодаря. Членове на публиката, страхувам се, че не стигнахме до вашите въпроси, но ще се погрижа те да бъдат препратени към подходящия гост, който имахме на линия днес. Искам да ви благодаря толкова много на Ерик, Малкълм и Рон за това, че сте наши гости днес. Това бяха страхотни неща, хора. И ако сте се радвали на днешната трансляция на IDERA, IDERA също ще бъде на Hot Technologies следващата сряда, ако искате да се присъедините, обсъждайки предизвикателствата на индексирането и Oracles, така че друга интересна тема.
Благодаря ви много, хора, грижете се и ще се видим следващия път. Чао чао.
