-ѕоиск по дневнику

ѕоиск сообщений в fidonet

 -ѕодписка по e-mail

 

 -—татистика

—татистика LiveInternet.ru: показано количество хитов и посетителей
—оздан: 29.10.2009
«аписей:
 омментариев:
Ќаписано: 4

«аписи с меткой soa

(и еще 112 запис€м на сайте сопоставлена така€ метка)

ƒругие метки пользовател€ ↓

fido fidonet soa фидо фидонет

SOA: плюсы и минусы

ƒневник

„етверг, 29 ќкт€бр€ 2009 г. 17:39 + в цитатник

√отовы ли компании к SOA-архитектуре?  

 

јналитическое агентство CNews Analytics /CNA/ исследовало настроени€ участников рынка. ќказалось, что интерес к SOA остаетс€ высоким. ћногие компании корректируют свои SOA-стратегии, чтобы подготовить »“-инфрастуктуру и бизнес к быстрому выходу из кризиса  

 

„то нужно учитывать?

 

SOA – это долгосрочный трансформационный проект. ћогут пройти годы – перед тем как бизнес почувствует реальные результаты (например, возможность быстрой адаптации »“ под новые процессы). CIO, разработчики и бизнес-пользователи вид€т SOA (и его эффективность) по-разному.

 

ѕреимущества SOA:

 

> способность быстро адаптировать »“ к мен€ющимс€ задачам бизнеса;

> стимул дл€ анализа и оптимизации бизнес-процессов компании;

> возможность обеспечить интеграцию при консолидации компаний (= систем);

> возможность снизить “—ќ систем.

 

ќсобенности SOA:

 

> продолжительные сложные проекты;

> переосмысление »“-стратегии предпри€ти€ в целом.

 

ќднако

 

> проект SOA должен решать задачи не »“-департамента, а бизнеса в целом;

> часто результат SOA – красива€ инфраструктура, но не реальна€ ценность дл€ бизнеса.

 

—ложности на пути SOA

 

ќрганизационные – заинтересованность руководства, мотиваци€ сотрудников.

Ёкономические – большие начальные инвестиции.

–есурсные – дефицит кадров, неготовность инфраструктуры.

“ехнические – трудоемкость проектов, большой объем подготовительных работ.

ѕсихологические – консервативность, излишние амбиции на старте, быстрое разочарование.

 

—тоимость перехода SOA-проект требует значительных инвестиций сразу по нескольким направлени€м:

—оздание сервисов: создание повторно используемого компонента примерно в два с половиной раза дороже простого. Ёто значит, что сервис создаетс€ при условии дальнейшего использовани€ (минимум трижды).

—офт: ESB (сама€ затратна€ часть), репозиторий, системы тестировани€, управлени€ и мониторинга.

∆елезо: возможно потребуетс€ дополнительно оборудование (не сама€ больша€ стать€ расходов).

ќбучение »“-персонала работе с SOA.

 

 акова отдача?

 

IBM SOA Infrastructure Adoption Study провела опрос 900 »“-директоров и топ-менеджеров компаний из —еверной јмерики, ≈вропы и јзии:

> 50% игроков, реализующих SOAпроекты, констатируют возврат инвестиций;

> более 60% из тех, кто ставил задачу сокращени€ издержек, отмечают достижение этой цели.

Infosys: ѕосле перехода на —ќј с каждым годом возрастает количество повторных использований сервисов („15% в первый год, џ25% во второй год, я40% на третий год и т.д.) – что напр€мую сказываетс€ на сокращении затрат.

 

„то можно измерить переход€ на SOA?

 

> повышение эффективности (применительно к бизнес-процессам – ¬–ћ);

> сокращение административных издержек; > повышение прозрачности существующих бизнес-процессов;

> сокращение бумажного документооборота;

> ускорение внедрени€ процессов;

> сокращение циклов проектов;

> сокращение совокупной стоимости развити€ и поддержки приложений.

 

—тарт SOA-проекта

 

¬аша компани€ готова к старту SOAпроекта, если у нее есть:

 

»нфраструктура – достаточна€ пропускна€ способность сети, доступность серверов.

јрхитектура – приложени€ позвол€ют выставл€ть данные в качестве сервисов.

»нформаци€ – готовность данных к представлению в виде сервисов, адекватна€ структура хранилища.

„еловеческие ресурсы – уровень квалификации, знакомство с технологи€ми, адаптивность, готовность к работе в новых парадигмах.

”правление – заинтересованность топ-менеджмента, инновационный настрой, инициативность CIO.

 

Ўесть ошибок в SOA -проектах

 

Ѕеспор€дочный подход к сервисам. Ќачина€ проект, компании часто бездумно выдел€ют вебсервисы; среди них оказываютс€ избыточные или ненужные, а процедура становитс€ неоправданно дорогой.

»гнорирование бизнес-аналитиков. ”частие бизнес-аналитиков с самого начала проекта важно дл€ его успешного завершени€, чтобы фокус не оказалс€ исключительно на технических задачах и выделении веб-сервисов. ¬ первую очередь SOA должна быть бизнесзадачей.

¬нимание к продуктам в ущерб идеологии.  омпании часто фокусируютс€ на инструментах, интеграционных платформах и софте, хот€ рассматривать их имеет смысл только после составлени€ детального плана миграции на новую архитектуру. Ѕез особой необходимости не стоит сразу закупать много новых »“-продуктов.

ѕриоритет большим и сложным проектам. Ћучше начать с небольших и минимально рисковых проектов (менее очевиден результат, но зато хороша€ площадка дл€ обучени€, накоплени€ опыта и необходимой базы знаний). ” сложных и крупных инициатив риски очень высоки, они чаще проваливаютс€.

Ќепонимание ключевых ролей. Ѕизнес-роли должны быть заложены еще на стадии планировани€. „асто у проектной команды и ее руководител€ нет четкого понимани€ – кто €вл€етс€ ключевым «владельцем» данных. ѕроект, в котором нет изначального понимани€, какие подразделени€ владеют какими сервисами, обречен.

