Enterprise architecture vs. BPM

В блоге Анатолия Белайчука появилась заметка Граница между инструментарием EA и BPMS. Желание провести такую границу абсолютно уместно. Не выполненных обещаний архитектуры предприятия, BPM сообщество  просто не потянет. С другой стороны, накопленный Enterprise architecture опыт реальной деятельности в компаниях, тоже не стоит сбрасывать со счетов. Тем более, что ошибки у корпоративных архитекторов и специалистов по управлению бизнес процессов одинаковы: Читать далее Enterprise architecture vs. BPM

Вершки и корешки

Не смог побороть кодировки  на сайте Intellegent enterprise потому и написал комментарий к статье  Ольги Мельник Полезные зерна Enterprise 2.0 в своем блоге

Вполне ожидаемые выводы экспертов. Предприятия воспринимают Enterprise 2.0 пока очень односторонне. Я бы охарактеризовал это восприятие как Интранет 1.0. В Enterprise 2.0 пока видят всего лишь внутренний веб-сайт, дополненный возможностью писать комментарии и статьи. Отличие от традиционного и давно знакомого интранет сайта, разве что в скорости публикации, да и то не всегда.

Ситуация возможно изменится когда компании посмотрят на Enterprise 2.0 с других сторон. Во-первых, как на инфраструктуру данных, поверх которой строятся бизнес-процессы. Во-вторых, как решения с принципиально лучшим, чем у традиционных информационных систем юзабилити. И наконец, как способ быстрой реализации новых требований пользователей силами самих пользователей.

RESTful и Enterprise 2.0

В 2006 году профессор Andrew McAfee, по аналогии с термином Web 2.0, придумал термин Enterprise 2.0. Для пояснения этого термина он использовал аббревиатуру SLATES (Search, Links, Authorship, Tags, Extension, Signaling), описывающую набор требований к Enterprise 2.0 решению. В дальнейшем это понятие стали развивать, улучшать и трактовать в разных смыслах, что существенно затуманило понимание вопроса. Зато дало большой простор для дискуссий не темы типа: является ли Sharepoint решением Enterprise 2.0.

В 2000 году Roy Fielding придумал и описал архитектурный стиль RESTful, который частенько позиционируют как стиль Web 2.0. Понять, что же Филдинг подразумевает под «REpresentational State Transfer» могут не многие. Поэтому, в отличии от истории с Макафи трактовки REST, как самим Филдингом, так и его приверженцами оказали бы вполне кстати. Объединяя обоих авторов, я предлагаю свою трактовку приложений Enterprise 2.0: Читать далее RESTful и Enterprise 2.0

[За]метки на полях

Я давно собирался написать о том, почему метки (они же ярлычки, они же тэги) являются не только удобным способом классификации сообщений в блоге и инструментом эффективного поиска. За этим механизмом скрывается намного более мощная идея. Идея структурирования данных «на лету». Сейчас стало модным к любому понятию приписывать слово dynamic. Так вот метки – это механизм реализации динамических структур данных. Только мы, вскормленные на  реляционной модели данных, об этом совершенно не задумываемся.

Читать далее [За]метки на полях

Петли обратной связи

Управляющие процессы изобилуют корректирующими петлями (запросами на проверку и уточнение)

Не маленьких размеров камешек забросил в огород любителей тяжеловесных формализованных процессов Алистэр Коуберн в работе «The New Face of Software Engineering». Алистэр очень педантичный исследователь и потому, разбирая ту или иную тему, докапывается до сути. Его рассуждения интересны и поучительны.

В упомянутой работе Коуберн использует для процессов разработки программного обеспечения модели, присущие промышленному производству. Как известно, процесс промышленного производства описывается последовательностью работ по преобразованию сырья и материалов в готовые изделия. Процесс проходит несколько стадий. На каждой из которых, результат предыдущих стадий преобразуется в комплектующие для следующей. Пусть так. По аналогии с предложенным подходом мы можем представить интеллектуальную деятельность как упорядоченную последовательность принятия различных решений. Изображенные на картинке пирамидки и есть такие решения, кусочки информации, передаваемые от одного участника процесса другому. Однако, в интеллектуальной деятельности сплошь и рядом случаются ситуации, когда исполнитель очередного этапа просто не может выполнить свою работу из полученных комплектующих. Одни решения не понятны, другие не полны, третьи противоречивы. Во всех этих случаях требуется возврат к одному из предыдущих шагов и повторное прохождение по всей цепочке. Согласитесь, в повседневной офисной деятельности многократная доработка и пересогласование документов это правило, а не исключение. Это как путешествие по лабиринту, когда обнаружив тупик на одном из путей, мы возвращаемся к развилке и идем в другую сторону.

