1. - 1 -
2. - 2 -
3. - 3 -
4. - 4 -
5. - 5 -
6. - 6 -
7. - 7 -
8. - 8 -
9. - 9 -
10. - 10 -
11. - 11 -
12. - 12 -
13. - 13 -
14. - 14 -
15. - 15 -
16. - 16 -
17. - 17 -
18. - 18 -
19. - 19 -
20. - 20 -

Ми живемо в епоху величезних технологічних змін. Нашу життя буквально за кілька років змінили інтернет, бездротові технології, мобільні пристрої, хмарні обчислення. Це змінює те, як компанії вибудовують архітектуру ІТ-систем, що підтримують їх бізнес. Це змінює роль ІТ-керівника в компанії і нову ступінь проникнення технологій в кожен аспект діяльності компанії.

Це принципово змінює ландшафт всієї ІТ-індустрії. Це вимагає змін на стороні ІТ-постачальників, системних інтеграторів. Як технологічний прогрес впливав на ІТ-потреби бізнесу і бізнес-моделі?

- 1 -

Якщо проаналізувати розвиток корпоративних ІТ протягом десятиліть, то можна побачити, як відбувалася еволюція запитів бізнесу до ІТ, як змінювалися вимоги до них і як рішення давали можливість вирішувати всі нові і нові завдання.

І головний двигун цього розвитку - все більш тісна інтеграція різних бізнес-процесів і різних систем за допомогою все більш досконалих технологій.

Як це відбувалося?

- 2 -

Системи автоматизації стали широко використовуватися в бізнесі в 80-і роки.

На цьому етапі мова ще не йшла про інтеграцію систем - окремо один від одного, в основному на самописних системах, автоматизировались окремі не зв'язані між собою бізнес-операції, такі як розрахунок зарплати, складання балансів, розрахунок виробничих показників і т.д. Це був час окремих, не пов'язаних між собою додатків.

- 3 -

У 90-і роки на управління підприємством стали дивитися більш інтегровано.

Керівники компаній зрозуміли, що потрібно бачити не тільки якість окремих бізнес-операцій, але залежності між ними. У моду увійшов термін «бізнес-процес», і вирази «оптимізація бізнес-процесів», «виявлення« вузьких місць »та інші.

ІТ відповіли на це спробою інтеграції окремих додатків між собою, щоб охопити автоматизацією цілий бізнес-процес.

Стандартних інтерфейсів і протоколів обміну інформацією тоді ще не існувало. Тому в основному ця інтеграція полягала в написанні спеціальних програм-конекторів. З поглибленням інтеграції кількість цих самописних конекторів росло, складність систем і вартість підтримки також зростали.

Як альтернатива зростаючої складності інтеграції був запропонований підхід з впровадженням єдиних інтегрованих систем (додатків) - таких, як SAP R / 3. Цей період, безумовно, час зльоту SAP і концепції ERP. Компанії, зіткнувшись зі зростаючою складністю інтеграції розрізнених рішень, у відсутності якихось єдиних стандартів, були готові платити SAP. Головним достоїнством таких рішень була внутрішня інтегрованість.

- 4 -

Все змінилося в 2000-е. Стали з'являтися універсальні протоколи обміну даними та інтеграційні сервера, такі як IBM WebSphere або Microsoft BizTalk. Обчислювальні потужності, доступні компаніям, стали дозволяти інтегрувати між собою практично будь-які додатки. Виник новий тренд - інтеграція додатків.

- 5 -

Тоді ж з'явилися перші механізми для інтеграції даних.

По-перше, з'явилися технології підключення до джерел, вивантаження, нормалізації даних - ETL і системи інтеграції реєстрів, технології MDM. По-друге, з'явилися технології аналітичної обробки даних, OLAP, які дозволяли збирати інформацію з різних баз даних і швидко обробляти її.

- 6 -

Для зручності ці дані стали зберігати в єдиній системі. Виник такий інструмент як корпоративне сховище даних. Різні аналітичні додатки могли брати дані з нього і зберігати в ньому ж результати аналізу. Перш за все, таким чином вирішувалася досить вузька завдання підготовки аналітичної звітності.

- 7 -

Але поступово ці системи стали брати на себе все більше функцій. Поступово відмерли інтеграційні шини - завдання інтеграції стали вирішуватися безпосередньо на рівні КХД.

- 8 -

Шар аналітичних додатків також значно розширився - це була та типова аналітична звітність, і прогнозний аналіз, і інші аналітичні сервіси.

- 9 -

З ростом обсягів і різновидів даних все більше завдань лягало і на шар технологічної інтеграції даних - ETL, MDM. Сьогодні це ще й інтеграція неструктурованих даних - голос, відео, телеметрія, дані соціальних мереж і т.д.

- 10 -

Таким чином, в результаті цієї еволюції величезна корпоративне сховище даних - ми називаємо його екзахраніліщем - стає центральним компонентом корпоративної ІТ-архітектури.

Прикладні бізнес-додатки залишаються, але вони будуються поверх даних екзахраніліща і є фактично користувачами сервісів екзахраніліща.

- 11 -

Картинка, якщо зобразити на ній схематично структуру корпоративних ІТ, стає тривимірною. Є шар ІТ-інфраструктури, «заліза». Шар екзахраніліща - універсальної виртуализированной середовища зберігання і обробки інтегрованої корпоративної інформації, в якій вирішуються універсальні ІТ-завдання. Це спільний ресурс для всіх ІТ-додатків, що використовуються в організації.

