НовостиСобытияКонференцииФорумыIT@Work
Документооборот/ECM:

Блог

Почему у нас нет "Дома ИТ-архитектора"?

Андрей Колесов
20.02.2012 23:27:58

Некоторое время назад я написал пост-вопрос: Архитектура СЭД: это актуально?. Судя по отсутствию каких бы то ни было ответов-комментарий на ту запись, можно сделать вывод – "нет". Во всяком случае – не очень.

Хотя обсуждение именно такой темы на следующий день на очередной встрече "СЭД – строим вместе" прошло довольно активно. Сначала там разработчики "ИнтерТраста" рассказали о своем архитектурном подходе к созданию новой версии своей CompanyMedia, а потом уже прошла общая дискуссия, в начале которой и были заданы такие вопросы:
Считаете ли вы проблему "Выбор архитектуры СЭД" актуальной? Должны ли бизнес-пользователи участвовать в решении вопроса о выборе? Нужно ли их посвящать в эту проблему?

Было высказано довольно много разных соображений, но вот на какой момент хотелось бы обратить внимание. Наверное, не случайно, организаторы для проведения этой мини-конференции выбрали московский Дом Архитектора.



Аналогия ИТ-проектов со строительными проектами вырисовывается довольно очевидным образом: когда архитектор нужен, а когда можно обойтись и без него. И что бывает, если архитектора забыли пригласить, когда он, все же, был нужен.

На вопрос "актуальны ли вопросы архитектруры в СЭД" был получен в целом очевидный ответ – "уровень актуальности зависит от сложности и значимости проекта, для сложных и значимых – да, конечно".

Вопрос "должен ли у таких проектов архитектор" тоже ответ быть, в основном, утвердительный.
А вот вопрос – "бывает ли он (архитектор) на практике?" – экспертное сообщество больше, кажется, склонялось к отрицательному ответу.

А я вспомнил по этому поводу время своей учебы в МИФИ, середина 1970-х. Наша специальность 608 только за четыре года до нашего выпуска стала называться "инженер-системотехник", а до того она именовалась "инженер-электрик" (есть много забавных историй, возникавших в отделах кадров, куда приходили выпускники). Честно говоря, в то время понятие "системотехник" тоже было еще "не устаканилось" (поэтому нас на всякий случай учили в основном "классическим предметам" – матан, дифуры, физика, термех, сопромат – "остальное выучите сами"), а тут еще на последних курсах появилось новой словцо – "архитектор".

И в какой-то зарубежной книжке или статье я еще тогда нашел очень точную характеристику этих ролей:

Архитектор занимает каждым своим проектов до конца жизни. Системотехника проект интересует только до подписания акта о приемке работы.

Комментариев: 10

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

Андрей Губанов
21.02.2012 06:32:55

Архитектор нужен тем, кто мыслит самостоятельно. А зачем нужен архитектор, если уже поработал Главный архитектор? http://www.peoples.ru/undertake/soft/gates/

21.02.2012 10:05:19

Т.е. во всем (в том числе в наших домашних проблемах) виноваты проклятые империалисты? ЦРУ и Билл Гейтс?
Удобная позиция, так проще заснуть - все причины проблемы очевидны!

21.02.2012 16:02:56

