SOA і ситуативні програми: Частина 1. Зміна комп’ютингу в організації, Комерція, Різне, статті

Введення


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


Поки організації визначали і втілювали в життя свої SOA-ініціативи, недавній підйом масового комп’ютингу як серед професійних програмістів, так і серед співробітників, що володіють знаннями в області програмування, привів до виникнення іншого підходу до розробки. Відповідно до цього підходу фахівці, найкраще розбираються в бізнес-проблеми, розробляють рішення прискореним методом без звичайних непродуктивних витрат і формалізму традиційних IT-методів. Нове покоління ситуативних додатків (SA), які часто розробляються програмістами-аматорами ітеративним і колективним способом, скорочують традиційний життєвий цикл розробки на етапах редагування-компіляції-тестування-запуску. SA мають потенціал для вирішення нагальних бізнес-проблем найбільш рентабельним способом завдяки тому, що вони фіксуються на тій частині інформаційних систем, яка безпосередньо впливає на кінцевих користувачів, і націлені на області, які в організації досі вважалися занадто вузькоспеціалізованими або низькопріоритетним.


У даній серії статей про ситуативних додатках:


Частина 1:



Частина 2:



Частина 3:



Підйом в сфері ситуативних додатків, що використовують мережу Інтернет







 



Особливості ситуативних додатків:

  • Розробляються для вирішення конкретної ситуації;
  • Часто створюються непрофесійними, програмістами, що займаються програмуванням від випадку до випадку, акцент в них робиться на таких властивостях, як надійність, масштабованість, легкість в обслуговуванні і доступність;
  • Зазвичай використовують вже існуюче програмне забезпечення, Часто створене сторонніми розробниками, через відкритий інтерфейс;
  • Цикли розробки нетривалі, ітеративні, Що становлять кілька днів або тижнів, а не місяців чи років; особлива увага приділяється показнику time-to-value;
  • Зазвичай призначені для роботи з інформаційними ресурсами.
В есе Клея Ширкі (Clay Shirky), названому “Situated Software“(Ситуативна програмне забезпечення), описується тип програмного забезпечення, який” розробляється для використання конкретної соціальною групою, а не звичайним безліччю користувачів. “Автор доводить, що “велика частина програмного забезпечення, яке створювалося для величезних кількостей користувачів або розроблялося для використання протягом необмеженого часу так чи інакше не досягає жодної з цих двох цілей. “


Визнаний в широких колах термін ситуативні програми відноситься до таких додатків, які створюються для вирішення конкретної ситуації, проблеми або завдання. Життєвий цикл розробки для цього типу додатків відрізняється від традиційної розробки SOA-рішень фахівцями з IT. SA-програми зазвичай створюються нештатними програмістами з використанням коротких, ітеративних життєвих циклів розробки, які часто вимірюються днями або тижнями, а не місяцями або роками. У міру змін вимог малого колективу, який використовує програму, SA часто продовжує розвиватися, вбираючи в себе ці зміни. Істотні зміни у вимогах можуть привести до повної відмови від програми, в деяких випадках легше розробити новий додаток, ніж змінювати старе.


Ідея комп’ютингу для кінцевого користувача в організаціях не нова. Розробка додатків непрофесійними програмістами за допомогою IBM Lotus Notes, електронних таблиць Microsoft Excel в поєднанні з Microsoft Access або інших інструментів отримала широке поширення. Нове полягає в поєднанні вражаючого зростання комп’ютингу силами користувальницьких спільнот і загальним підвищенням кваліфікації користувачів, появою нових технологій і зростаючої потреби в динамічності бізнесу.


Поява таких технологій, як Asynchronous JavaScript + XML (Ajax), які використовують спрощений доступ до даних в мережі Інтернет і повнофункціональні елементи управління користувальницького інтерфейсу (UI), в поєднанні з архітектурним стилем Web-сервісів Representational State Transfer, REST (передача репрезентативних станів) надає зручну палітру для складання високоінтерактівних додатків на основі браузера.


