Про т.зв. "універсальну шину даних" (чи інтеграційну шину даних), enterprise service bus, ESB, — не з інженерної точки зору, а з точки зору внутрішніх бізнес-споживачів, перш за все — керівників.
Зазвичай у інженерів чи, скоріше, архітекторів інформаційних рішень є різні підходи щодо доцільності ESB.
Коротко, що таке ESB: це програмне забезпечення, платформа, що забезпечує уніфікований та централізований обмін даними, зазвичай на принципах сервіс-орієнтованої архітектури.
Часто архітектори тяжіють до інтеграційних рішень між різними системами типу "кожен з кожним" або фактично "доручають" функції інтеграційної платформи якійсь одній чи, рідше, кільком "провідним" системам.
Давайте розберемо деякі очевидні аргументи за та проти.
Коли систем не так вже й багато, або коли нема потреби в інтеграції всіх систем, лише кількох, то інтеграція "кожен з кожним" (кому потрібно і з ким потрібно) може мати сенс. Очевидний плюс — частіше за все це найдешевше рішення в короткостроковій перспективі.
Очевидний мінус — за умови розвитку, особливо, якщо майбутні потреби не досить ясні, загальна архітектура перетворюється на жмуток переплетеної вермішелі — чи клубок змій, кому як краще. При цьому навантаження на деякі системи може стати досить значним, а розвиток може бути пов'язаний з переглядом значної частини "вермішелі", якщо не всієї загалом.
Тим не менш, якщо системи всього дві, наприклад, то таке рішення, особливо з огляду на потреби моменту, може бути найбільш оптимальним.
Ситуація, коли роль платформи обміну даними повністю чи частково виконує якась одна система, найчастіше виникає з ситуації, коли актуалізується задача контролю даних і управління процесами в більш складних ситуаціях, ніж обмін, наприклад, між CRM-системою та системою бухгалтерського обліку. Часто таку роль виконує ERP-система чи ERP-подібне галузеве рішення, але може й взагалі будь-яка система, що більш розвинута в порівнянні з іншими. Деколи таку роль на себе бере та система, якій більш "потрібно", тобто архітектура складається через конкретні потреби конкретних бізнес-функцій, наприклад, маркетингу та продажу. Тоді чутливі до таких потреб даних можуть акумулюватись в CRM-системі, системі автоматизації маркетингу чи інших системах автоматизації (наприклад, систем RPA, robotic process automation).
Чому це питання може бути актуально для бізнесу? Тому що інженери часто не бачуть загальної картини, не знайомі чи не достатньо розуміють стратегію розвитку та задумки керівництва. Вони, загалом, мислять по-інженерному: є задача — потрібно рішення. Або, у випадку архітекторів: є група задач, є варіанти рішень, треба вибрати оптимальне архітектурне рішення, яке дозволить рішення перелічених та вірогідних в майбутньому задач.
З іншого боку, "бізнес" менеджери деколи або недооцінюють можливості інформаційних технологій, або, частіше, переоцінюють їх і схильні очікувати гарантовані рішення, навіть в умовах, коли початкові дані не дуже визначені.
Дозволю собі порівняння з авіаційною темою: рішення "кожен з кожним" схоже на чартерні рейси. Ніщо не буде дешевшим і ефективнішим, якщо мова йде про визначену заздалегідь кількість пасажирів та маршрут. Але побудувати системне рішення за допомогою чартерів ще не вдалося нікому — бо в загальному випадку кількість пасажирів дуже змінюється і її важко "впихувати" в певні межі стандартного рейсу.
При цьому, зверніть увагу на певний псевдопарадокс: перельот з адреси до адреси зазвичай дорожче, чим такий само з однією чи двома пересадками. З точки зору фізики, пересадки — зайві витрати пального, часу, грошей на послуги аеропорту і т.д.
Але з точки зору логістики, мова не йде про літак. Мова йде про різномаїття пасажирів, а стикувати їх рейси та влаштовувати рейси "останньої милі" простіше і дешевше через хаб, тобто з пересадками, чим через організацію прямих рейсів. Тобто маємо: для пасажира оптимальний маршрут — прямий, але для перевізника — через хаб, який дозволяє оптимізувати і навантаження, і напрямки, і координувати час, і багато іншого. Ціну встановлює перевізник, тому ми бачимо, що парадоксу нема: те, що для перевізника дешевше, він може дешевше і продати.
Приблизно така сама ситуація і в інформаційних технологіях: хаб у вигляді інтеграційної шини може допомогти оптимізації запитів, уніфікації форматів, координації завантаження різних ресурсів, масштабування чи розвиток інформаційної архітектури і т.д.
Потрібна така шина чи ні — універсальної відповіді, звісно, нема.
Але керівникам корисно розуміти, в чому різниця, які плюси-мінуси, і які питання та задачі ставити інженерам чи аналітикам — особливо, якщо ситуація знаходиться в динаміці і треба заздалегідь забезпечити потрібні можливості. І розуміти, звісно, ціну різних варіантів рішення.
Перетворення якоїсь однієї системи на інтеграційну платформу добре виглядає з огляду на еволюційність змін, але підвищує залежність і від цієї платформи, і, як наслідок, від її можливостей, розробників, цінової політики і т.і.
Створення окремої інтеграційної платформи — стратегічно серйозне рішення, але воно буде потребувати і коштів, і зусиль кваліфікованих спеціалістів, і розуміння стратегії розвитку. Інакше все може вилитись в коштовний, але малокорисний проект.
Загалом, резюме: створення інтеграційної платформи може бути коштовним, але стратегічно це може відкрити двері більш гнучким і швидким рішенням, що в свою чергу може бути важливим в умовах постійних змін.
Зазвичай у інженерів чи, скоріше, архітекторів інформаційних рішень є різні підходи щодо доцільності ESB.
Коротко, що таке ESB: це програмне забезпечення, платформа, що забезпечує уніфікований та централізований обмін даними, зазвичай на принципах сервіс-орієнтованої архітектури.
Часто архітектори тяжіють до інтеграційних рішень між різними системами типу "кожен з кожним" або фактично "доручають" функції інтеграційної платформи якійсь одній чи, рідше, кільком "провідним" системам.
Давайте розберемо деякі очевидні аргументи за та проти.
Коли систем не так вже й багато, або коли нема потреби в інтеграції всіх систем, лише кількох, то інтеграція "кожен з кожним" (кому потрібно і з ким потрібно) може мати сенс. Очевидний плюс — частіше за все це найдешевше рішення в короткостроковій перспективі.
Очевидний мінус — за умови розвитку, особливо, якщо майбутні потреби не досить ясні, загальна архітектура перетворюється на жмуток переплетеної вермішелі — чи клубок змій, кому як краще. При цьому навантаження на деякі системи може стати досить значним, а розвиток може бути пов'язаний з переглядом значної частини "вермішелі", якщо не всієї загалом.
Тим не менш, якщо системи всього дві, наприклад, то таке рішення, особливо з огляду на потреби моменту, може бути найбільш оптимальним.
Ситуація, коли роль платформи обміну даними повністю чи частково виконує якась одна система, найчастіше виникає з ситуації, коли актуалізується задача контролю даних і управління процесами в більш складних ситуаціях, ніж обмін, наприклад, між CRM-системою та системою бухгалтерського обліку. Часто таку роль виконує ERP-система чи ERP-подібне галузеве рішення, але може й взагалі будь-яка система, що більш розвинута в порівнянні з іншими. Деколи таку роль на себе бере та система, якій більш "потрібно", тобто архітектура складається через конкретні потреби конкретних бізнес-функцій, наприклад, маркетингу та продажу. Тоді чутливі до таких потреб даних можуть акумулюватись в CRM-системі, системі автоматизації маркетингу чи інших системах автоматизації (наприклад, систем RPA, robotic process automation).
Чому це питання може бути актуально для бізнесу? Тому що інженери часто не бачуть загальної картини, не знайомі чи не достатньо розуміють стратегію розвитку та задумки керівництва. Вони, загалом, мислять по-інженерному: є задача — потрібно рішення. Або, у випадку архітекторів: є група задач, є варіанти рішень, треба вибрати оптимальне архітектурне рішення, яке дозволить рішення перелічених та вірогідних в майбутньому задач.
З іншого боку, "бізнес" менеджери деколи або недооцінюють можливості інформаційних технологій, або, частіше, переоцінюють їх і схильні очікувати гарантовані рішення, навіть в умовах, коли початкові дані не дуже визначені.
Дозволю собі порівняння з авіаційною темою: рішення "кожен з кожним" схоже на чартерні рейси. Ніщо не буде дешевшим і ефективнішим, якщо мова йде про визначену заздалегідь кількість пасажирів та маршрут. Але побудувати системне рішення за допомогою чартерів ще не вдалося нікому — бо в загальному випадку кількість пасажирів дуже змінюється і її важко "впихувати" в певні межі стандартного рейсу.
При цьому, зверніть увагу на певний псевдопарадокс: перельот з адреси до адреси зазвичай дорожче, чим такий само з однією чи двома пересадками. З точки зору фізики, пересадки — зайві витрати пального, часу, грошей на послуги аеропорту і т.д.
Але з точки зору логістики, мова не йде про літак. Мова йде про різномаїття пасажирів, а стикувати їх рейси та влаштовувати рейси "останньої милі" простіше і дешевше через хаб, тобто з пересадками, чим через організацію прямих рейсів. Тобто маємо: для пасажира оптимальний маршрут — прямий, але для перевізника — через хаб, який дозволяє оптимізувати і навантаження, і напрямки, і координувати час, і багато іншого. Ціну встановлює перевізник, тому ми бачимо, що парадоксу нема: те, що для перевізника дешевше, він може дешевше і продати.
Приблизно така сама ситуація і в інформаційних технологіях: хаб у вигляді інтеграційної шини може допомогти оптимізації запитів, уніфікації форматів, координації завантаження різних ресурсів, масштабування чи розвиток інформаційної архітектури і т.д.
Потрібна така шина чи ні — універсальної відповіді, звісно, нема.
Але керівникам корисно розуміти, в чому різниця, які плюси-мінуси, і які питання та задачі ставити інженерам чи аналітикам — особливо, якщо ситуація знаходиться в динаміці і треба заздалегідь забезпечити потрібні можливості. І розуміти, звісно, ціну різних варіантів рішення.
Перетворення якоїсь однієї системи на інтеграційну платформу добре виглядає з огляду на еволюційність змін, але підвищує залежність і від цієї платформи, і, як наслідок, від її можливостей, розробників, цінової політики і т.і.
Створення окремої інтеграційної платформи — стратегічно серйозне рішення, але воно буде потребувати і коштів, і зусиль кваліфікованих спеціалістів, і розуміння стратегії розвитку. Інакше все може вилитись в коштовний, але малокорисний проект.
Загалом, резюме: створення інтеграційної платформи може бути коштовним, але стратегічно це може відкрити двері більш гнучким і швидким рішенням, що в свою чергу може бути важливим в умовах постійних змін.
No comments:
Post a Comment