Именно так бы охарактеризовал я своё впечатление от прошедшей сегодня конференции CNews BPM 2011: направления развития. К сожалению, я не смог выслушать два последних выступления но и остальных докладов хватило для того чтоб понять, что призрак adaptive case management потихоньку пробирается из Европы и в нашу страну. Причем, если старожилы BPM сообщества в своих докладах упоминали термин case management, то «новички» рассказывали про BPM в стиле «управление и автоматизация бизнес-процессов без консервантов BPMN». Но обо всем по порядку:
Рубрика: Software architecture
Сценарии интеграции приложений (3)
Я довольно редко пишу о сценариях интеграции и потому не могу закончить с интеграцией данных и перейти к интеграции приложений и сквозным бизнес-процессам. Тем не менее, интеграция данных это важно. ESB, SOA и прочие трехбуквенные сокращения, занимая наше внимание, отвлекают нас от других, намного более важных трехбуквенных сокращений, таких как ODS и DWH. ODS и DWH – «рабочие лошадки» ИТ архитектуры предприятия, способные избавить нас от множества лишних информационных систем и оппортунистических связей между ними.
Читать далее Сценарии интеграции приложений (3)
Ожидания, разочарования и прогнозы 2010/2011
Под бой курантов принято подводить итоги прошедшего года и строить планы на будущее. Следуя этой традиции я проведу краткий обзор того о чем писал в своем блоге и того о чем намерен писать.
Безусловным хитом года 2010 стала тема адаптивного кейс менеджмента. Adaptive Case Management это разумная середина между излишней наукообразностью BPM подхода и отсутствием таковой у подхода ECM. Читать далее Ожидания, разочарования и прогнозы 2010/2011
Релизы и версии
Как и во многих крупных компаниях, наш корпоративный ИТ ландшафт состоит из информационных систем, таких как система управления отношениями с клиентами (CRM), система самообслуживания, биллинговая система и т.д. Всего их в CMDB насчитывается несколько сотен. Каждая система включает в себя несколько программных компонент. Это и базы данных и JEE приложения, толстые клиенты и web-интерфейсы. До пришествия виртуализации каждая система развертывались на своем наборе оборудования. Впрочем, и сейчас основные системы развернуты на закупленных специально для них серверах.
Не удивительно, что ИТ система является основным элементом управления. К ИТ системам привязываются запросы на изменения (Request for Change, RFC). Системы являются основной единицей процесса управления релизами. Т.е. для каждой системы развивается своя ветка релизов. Все планирование, разработка, тестирование и развертывание ведется в границах систем. Версии приложений попросту совпадают с релизами. Мы не уникальны. Многие компании развивают свою ИТ-инфраструктуру примерно так же. Но в какой-то момент это становится проблемой. Сначала проблемой ИТ архитектуры, а вскоре и проблемой всего ИТ.
На днях листая перед сном ITIL я пытался найти ответ на вопрос почему релиз может включать в себя только одну ИТ систему. Честно говоря, в явном виде такой рекомендации я не нашел. В чем недостатки привязки релиза к одной конкретной ИТ системе? Все очень просто. Традиционный цикл выпуска программного обеспечения ограничивается фазами анализ->проектирование->разработка->тестирование->развертывание. Однако в большинстве современных компаний изменения в ИТ носят комплексный характер, затрагивают сразу несколько систем (см. примечание). Такие работы, как согласование интерфейсов, интеграционное тестирование, конфигурирование приложения (это когда вместо абстрактных интерфейсов, администраторы прописывают реальные ip-адреса web-сервисов и connection strings баз данных), пользовательское тестирование (UAT), разработка архитектуры, в конечном счете =) и управления конфигурациями – остаются за бортом процесса.
Вообще говоря, роль ИТ архитектора на предприятии и заключается в отслеживании взаимосвязей между приложениями, предоставляемыми ими сервисами и развертывающимися в этом ландшафте изменениями. Чем меньше в корпоративной информационной системе происходит релизов, тем согласованней изменения и ниже IT complexity
Примечание: Опрос Как интегрируют приложения в России, приведенный в блоге Андрея Коптелова, показывает что всего треть отечественных компаний никак не интегрируют свои приложения. Остальные – тем или иным способом решают задачу интеграции приложений
Одна из ошибок при переходе от инхауса к аутсорсингу
На неделе выступал перед довольно масштабной аудиторией наших разработчиков. Так как развитием ИТ систем в нашей компании занимается несколько сотен человек, то недостатка в слушателях не было. Выступая, затронул новую для себя тему. Похоже, об этом я еще нигде не рассказывал.
Итак, зачем компании нужна сервис-ориентированная архитектура Читать далее Одна из ошибок при переходе от инхауса к аутсорсингу
Почему Oracle APEX
Что делает нормальный программист, не испорченный разговорами об архитектуре предприятия и презентациями о системах управления бизнес-процессами, когда к нему приходит пользователь с пачкой excel-файлов и говорит: «Надо бы как-нибудь автоматизировать!». Немного похмурив брови и почесав затылок, программист говорит: «Нужно базу данных писать, начальника». Так делали наши деды и, возможно, так же будут поступать наши внуки. Если, конечно, SalesForce к тому времени не утащит все наши данные в облако(см. http://www.database.com/) Читать далее Почему Oracle APEX
Oracle Application Express
Есть вещи, о существовании которых не знаешь, не помнишь или просто не задумываешься
[slideshare id=1554612&doc=applicationexpressvaluepropositionforcustomers-124456216456-phpapp01] Читать далее Oracle Application Express
ArchiMate – друг архитектора?
Здесь на каждого по три истины
И на всех одно заблуждение
(с)Зимовье зверей
От всех экспертов, занимающихся архитектурой предприятия, окружающие ожидают примерно одного и того же – картинок. Переплетенных стрелочками квадратиков, взгляд на которые волшебным образом расставит все по своим местам. Я уже писал о том, что в моём понимании архитектура предприятия – это внутрикорпоративный веб-сайт, на котором широкий круг экспертов создает и редактирует странички с описанием процессов, приложений, основных информационных объектов и связывает их гиперссылками в сообщении Архитектура предприятия в формате SemanticWeb и продолжаю придерживаться мнения, что архитектура это не картинка, не книжка и не презентация, а социальный интранет-сайт. Тем не менее, люди хотят картинок. Потому, вопрос выбора графической нотации вряд ли когда-либо исчезнет. Читать далее ArchiMate – друг архитектора?
Заказная разработка vs. коробочные решения
Большую часть прошлой недели я провел, обсуждая с коллегами стратегию развития информационных систем нашей компании. И естественно тема: «Что лучше? Заказная разработка или коробочные решения» тоже возникла. Эта тема не сходит с первых полос ИТшных форумов уже минимум лет пятнадцать. Правда состоит в том, что в любой более-менее крупной компании будет и то и другое. Я не стану приводить доводы в пользу того или иного решения. Порассуждать я хочу совсем о другом, а именно о том, как эксплуатировать те и другие решения.
Эталоном процессов эксплуатации промышленных решений является ИТ-сервис менеджмент (ITSM). Helpdesk-и, отстроенная система управления инцидентами и дефектами и т.д. и т.п. Однако, для заказной разработки весь этот айтил-майтил, не то чтобы совсем не подходит,… просто не эффективен. Причины следующие:
Во-первых, люди, которые делают заказную разработку, как правило, являются ответственными профессионалами, испытывающими гордость за созданное решение. И поэтому, разработчики заказных систем готовы отвечать за результат своего труда и поддерживать свое решение и днем и ночью и в выходные и в праздники. Вытеснение таких разработчиков из продуктивной среды, замутнение коммуникаций формализованных процессами инцидент менеджмента и управления дефектами, приводит к тому, что мы не используем это благородное чувство ответственности. Это момент психологический.
Во-вторых, как известно, заказная разработка заключается в создании некоторого уникального продукта, созданного и используемого единожды. С другой стороны, ключевым фактором эффективности ИТ-процессов является экономия на объеме. Сервисная служба эффективна потому, что у разных пользователей возникают одинаковые проблемы, которые можно консолидировать, классифицировать и исправить. Т.е. выгода в том, что для большинства обращений мы уже заранее знаем, почему болит и как лечить. Вся эта логика не особо работает для заказной разработки, которая по определению уникальна. И проблемы в ней уникальны. И разобраться в этом может только тот, кто их создал.
Ну и третий аргумент заключается в том, что ИТ-индустрия семимильными шагами движется от массового производства компакт дисков(ну а как еще назвать программное обеспечение, продаваемое в каждом втором ларьке) к software-as-a-service (SaaS), т.е. продукту не тиражируемому в миллионах экземпляров, а уникальному, развернутому централизованно и потребляемому из сети. Смысл архаичного и мега-бюрократического подхода к эксплуатации такого решения просто теряется
Архитектор SOA
На прошлой неделе я три дня посвятил обучению на курсе Архитектор SOA Содержательную оценку курсу давать пока не хочу. Пожалуй, самое интересное, что я из него вынес это то, как организовать бизнес на пустом месте. Томас Эрл, в соавторстве с другими уважаемыми экспертами написал дюжину толстых книг про SOA http://www.soabooks.com, организовал школу сервис-ориентированной архитектуры http://www.soaschool.com , договорился с Prometric о проведении экзаменов http://www.soacp.com и продолжает развивать тему SOA. Лейтмотивом всей этой бурной деятельности, на мой взгляд, является тезис о том, что SOA – это не об интеграции приложений, а о том, как избежать интеграции приложений. О том, почему интеграция это долго, дорого и всегда рискованно я рассказывать здесь не стану, а интересующихся, переадресую к статье Глеб Ладыженский. “Интеграция приложений такая, как она есть”
Вернемся к SOA. Тем временем у самой SOA дела идут не столь хорошо, как у SOASystems Inc. Главное свое обещание – избавить нас от интеграции бизнес-приложений она не исполнила. И одна из причин тому чисто технологическая. SOAP и WS-* порождают интеграционных задач больше чем решают. Надежды на изменении ситуации к лучшему и достижению цели SOA, пусть хоть не в полном объеме, связаны теперь с RESTful Web services. Не обманут ли нас в очередной раз? Вообще-то, могут и обмануть. Просто интерфейсы бывают плохие и хорошие. А о том, почему одни интерфейсы лучше других я напишу в следующий раз