Вопросы архитектуры важны, но большинству это не очевидно.
Необходимость архитектора не всегда очевидна даже при традиционном строительстве, очень многие не умеют читать проектную документацию, понимать на уровне чертежей, куда ставить диван, а куда- холодильник. Мебель покупают, которая в кухню не влазит!
Когда же касается архитектуры информационной системы, понимания еще меньше. Все технические требования- это функциональные требования, в лучшем случае оговаривается количество пользователей и обрабатываемых документов. А вопросы архитектуры так и остаются - за границей внимания.
Многие случаи неудачного внедрения вполне удовлетворительных СЭД и ECM систем можно объяснить неудачной архитектурой- падает скорость доступа к информации, "висят" запросы. А причина- в неправильной архитектуре. Это похоже, как если бы под тяжестью танка рухнул деревянный мост, который строили для лошадей с телегами, а потом обвинили архитектора- не устоял!
И информационные системы "падают" при некотором критическом количестве процессов, определяемых количеством обращений и запущенных процессов обработки.
Насколько это понимают заказчики? Трудный вопрос.Исходный материал для анализа вроде бы есть. Я,например, готовлю в составе документации, сдаваемой заказчику, документы под названием "Техническая архитектура", "Программная архитектура" с описанием разработок, сделанных системными архитекторами индивидуально под конкретного заказчика.
Отдельный вопрос- как заказчику это оценивать. Я не знаю ни статей, ни книжек на тему типа "Методика оценки влияния архитектуры системы на конечные характеристики работы", это знание живет где-то среди инженеров на уровне неявно собранного опыта. Или я ошибаюсь, и кто-то умеет определять такие вещи- имею в виду специалистов заказчика, а не инженеров конкретной платформы.

Цитата
Архитектор занимает каждым своим проектов до конца жизни. Системотехника проект интересует только до подписания акта о приемке работы.

Не согласна. Когда идет многолетнее сотрудничество с клиентом, и система развивается и набирает обороты, приходится следить не только за текущим состоянием, а расширять и перестраивать, и думать о перспективах.


21.02.2012 16:41:35

Спасибо за подержку темы!
Я совершенно уверен в ее актуальности и искренне удивляюсь, что она почти не присутствует в наших СЭД/ECM дискуссиях.
Добаавлю еще один аспект, кроме масштабирования - обновление и сопровждений, переход \с версии на версию. И еще - необходимость понимания долгосрочной стратегии поставщика, включая вендора

Цитата
Не согласна. Когда идет многолетнее сотрудничество с клиентом, и система развивается и набирает обороты, приходится следить не только за текущим состоянием, а расширять и перестраивать, и думать о перспективах.


Приведенное определение - это аксиома!
И ваш случае говорит только о том, что вы выступаете в проекте в качестве архитектора, а не системотехника smile:)

Максим Смирнов
27.02.2012 23:40:26

Ольга, а вот заказчики считают, что архитекторы отсутствуют в среде поставщиков и разработчиков информационных систем smile:| Несколько комментариев на эту тему: Software product management С удовольствием расскажу подробнее на что в программном продукте смотрит архитектор со стороны заказчика. Мы в свое время даже предложили пятиуровневый градиент оценки архитектуры приложения с градациями от dark до clear

28.02.2012 00:13:29

Максим!

Спасибо, что поключились к разговору. Давайте попробуем продолжить тему. Предлагаю вам написать пост в этом блоге,

Максим Смирнов
28.02.2012 09:21:30

Андрей, я думаю сейчас время не рассуждать об архитектуре СЭД/ECM а менять её. Честно говоря, мне немного надоело писать визионерские посты о RESTful, NoSQL и ACM

Что касается ИТ архитектуры, так я собрал основные моменты в трехдневный тренинг. Пару раз проведу внутри нашей компании и затем выведу на рынок

28.02.2012 09:27:35

Давайте менять!
Но чтобы поменять, нужно показать - почему это нужно делать.

Я думаю, что трениниги и рассуждения (в том числе в блогах) можно вполне совмещать. Они не исключают, а дополняют друг друга. Так что - еще раз предлагаю делиться мыслями и тут, у нас. Это тоже не исключает, а дополняет записи на вашем персональном блоге smile:)

22.02.2012 23:38:39

1. Хотел бы утешить основного автора блога. Наличие или отсутствие Дома архитектора никак не связано с уровнем архитектурных достижений. Например, в Ленинграде Дом архитектора открылся в 1934 году, когда основные общепризнанные успехи этой музы в городе были уже позади.

