Лоскутная автоматизация 2.0
Слушайте, а есть уже такой термин или нет? На фоне всеобщей «дванольности» он смотрится вполне себе ничего, тем более, что и смысл в нем определенный есть.
Слушайте,
а есть уже такой термин или нет? На фоне всеобщей «дванольности» он смотрится
вполне себе ничего, тем более, что и смысл в нем определенный есть. Поясню.
Работая с заказчиками, читая success stories внедрений у нас и за рубежом, все больше прихожу к мысли, что тема внедрения отдельных систем для отдельных (зачастую очень близких) задач становится устойчивой тенденцией. Да, есть best-of-breed. Но мне кажется, что тут имеется существенное отличие: при лоскутной автоматизации 2.0 для решения схожих (а иногда одних и тех же задач) на разных уровнях предприятия, в разных подразделениях могут выбрать разные системы, в то время как best-of-breed предполагает подбор комплекта корпоративных систем, которые четко разделены по области ответственности и вряд ли будут разными на разных уровнях предприятия. (Хотя допускаю, что эти термины подразумевают одно и то же.)
Я бы выделил некоторые основные тенденции лоскутной автоматизации 2.0:
1. Широта охвата. Да-да. В отличие от лоскутной автоматизации 1.0, известной нам по диким 90-ым, здесь сохраняются черты некоторой глобальности, ориентации на решение всех проблем и автоматизацию всех пользователей в рамках четко очерченной бизнес-задачи. Например, если invoicing – то total: будет создаваться архив абсолютно всех входящих счетов во всех подразделениях предприятия (хотя архива для других документов может и не быть вовсе).
2. Использование комплексных систем для решения частных горизонтальных или вертикальных задач. Т.е. система, которая может решить, скажем, все задачи ERP, внедряется только для решения вопросов управления торговлей, а, к примеру, бухучет или управление договорами делают в другой системе. Причины кроются в зачастую неадекватной стоимости лицензий, в высокой стоимости услуг консультантов, в опыте компаний-интеграторов («да, торговлю мы делали часто, а договора – редко»), в большей готовости самих систем (модуль управления персоналом проработан до мелочей, а «зарплату» нужно напильником дорабатывать).
3. Вовлечение бизнес-персонала в выбор систем. Поскольку задачи при лоскутной автоматизации 2.0 уже, четче, локальнее, то выбирать и принимать решение о приобретении вполне может не высший руководитель предприятия или ИТ-служба, а руководитель отдела, глава департамента или главный бухгалтер.
4. Возникают требования к высокой интегрируемости систем. Тема SOA в последнее время раскрывается все больше. Требования к интерфейсам систем, их API, открытости их сервисов, требования к SOA-платформам становятся все жестче. Именно в появлении (вполне объективном появлении!) огромного числа систем на предприятиях кроется причина тяготения к SOA.
Вот как-то так. Осталось понять: что же нас ждет дальше. Комплексная автоматизация 2.0? :)
Комментарии 7
Кто же сможет уследить за SOA архитектурой строящейся системой? Наверное SOA архитектор - человек который видит все лоскутки и их развитие сверху. Понимает куда двигается вся система и все её частички по отдельности. Какой же колоссальный опыт должен быть у этого архитектора, он должен представлять все кусочки системы. Всё таки изменение части SOA системы, как части как большого организма состоящего из множества систем, процесс довольно не тривиальный, а в России бизнес среда довольно изменчива пока. В связи с этим нужен всё таки какой-то системный архитектор. И компании внедряющие у себя SOA архитектуру должны иметь такого человека, и ИТ интеграторы должны иметь SOA архитекторов с большим опытом для консалтинга заказчиков и архитекторов заказчиков.
В этом контексте интересна история развития средств безопасности. Одно время был этап, когда считалось, что можно создать один супер-продукт, который будет всех от всего защищать. Сейчас пришли к лоскутности, когда механизмы защиты встраиваются в ОС, SQL, системы ЭДО, а также создаются отдельные продукты для конкретных задач. Но, помня о спиральном развитии, можно предположить, что "Комплексная автоматизация 2.0" тоже обязательно будет, возможно она будет заключаться в том, что все многообразие продуктов, которые только можно пожелать будут поставляться одним вендором :)
При лоскутной автоматизации всегда появляется проблема синхронизации справочников. Эту проблему может решить и претендовать на систему, поддерживающую эталонные справочники, ECM, если она действительно управляет содержанием. Рецепт прост, если поддерживается стандарт 21 века XML, то преобразовать данные из одной структуры в другую становится делом понятной технологии. Без технологии не обойтись. Тот же SOA использует все туже схему преобразования XSLT в среде XML языка XSDL (или подобного). Как здорово было бы эталонные таблицы утверждать в стандартах в виде XML документах MS Word и преобразовывать в справочники любой структуры от dbf до Oracle.
...проблема синхронизации справочников...
Абсолютно согласен. Другое дело, что а) роль ECM как центральной системы спорна; б) XML/XSLT/XSD удобны для хранения данных в системах и для преобразования их при переносе между системами, но есть и масса других вопросов, которые эти технологии не решают: правила разрешения конфликтов, приоритетов, слияния; транспорт; аутентификация/безопасность. Плюс с точки зрения нагрузки и трафика XML не оптимален. Но лучшего и более проработанного решения, соглашусь, сейчас нет.
... Рецепт прост, если поддерживается стандарт 21 века XML, то преобразовать данные из одной структуры в другую становится делом понятной технологии ...
Хм, странно... А вот мне всегда казалось, что проблема синхронизации справочников не сводится к банальному формату передачи данных уже годов так с 90-х, видимо у кого-то эта проблема все еще остра...
Обычно, самой большой проблемой синхронизации становится разработка регламента: какие данные передавать, с какой периодичностью, как выявлять дубликаты и разрешать конфликты, как сопоставлять записи в разных справочниках, как контролировать изменения, чтобы не передавать каждый раз полные данные и т.д.
Кто же сможет уследить за SOA архитектурой строящейся системой? Наверное SOA архитектор
Меня этот вопрос тоже очень интересовал http://www.ecm-journal.ru/docs/1844224.html
Что касается комплексной автоматизации 2.0, то мне кажется к ней прийдем, когда все системы распадутся на сервисы и о классах систем говорить смысла уже не будет. Тогда вендоры или аналитики, очевидно, вынуждены будут придумать классификацию групп сервисов, чтобы хоть как-то позиционировать предлагаемые на рынке продукты.
В современных ИТ достаточно много технологий, которые имеют революционное значение. Взять хотя бы Семантический WEB. Понимать содержание текста можно лишь при высоких уровнях описания метаданных. Над этим и работают в проекте семантический WEB. Думается, что SOA станет не всеобщим ресурсом, а переходной технологией, определившей путь развития. Очень много групп разработчиков разрабатыва\ют сервисы и интерфейсы для открытых web-технологий, но эти ресурсы станут бесполезны, при переходе на новую платформу. Так оказались забытыми многие библиотеки алгоритмов на языке Fortran, когда появились средства объектного-ориенттрованного программирования.