Ќадежда на быстрое распространение. ћногие ожидают, что SOA-инициативы будут быстро распростран€тьс€ от одного бизнесподразделени€ к другому, и считают неудачей, если этого не происходит. ќднако именно постепенный медленный переход на сервисы всего предпри€ти€ €вл€етс€ залогом более эффективной инфраструктуры.  

 

—тереотипы поведени€ уничтожают преимущества

–азработка композитных приложений в сервис-ориентированной архитектуре требует изменений не только в технологи€х, но в первую очередь в процессах развити€ и управлени€ корпоративной информационной системой. —формированные годами стереотипы поведени€ как у »“-специалистов, так и у бизнесзаказчиков способны свести на нет все преимущества SOA. ¬опреки распространенному мнению, основные затраты времени приход€тс€ не непосредственно на разработку »“-решений, а на выработку и согласование требований, соблюдение процедур и правил внесени€ изменений. »зменение подобной практики займет не один день. ѕожалуй, наиболее эффективным подходом внедрени€ новых методов управлени€ €вл€етс€ организаци€ центра компетенции по интеграции (Integration competence center), дополн€ющего традиционные процессный и проектный подходы к управлению »“.  

ѕоддержка SOA-решений сложнее привычных соединений

“рудности возникают по нескольким направлени€м. Ёто трудности технологические (некоторые решени€ в стиле SOA построить с соблюдением за€вленных атрибутов качества крайне сложно); ресурсные (пока SOA €вл€етс€ только архитектурной парадигмой, используемой при построении решений, но не выделена в проект, достаточно приоритетный дл€ банка, недостаточно ресурсов дл€ процессов стандартизации, определени€ бизнес-объектов и т.д., объедин€емых словом governance). Ќекоторые трудности возникают, конечно, в св€зи с тем, что решени€ в стиле SOA на этапе накоплени€ сервисов €вл€ютс€ более сложными и затратными, чем при peer-topeerинтеграции. Ёто трудности как на уровне менеджеров проектов, которым приходитс€ разъ€сн€ть, почему в проект добавлен «архитектурный налог» в виде создани€ сервисов, так и на уровне, например, системных администраторов, дл€ которых поддержка SOA-решений объективно сложнее привычных peer-topeerсоединений.  

 (699x271, 67Kb)

ћетки:  

ќ чем забывают при создании SOA-систем

ƒневник

„етверг, 29 ќкт€бр€ 2009 г. 17:32 + в цитатник

 ак подход к проектированию, SOA существует уже много лет. ќднако в новых проектах специалисты сталкиваютс€ с одними и теми же проблемами, что приводит к серьезным сложност€м дл€ бизнеса  

 

ј нужно ли вообще SOA бизнесу?

 

Ѕизнесу безразлично, какие технологии и продукты использует »“-подразделение, если это удовлетвор€ет потребности бизнеса. SOA-технологии не удовлетвор€ют напр€мую ни одну из потребностей бизнеса. ѕоэтому, бесполезно рассматривать их в качестве «лекарства от всех болезней» бизнеса. Ѕолее того, существует очень серьезный барьер «на входе в SOA», что про€вл€етс€ в необходимости привлечени€ немалых финансовых, людских и временных ресурсов. ј это, в свою очередь, перечеркивает возможность использовать SOA, как «инструмент экономии». Ќо SOA может быть успешно использована дл€ повышени€ эффективности бизнеса, если рассматривать эффективность более широко. ѕравда, универсальных средств быть не может, по причине того, что пон€тие эффективности зависит от целей компании, а у каждой компании они свои.

ќднако, даже име€ схожие цели, в текущей непростой ситуации разные компании могут выбрать разные стратегии достижени€ своих целей. –ассматрива€ потенциальные стратегии, разделим их условно на две группы: пассивные и активные. ѕричем реализаци€ активных стратегий практически всегда требует современных информационных технологий. ѕоэтому можно утвердительно ответить на поставленный выше вопрос: «Ќужна ли сервисноориентированна€ архитектура бизнесу?». ≈сли у компании есть силы, то новые SOA-проекты необходимо начинать именно сейчас, когда основна€ масса конкурентов это не приемлет.

“акой подход позволит компании создать конкурентное преимущество и продвинутьс€ вперед. ƒл€ многих российских компаний сложилась уникальна€ ситуаци€. ¬ –оссии не так сильно, как в других странах, актуален «груз унаследованных систем». »спользование инноваций – это единственный шанс стать технологическим лидером в свой отрасли.

 

ћесто SOA в стеке технологий

 

ѕри реализации SOA-решений необходимо понимать, что основу этих решений составл€ет, так называемое, промежуточное программное обеспечение (промежуточное ѕќ). —амо по себе оно не может €вл€тьс€ целью бизнеса. Ёто необ€зательный компонент системы. ¬ то же врем€ это эффективный помощник дл€ решени€ некоторых задач, дл€ организации вычислительного процесса и дл€ построени€ прикладных приложений и систем. Ќо ничто не бывает бесплатно. «а использование промежуточного ѕќ необходимо платить налог – либо финансами, либо производительностью, либо аппаратным обеспечением, либо чем-то другим. » это важно понимать, вступа€ на путь SOA.

 

ѕочему вокруг SOA так много названий, технологий и продуктов?

 

≈ще одно важное отличие промежуточного ѕќ от других видов ѕќ – большой спектр решаемых задач. ќтсюда по€вление большого количества компонентов и технологий относ€щихс€ к промежуточному ѕќ. » это число посто€нно растет с развитием предметной области. Ќо далеко не все технологии и компоненты нужны в одном проекте. Ќа практике дл€ каждого решени€ желательно подбирать конкретный состав продуктов и технологий. ѕроблему выбора нередко серьезно затрудн€ет «маркетинговый шум».

 

“ехнологии ради технологий

 