Як і рішення на базі SOA, SA-додатки рідко розробляються з нуля, частіше вони збираються з уже існуючих компонувальних блоків (або запасних частин, як прийнято їх називати). Найбільш відоме підмножина SA – це гібридні додатки (Mashup). Велика кількість нескладних інтерфейсів прикладного програмування (API) і використання Web-компонентів в стилі Ajax (наприклад, шаблони проектування Yahoo Developer Network і API, представлені на Web-сайті ProgrammableWeb.com) внесли свій внесок у зростання популярності цього стилю розробки. В результаті отримали нове життя більш старі Web-технології, наприклад JavaScript.


У таблиці 1 перераховані фактори, які внесли свою лепту в зростання популярності ситуативних додатків (SA), що використовують інтернет, серед володіють спеціальними знаннями в області програмування співробітників та професійних розробників.


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
































Фактор


Вклад в зростання популярності SA, що використовують інтернет

Поява таких технологій і методів, як Ajax, REST, Atom і канали новин RSS


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

Загальна комп’ютерна грамотність


Все більша кількість користувачів може “програмувати”.

Впровадження SOA


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

Поширення комп’ютингу силами користувальницьких спільнот колективної творчості


Розробники й користувачі спільно використовують компонувальні блоки і покращують те, що створено їхніми колегами.

Взаємопроникнення API і Web-компонентів


Творці SA-додатків мають багату палітру для вибору компонувальних блоків.

Доступність великої кількості гібридних додатків в публічних предметних областях


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

Менші витрати на інфраструктуру


SA не потребують централізованому розгортанні, можна використовувати в якості серверів комп’ютери окремих користувачів.

Зростаюча потреба в динамічності бізнесу


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


Порівнюємо SOA і SA


Одні фахівці говорять про натягнутих відносинах між SOA і SA. Вони відзначають, що SOA фокусується на наданні надійних масштабованих на рівні організації рішень, тоді як SA є “Доморощені” додатка, масштабування яких для задоволення бізнес-потреб неможливо.


Інші відзначають синергізм щодо цих двох технологій, як, наприклад, в блозі, Що описує Web 2.0 (одним з аспектів якого і є SA-додатки) як “реально наймасштабніший зразок сервіс-орієнтованої архітектури з усіх можливих”.


Наші спостереження показали, що хоча SOA і SA мають контрастують життєві цикли і мотивацію розробки, різні шаблони застосування і використовують абсолютно різні технології, у них є важливі загальні аспекти.



У той час як компонувальних центр SOA розміщується на стороні сервера прозоро для користувача, багато SA використовують мережу Інтернет як платформу, часто фокусуючись на компонуванні сервісів на архітектурному рівні споживача, “на склі”.


Життєвий цикл розробки та шаблони застосування


На відміну від розробки на базі SOA, яка часто займає багато місяців і навіть років, при розробці SA-додатків передбачаються значно коротші життєві цикли від ідентифікації потреб до початку ефективної роботи з додатком і отримання економічного ефекту від підвищення продуктивності та функціональності (показник time-to-value). Такі рішення можуть дозволити деякі невідкладні бізнес-проблеми рентабельним способом-за рахунок залучення тієї частини інформаційних систем, яка безпосередньо стосується співробітників, що володіють спеціальними знаннями в області програмування,-і націлені на ті області, які раніше вважалися занадто вузькоспеціалізованими або низькопріоритетним, щоб включати їх в SOA-проект, з легкої руки Кріса Андерсона (Chris Anderson) їх іноді називають “хвостатими рішеннями “(the Long Tail). За допомогою цієї парадигми розробки інформаційні системи можуть здійснити автоматизацію бізнес-областей, які раніше вважалися неохопленими.


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


Таблиця 2. Життєві цикли розробки SOA і SA

































SOA / Традиційна розробка інформаційних систем


Ситуативні додатки (SA)

