Есть одна тема, которая, вероятно, является основной в деятельности архитектора информационных систем. Это тема проектирования. Тема о том, как люди придумывают те или иные решения. К сожалению, по этой теме нет каких-либо общепризнанных работ. Различные авторы затрагивают её порой в своих книгах, но не дают исчерпывающего подхода, позволяющего организовать такую деятельность. Я знаю, как в своей работе это делаем мы. Я много раз видел, как это делают другие люди. Но у меня нет рецептов описания этой «техники». Я не могу включить это в учебный курс и стараюсь обходить тему проектирования стороной. Но ведь людей, пришедших разбираться в архитектуре информационных систем, на самом деле, в основном и интересует вопрос как их проектировать.
Несколько замечаний от тех, кто пытался «раскопать» эту тему. Роберт Гласс «Программирование и конфликты» (Robert L. Glass «Software Conflict 2.0. The Art and Science of Software Engineering»):
Все это время, говоря о проектировании, мы ходили вокруг да около. Методологии это не проектирование; они представляют собой платформу, на которой мы объединяем и организуем наши проектные усилия. И языки (программирования) – это не проектирование; это способ записи готового по сути, проекта. Проектирование есть нечто такое, что происходит внутри головы, в мозгу, причем происходит быстрее молнии.
Т.е. ни методологии, ни языки программирования или другие средства разработки не дают ответа на вопрос, как человек проектирует информационные системы. Более того, далее Гласс ссылается на исследование трудностей, возникающих у людей при проектировании. И вероятной причиной таких трудностей является то, что люди строят в своей голове представления будущих программ, а не действующие модели. Представления: описания структур данных, компонентные диаграммы, разнообразные другие картинки не могут быть выполнены. Их нельзя подвергнуть тестовому прогону в уме. По крайней мере, они для этого не предназначены. Т.е. все, чему нас учат книжки по разработке архитектуры информационных систем, не очень помогает, а может даже и помешать этой деятельности.
От архитекторов постоянно требуют нарисовать картинку. Но никто не требует её исполнения. Когда к вам приходит архитектор с картинкой, вы не знаете, сколько тестовых прогонов данной архитектуры он произвел в своей голове. Возможно, ни одного. Определенную пользу приносят обсуждения. Но сначала вы должны потратить некоторое время, чтоб загрузить картинку в свою голову. Если угодно, задеплоить модули и классы на нейроны своего мозга и затем начать мысленно (или вслух) выполнять сценарии. В жизни обычно так и происходит. Когда кто-то хочет представить вам архитектуру он начинает рассказывать как те или иные объекты друг с другом взаимодействуют. Довольно быстро оперативная память слушателя или же самого рассказчика заканчивается и тогда он хватает карандаш или маркер и начинает рисовать что-то не очень внятное. Процесс нормального исполнения в этот момент прерывается. То же самое происходит, если на определенном шаге прервать рассказчика вопросом: «А что если…?». В обоих случаях шансов вернутся к основному сценарию совсем не много. В общем, довольно быстро все запутываются (теряют нить рассуждений) и возвращаются к началу сценария.
Что же делать?
Во-первых, не преувеличивать роль картинок. Картинка – это инфраструктура, если хотите аппаратное обеспечение, на котором будет разворачиваться сюжет. Реквизит, помогающий не сразу запутаться в ходе дальнейшего обсуждения.
Если вы хотите нарисовать на картинке направленные стрелочки, то нарисуйте. Но, по крайней мере, пронумеруйте их и снабдите описанием осуществляемых действий, чтоб читатель мог провести мысленный запуск проекта. При этом, не забывайте что человек по природе своей однозадачен и не может выполнять в уме несколько потоков параллельно. Двунаправленная стрелочка – это удар в мозг. В лучшем случае её проигнорируют.
Пишите сценарии. Это дает хоть какую-то гарантию того, что зарисованное решение было хотя бы однажды исполнено. Вообще, написание и проговаривание сценариев – это одна из основных практик проектирования решений. Рассказывайте сценарии. Всегда помните, где находится исполняемый в данный момент процесс. Хотя бы для того, чтобы знать, куда следует вернуться после обработки очередного исключения вызванного внезапным вопросом.
Программная архитектура возникла во времена структурного программирования Дейкстры, когда основной задачей разработки ПО было научить людей упорядочивать данные и исходники программ. Инструменты архитектуры изначально были статичны и останутся таковыми еще довольно длительное время. Сегодняшние информационные системы – это множество взаимодействующих друг с другом модулей, развернутых на различных узлах сети. Их очень непросто запустить и практически нельзя выключить (все и сразу). Современную нам архитектуру информационных систем Рой Филдинг назвал абстракцией времени выполнения (run-time abstraction). Она существует только в то время, в которое приложение выполняется и не существует ни до ни после того.
Изображение взято из заметки: «Нейросети для чайников» http://habrahabr.ru/post/143129/
Из того что мне удалось найти на эту тему – это ТРИЗ (теория решения изобретательских задач).
Я не сильно глубоко изучал ТРИЗ, но поверхностно прошелся по ней и понял что все время применял многие принципы этой теории при проектировании и создании различных систем.
Ссылка http://ru.wikipedia.org/wiki/%D2%E5%EE%F0%E8%FF_%F0%E5%F8%E5%ED%E8%FF_%E8%E7%EE%E1%F0%E5%F2%E0%F2%E5%EB%FC%F1%EA%E8%F5_%E7%E0%E4%E0%F7
Ее же продвигает Юрий Мороз, широко известный в узких кругах 🙂
Проектирование ПО это не только изобретения. В первую очередь это “кооперативная игра”. Игра в изобретения и коммуникацию: http://www.maxkir.com/sd/SoftwareDevelopmentCooperativeGame1.html
Можно и так сказать. Можно разбить создание информационной системы на 2 условных этапа: создание ПО и внедрение ПО.
В первом этапе нам нужно понимать механизмы технических систем. Тут нам и помогает ТРИЗ. Здесь теорий много. Все они в той или иной степени точны и помогают.
Во втором этапе нам нужно понимать механизмы социальных систем. Вот тут теорий меньше. Из современных книг хорошо тема раскрыта в “Монстр перемен”.
Если же брать эпоху ренесанса, то там можно выделить 2-х людей: Леонардо Давинчи – эксперт в технических системах и Николо Макиавелли – эксперт в социальных системах. Один умело использовал ТРИЗ, второй хорошо описал Монстра перемен. По утверждению В.Тарасова – он первый кто это сделал так глубоко и грамотно.
Оба этапа важны при создании системы. Можно сделать плохое ПО и будь вы богом в социальных системах – ничего не выйдет. Можно иметь гениальное ПО и не увидев монстра перемен – провалить проект создания информационной системы.
Рисование картинок – как правильно замечено это второстепенно. Я вот тут эту тему трогал и делал больно комменаторам http://ecm-journal.ru/post/Zachem-risovat-skhemy-biznes-processov.aspx
Вообще с проектированием информационных систем имею дело достаточно часто, но рисую картинки крайне редко. В последнем проекте мне это понадобилось, но и там, попробовав рисовать в BPMN понял что это сложно, долго и мало толку. Потому нарисовал логику при помощи интелект карты, тем самым добился понимания со стороны руководителя службы персонала и программиста, который разрабатывал соответствующую систему.
Основного эффекта добился за счет написания процедуры, текстом. В данном случае это было названо “сценарием”. Вообще тема крайне интересная. Думаю в ближайшее время написать статью “Объектно ориентированное регламентирование” – как раз для того чтобы показать слабую полезность рисования картинок и пользу от описания сценариев или проще говоря “инструкций по действиям сотрудников, с описанием ключевых особенностей”.
Да. Такая статья была бы очень интересна
Польза от слов несомненна, тем и отличаются люди от братьев меньших, однако использование текстов и текстовых “сценариев” для описания процедур (в том числе регламентов) является вынужденным и означает лишь отсутствие нормальных инструментов. Не зная языка программирования, можно любой алгоритм описать словами естественного языка, но хорошего в этом мало. Так и регламенты, представленные в виде простого текста, малоприменимы, их каждый раз надо интерпретировать, т.е. читать и понимать. Поэтому и картинки тоже нужны, чтобы одним взглядом представить всю картину в целом. Раньше только так и работали. Но в наше время лучше все-таки использовать средства автоматизации. Любые корпоративные регламенты представимы визуально в виде либо BPM-схемы либо кейса. Кейс предпочтительней, так как позволяет визуально разместить и текстовые описания пунктов регламента в нужной последовательности. К тому же в кейсе можно предусмотреть и непроцедурные требования регламента, не являющиеся задачами. Фактически с помощью системы кейс-менеджмента можно визуально представить любой корпоративный регламент, более того, сделать его интерактивным, запустить его на исполнение, так, чтобы утвержденный корпоративный регламент реально контролировал описанные в нем корпоративные процессы.
Не соглашусь. Не все операции или действия проходят у окна монитора… Часть может быть у ПК, часть может быть “на ходу”, “в полях”, “где то за ПК” …
При этом эти действия также влияют на конечный результат и подлежат регламентации.
Да, ACM – позволят большую часть действий упаковать в кейс и там через чек-лист, а также краткие инструкции и гиперссылки обозначить почти весь состав действий. Это супер удобно для исполнителей и для руководства. Но! Это не 100% действий.
И пока я не готов отказаться от структурированного описания процессов.
Структура процессов или модель – это основа.
А вот на ее базе уже можно творить дополнения. Будь то чек-лист АСМ, краткое изложение инструкций, гиперссылки, видео-демо или картинки “Не раскачивайте кабинку” на гандолах в ГРК, или “Не курить” на АЗС, или “Комикс как одеть спасательный жилет при крушении самолета” 🙂
У нас есть база – модель, и нам нужны краткие доп.инструкции, визуализированные или выделенные иначе, в ключевых моментах процесса.
Чек-лист в АСМ – это лишь частный случай визуального выделения ключевых особенностей процесса.
>>Не соглашусь. Не все операции или действия проходят у окна монитора.
Так с этим никто и не спорит. Но если нужен инструмент автоматизации регламентов, то лучшим выбором для этого будет ACM. Вы сами подтверждаете, что “Да, ACM – позволят большую часть действий упаковать в кейс”. К тому же, да, “не все операции или действия проходят у окна монитора”, но КОНТРОЛЬ за практически всеми операциями и действиями можно оформить как чек-лист в кейсе. А это решает главную проблему бумажных регламентов – отсутствие автоматизированного контроля за их исполнением. Требования к процедурам легко оформить как чек-лист. Но и непроцедурные требования типа “все должны ходить на работу в галстуках” или, как в одной канадской компании, где работает много индусов – “NO SOCKLESS SANDALS!” тоже можно оформить как кейс для отдела кадров по контролю за дресс-кодом.
>>И пока я не готов отказаться от структурированного описания процессов.
Так существующие системы ACM также позволяют делать структурированное описание процессов. И сами чек-листы и категории кейсов могут быть иерархическими, т.е. вполне способны отражать структуру бумажных регламентов, описывающих требования к корпоративным процессам. Это у Макса на 8-м слайде в его посте “Внедорожник для бизнес-процессов” в картинке кейса скромный выпадающий список типов и несколько аттаченных файлов :), а индустриальные ACM-системы имеют иерархическую структуру типов, иерархическую структуру самих кейсов и иерархическую структуру файловых каталогов в кейсах, позволяющих закрыть все потребности в представлении любой информации – и документы, и видео, и фото и слайд-шоу
>>Чек-лист в АСМ – это лишь частный случай визуального выделения ключевых особенностей процесса
Да, именно поэтому, кроме простого чек-листа в реальных ACM можно размещать и произвольные сообщения, содержащие инструкции, ссылки, файлы и обсуждения