ѕоскольку использование подхода SOA это всегда издержки, то каждый руководитель должен задать себе и членам команды вопрос: «ѕочему в данном проекте необходимо использовать именно SOA?» ≈сли ответы будут неточными, общими, или вообще лежать в области «верю/не верю», то это первый признак того, что SOAтехнологи€ выбрана ради самой технологии. “акое использование смысла не имеет, хот€ это еще часто встречаетс€ на практике. ƒл€ бизнеса важно лишь то, как ѕќ соотноситс€ с бизнесцел€ми. » если на данном этапе это не вы€снить, то на следующих этапах уже будет очень сложно обосновать большие издержки.

 

SOA и моделирование бизнеса

 

Ќо чтобы пон€ть, как соотноситс€ будущее SOA-решение, к разработке которого приступает компани€, с цел€ми бизнеса, необходимо, как минимум, определитьс€ с этими цел€ми, а как максимум – смоделировать аспекты бизнеса, нужные дл€ достижени€ поставленных целей, в том числе и создать модель процессов и сервисов де€тельности компании. » здесь SOA лучше других подходов вписываетс€ в управление бизнеспроцессами, предоставл€€ только необходимые сервисы и ничего лишнего.

 

ј сколько это стоит?

 

„асто, чтобы определить цену, необходимо проделать длинный путь. ¬начале определить проблему, далее описать задачу, после этого выбрать под задачу необходимые технологии и продукты. » только, когда уже будет определена архитектура будущего решени€ и диаграмма его развертывани€ на аппаратном обеспечении, только тогда можно предметно говорить о цене. „ем меньше сделано на этом пути, тем менее обоснованными будут стоимостные оценки SOA-решени€. Ѕыстрее этот путь можно пройти только в одном случае, если задача и ее решение хорошо известны, а стоимостной анализ на практике проводилс€ уже много раз.

 

 акова будет производительность?

 

ѕроблема заключаетс€ в том, что универсальных единиц измерени€ производительности вычислительных систем нет. ѕроизводительность – это комплексна€ характеристика всей системы, котора€ зависит от множества компонентов. ¬от некоторые из них:

> конкретна€ совокупность задач на входе в систему и их соотношение (смесь задач);

> организаци€ вычислительного процесса и используемые алгоритмы;

> используемые проектные решени€, технологии и продукты;

> системное и промежуточное программное обеспечение;

> аппаратное обеспечение;

> а иногда и регламенты, относ€щиес€ к выполн€емой задаче. ≈сли две системы отличаютс€ хоть одной компонентой, то их показатели производительности (например, количество обработанных задач на выходе системы в единицу времени) уже нельз€ сравнивать. Ќа практике же сплошь и р€дом встречаетс€ ситуаци€, когда на тестовых стендах, конфигураци€ которых существенно отличаетс€ от конфигурации будущей системы, снимаютс€ «какие-то» характеристики производительности, причем делаетс€ это на смеси задач, абсолютно не относ€щихс€ к будущей системе. » тут же на основе этих сн€тых характеристик делаютс€ далеко идущие выводы о производительности будущей системы. ѕеречислим только некоторые проблемы такого подхода:

> трат€тс€ ресурсы на бесцельное тестирование;

> на основе недостоверных данных может быть остановлен успешный проект;

> если проект не остановлен, то он существенно задерживаетс€;

> формируютс€ некорректные ожидани€ относительно характеристик промышленного SOA-решени€.

 

 ак организовать разработку SOA-решений?

 

Ќа этапе подготовки проекта существует еще и конфликт интересов с поставщиками SOA-решени€, в случае, если оно заказываетс€ на стороне. (“акого рода конфликт интересов, на самом деле, возникает и внутри организации, когда SOA-решение заказываетс€ внутри компании. Ќо в этом случае он менее выражен, хот€ и не менее болезненный.) ƒанный конфликт интересов заключаетс€ в следующем. «аказчику, еще до начала проекта, желательно знать функциональные, нефункциональные и стоимостные характеристики будущей SOA-системы. ¬ то же врем€, ввиду уникальности большинства SOA-решений, создаваемых под конкретные задачи и рассчитанные на работу в уникальном »“-окружении заказчика, поставщик не может предварительно предоставить такого рода информацию. ј, провод€ какиелибо исследовани€, оценки и другую предварительную проработку за свой счет, поставщик понесет существенные риски, почему и не идет на это. –ешение кроетс€ в организации процесса разработки SOA-систем, которое упрощенно представлено в таблице ниже.

Ќа первом этапе разрабатываетс€ концепци€ SOA-решени€, котора€ проходит проверку, как правило, внутри виртуальной машины или на ноутбуке. Ќа втором этапе выбираетс€ «наиболее характерный полигон», на основе которого реализуетс€ пилотный проект. ѕилот уже может использовать существующие системы, но ни в коем случае не «боевые», а «тестовые» экземпл€ры. ¬сегда возникает искушение «почти работающий пилот» запустить в эксплуатацию. Ётого категорически нельз€ делать, поскольку цели пилота противоречат цел€м промышленного проекта. ≈го задача – вы€снить принципиальную жизнепригодность SOA-решени€, в св€зи с чем, дл€ уменьшени€ издержек на пилотное проектирование, могут быть сделаны существенные упрощени€, например, в структуре системы. » только когда проанализированы результаты пилота, и он признан удачным, можно с открытыми глазами начинать промышленный проект. –аспределение времени и средств по этапам складываетс€ примерно следующее (см. таблицу 1).  ак можно видеть, такой подход удобен всем:

> есть возможность концептуального понимани€ решени€ задачи без необходимости нести издержки;

> есть возможность провести предварительную, глубокую проработку уникального решени€;

> стоимость предварительной проработки отлична от нул€, что позвол€ет поставщику привлечь высококвалифицированные ресурсы;

> в то же врем€, заказчик рискует лишь около 10% средств, а не всем бюджетом проекта, но получает за это полную картину относительно будущего SOA-решени€;

> промышленное проектирование ведетс€ с учетом накопленного опыта, полученного на этапе пилотного проектировани€.

 

Ётап проектировани€

 

