Обсуждение

вы практик?

замечательно. я думал, это только у меня такой подход к "оформить результаты". А оказывается - вполне "межотраслевой стандарт" ;) (вот что значит - мало у меня опыта!)

Знать бы ещё, что вы под этим словом "практик" понимаете -- ибо напрашивающееся "не теоретик" для меня означает "дурак" ("на нюх" ведь реальные задачи решать можно, но будешь обречён вечно изобретать велосипед -- и поэтому нужно "учить матчасть"). Так что я, конечно, теоретик (в том числе член ACM+SIGSOFT, INCOSE, ASEM, где любят поговорить о теории), плюс имею большой опыт участия в реальных проектах (чаще всего крупномасштабных: уж так сложилось, что мои клиенты обычно весьма крупны). Более того, до сих пор руковожу разработкой софта (хотя прямо сейчас это очень небольшая инициативная разработка TechInvestLab, зато на идеологическом фронтире -- dot15926). Текст постинга также касается одного реального прямо сейчас идущего проекта, с абсолютно реальными архитектурными развилками, там как раз эти вопросы начинают обсуждаться. На всякий случай: в постинге много терминологии (типа "расширенного предприятия", extended enterprise; "жизненный цикл", life cycle, и т.д.), которые взяты вовсе не из "теории" а из некоторых весьма практичных стандартов -- просто чтобы не спорить о терминах из разных учебников. Это ISO 15288, ISO 42010, ISO 24744 и т.д.. В принципе, в своём блоге я за последние года три приводил оттуда многие определения, поэтому вам легко будет их найти.

ailev просто фунциклирует на мета-уровне: для него практикой является то, что для других (например, его клиентов) является теорией

Для меня практикой является и то, что для клиентов является теорией, и то, что для клиентов является практикой. Зона практики у меня много шире, чем у многих моих знакомых, это так. Это не случайно, я ведь консультант, поэтому была возможность попрактиковаться во многих областях.

и очень прошу не пользуйтесь аббревиатурами (они затуманивают и размывают смысл) и используйте числовые критери оценки (например много вместо 46, крупномасштабный вместо 3 офиса по 400 пользователей) для меня те, кто оперируют уводящими в сторону словами подпадают под другую категорию "руководитель, который думает что он хороший руководитель" из ваших рассуждений уверен, что Вы не знакомы с архитектурой 1С:Предприятие 8.2

Я знакомился с архитектурами более ранних версий. Это было в разы лучше архитектур тех же систем SAP :-) Но (учитывая, что я поминаю тут расширенное предприятие, что не слишком релевантно для приложений 1С), я тут имею ввиду прежде всего инженерные системы -- где нужно собрать в одно целое результаты работы сотен проектировщиков, планировщиков, сметчиков и т.д.. Также учитываем "одинаковость" архитектур 1С, если брать именно 1С как платформу -- что не соответствует моей постановке задачи как выбору из разных архитектур (например, выбор между архитектурой 1С и SAP/R3).

сделать работу "за других", как видимо придется в этом проекте, дело не благодарное, а потому хочется пожелать, чтобы все получилось :)

Интересно будет увидеть мысли/тезисы, как "делать" то самое ядро, если из существующего ничто не подошло по критериям. Или если не "делать" новое, то "переделать" старое, что больше всего подошло.

умного я всё равно не скажу, но потрындеть - могу %) насчёт "переделать заново" vs "сделать из старого", вы будете смеяться, но единственный критерий - бюджет (время*люди*деньги). Нету бюджета - варим кашу из топора ;) в принципе, если есть уже существующая архитектура, она тоже "имеет право" "соревноваться" с другими и даже с идеей "переделать заново" (не имея идеи - какая будет, но отвечая на принципиальный вопрос), почему нет ? если "ничего не подошло", но вы всё-равно хотите "что-то сделать" - делайте по списку из того, что не требует предусловий (или предусловия можно легко сымитировать) слева направо и сверху вниз. То, что получится "по факту" и будет "ядром". Чудовищно рыхлым и немасштабируемым, но если выполняет функции (ака клиент доволен), почему нет ? Делают же модели мостов из плексигласа и дома из пенопласта ;)

Хотел запостить комент в общую линейку, но "Акела промахнулся". Но вопрос не в ресурсах, а в концепции закладываемой в создаваемую систему. Что должен конечные продукт понят, а что делать чтобы этого добиться не понятно.

>это и есть суть системного подхода: любая целевая система рассматривается прежде всего не "вглубь", а "наружу" -- не ее конструкция интересна прежде всего, а поддерживаемая системой функция во внешней надсистеме как и теоркатегорный подход, да

Меня очень порадовал следующий отрывок Выбор также поделим на две части: содержательное рассмотрение и оформление результата (обоснование). Я не верю в процедуры с "коэффициентами критериев" или расчётом ROI как механизмы содержательного рассмотрения альтернатив, я верю в то, что они хорошо позволяют оформить результат -- подогнать коэффициенты в какой-то модели, а затем представить красивую табличку выбора на одном слайде. Значит, я не один такой, кого смущает обоснование выбора с помощью ROI и подобных методик. Согласен в том, что в красивых презентациях по обоснованию бюджета подобные слайды необходимы, только вот модели этих оценок в большинстве случаев слишком примитивны, чтобы что либо обосновывать, слишком уж "многофактириальная" задача.