Спеціаліст з архітектури програмних систем: Частина 2. Про труднощі проектування архітектури даних
- Серія контенту:
- Цей контент є частиною серії: Спеціаліст по архітектурі програмних систем
- Каталізатор - зміна
- проблеми
- "Це всього лише дані"
- Малюнок 1. Масиви даних не завжди об'єднуються в процесі інтеграції
- Технічні перешкоди
- шлях вперед
- Пошук союзників
- наведення мостів
- Ітерація, ітерація і ще раз ітерація
- висновок
- Ресурси для скачування
Спеціаліст з архітектури програмних систем
Як впоратися з професійними труднощами розробки архітектури даних
Серія контенту:
Цей контент є частиною # з серії # статей: Спеціаліст по архітектурі програмних систем
https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=Специалист+по+архитектуре+программных+систем
Слідкуйте за виходом нових статей цієї серії.
Цей контент є частиною серії: Спеціаліст по архітектурі програмних систем
Слідкуйте за виходом нових статей цієї серії.
Архітектура даних - це розвивається дисципліна, яка займається статичними (моделювання даних) і динамічними (потоки даних) характеристиками інформації в системах, що поєднують кілька відділів або навіть всі підрозділи організації. Розробники архітектури даних завідують усіма формами представлення даних на підприємстві - від реляційних баз даних до плоских файлів, від документів і матеріалів до звітів і даних транзакцій. У цьому описана дисципліна перетинається з дисципліною проектування загальної архітектури організації, яка прагне оптимізувати бізнес-процеси в цілому через інформаційні технології, і дисципліною проектування інформаційної архітектури, яка шукає найкращі способи подання інформації в роботі користувачів (як правило, в мережі Інтернет). Нещодавно організації стали розуміти, що управляти даними слід глобально, незалежно від систем, які обробляють їх в даний час, у зв'язку з чим роль розробника архітектури даних значно зросла. Незважаючи на це, розробники архітектури даних відчувають значні труднощі у виконанні своїх службових обов'язків у багатьох організаціях. Велика частина цих труднощів аналогічна тим, з якими стикалися й інші дисципліни проектування архітектури програмного забезпечення в процесі їх становлення, і можуть служити уроком для всіх фахівців подібних професій.
Каталізатор - зміна
В інформаційних технологіях (ІТ) зміни відбуваються постійно. Сьогодні керівник може звернути увагу на портфель автономних додатків з багаторівневою архітектурою, завтра - на проекти планування ресурсів організації (enterprise resource planning, ERP), а післязавтра - на сервіс-орієнтовану архітектуру (Service-Oriented Architecture, SOA). Розробники та керівники приходять і йдуть, організації об'єднуються, а галузеві тенденції змінюються. Підтримувати актуальність ІТ-систем при такій кількості змін завжди було найскладнішим справою фахівців з інформаційних технологій і причиною багатьох дуже неприємних проблем, в тому числі, не відбулися проектів і перевитрат коштів. Останні події показали важливість збереження значення даних організації при впливі таких змін. Успіх Web-технологій, в тому числі XML і розвивається технології SOA, послужили тим "пряником", завдяки якому керівники почали лояльніше ставитися з повагою до архітектури даних, а законодавчі вимоги, наприклад, закон Сарбейнса-Окслі в США, зіграли роль "батога". -аудиторія і фахівці із забезпечення відповідності нормативним вимогам тепер в плановому порядку попереджають керівників про те, що їм, найімовірніше, доведеться зберігати дані і забезпечувати управління ними набагато довше корисного життєвого циклу програм, котор Перші обробляють ці дані. Такі дії завжди вважалися правильними, а зараз це перетворилося в визнану норму.
Розробники архітектури даних все частіше приймають рішення, що сприяє підвищенню їх ролі в організації. На жаль, вони часто виявляють, що коло своїх функцій і обов'язків став ширше, а ось ресурсів або повноважень, які дозволили б виправдати очікування, не додалося; подібна комбінація може виявитися ризикованою не тільки для кар'єри окремого спеціаліста, а й для реалізації глобальних цілей організації. Стійка архітектура даних зазвичай вимагає внесення в додатки і бізнес-процеси невеликих змін, а посадові обов'язки фахівця в організаційній схемі рідко надають таке право. В останнє десятиліття проекти ERP тісно зв'язувалися з більш стрімкими змінами під прапором реінжинірингу бізнес-процесів (business process reengineering, BPR), і такі зміни затверджувалися наказами керівництва. Більшість розробників архітектури даних не мають наказів керівників, на які вони могли б спиратися, не дивлячись на те, що вони вимагають від організації набагато менше, ніж ERP. Це сувора правда життя, і у фахівців немає іншого виходу, крім як сприятиме поступовій каталізації таких змін за принципом: одна маленька перемога за один раз.
проблеми
Класифікація проблем, з якими можуть зіткнутися розробники архітектури даних, захищаючи корпоративні моделі даних - майже завжди невдячна справа. Обговорюючи цю проблему з колегами, я виявив, що цей список майже універсальний і до болю знайомий всім фахівцям. Проте, я вважаю, що корисно ще раз обговорити ці проблеми, щоб виробити ефективну стратегію руху вперед.
"Це всього лише дані"
Слабкі місця в архітектурі даних завжди стають видні в ході інтеграції. Інтеграція систем довго розглядалася як злиття функціональних можливостей, а не злиття інформації. Керівники програм приділяють більше уваги коду і шаблонами проектування, ніж спільно використовуються моделям даних. Нерідко результатом проекту інтеграції двох додатків стає об'єднане додаток, яке працює на двох вихідних масивах даних, як показано на малюнку 1. Величезна частина інфраструктури остаточного об'єднаного додатки виділяється для обслуговування запитів між двома цими масивами. В "старі недобрі часи" програмування "під конкретну ситуацію" особи, відповідальні за прийняття рішень, відмовлялися від ідеї розробки архітектури програмного забезпечення зі словами "це всього лише код". В наші дні програмний код вже отримує щедру допомогу від засобів проектування і планування, і ви, швидше за все, почуєте іншу фразу: "Це всього лише дані." Деякі форми даних, наприклад, реляційні дані, насолоджуються перевагами спрямованого проектування, і це - результат невтомної діяльності відповідних фахівців. Аналогічне увагу нечасто приділяється всім іншим видам даних в системі. Для того, щоб таке розуміння поширилося на інші види даних, буде потрібно менше вузькоспеціалізована підтримка, але розробника архітектури, який буде наполягати на такій увазі, можуть вивести з гри, або, ще імовірніше, спочатку підтримають тільки для того, щоб під тиском непередбачених обставин на завдання, ресурси або графік проекту відмовитися від усіх пропонованих їм переваг.
Малюнок 1. Масиви даних не завжди об'єднуються в процесі інтеграції
Різне розуміння
Як не дивно, рука об руку з проблемою "це всього лише дані" часто йде дискусія про контроль над даними. Існує тенденція, згідно з якою важливі дані, що походять з додатка, розробленого одним з підрозділів організації, в кінцевому підсумку стають необхідними іншим підрозділам. Проект інтеграції, який має на меті генерализацию контролю над даними, часто стикається з проблемою розподілу інтересів. Без уважного ставлення до проектування дані можуть бути в кінці кінців обмежені точкою зору одного підрозділу, що знизить їх цінність для всіх інших підрозділів, але, оскільки створити нейтральний проект досить складно, суперечки з цього приводу іноді можуть призвести до відмови від проекту.
Технічні перешкоди
У порівнянні з організаційними перешкодами здається, що технічних не дуже багато, але коли доходить до справи, такі питання, як управління версіями даних, паралелізм (блокування) і управління життєвим циклом ніколи не бувають простими. Як і раніше, дуже складно визначити і застосувати бізнес-правила, які повинні надати форму даними і забезпечити технологію наочного уявлення, що дозволяє зробити цю форму доступною користувачам даних. Всі ці технічні проблеми додатково посилюються внаслідок протиріч в розумінні даних (різні підрозділи компанії, можливо, хотіли б налаштувати різні блокування або правила життєвого циклу), і для їх вирішення потрібні такі види ресурсів, які навряд чи можуть бути отримані - адже "це всього лише дані ".
шлях вперед
Неможливо досягти мети, якщо думати тільки про труднощі. Існують різні тактики, які може використовувати розробник архітектури даних, щоб виконувати свою роботу в організації.
Пошук союзників
Найпростіший спосіб дій при впровадженні архітектури даних - це пошук друзів. Всі взаємодії фахівців - це різноманітні обговорення, тому завжди дуже важливо залучити на свою сторону головне відповідальна особа. Це не тільки дасть вам союзника, а й підвищить ваші шанси на те, що вас всерйоз сприймуть інші керівники. Іноді особи, відповідальні за прийняття рішень, можуть відчувати стадне почуття і небажання виглядати незгодним з думкою керівництва. Можна знайти керівників, які мають досвід успішних проектів з сильною архітектурою даних на попередньому місці роботи або навіть на нинішній посаді. Знання попереднього досвіду основних осіб, відповідальних за прийняття рішень - це ключ до управління їх зацікавленістю в той момент, коли ви будете пояснювати їм значення пропонованої вами архітектури. З великою ймовірністю вашим прихильником може стати керівник підрозділу, який з найбільшою очевидністю виграє від реалізації проекту. Ефективна архітектура даних, безумовно, повинна прагнути забезпечити переваги всієї організації, але часто набагато більш наочним буде показати окремій групі з загальним набором інтересів, як ваша робота допоможе їй досягти більшої ефективності. Немає нічого помилкового або нечесного в тому, щоб спочатку відточити свою тактику на таких групах. Я прийшов до висновку про небезпеку однієї тактики, яка полягає в тому, щоб зробити своїм прихильником постачальника програмного забезпечення. Керівники часто пов'язують проекти інтеграції з конкретним виробником програмного забезпечення або сервісів, які повинні забезпечити інтеграцію. Може здатися привабливим спробувати вибудувати архітектуру даних відповідно до плану постачальника, але насправді це дуже рідко буває здійсненним. Велика частина програм і сервісів інтеграції розробляється з урахуванням організаційної моделі постачальника, і більшість компаній вважає за краще в деякій мірі нав'язати клієнтам свої бізнес-процеси, ніж змінювати свої програми відповідно до потреб клієнтів.
наведення мостів
Різні підрозділи організації можуть мати різні точки зору, але, в кінцевому підсумку, їм необхідно виробити способи спільної роботи. Допомагаючи організувати спільне використання даних, ви створюєте реальну цінність у вигляді зниження витрат, запобігання додаткових витрат і, за певних сприятливих обставин, можете навіть сприяти отриманню прибутку, наприклад, якщо ваша робота забезпечує раніше не використовувалися можливості перехресних продажів або продажу більш дорогих продуктів споживачеві. Використовуйте бажання керівників взяти на себе відповідальність за бізнес-процес через підтримку керівних рад за основними, спільно використовуваних даних, які роз'яснюють, як саме потоки даних підтримують процес. Це може бути простіше, ніж вам здається. Як правило, ті ж самі керівники, які відмовляються надати більш матеріальні ресурси, із задоволенням беруть участь в роботі практичних комітетів. Тісне спілкування в такій межфункциональной групі в деякому роді допоможе вам зрозуміти практичні аспекти організації, які наповнять змістом архітектуру даних. Зазвичай можливість навести мости з'являється в зв'язку зі стратегічними проектами великої важливості, з зацікавленими особами з декількох підрозділів.
Ітерація, ітерація і ще раз ітерація
Проект масштабу організації може здатися нездійсненою мрією для більшості розробників архітектури даних, але шлях до такого проекту починається з більш скромних здобутків. Якщо ви бачите перспективу в порівняно невеликому, але стратегічно важливому проекті, наприклад, проект нового Web-сайту, що сприяє розвитку електронної торгівлі, -то можна розробити вузькоспрямований рекламний заклик до зацікавлених осіб, можливо, про важливість даних, які можуть бути доступні з здаються віддаленими джерел, або очікуваному виграші в продуктивності за рахунок добре оптимізованих потоків даних. Якщо у вас буде один або два союзника, це дуже допоможе в даному питанні. Якщо ви можете створити точку опори в плані проекту, будьте далекоглядні. Якщо проект виявляється успішним, обов'язково знову зустріньтеся з зацікавленими особами і розкажіть їм про реальні переваги ваших розробок, і навіть про майбутні переваги в сенсі можливої інтеграції з іншими системами. Вони можуть стати вашими союзниками в наступних проектах, які зможуть розвинути ваш успіх. Після роботи над лінійкою таких проектів у вас, ймовірно, з'явиться модель даних, яка задовольняє потребам декількох підрозділів, і можливість втілити в життя більш честолюбні плани. Крім того, у вас буде перевага декількох ітерацій для вирішення певних технічних складнощів, що дозволить екстраполювати проекти до більш масштабних рішень.
висновок
Майже всі галузеві дисципліни, що з'явилися останнім часом, спочатку стикалися з проблемами, аналогічними тим, які розглядалися в даній статті. Розробникам архітектури даних нескладно відчути себе пригніченими перед лицем цих проблем, тому важливо сконцентруватися на позитивних моментах. В даний час організації приділяють безпрецедентне увагу ролі даних в корпорації, і, незважаючи на початкові труднощі, це може означати тільки хороше майбутнє для професії розробника архітектури даних. Підбираючи союзників в середовищі керівництва, наводячи мости між підрозділами організації і домагаючись помірних успіхів в ретельно підбираються проектах, професійні розробники архітектури даних можуть зміцнити своє майбутнє, поступово перетворюючи свої обіцянки організації в реальність.
Ресурси для скачування
Схожі теми
- Оригінал статті: The professional architect, Part 2: Overcoming professional challenges in data architecture (EN) ;
- Завантажте ознайомлювальну версію: Rational Data Architect . Цей інструмент моделювання корпоративних даних і розробки інтеграції з сімейства ПО Rational® призначений для того, щоб допомогти розробникам архітектури даних в створенні реляційних і інтегрованих баз даних, осмисленні інформаційних ресурсів і їх взаємозв'язків і раціоналізації проектів баз даних; (EN)
- Додаткову інформацію про різні типи розробників архітектури даних можна знайти в статтях Вікіпедії про (EN) архітектурі даних , корпоративної архітектурі і інформаційної архітектурі ;
- Про те, як можна використовувати в розробці архітектури даних процес Rational і уніфікована мова моделювання (Unified Modeling Language, UML), можна дізнатися зі статті " Modeling the enterprise data architecture "(Моделювання архітектури корпоративних даних) Ендрю Джонстона (Andrew Johnston) і Річарда Уіггінс (Richard Wiggins) (developerWorks, февраль 2003 г.); (EN)
- У першій статті даної серії, " The professional architect, Part 1: How developers become architects "(Спеціаліст по архітектурі програмних систем, частина 1: Як розробники стають системними архітекторами) Юча Огбуджі (Uche Ogbuji) (developerWorks, грудень 2006 р), розповідається про те, як багато розробників архітектури зросла з розробників ПЗ;
- відвідайте розділ SOA і Web-сервіси сайту developerWorks для отримання більш докладної інформації про SOA;
- Використовуйте в своєму наступному проекті по розробці ознайомчі версії ПЗ IBM , Які можна завантажити безпосередньо з сайту developerWorks. (EN)
Підпишіть мене на повідомлення до коментарів
Jsp?