“еперь, когда прин€то решение о проектировании SOA решени€, когда начинаетс€ закладыватьс€ фундамент будущей SOA-системы, важно избежать самых дорогосто€щих ошибок – ошибок этапа проектировани€.

 

ћодель мастер-данных

 

—реди всей совокупности данных, используемых в компани€х, есть определенна€ специфична€ категори€ (15-20% от всего объема), котора€ используетс€ как «€зык информационных систем», лежащий в основе самого бизнеса компании. “акие данные называют мастер-данными. ѕерва€ задача, сто€ща€ перед архитектором (или аналитиком) при построении и/или развитии информационной системы, выделить (идентифицировать) мастерданные и создать на их основе модель мастер-данных. ћодель мастер-данных включает в себ€ следующие компоненты (но ими не ограничиваетс€):

> определение типов данных (бизнес-объектов, справочников, вспомогательных данных и технологических данных);

> определение событий;

> определение исключительных ситуаций;

> определение интерфейсов. ¬ SOA-системах модель мастерданных – это межсистемный €зык, со своим, как правило, очень длительным, жизненным циклом и желательно с версионностью (смотрите, например, «ћетоды работы с моделью мастерданных в SOA-проектах», http://soa. it-consultants.ru/?q=node/4). ќт того, насколько тщательно спроектирован этот €зык, очень многое зависит, так как модель данных будет непосредственно использоватьс€ во всех без исключени€ прикладных проектах.

 

SOA-системы: распределенные и многопоточные

 

SOA-системы уже не €вл€ютс€ сосредоточенными программами, они по сути – распределенные, параллельные приложени€, состо€щие из множества независимых компонентов. ѕоэтому здесь нельз€ примен€ть традиционные подходы и алгоритмы дл€ сосредоточенных систем. “о, что тривиально решаетс€ в рамках сосредоточенных систем, например, передача параметра или перехват ошибок, в распределенных и многопоточных системах требует уже определенных усилий. »менно поэтому перед началом проектировани€ SOA-систем стоит освежить подходы проектировани€, как распределенных и многопоточных, так и событийно-ориентированных систем.

 

¬заимодействие с внешним миром

 

¬ параллельных системах часто возникает еще одна проблемна€ область – организаци€ взаимодействи€ с внешней средой. » поскольку логика такого взаимодействи€ может быть очень сложной, то имеет смысл выделить отдельный класс интерфейсных задач (сервисов), которые будут инкапсулировать такую логику. ’орошим примером такого подхода может служить набор из шести веб-сервисов продукта Oracle SOA Suite дл€ организации интерфейсного взаимодействи€ с пользователем – Human Workflow Services.

 

ѕроблема взаимного исключени€

 

¬о всех параллельных и многопоточных системах, включа€ и SOA-системы, особенную остроту приобретает проблема организации совместного доступа к раздел€емым ресурсам. ј каждый сервис или произвольна€ их совокупность потенциально может стать таким раздел€емым ресурсом. ƒл€ решени€ этой проблемы необходимо реализовывать механизмы синхронизации. Ќо о таких механизмах проектировщики часто забывают, полага€сь, что инфраструктура магическим образом прочитает мысли проектировщика и сама разрешит конфликт за ресурс. ¬ классическом решении проблемы используютс€ семафоры, предложенные ƒейкстрой еще в 1968 году. ¬ SOA-решени€х дл€ конкретного ресурса (ресурсов) обычно используют менеджер транзакций и/или выделенный сервис, инкапсулирующий логику управлени€ транзакцией, которые могут использовать широкий арсенал хорошо известных алгоритмов.

 

»нтерфейс с пользователем

 

≈ще одна область, о которой часто забывают проектировщики – удобство пользователей, дол€ которых в выполнении операций может доходить до 100% в SOA-системах с широким участием человека в выполн€емых операци€х. »менно принцип SOA позвол€ет клиентским приложени€м абстрагироватьс€ от того, как выполн€етс€ операци€ сервиса. ѕоэтому потенциально за каждым сервисом может находитьс€ человек и удобство его работы нельз€ игнорировать.

 

Ётап разработки

 

ќн €вл€етс€ одним из самых технологически проработанных. ¬ то же врем€ до сих пор много SOA-проектов реализуетс€, так сказать, «на коленке». ’от€ отсутствие стандартов, технологических и программных средств дл€ автоматизации процессов разработки уже давно не €вл€етс€ проблемой. “акже с удивлением хочетс€ отметить практически полное отсутствие интереса к средствам поддержки автоматического тестировани€. ’от€ такие возможности тоже широко представлены.

 

Ётап внедрени€

 

Ќа этапе внедрени€ SOA-системы подстерегают новые сложности. “ак, поставл€€ гибкую, конфигурируемую SOA-систему, необходимо поставл€ть заказчику и регламенты ее изменени€, а возможно и автоматизировать процессы, поддерживающие такие регламенты. “о есть каждый заказчик, использующий гибкую SOA-систему должен, либо стать маленькой »“-компанией, вне зависимости от отрасли, в которой он работает, либо отдать конфигурирование системы на аутсорсинг. ≈ще одна проблема внедрени€, котора€ часто разрушает самые перспективные SOA-проекты – абсолютна€ непроработанность вопросов обучени€ конечных пользователей. ј ведь именно от их мнени€ о системе зависит ее будущее.

 

Ётап эксплуатации

 

–ассмотрим важные моменты при эксплуатации проекта.

 

Ќужно ли гибкое конфигурирование и настройка в SOA-решении?

 

¬ первую очередь хочетс€ выделить парадоксальную т€гу р€да компаний к «возможност€м мен€ть характеристики на работающей системе». » это при тотальном игнорировании необходимости тестировать внесенные изменени€ и абсолютной невозможности организовать такой процесс тестировани€ внутри компании. —амые известные средства данного класса решений – это поддержка бизнес-правил, изменение маршрутизации запросов средствами шины сервисов и формирование «на лету» цепочек утверждени€ документов. ¬се эти средства есть и поддерживаютс€, но они требуют более чем тщательного и продуманного подхода к использованию. “олько представим себе, к каким последстви€м может привести неправильное бизнес-правило о предоставлении скидки?! ј ведь большинство таких ошибок не будут видны без специальных средств диагностики. ѕоэтому дл€ того чтобы пользоватьс€ гибкой системой, в первую очередь гибким должен быть сам бизнес. ¬ противном случае эта функци€ будет в лучшем случае не задействована, а в худшем – создавать только проблемы на этапе эксплуатации.

 

«—ильное взаимодействие» или «—лабое взаимодействие»

 

≈ще одно неудобство, возникающее на этапе эксплуатации, вызвано слишком широким увлечением сильным взаимодействием систем, причина которого в проектировании SOA-решени€ как сосредоточенной системы. »спользование сильного взаимодействи€ приводит к образованию избыточного количества жестких св€зей, что сводит на нет все усили€ по достижению общей гибкости решени€, за счет применени€ SOA. ¬торое следствие слишком широкого использовани€ сильного взаимодействи€ приводит к практически полному выпадению из пол€ зрени€ проектировщика такого пон€тие как событие. ћало кто проектирует событи€ в SOA-системах..., мало кто их анализирует... ¬ то же врем€ случаютс€ ситуации, когда событи€ невозможно игнорировать, например, асинхронные исключительные ситуации. Ќо, вместо того, чтобы еще на этапе проектировани€ в систему заложить средства контрол€ и обработки таких событий и просто обработать их в процессе исполнени€, разработчики предпочитают построить в своих системах хитроумные конструкции дл€ компенсации нештатной ситуации или «вычисл€ющие» событи€ по р€ду следов, оставленных в системе.

 

24*7 или 8*5?

 

ѕрактически каждое техническое задание, где есть требование высокой готовности, требуетс€ готовность на уровне 24*7. ѕричем одни хот€т высокую готовность, выражаемую как 99,9, другие как 99,99, а некоторые и как 99,9999. ѕолучаетс€ своего рода негласное соревнование. ј ведь конечна€ цена SOA-решени€ в зависимости от числа этих дев€ток увеличиваетс€ по экспоненциальному закону. ѕри анализе же задачи часто убеждаешьс€, что заказчику достаточно и скромной величины 8*5. ¬ крайнем случае, с учетом шестидневной рабочей недели и при работе во всех часовых по€сах –оссии это будет 16*6.  онечно же, режим 24*7 нужен дл€ некоторых компаний, но уж точно не дл€ всей SOA-системы. » здесь очень важно еще на этапе проектировани€ провести группировку участков системы, к которым предъ€вл€ютс€ различные требовани€ по уровню поддержки высокой готовности.

 

Ётап вывода из эксплуатации

 

ѕро этот этап забывают практически в 100% проектов. ј ведь просто введение пон€ти€ определенного срока эксплуатации дл€ разрабатываемой системы (или ее версии) может сн€ть много неопределенностей еще на этапе проектировани€. ¬виду отсутстви€ €вного срока эксплуатации, у проектировщика нет возможности провести оптимизацию с учетом этого параметра. », как мне кажетс€, отсутствием срока эксплуатации прикрывают то, что никем не проводилс€ анализ де€тельности бизнеса на перспективу, а, следовательно, и анализ потребности в информационных технологи€х и их характеристиках.      


 (548x183, 60Kb)

ћетки:  

SOA. ¬згл€д шире!

ƒневник

„етверг, 29 ќкт€бр€ 2009 г. 17:22 + в цитатник

Ёто не просто набор стандартов и технологий  

 

ћногие относ€тс€ к SOA-технологи€м настороженно, если не сказать отрицательно. Ќо SOA – не миф. Ёто новый взгл€д на работу и место »“ в бизнесе

 

„то скрываетс€ за SOA?

 

SOA (Services Orientated Architecture) – сервисно-ориентированна€ архитектура построени€ информационных систем. Ётот подход основан на выделении сервисов (функций) и последующем их повторном использовании. ¬ыдел€ть общие части программного кода, скрывать логику выполнени€ функции за названием, а затем ее многократно использовать – это первое, что придумали программисты и продолжают активно практиковать до сих пор. “акой подход существенно сокращает затраты на техническую поддержку, модификацию информационных систем. ѕо моим наблюдени€м с наибольшим недоверием к SOA относ€тс€ специалисты, которые имеют какой-либо опыт программировани€. ƒл€ них выдел€ть сервисы, а затем их повторно использовать – прописные истины. Ќо почему тогда так много внимани€ удел€етс€ SOA сегодн€? ѕочему это обсуждаетс€, как некий революционный подход? ѕопробуем разобратьс€. ƒействительно, SOA основано на выделении общих частей информационных систем, оформлении их в сервис и повторном использовании сервисов.

ќчевидно, что повторное использование существенно экономит средства компании. ƒругое важное завоевание SOA состоит в следующем. SOA позвол€ет бизнес-пользовател€м информационных систем получить доступ непосредственно к программному коду, написанному программистом. ≈сли раньше функции, написанные программистом, были спр€таны в упаковку черного €щика откомпилированного программного кода, то сегодн€ они приобрели дл€ бизнес-пользователей вполне конкретные очертани€, с ними стало возможно работать.

—егодн€ бизнес-пользователь сам может определ€ть, когда и как будет вызвана функци€ (сервис), написанна€ программистом. ѕри этом на экране бизнес-пользователь видит не программный код функции, а симпатичную картинку, которую он перемещает по экрану, вбива€ данные в удобные экранные формы графического редактора. Ќеобходимо отметить, что цена за такое удобство – дополнительный программный код, который будет автоматически создан графическим редактором.  ак следствие, информационные системы работают медленнее, чем, если эти изменени€ были бы проведены программистом непосредственно в коде. –аньше дополнительные издержки были недопустимы и ограничивались производительностью вычислительных машин.

—егодн€, на фоне значительного роста мощности аппаратных ресурсов, такие издержки стали более чем незначительны. »так, бизнес дот€нулс€ до программного кода. Ѕизнес-пользователь получил инструмент дл€ работы с программным кодом. “еперь бизнеспользователь может самосто€тельно определ€ть и измен€ть согласованную работу информационных систем (сервисов). Ёто, по моему мнению, и есть главное завоевание SOA.

ќднако важно понимать, что речь не идет обо всем программном коде! Ѕизнес-пользователю интересны только те функции (сервисы), которые обеспечивают выполнение конкретных бизнес-задач. Ќапример, «открытие счета», «пополнение счета», «отправление SMS-сообщени€» и т.д. Ѕизнесу неинтересен программный код, который скрываетс€ за этими сервисами. Ѕизнесу важно, что при вызове сервиса в информационных системах компании будут выполнены корректные операции, соответствующие данной бизнес-операции. „тобы пон€ть значимость этого, необходимо оторватьс€ от технологий и посмотреть на »“ с точки зрени€ бизнеса. ќн сегодн€ все чаще сталкиваетс€ с ситуацией, когда скорость вывода новых услуг или продуктов определ€ет успешность компании на рынке и победу над конкурентом. ѕри этом гибкость и маневренность бизнеса во многом определ€етс€ гибкостью и готовностью к изменени€м информационных систем и »“ в целом. Ќеготовность »“ к быстрым изменени€м становитс€ сдерживающим фактором при завоевании компанией новых рынков.

“аким образом, с одной стороны, технологии готовы предоставить бизнесу новые рычаги дл€ управлени€, а с другой – бизнес сегодн€ крайне заинтересован в увеличении гибкости и маневренности на высоко-конкурентных рынках, ему необходимы новые идеи и инструменты дл€ управлени€. ¬се это объ€сн€ет рост интереса к SOA.

 

≈дина€ виртуальна€ информационна€ система компании

 

SOA позвол€ет сопоставить бизнес-задачи с функци€ми программного кода информационных систем. ƒл€ того чтобы заработало SOA, в компании разворачиваетс€ программное обеспечение, которое формирует дополнительный слой над всеми информационными системами компании. ¬ этом слое с помощью сервисов (бизнес-задач), определ€емых бизнес-пользовател€ми, формируетс€ едина€ виртуальна€ информационна€ система. ¬ этом слое формируютс€ новые услуги и продукты компании.

ƒополнительный слой позвол€ет отделить жизненный цикл новых услуг от жизненного цикла самих сервисов и информационных систем. — по€влением SOA компани€ перестает быть зависимой от поставщиков информационных систем. Ћогика каждой новой услуги теперь не €вл€етс€ частью информационной системы, она становитс€ досто€нием компании. ќтныне поставщикам информационных систем раздаютс€ задани€ не на реализацию новых услуг, а на предоставление сервисов.

 

¬ли€ние SOA на организационную структуру

 

 ак было отмечено выше, не все функции, написанные программистом, нужны бизнесу на уровне сервисов. Ќеобходимо выделить сервисы, которые будут востребованы. ѕоскольку дополнительный слой формирует единую виртуальную информационную систему, то, очевидно, дл€ этого сло€ помимо определени€ сервисов необходимо подготовить и свою модель данных, пон€тную бизнесу и реализованную на €зыке бизнеса. ѕричем разработка модели данных часто не уступает в сложности задаче выделени€ сервисов. “аким образом, мы определили еще одну важную составл€ющую SOA – это модель данных.

»так, две составл€ющие: сервисы и модель данных, от которых будет зависеть успех использовани€ SOA в компании. ћы подошли к важной роли SOA – роли архитектора, на которого возлагаетс€ задача отделить «зерна от плевел»: правильно определить модель и форматы данных, прин€ть решение, какие функции необходимо поднимать до уровн€ бизнеса и т.д. ”стойчивость системы, ее жизнеспособность теперь во многом зависит от архитектора. «афиксированные архитектором сервисы и данные станов€тс€ стандартом дл€ вашей компании. ѕри выборе новой информационной системы эти стандарты превращаютс€ в требовани€ к взаимодействию новой системы с информационной системой компании. –оль архитектора возрастает и в глазах бизнеса.

ќт архитектора теперь зависит, насколько удобными дл€ бизнеса будут новые рычаги управлени€. ѕонима€ это, во многих компани€х даже создаютс€ специальные комитеты, где принимаютс€ решени€ об изменении модели данных и сервисов. “еперь становитс€ пон€тно, что использование SOA не только привносит новые технологии, но и может вли€ть на изменени€ в организационной структуре компании.

 

—мещение акцентов с систем на сервисы

 

ѕомимо организационных изменений SOA смещает акцент с монолитных информационных систем в сторону сервисов. ¬нимание бизнеса переключаетс€ с названий и поставщиков информационных систем на качество и доступность нового сервиса. “еперь компани€ может работать не с лучшими поставщиками информационных систем, а с лучшими поставщиками сервисов. Ёто могут быть небольшие компании, но лучшие в предоставлении конкретного специализированного сервиса. Ѕизнес получает прекрасный инструментарий, »“ и бизнес получают большую маневренность в работе с поставщиками.

ѕроисходит важное изменение и в мировоззрении сотрудников: центры компетенции и ответственности начинают смещатьс€ от крупных монолитных систем в сторону сервисов, качества предоставлени€ сервисов и т.д. Ќекоторые компании идут дальше, бизнес ранжирует сервисы по степени важности, определ€ет и контролирует соглашени€ об уровне качества предоставлени€ сервисов (SLA). —амые передовые компании даже начинают считать доходность сервисов.

“аким образом, новые технологические решени€, пришедшие вместе с SOA, обеспечивают большую гибкость бизнеса, сокращают врем€ вывода новых услуг, позвол€ют больше зарабатывать и отвоевывать новые рынки. ѕри этом мен€ютс€ взаимоотношени€ бизнеса и »“, мен€ютс€ правила работы с поставщиками систем, мен€етс€ даже организационна€ структура компании. ¬се перечисленное, на мой взгл€д, и €вл€етс€ причиной такого пристального внимани€ к SOA. » часто, обсужда€ SOA, подразумевают все или часть вышеперечисленных изменений.

 

“ребуйте SOA!

 

Ќужно ли SOA вшей компании? ѕредположим, разработка, модификаци€ систем осуществл€етс€ внешней командой. ¬ы ставите задачи, определ€ете правила приемки работы. ¬ результате в заранее определенные сроки получаете результат. ” вас отлаженный процесс работы, предсказуемые сроки и пон€тный процесс вывода новых услуг. «ачем вам использовать SOA? ≈сли в вашей компании не обсуждают SOA-стратегии, это не означает, что SOA бесполезно и вам ни к чему в этом разбиратьс€. Ќа самом деле, SOA в вашей компании уже есть. ” вас уже есть сервисы, которые повторно используютс€, есть модель данных дл€ согласованного взаимодействи€ сервисов, реализован механизм поддержки жизненного цикла сервисов и т.д.

√де же спр€тано SOA? »скать его необходимо в новых черных коробках или адаптированных под вашу компанию модул€х информационных систем, которые принос€т ваши поставщики. “ам уже есть сервисы (функции) и они уже хорошо стандартизованы и активно переиспользуютс€. — каждой новой доработкой стоимость модификации системы становитс€ дешевле за счет повторного использовани€ сервисов. — каждой новой доработкой ваш поставщик все меньше тратит врем€ на разработку новых сервисов, все больше акцент смещаетс€ в сторону лишь настройки согласованной работы уже существующих сервисов. ” поставщика вашей информационной системы снижаютс€ издержки, одновременно растет маржа выполн€емых работ.

ѕри заключении нового договора на модификацию системы SOA работает и помогает зарабатывать. Ќо не вам, а поставщику! ƒл€ вас мир SOA закрыт черной коробкой, которую вы получаете после выполнени€ очередного договора. “еперь посмотрим, что происходит в вашем »“. ѕолучить решение, пусть и в черной коробке, в фиксированные сроки с ожидаемой функциональностью – это отличный результат. Ётот подход позвол€ет решить текущую задачу бизнеса. Ёто вполне приемлемо в краткосрочной перспективе. Ќо в долгосрочной перспективе с каждой новой черной коробкой вы все больше попадаете в зависимость от поставщика. »нформационные технологии изменчивы. ћен€ютс€ лидеры рынка информационных систем, по€вл€ютс€ новые классы специализированных систем. ≈сли ваша компани€ стремитс€ стать лидером рынка или остатьс€ работать на высококонкурентном рынке, ваши бизнес-лидеры должны посто€нно что-то изобретать и предлагать своим клиентам. ј это неминуемо требует внедрени€ новых специализированных решений и систем.

–ано или поздно, наступит момент, когда от каких-то черных коробок придетс€ отказатьс€. Ќо какова будет цена такой замены? „то, если пара черных коробок, требующих замены, упакована в один металлический контейнер (монолитной информационной системы), который вы так долго финансировали? »з-за пары коробок в утиль пойдет все, включа€ те коробки, которые устраивают и обеспечивают работу части вашего бизнеса, не требующего модификации сегодн€. „то останетс€ у вас после отправки контейнера в утиль? Ѕизнес-процессы? —ервисы? ћодель данных? – Ќичего! ¬аше врем€, потраченное на обсуждение, проектирование бизнесили технологических процессов, уникальные идеи и находки, также отправитс€ в утиль, вслед за контейнером.

ѕомимо внедрени€ новой функциональности теперь вам потребуетс€ восстановить прежнюю, котора€ была уже однажды адаптирована дл€ вас прежним поставщиком системы. —то€ перед блест€щим новым контейнером с новыми коробками вам придетс€ начать работу с чистого листа! –азве это плохо? ¬едь это вызов дл€ »“-специалистов, это нова€ творческа€ работа дл€ »“-специалистов. Ёто новые »“-бюджеты, новый штат сотрудников. Ёто плохо дл€ бизнеса! –еша€ краткосрочные задачи, ваш бизнес лишил себ€ возможности повторно использовать потраченное уже однажды врем€, уникальные идеи и находки, однажды уже реализованные. —то€ перед новым контейнером, ваш бизнес очутилс€ на пороге революции, размеры и сроки которой завис€т от размера контейнера.

—может ли ваш бизнес пережить эту революцию? ’ватит ли средств на замену?  ак скажетс€ на бизнесе потер€ части функциональности или временна€ их недоступность? ¬сего этого можно было избежать, если бы из каждой коробки к информационной системе компании вел интерфейсный шнур – это и есть сервис. Ќо готов ли пойти на это поставщик монолитной системы? ѕ

ередать сервис клиенту, означает, что теперь клиент будет повторно использовать сервис, а новые услуги могут уже создаватьс€ без привлечени€ поставщика системы. ƒл€ поставщика это означает существенную потерю доходов. “ем не менее, в нынешней экономической ситуации дробление монолитных систем на сервисы происходит. Ёто происходит с поставщиками, которые еще несколько лет назад не хотели даже слышать об этом. “ребуйте SOA! “ребуйте от поставщиков реализации сервисов, а не услуг!

 

ј где деньги?

 

ќбща€сь со специалистами из различных индустрий, дл€ ответа на этот вопрос € всегда рекомендую обратитьс€ к графику длинного хвоста. ѕредположим, мы смогли перенумеровать все социальные и другие разновидности групп своих клиентов. ѕредположим, мы аналогично пересчитали всевозможные услуги, которые ваша компани€ оказывает и могла бы оказывать. —троим график, где по вертикальной оси откладываем количество людей в группах, по горизонтальной оси наносим пронумерованные услуги по мере убывани€ их попул€рности у ваших клиентов. ¬ итоге получитс€ гипербола (см. рис. 1).

ј теперь задайте себе вопрос: где сегодн€ зарабатывает ваша компани€? ¬аши услуги заканчиваютс€ недалеко от начала координат, а площадь под гиперболой от начала координат до самой непопул€рной вашей услуги – и есть зарабатываемые вами сегодн€ деньги. ѕлощадь под кривой, котора€ прижимаетс€ к горизонтальной оси – это доходы, которые остаютс€ без вашего внимани€. » нетрудно пон€ть, что они соизмеримы с вашими текущими доходами. јналогичную кривую можно нарисовать дл€ соответстви€ бизнес-процессов и количества людей, которым необходима их автоматизаци€.

 √отова ли ваша компани€ запустить проект по выводу услуг дл€ сообщества социальной среды, состо€щей из дес€ти человек? √отова ли ваша компани€ начать проект по автоматизации бизнес-процесса дл€ трех специалистов маркетинга, когда запускаетс€ тестова€ маркетингова€ компани€ на две недели? ѕри традиционном подходе это окажетс€ нерентабельным: расходы на проектную команду, проектирование, тестирование... » главное, сроки. ≈сли новый бизнес-процесс не заработает в течение нескольких дней, это потер€ет актуальность.

 

»нновации IBM в SOA

 

—егодн€ IBM предлагает SOA-решени€, которые позвол€ют компани€м охватить бизнес из длинного хвоста: управлени€ бизнес-правилами – WebSphere ILOG BRMS, система коррел€ции различных событий в нескольких системах – WebSphere Business Events, система построени€ ситуационных систем на основе виджитов – WebSphere sMash. ѕродукты, составл€ющие основу линейки WebSphere дл€ построени€ SOA, посто€нно совершенствуютс€. ќсобое внимание удел€етс€ сокращению времени разработки и модификации. Ќапример, в WebSphere BPM по€вилась технологи€ Business Spaces, основанна€ на виджитах. “еперь бизнеспользователь в браузере с помощью мышки сам может собирать удобный дл€ него интерфейс, без привлечени€ программиста.

 ¬ WebSphere BPM бизнес-пользователь получает возможность самосто€тельно спроектировать не только экранные формы, которые потом будут автоматически созданы, или бизнес-процессы, но и возможность самосто€тельно отлаживать и прогон€ть бизнес-процессы. ѕомимо программного обеспечени€ IBM предлагает дл€ построени€ SOA фрейморки дл€ различных индустрий с готовой моделью данных, бизнеспроцессами и даже прописанными сервисами. ƒл€ отдельных индустрий IBM предлагает платформы, которые существенно расшир€ют даже модель бизнеса. Ќапример, дл€ «“елеком» – это платформа SDP (Service Delivery Platform), котора€ позвол€ет любому желающему создавать программы, где используютс€ сервисы «“елекомоператора». “ем самым с помощью программистов-энтузиастов “елекомоператор охватывает интересы небольших групп клиентов.

 

ћожно ли прикоснутьс€ к SOA?

 

ƒа! —егодн€ IBM предлагает аппаратное решение – семейство WebSphere DataPower SOA Appliances. Ёто совершенно новый класс решений. ”стройства на аппаратном уровне оптимизированы дл€ работы с сервисами, дл€ их маршрутизации, трансформации и обработки. –ешени€ из семейства WebSphere DataPower SOA Appliances обеспечивают работу с цифровыми подпис€ми, шифрованием трафика и отдельных частей передаваемой информации, реализует аутентификацию и авторизацию. ”стройства обеспечивают проксирование сервисов, ведение SLA и мониторинг. ѕомимо многофункциональности хотелось бы выделить основные особенности семейства устройств:

> производительность;

> простота в использовании и обслуживании;

> быстрое внедрение;

> быстрый возврат инвестиций.

Ќовое семейство устройств быстро завоевало признание специалистов. WebSphere DataPower SOA Appliances обладатель р€да призов. —егодн€ IBM предлагает уже п€ть аппаратных решений из этого класса.   различным характеристикам SOA теперь добавл€етс€ вес и цвет! *** Ќадеюсь, в этой статье мне удалось пролить свет на SOA и показать, что это не просто набор стандартов и технологий. ¬ первую очередь, это новый подход к взаимодействию бизнеса и »“, новый взгл€д на работу и место »“ в бизнесе. «а стандартами и технологи€ми, реализующими SOA, т€нутс€ изменени€ в организационной структуре компании, смещаютс€ акценты при построении »“, мен€ютс€ правила работы с поставщиками информационных систем. ѕеред компани€ми открываютс€ возможности построени€ новых моделей бизнеса.

 

“рудности есть, но они преодолимы

 

 ¬ 2006 году, при построении SOA в банке –енессанс  апитал (–енессанс  редит), где в то врем€ € занимал должность главного архитектора »“, мы сталкивались со следующими трудност€ми.  ¬о-первых, сложно было убедить бизнес в необходимости трансформации в соответствии с подходом SOA. Ќо пока бизнес не поймет преимуществ SOA и не станет де€тельно сотрудничать с »“, построение SOA невозможно. —тратегическую цель перехода к SOA определил тогдашний Chief Operating Officer ¬ольфганг ’айнрих.

ќднако основную роль пропагандиста SOA-подхода к построению »“-архитектуры в банке вз€л на себ€ ярослав ћедокс, бывший директором департамента развити€ »“. Ѕлагодар€ их де€тельности стал возможен постепенный переход к SOA-архитектуре в банке.

¬тора€ проблема – кадры. ƒл€ построени€ SOA требуютс€ квалифицированные сотрудники. —начала мы привлекли специалистов компании «Ќеофлекс». ѕостепенно экспертиза по€вл€лась и у сотрудников банка. ¬-третьих, закономерны технические сложности. ƒл€ нас они состо€ли в том, продуктова€ линейка IBM WebSphere ESB V6 и IBM WebSphere Process Server V6 была еще довольно «сырой».

ќднако нам удалось впервые в –оссии построить кластер WebSphere ESB и WebSphere Process Server, в так называемой, золотой топологии. 

 (699x287, 93Kb)

ћетки:  

 —траницы: [1]