Это всё из области логической архитектуры приложений. Проблемы, которые ты перечислил, успешно решаются. Например при помощи SOA и BPM. Я имею в виду логическую архитектуру, а не физическую. Последняя всегда скатывается к вопросам web services, security и прочей технической лабуды, не имеющую никакого отношения к бизнесу. Сначала надо понять бизнес. Понять бизнес-сервисы (наприме, "Зарплата", "Бухгалтерия"), бизнес-процессы ("Начисления зарплаты", фантазия закончилась ), бизнесс-операции ("Расчёт зарплаты", "Выплат денег из кассы", "запуск ядерного реактора"). Если начать с бизнес-объектов, то там же вы и закончите (это принцип объектно-ориентированного анализа и архитектуры). Вот пример, в систему вводиться "Человек" как бизнес-объект (и это в реальном проекте, который кстати провалился). Зачем? Из ОО понятно, что это есть некое обобществление. С точки зрения бизнеса — это полный бред. Почему? Бизнес не имеет дела с человеком, он имеет дело с работниками, кандидатами на работу, провинившимися, покупателями, частными предпринимателями. Всё это бизнес-объекты. Увольняем Буча. Он не писал свою книгу во времена интеграции приложений и бизнес процессов. Он писал приложения, которые всегда были одни во вселенной и не должны были взаимодействовать с другими системами. Кроме того ОО требует чтобы все бизнес объекты были известны наперёд. Это возможно, но нельзя знать все бизнес процессы наперёд. Помещаем части бизнес-процесса в объекты и всё, систему можно выкидывать на свалку, поскольку процессы меняются часто и почти всегда различны в разных фирмах. Зарплату и ту везде по разному начисляют. 1С потому и хорош, что позволяет быстро адаптироваться под требования заказчиков, но это не есть правильное решение с точки зрения логической архитектуры.
Субъективности при моделировании можно избежать очень простым способом — не давать этим заниматься программистам, точнее тем, кто умеет писать код и знает хоть что-то про UML и ОО. Найдите бизнес-аналитика, да-да того самого, который знает бухгалтерию, финансы, кадры, или того кто знает устройство ядерного реактора и как он работает в деталях. То есть человека, который точно значет, что такое "покупатель", "бухгалтерский счёт" и пр. бизнес-объекты. Он всегда говорит на том-же языке, что и пользователи, и потому субъективности быть не может. Далее встаёт проблема взаимодействия бизнес-аналитика и программиста. "Покупатель" для бизнес-аналитика — это "человек, готовый заплатить деньги за услуги или товар", для программиста... что угодно... с вариациями, например C++ класс Customer, запись в Oracl-овой таблице Customer, web-service Customer (за это убивать надо, ну где вы видели, чтобы бизнес обеспечивал сервис под названием "Покупатель" ). Решением несоответствия между реальностью (точка зрения бизнес-аналитика) и "матрицей" (точка зрения программиста, где "покупатель" может прыгать и летать как Супермен ) должен заниматься человек, в задачу которого входит то, что на Западе называют "aligning IT to Business". То бишь заставляет IT смотреть на мир с точки зрения бизнеса (убирает субъективность, а заодно приводит к бизнес-ориентированной методологии разработки ПО, всё остальное — технические проблемы, и потому не интересные). Человек такой должен разбираться в технической архитектуре, а также в бизнес архитектуре. То есть нечто вроде бухгалтера-программиста. И такие люди есть. Да, и они не пишут код, поскольку это влияет на восприятие реальности.
Процесс обычно выглядит так: смортим что нужно закачику, определяем бизнес-процессы (если у вас есть желание их изменить, то вам нужно доказать, что то, как владелец фирмы делает бизнес сейчас — это неправильно, а вы готовы к этому?) и автоматизируем их Конечно для этого нужна инфраструктура, но это технические детали и потом не интересны (если очень хочется то смотрим WfMS, BPMS и пр.).
Да, "фазовые превращения" — это и есть бизнес процесс. "Запустили реактор" -> "Пустили козла в огород" -> "Пытаемся остановить цепную реакцию"


СВ>3. Статичность и динамичность
СВ>Начну с примеров. Разработана база данных, в которой ведется некий учет. Ясен динамический характер ведения учета, данные заносятся в определенные моменты времени, используются (просматриваются, экспортируются) тоже в определенные моменты времени. Поменялись требования, изменилась структура БД, теперь надо возможно переработать все модули (программы, протоколы и стандарты), которые используют эту базу. Виден динамический характер <модели> базы данных.

Вот тут то и встаёт вопрос о том, кто владелец данных Если все модули владеют "Бух. счётом" (потому что в бухгалтерии всё связано с ним), то надо будет переписывать все эти модули. А как насчёт того, чтобы определить владельца? Одного, который владеет "Бух. счётом". Тогда, чтобы не случилось с БД (если она вообще есть Программеры редко могут представить себе, что "Бух. счёт" может быть вне компьютера, например, в учётной книге, что не меняет бизнес-процесс, между прочим ) единственное что нужно будет изменить — это владельца.

СВ>Другой пример. Разработана огромная, сложная, система с "кучей" модулей-подмодулей, множеством средств хранения данных (базы данных, файлы различных форматов, распределенные данные в сети, контроллеры учета и регистрации и т.п.). Все это четко описано, регламентировано, стандартизировано, определены меры в случае изменения требований. Здесь виден динамический характер самой системы, а также динамический характер модели.

Система не должна быть сложной. Она должна быть модульной. Каждый модуль "владеет" своими данными и полностью не зависим от других модулей. В последнем предложении заменям модуль на сервис и приходим к SOA


СВ>Пока остановлюсь на этом, жду ваших мнений. Стоит ли это дальше обсуждать.

Зачем? Решение есть. Проблема только в том, что это решение в жизнь не так легко воплотить по одной простой причине — ни программисты, ни бизнес-аналитики, ни менеджеры не готовы к такому повороту дел. Менеджеры понимают, что так надо делать, но и их заносит в технические детали. С архитекторами другая проблема (из моего опыта) — они слишком технические ребята, им тяжело отделить бизнес проблемы от технических проблем. Потому каждая попытка внедрить такое решение скатывается сначала на web servic-ы, потом на недостатки XML, потом на то, что Microsoft не поддерживает транзакции для web-servic-ов. Господи!!! Какое мне дело до web-servic-ов или Microsoft??? SOA тут вообще ни причём!

СВ>P.S. Буквально недавно произошло, высказывание одного электронщика схемника: "У вас программистов все не так, и один — не один, а два, потому что есть еще ноль!"

Вот и я о том же. 1 — это 1. Это знают все. А программисты выпендриваются — в "Матрице" видишь ли 1 — это 2 и потому мы не можем выполнить ваш проект в срок, или автоматизировать ваш бизнес-процесс без написания кода (а ещё вчера Нио прыгнул с небоскрёба, упал и разбил себе нос, не повезло — не допрыгнул ).