2. Содержательный диалог с актуальным ИТ-архитектором, увы, невозможен. Разве что, если повезет, с бывшим архитектором, а так придется довольствоваться архитектурными критиками (разница тут приблизительно такая же как между музыкантом и музыковедом). ИТ-архитектор (не по должности, а по жизни) выражает себя в творческом акте – создании ПО, и в процессе творчества на диалог с публикой (тем более, с прессой) не идет. Творцы наиболее популярных ИТ-продуктов, уже упомянутый здесь Б.Гейтс и, допустим, С.Джобс, не опускались до дискуссий со своими пользователями по вопросам архитектуры или эстетики ПО. Писать книги (а это тоже, заметим, не диалог, а монолог) они стали уже после того как стали Гейтсом и Джобсом. Этот феномен меня всегда занимал – ПО сделанное в одностороннем порядке («я так вижу») имело значительно больший успех, чем продукция изготовленная в тесном контакте и при непосредственном участии пользователя/заказчика.

3. Не могу удержаться, чтобы не вспомнить парадокс не дававший мне покоя много лет назад. Почему, зайдя в обувной магазин в Европе, где я не живу и меня никто не знает, и запросы мои никто не изучает, я легко могу купить подходящие (именно мне) ботинки, а дома, в Советском Союзе, где все (от главного министра и дальше по инстанциям) только тем и озабочены, чтобы удовлетворить мои потребности, сносных ботинок не найти. Можно было даже написать письмо-требование председателю Совета Министров – почему невозможно купить нормальную обувь, и получить вполне уважительный ответ – мол, «Вы совершенно правы, будем над этим работать». И нельзя сказать, чтобы не работали. Работали. С известным результатом. Я это к тому, что благонамеренные разговоры с пользователем о том, чего бы ему хотелось – совершенно не гарантированный путь к успеху, иной раз, это шаг в прямо противоположном направлении. Так что я с нескрываемым волнением слежу за экспериментом «делаем СЭД вместе».

4. Правильная архитектура далеко не всегда приводит к эффективному результату. Многие правильно спроектированные системы работают медленно, именно потому, что отрабатывают функции последовательно, аккуратно передавая данные от одного логического слоя к другому. Такие системы удобно развивать и модифицировать, они могут отличаться завидной интероперабельностью и многоплатформенностью, но, если бы программист прямо залез в конкретную базу и сделал то что надо сделать, работало бы быстро (хоть и неправильно), а так работает правильно (радует архитектора), но смотреть на часики – слезы душат. Пример из мира ECM/СЭД – CMIS (в некоторых реализациях, про все говорить не буду).

5. С учетом сезона, сделаю еще вот какое замечание. Чтобы удачно выйти замуж и быть счастливой женой и матерью, женщине не нужно обязательно быть идеалом красоты «для всех». Существует множество неидеальных информационных систем, вполне уязвимых для чисто архитектурной критики, но вполне полезных и удовлетворительно работающих с точки зрения своих пользователей.

23.02.2012 09:19:34

1. Я не выражал горестных сожалению по поводу отсутствия, просто спросил "почему". Так что не очень понятно по поводу выражения "утешений".

> 4. Правильная архитектура далеко не всегда приводит к эффективному результату.
Мне этот тезис кажется очень странным. Как может быть архитектура правильной, если она не эффективна.
И мы столь же хорошо понимаем, что наличие архитектора совсем не означает, что архитектор является хорошим.

2. Пример Джобса - крайне неудачный. Он был бизнесменом и менеджером, но не ИТ-шником.


Александр!
Что вы хотите сказать? Есть кратко?

Что наличие Архитектора не гарантирует успеха? Да, конечно.
Что отсутствие Архитектора не означает неуспех? Да, конечно.
НО!
1. Наличие роли Архитектора и создание "эффективной (= правильной) Архитектуры - это не одной и то же
2 Архитектура ЕСТЬ ВСЕГДА! Пусть она даже реальзуется не интуитивно уровне человеком не умеющим писать и читать. Но вероятность создания Эффективной архитектуры с повышением сложности проекта существенно повышается с повышение уровня подготовки Архитектора.

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии