Обсуждение

Возможно при описании уже действующего бизнеса с использованием сервисов и процессов , разницы нет. Однако при проектировании разница в результате принципиальная, аналогично разнице при использовании top-down и bottom-up подходов ..

Я замечу, что даже в ISO 19760 (который будет 24748-2) прописывается подход middle-out как предпочтительный (то есть сочетающий черты и сверху-вниз, и снизу-вверх). Так что все ОК, ваше высказывание говорит только о том, что нужно одновременно удерживать при проектировании оба этих описания. Это полностью соответствует из ISO 42010, который говорит про необходимость иметь множество групп описаний, порождаемых множеством методов описаний, чтобы удовлетворить интересы разных заинтересованных сторон. Так что не "или" (с неминуемо разными результатами, тут я согласен), а "и" (несмотря на всю изоморфность, одновременно делать предметом проектирования нужно оба описания). Как я понимаю, именно в этом и фишка поста.

Невозможность разрыва бизнес-модели и проектирования бизнес-приложений, о которых постоянно твердят старперы вроде меня наконец-то была осознана и задокументирована свыше!!!!! Большего трюизма надо искать значительно дольше. А самое главное: какая замечательная возможность уволить половину из тех, кто делает одно и то же. Только остается вопрос: какую половину ведь они до сих пор лопочут одно и то же только на РАЗНЫХ языках. В качестве P.S.: Две половинки St. Andreas Fault of Business Application development brought closer people on both sides. Note to the inhabitants of the Valley: earthquakes will still happen because fault continues to move

Т.е. в идеале сервис должен быть элементарной работой (сабтаском)?

Нет. Сервис -- это выполнитель работы, а не работа.

Тогда я не понял, о каком изоморфизме речь :(

Должно быть соответствие 1:1 между бизнес-делами (tasks из организационных-процессов, а не айтишных процессов) и сервисами (как выполнителями этих работ). Но сами сервисы -- это не работы. В этом и есть изоморфизм (похожесть формы, а не совпадение).

Какой смысл тогда в проектировании сервисов однозначно соответствующих таскам? На пальцах можете маленький кейс разобрать? Не догоняю.

Напишите коммент авторам этой концепции, они разъяснят на кейсе. Я же замечу, что таски будут взяты не из голов айтишников (архитекторов информационной системы), а из голов организаторов работ (возможно при посредничестве бизнес-аналитиков, а не айтишников-архитекторов). А сервисы -- из голов айтишников. Этот момент и объявляется приниципиально важным, смычка между айтишниками и менеджерами: ведь архитектуру сервисов и архитектуру практик-процессов обычно на крупных предприятиях разрабатывают разные люди по разным принципам. А тут дается хинт, как это дело синхронизировать.

Спс. Хотя, честно говоря, вспоминаются ветряные мельницы: когда у нас внедряли ISO9*, менеджеров попросили описать бизнес-процессы - это было вполне ужастно: организаторы работ оказались не способны описать собственную деятельность, а то что было порождено в рез-те мномесячных иттераций смело можно выставлять в кунсткамере.