І над цим сховищем побудовані додатки, які вирішують специфічні бізнес-завдання, і занурені в цю середу даних, які користуються її обчислювальними ресурсами, універсальними сервісами і збереженої там інформацією.

Можна називати такий підхід побудови ІТ «датацентрічной корпоративної ІТ-архітектурою».

Насправді це не просто нова ІТ-архітектура, це відображення нової парадигми ведення бізнесу - інтеграція між собою внутрішніх і зовнішніх інформаційних потоків, управління в реальному бізнесі, Інтелектуальне рішення в інтересах бізнесу.

- 12 -

Не потрібно забувати, що на це наклалося нове явище, яке ми називаємо «великі дані» - нова ІТ-архітектура повинна дозволяти зберігати і обробляти ці надвеликі обсяги, працювати з неструктурованими даними.

Це висуває нові вимоги до якості всієї ІТ-інфраструктури.

- 13 -

З появою ІТ-архітектури, в центрі якої знаходяться потоки бізнес-даних, виникла нова бізнес-завдання, якої раніше в принципі не існувало. Це забезпечення організаційного процесу управління корпоративними даними (Data Governance).

Вирішення цього завдання має на увазі створення спеціальної організаційної одиниці, яка займається управлінням даними як активом організації. Це великий складне питання: яким чином методологічно управляти життєвим циклом даних, яким чином підтримувати корпоративну модель даних. Без такої моделі, без розуміння, які дані є в організації, як ними управляти і як вони можуть бути використані бізнесом, дані не представляють ніякої цінності.

У більшості компаній це питання поки що ніяк не вирішується, хоча в західних компаніях є приклади ставлення до даних як до найважливішого корпоративному активу.

- 14 -

Пора трохи ближче поглянути на функціональну архітектуру екзахраніліща. Тому що зовні виглядає досить просто, ця структура всередині дуже складна. Вирішення багатьох із завдань, покладених на кожен шар, базується, як правило, на різних спеціалізованих системах, які повинні бути наскрізним чином інтегровані між собою.

- 15 -

При цьому вся архітектура існує не сама по собі, а в просторі інших, нових вимірів, таких як мобільність, хмари, зовнішні програмні сервіси, гібридні рішення і т.д.

- 16 -

Якщо уважніше придивитися на «будівельні блоки», з яких вибудовується екзахраніліще у великій організації, то ми побачимо, що це десятки і сотні різних продуктів і рішень.

Ми живемо в епоху вкрай фрагментированного продуктового ландшафту - вже далеко в минулому ті часи, коли корпорації спиралися тільки на два-три великих бренду. Раніше, якщо говорили про обробку даних, брали Microsoft, Oracle, іноді db2. Сьогодні кількість продуктів, які спеціалізуються на інтеграції даних, вимірюється сотнями - досить поглянути на аналітичні звіти по ринку Gartner або IDC.

- 17 -

Ці платформи і продукти не так легко складаються разом в єдину картину. Рішення часто поєднують в собі властивості і функції з різних функціональних шарів.

- 18 -

Крім того, інтеграція продуктів і платформ відбувається не «в чистому полі», а в певному сформованому успадкованому корпоративному ландшафті, від якого не можна одномоментно відмовитися. Перехід до нової екза-архітектурі повинен відбуватися без переривання обслуговування поточної ІТ-структури. Це еволюційний процес.

- 19 -

В результаті виходить досить складне завдання на перетині різних експертиз.

Потрібно укласти всі ці нестандартні шматки-компоненти в досить правильну картинку, грамотно підібрати продукти, інтегрувати всі між собою, зробити так, щоб всі завдання бізнесу були закриті тих чи інших продуктом.

Потрібно продумати, яким чином еволюційно відбувається поступовий перехід до нової архітектури і як вона вписується в існуючий успадкований ландшафт.

Все це професійна зона застосування знань для фахівців в області інтеграції систем і даних. Такі послуги будуть затребувані в найближчому майбутньому.

- 20 -

Для таких проектів всередині компаній повинен вирости внутрішній замовник.

Для вирішення нової бізнес-завдання поступово виникає новий корпоративний лідер - CDO, Сhief Data Officer. Завдання CDO, як уже говорилося, - побудувати модель даних, організувати її підтримку і забезпечити взаємодію всіх керівників C-level з питань корпоративних даних.

Завдання CIO і CDO не в тому, щоб побудувати універсальну архітектуру, яка могла б вже сьогодні вирішити всі завдання функціональних замовників на найближчі 10 років. Передбачити нічого не можливо. Головні характеристики дата-архітектури майбутнього - це гнучкість і адаптивність.

Тому завдання ІТ-керівника - створити таку ІТ-архітектуру компанії, яка б дозволила дуже швидко і з зрозумілим ефектом розгортати нові сервіси поверх єдиного корпоративного екзахраніліща. Він повинен мати можливість максимально швидко реагувати на виникнення нових потреб у бізнес-замовника. Виклик CIO - побудувати інфраструктуру високої готовності, високої гнучкості, з урахуванням всіх нових платформ і необхідності адаптації до майбутніх змін.

Виклик CDO - знайти спосіб зробити цифрові дані організації активом, що приносить дохід. Це складне завдання, це вдається поки далеко не всім.

Але ті, кому вдасться це зробити - досягнуть успіху, а хто ні - ті, безумовно, втратять.