Time-to-value (тривалість життєвого циклу)


Багато місяці або роки


Дні або тижні

Фази розробки


Добре визначені, згодом затверджені у вигляді плану-графіка (хоча терміни часто порушуються)


Певні фази, віхи чи графіки відсутні


Завдання – досить гарне рішення нагальної проблеми

Функціональні вимоги


Визначаються обмеженою кількістю користувачів


IT-фахівцям необхідно “зафіксувати” вимоги, щоб перейти до розробки

При зміні бізнес-потреб часто відбувається деформація вимог


Зі зміною вимог зазвичай змінюється і SA-додаток, враховуючи зміни в бізнесі


SA допускають непередбачені розробником варіанти використання

Нефункціональні вимоги


Ресурси, виділені для вирішення питань продуктивності, доступності та безпеки


Концентрація на цих та інших нефункціональних вимогах (таких як масштабованість і обслужіваемость) часто сприяє розробці надійних рішень


Вимоги масштабованості, зручності обслуговування, доступності і т. п. майже (або повністю) не приймаються в розрахунок.

Тестування


IT-фахівці і кілька залучених користувачів


Користувачі, в процесі реального використання програми

Фінансування


Часто збігається з щорічним плануванням витрат на IT


Вимагає затверджених бюджетних асигнувань


Формальне виділення коштів відсутня


Розробляються і виконуються під наглядом IT-фахівців організації



Соціальний аспект


Укорінене відмінність між SOA і SA-додатками полягає в соціальному аспекті, принципі, який багатьма визнається центральним для руху до Web 2.0 (який може бути вигідним і для централізовано керованої SOA). Ситуативні програми розвиваються завдяки зворотного зв’язку від користувача спільнот, і саме їх існування залежить від цієї архітектури участі. У таблиці 3 наводиться порівняння соціальних аспектів


Таблиця 3. Соціальний аспект – відмінності між SOA і SA-додатками























SOA


Ситуативні додатки (SA)

Зацікавлені особи


Керівники напрямків бізнесу / IT-фахівці організації


Окремі розробники / мимовільно сформувалися невеликі колективи, спільноти користувачів, які зібралися для розробки SA

Цільові користувачі


Великі, неспеціалізовані групи


Відомий окремий користувач (часто творець додатку) або невеликий колектив, що привертає користувачів, для яких дане додаток спеціально не розроблялося

Механізм керівництва


Централізований, формальний


Звичайні люди, члени користувальницького співтовариства

Розвиток


Управляється по вертикалі зверху вниз, проводиться централізовано, залежить від наявності фінансування


Природне, поступове, на основі зворотного зв’язку та участі користувачів