Не понятно, почему же менеджеры высокотехнологичных проектов, прекрасно понимая, что найти решения с первого раза получится далеко не всегда, по прежнему верят в диаграммы Ганта и метод критического пути.

Интеграция приложений

Среда интеграции приложений – программная платформа, предназначенная для развертывания большого количества композитных [микро]приложений в стиле SOA. Существуют два основных подхода к интеграции приложений: асинхронная интеграция приложений при помощи message-oriented middleware или же просто асинхронного взаимодействия между приложениями посредством обмена файлами или записями в общей базе данных и синхронная интеграция посредством сервисной шины. Недостатком первого подхода является сложная логика интеграции из-за необходимости синхронизации состояний объектов в различных системах. Второй подход требует обеспечения высокой надежности и масштабируемости решений.

Сервис-ориентированная архитектура (SOA) – стиль разработки, минимизирующий внесение изменений в унаследованные системы за счет повторного использования существующего функционала. Ключевой момент SOA заключается в реализации каждого бизнес-процесса в виде отдельного слабосвязанного компонента. В традиционных бизнес-приложениях множество бизнес-процессов реализуются в едином монолитном решении, что затрудняет локализацию проблем, существенно повышает вызванный внесением изменений риск нарушение работоспособности и как следствие требует более тщательного проектирования, разработки изменений и, как правило, проведение полного регрессионного тестирования.
Сервисная шина (ESB) – отдельный класс платформ интеграции приложений реализующий, в отличии от традиционных интеграционных сред, не только асинхронное, но и синхронное взаимодействии. Современные сервисные шины строится на базе решений JavaEE application server
Сервер приложений (JavaEE application server) – программная платформа, предназначенная для эффективного использования серверных ресурсов (процессы, оперативная память, пулы соединений, очереди и пр.) при исполнении множества java-приложений, реализованных в виде сервисов.

SOA сервис – слабосвязанный программный компонент, предназначенный для повторного использования. В отличии от традиционных интеграционных компонент, разработанных с учетом интерфейсов интегрируемых систем и используемых для интеграции только этих систем, сервис может использоваться любыми другими новыми приложениями.
Stateless протокол – протокол взаимодействия между клиентом и сервером, запрещающий сохранение на сервере состояния клиентского соединения. Таким протоколом, например, является протокол web-сервисов HTTP. В отличии от протоколов работы с базой данных, сохраняющих состояние клиентской сессии, stateless протоколы допускают высочайшую степень масштабирования за счет возможности установки дополнительных серверов, включаемых в общую систему балансировки нагрузки.

Архитектура предприятия в формате Semantic Web

Готовлю презентацию на обозначенную тему:
[slideshare id=5778408&doc=semanticweb-101114155947-phpapp01]
Основные тезисы:
Читать далее Архитектура предприятия в формате Semantic Web

Lean процессы :-)

Как работает (хороший) бизнес-аналитик сегодня:
Он довольно быстро создает основную ветку процесса. Иногда это называют типичным ходом событий. А потом очень много времени тратит на выявление исключительных ситуаций и написание для них обработчиков. Причем, сложность обработчиков может быть крайне велика. Существенно больше, чем сложность основного сценария. Это хорошая практика. Нас всех так учили на уроках программирования. В результате, в современных приложениях огромный объем кода никогда не вызвался, а возможно и не будет вызываться. А модели бизнес-процессов перегружены логикой, которая мало того что сложна и редко используется, но с большой вероятностью уже давно неактуальна. Ситуация меняется. Исключения надо обрабатывать иначе. Case management интересен тем, что сводит развесистый граф традиционной модели процесса к небольшому набору практически линейных наборов активностей. Ну а с исключениями пусть разбираются люди.