Шрифт:
5. Разделите функциональную схему и техническую разработку.
6. Определите последствия разработки и добейтесь согласия по ним.
7. Как указано в главе 14, важно применять архитектуру гибко. Например, что делать, если появилось срочное бизнес-требование, а решение не укладывается в архитектуру? Один из вариантов – дать возможность проработать требование и установить строгие правила работы с таким исключением (например, решение должно быть выведено из эксплуатации в течение Х месяцев или соответствовать архитектуре в течение N месяцев). Такой механизм «клапана скороварки» очень важен, поэтому окончательный тест архитектуры – способ обработки исключений. Отвергать или игнорировать все исключения может показаться выигрышным подходом, однако это ведет к конечному проигрышу, поскольку люди будут все больше игнорировать архитектуру.
8. Критично включение требований к программному и аппаратному обеспечению, поскольку в большинстве случаев между ними есть взаимозависимость.
Кейс: неверный «быстрый путь»
Оператор связи хотел ввести новую систему для поддержки биллинговых процессов и обслуживания клиентов, и разработал требования только на основе действующей бизнес-модели: предоставление услуг наземной связи населению. Когда нам показали исходные спецификации, мы указали, что они полностью лишают систему гибкости. Исходя из обобщенной бизнес-модели, мы предложили оператору пойти по пути создания системы на основе переменного комплекса бизнес-параметров, а не жесткого программирования функциональности в системе. Например, вместо обеспечения услуг только населению, следует предусмотреть и другие типы клиентов: предприятия и дистрибьюторы, а вместо только одной роли организации (провайдер услуг) – допустить различные типы (сетевой оператор и дистрибьютор). Оператор совет проигнорировал, и после двух крупных перемен в его стратегии система стала безнадежно сдерживать бизнес; в такой степени, что была упущена редкая возможность увеличить долю рынка, и огромные усилия прилагались для сохранения рентабельности.
Вывод. Проведите анализ «что если…», чтобы убедиться, что ваши требования выдержат предполагаемые изменения.
В работе с ПО важный вопрос – применение соответствующих стандартов. С появлением таких технических средств, как XML, веб-сервисы и сервисно-ориентированная архитектура, возможности распространения автоматизации процессов расширяются далеко за пределы данной организации на поставщиков, клиентов и партнеров. При этом повышается эффективность и быстрота.
Сегодня обсуждать стандарты моделирования, компоновки, исполнения и совместимости все еще весьма сложно. Нет общего консенсуса между поставщиками инструментов относительно цельного комплекса стандартов BPM, хотя на данный момент лидерами являются BPEL и BPMN. По этой причине мы настоятельно призываем читателя осознать этот факт и выйти за рамки дискуссии, чтобы понять, действительно ли стандарты играют существенную роль в конкретной ситуации.
В области BPM ведущая роль сегодня принадлежит следующим стандартам:
• BPEL (язык исполнения бизнес-процессов). Сейчас это главный язык исполнения, который компонует бизнес-процессы, используя веб-сервисы, и позволяет интегрировать и связывать различные приложения BPM;
• BPML (язык моделирования бизнес-процессов). Непосредственно конкурирует с BPEL как мета-язык моделирования бизнес-процессов;
• BPMN (спецификации обозначений моделирования бизнес-процессов). Стандарт обозначений (т. е. комплекс пиктограмм и графических изображений) для моделирования бизнес-процессов. Главная цель этого стандарта – применение общих графических средств моделирования в инструментах моделирования бизнес-процессов и приложениях BPM; таким образом, BPMN является дополняющим для других стандартов BPM;
• Wf-XML (расширенный язык разметки – XML – для рабочего потока). Обеспечивает взаимодействие и совместимость между модулями-машинами BPM, давая возможность исполнять длительные бизнес-процессы, задействованные на нескольких машинах-модулях;
• XPDL. Язык определения бизнес-процессов, который описывает полный процесс и может использоваться для интеграции компонентов BPM при моделировании, исполнении и контроле процессов в рамках продукта. XPDL также широко применяется в продуктах BPM с открытым исходным кодом.
Шаг 5. Разработка ПО
В целом, можно выделить три слоя любого автоматизированного решения BPM:
1. Слой представления решения пользователю.
2. Слой обработки, содержащий автоматизированные задания.
3. Слой интеграции с другими системами и базами данных, содержащими информацию.
Необходимо осознавать, что как в разработке, так и при тестировании каждому из этих трех слоев нужен свой подход, поскольку задействуются разные группы людей. Слой представления нацелен на конечных пользователей и видится ими в качестве системы. Необходимо учесть следующие факторы:
• знакома ли такая картина конечным пользователям и воспринимается ли она логично (т. е. похожа на другие системы и представлена логичной последовательностью картинок на экране);
• у различных типов пользователей будут разные потребности и способы взаимодействия с системой (например, работники, контролеры, менеджеры и т. д.).
Слой обработки связан с операциями, которые должна выполнять система. Необходимо, чтобы она разрабатывалась людьми, хорошо понимающими бизнес и цели проекта. Важный вопрос – документация, и при растущей популярности разработки пилотных инструментов (RAD и BPM) налицо крепнущая тенденция не документировать вообще, или делать это не столь подробно, как следует. Разработчики утверждают, что документация неявно присутствует в конфигурации системы, и ее можно там посмотреть. Вид системы дает представление о том, что было сконфигурировано, но не объясняет, почему была выбрана именно такая конфигурация. Не видя решений, определивших конфигурацию, трудно вносить изменения в будущем с какой-либо степенью уверенности, что они будут согласованы с выбранными ранее вариантами процессов.
Слой интеграции/данных более технический, поскольку связан с интерфейсами других систем. Требуются глубокие технические знания, а также четкое понимание систем, с которыми связаны автоматизированные решения BPM.
Один из наиболее остропроблемных аспектов этапа разработки ПО проекта не просто относится к фактической разработке, но и к переходу на новую систему. Путь к успеху усыпан остатками проектов, в которых недооценивались проблемы, связанные с переходом и интерфейсами.
Переход с точки зрения рядового сотрудника может выглядеть просто, потому что единственное, что требуется для переноса бизнес-моделей, процессов и данных из одной системы в другую, – это простое соответствие полей данных между новой и старой системами. Но очень важно, чтобы бизнес-модели, процессы и данные существующей системы были правильными. Опытные практики знают, что пользователи будут задействовать систему по-разному, и это означает, что в ней окажется значительно больше ошибок, чем казалось на первый взгляд.