A
Alexander Samarin
Странно, я показываю эти viewpoints и views в международных группах (как архитектор-методолог) и оне их понимают (ну не всегда с первого раза)
я тоже всегда говорю: "большое спасибо за ваш показ, это было очень полезно" )))
Size: a a a
2017 May 31
AS
так я о том и пишу, что продвигаемая вами теория очень оторвана от практики. А то читаю много умных слов (да я и сам их знаю, умею употреблять), а на практике все сильно иначе (если мы хотим действительно иметь какой-то результат, кроме наличия views в какой-то материальной или нематериальной форме)
А большинство моих models являются explicit and machine-executable, так что они идут в работу напрямую.
A
давайте простой пример: презентация/донесение ИТ-стратегии - какие views стоит использовать?
GK
ну да, ну да. Дано: международная компания с капитализацией $237 млрд, выстроенные подразделения, занимающиеся архитекторой по направлениям бизнеса, по регионам, на местах. Выстроенная практика донесения информации до ЛПР, подход к принятию решений. Между собой архитекторы могут общаться с использованием любых фреймворков и нотаций, а вот материалы для ЛПР (презентации) включают в себя уже несколько иной вид всех этих view - таких и не встретить в фреймворках. При этом с точки зрения принятия решений это очень качественные материалы.
Думаю, тут ключевой момент - не столько полное соответствие стандартам, сколько пригодность для принятия решений. В зрелых проектах рождается культура коммуникации, которая деформализует взаимодействие. В том числе, рождаются удобные нотации, которые все понимают. Правда остаётся проблема введения новых людей в проект, подключения аутсорсеров и пр.
GK
так я о том и пишу, что продвигаемая вами теория очень оторвана от практики. А то читаю много умных слов (да я и сам их знаю, умею употреблять), а на практике все сильно иначе (если мы хотим действительно иметь какой-то результат, кроме наличия views в какой-то материальной или нематериальной форме)
Views точно можно сделать качественными, чтобы целевая аудитория их понимала.
A
Alexander Samarin
А большинство моих models являются explicit and machine-executable, так что они идут в работу напрямую.
у IBM тоже процесс разработанный в business modeler является explicit и machine-executable :) только опять же (исключительно из практики) это рисование хорошо работает в простых кейсах. Если же хотим надежности (даже в простых кейсах), то явно написанный разработчиком процесс - куда предпочтительнее
GK
давайте простой пример: презентация/донесение ИТ-стратегии - какие views стоит использовать?
Как вариант - контекстные и функциональные в нотации "box-and-lines"
AS
как архитектор-методолог вы кому их показываете? архитекторам? CEO?
Людям, котоорые будут делать подобные системы для себя - обчно они subject matter experts.
GK
у IBM тоже процесс разработанный в business modeler является explicit и machine-executable :) только опять же (исключительно из практики) это рисование хорошо работает в простых кейсах. Если же хотим надежности (даже в простых кейсах), то явно написанный разработчиком процесс - куда предпочтительнее
Написанный разработчиком процесс - это уже, можно сказать, реверс инжениринг
AS
давайте простой пример: презентация/донесение ИТ-стратегии - какие views стоит использовать?
Вам нужна песплатная консультация? Elementary - http://improving-bpm-systems.blogspot.ch/2013/02/linking-business-strategy-and-it.html
AS
у IBM тоже процесс разработанный в business modeler является explicit и machine-executable :) только опять же (исключительно из практики) это рисование хорошо работает в простых кейсах. Если же хотим надежности (даже в простых кейсах), то явно написанный разработчиком процесс - куда предпочтительнее
Надежность всей системы редко является приоритетом для разработчика.
A
Alexander Samarin
Вам нужна песплатная консультация? Elementary - http://improving-bpm-systems.blogspot.ch/2013/02/linking-business-strategy-and-it.html
спасибо, не нужна. Подобных подходов есть у меня ))
A
Alexander Samarin
Надежность всей системы редко является приоритетом для разработчика.
верно, но почему-то весь мир решил, что если процесс будет разрабатывать аналитик - то это будет надежно (ну или не решил, а принял это по умолчанию)
A
мое мнение, что все эти фреймворки являются неплохим средством для размышления над проблемой (системный подход/взгляд, которого часто многим не хватает), но на данный момент они являются плохим средством коммуникации, то есть донесения мысли
A
(если мы доносим какую-то мысль не такому же архитектору)
AS
у IBM тоже процесс разработанный в business modeler является explicit и machine-executable :) только опять же (исключительно из практики) это рисование хорошо работает в простых кейсах. Если же хотим надежности (даже в простых кейсах), то явно написанный разработчиком процесс - куда предпочтительнее
Я же уточнил - в работу, а не только "process modeling, simulation, and analysis capabilities to help business users visualize, understand, and document business processes for continuous improvement."
AS
Alexander Samarin
Я же уточнил - в работу, а не только "process modeling, simulation, and analysis capabilities to help business users visualize, understand, and document business processes for continuous improvement."
"процесс будет разрабатывать аналитик" - архитекторы не работаю "по умолчанию", они обязаны все сделать explicit. Поэтому, человек, которые разрабатывает процесс будет следовать принятому стилю моделирования (ответственность за такой стиль - на архитекторе).
GK
Позволю себе добавить, что процесс может уточняться на этапе разработки. При это важно отслеживать изменения
AS
мое мнение, что все эти фреймворки являются неплохим средством для размышления над проблемой (системный подход/взгляд, которого часто многим не хватает), но на данный момент они являются плохим средством коммуникации, то есть донесения мысли
Согласен, что хороший набор viewpoints покрывает problem space и solution space. Ну а насчет срества коммуникации - это о выборе обоих сторон.
GK
мое мнение, что все эти фреймворки являются неплохим средством для размышления над проблемой (системный подход/взгляд, которого часто многим не хватает), но на данный момент они являются плохим средством коммуникации, то есть донесения мысли
Языки программирония являются хорошим средством написания кода, но код при этом редко бывает понятным всем