Творці SA кажуть, що відчувають глибоке задоволення від результатів своєї роботи і відчувають, що все “під контролем”. Маркетингове дослідження IBM показує, що користувачі SA-додатків розглядають їх як особливо важливі. Більше половини користувачів вважають їх “критично важливими для бізнесу” і дають їм оцінку “дуже важливо” для успіху їх особистої повсякденної діяльності, а також діяльності підрозділів і компаній в цілому (зі звіту “Changing the corporate IT development model: Tapping the power of grassroots computing” (Зміна корпоративної моделі розробки інформаційних систем: ефективне використання масового комп’ютингу) (жовтень 2007 р.).


Технології


А тепер давайте розглянемо технологічні зміни (перераховані в таблиці 4), які сприяли підвищенню ролі SA-додатків.


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


Таблиця 4. Особливості технологій SOA і SA























SOA


Ситуативні додатки (SA)

Зрілість


Високорозвинені, перевірені технології


Часто використовуються менш зрілі і розвиваються технології

Надається перевага технології, архітектурні моделі і стандарти


Мова опису Web-сервісів (Web Services Description Language, WSDL), WS-*, SOAP, мова виконання бізнес-процесів (Business Process Execution Language, BPEL), платформа Java ™ 2 Platform, Enterprise Edition (J2EE), XML


Ajax, REST, Atom, RSS, нотація об’єктів JavaScript (JavaScript Object Notation, JSON), XML, мікроформати, Flash, Ruby on Rails, PHP, JavaScript

Інтерфейс користувача


Не має значення


Перевага віддається стандарту повнофункціональних інтернет-додатків Rich Internet Applications (RIA) через використання таких технологій, як Ajax, Adobe Flex, Adobe Integrated Runtime (AIR), OpenLaszlo і XAML Browser Application (XBAP), а також інтеграції шаблонів “at the glass” (на склі)

Інструменти


Автономна інтегрована середа розробки (IDE)


На базі браузера


Архітектурний стиль REST, що використовує уніфіковані ідентифікатори ресурсу Uniform Resource Identifiers (URI) для ідентифікації Web-ресурсів, уможливлює однакову доступність таких ресурсів з браузерів, мобільних пристроїв, серверних додатків, посилання з повідомлень електронної пошти та закладки, завдяки чому цей стиль програмування стає привабливим для широкого діапазону клієнтських додатків. Оскільки сервіси в стилі REST можуть використовувати інфраструктуру Web для кешування, вони можуть досягати більш короткого часу відгуку. Враховуючи, що в REST не потрібно обслуговувати режим комунікації, ви можете підвищити масштабованість сервера, використовуючи цей стиль-можна використовувати для обробки першого і наступних запитів різні сервери


Застосовність SA в організації


Спільноти Web 2.0, що сформувалися в організації, часто вважають, що діяльність IT-фахівців, що відповідають за реалізацію SOA, є неефективною і не може задовольнити бізнес-потреби. Хоча багато ентузіастів SA вважають SOA великовагової, між цими двома технологіями існує ряд чудових подібностей (як було показано раніше в цій статті).


Розробка і SOA, і SA-додатків часто мотивується бажанням привнести динамічність в бізнес. IT-фахівці не повинні ігнорувати комплементарний характер SOA і SA-додатків; SA-додатки вносять важливі нововведення, з яких SOA може отримати вигоду, а саме:




Переваги SA-додатків


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


SA допомагають у веденні бізнесу за допомогою:




SA покращують бізнес-рішення за допомогою:




SA сприяють підвищенню індексу ROI шляхом:




Проблеми SA-додатків


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


Відділ з інформаційних технологій може розглядати SA-додатки як “контрольований” хаос, оскільки:



Інтеграція SA-додатків виходить на передній план, оскільки:



Управління ситуативними і корпоративними додатками викликає складності через:




SA викликають проблеми з забезпеченням безпеки, конфіденційності та цілісності даних, у тому числі:



Висновок


Впровадження SA-технології в організації вимагає додаткової гнучкості від існуючої інфраструктури організації. SOA може сприяти пом’якшенню деяких проблем, наприклад шляхом багаторазового використання сервісів та інфраструктури, створеної SOA-ініціативами, для управління, функціонування та керівництва.


Хоча багато IT-підрозділу скептично ставляться до корисності SA для корпоративного комп’ютингу або остерігаються використовувати розроблені за межами організації API в периметрі своїх міжмережевих екранів, дирекція з інформаційних технологій IBM прийняла рішення дозволити використовувати SA у своїх організаціях. Щоб краще розібратися в проблемах і можливостях впровадження розробки в рамках спільноти, дирекція з інформаційних технологій IBM розробила ініціативу, яка отримала назву середовища ситуативних додатків (Situational Applications Environment, SAE). На малюнку 1 зображена схема динамічного лабораторного експерименту з вивчення SAE і виробленні передових методів.


Рисунок 1. Концепція SAE в IBM

Слідкуйте за виходом частини 2 цієї серії статей, в якій описуються архітектура і уроки, отримані при створенні описаної середовища SAE. Нижче перераховані ранні переваги для бізнесу, які ми спостерігали при вивченні даної теми:



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


Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*