Системный архитектор: первый после Бога


    Источник


    "Правильно мыслить более ценно, чем многое знать"
    Джон Локк


    Системный архитектор – интересная и крайне важная профессия в современном мире, имеющая отношение отнюдь не только к миру ИТ. Как сегодня, так и в обозримом будущем системные архитекторы будут наиболее востребованным и весьма дефицитным ресурсом в любой быстро развивающейся отрасли. И обязательно в сфере системной интеграции. Причем по степени и качеству использования системных архитекторов можно судить по зрелости управления в организации. И по соответствующей оценке их труда тоже. Во многом именно поэтому в получении информации о профессии системного архитектора заинтересована значительная часть молодых специалистов, у которых все еще впереди. А что именно?


    Если вы считаете, что Создатель не был первым системным архитектором, то можете не читать дальше эту статью.


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


    О компетенциях


    Разумеется, инженеры обладают различными специализациями, навыками, кругозором, компетенциями и опытом. И если выстраивать из них пирамиду с учетом всего этого, то наверху окажутся сущности, именовавшиеся ранее главными конструкторами, но сегодня в разных организациях их чаще называют системными, иногда комплексными архитекторами, или бизнес-архитекторами, что по сути одно и то же. Но главное – это то, что под этими названиями понимают произносящие их люди. К примеру, в реальных проектах помимо бизнес-процессов встречается немало других проблем, которые надо решать комплексно или системно.


    Вокруг понятия «системный архитектор» существует много терминологической путаницы, более связанной с комплексом решаемых задач или личным кругозором тех, кто его употребляет. Поэтому сразу же следует отметить, что термин «системный» может происходить от двух понятий — собственно «система» и «системный подход», что в современном мире отнюдь далеко не одно и то же. Поэтому при любом разговоре о системных архитекторах (а это весьма важная тема для всех сегментов рынка) следует вначале уточнить, о каких именно архитекторах идет речь. Стоит, кстати, упомянуть, что точно такая же проблема возникает, когда люди начинают говорить об интернете, который на самом деле существует одновременно в трех ипостасях: как сеть сетей, как всемирная информационная база данных и как бизнес-площадка. Порой люди могут долго спорить и доказывать что-то до хрипоты, пока вдруг не выясняется, что обсуждаемые ими проблемы находятся в совершенно разных пулах и практически ортогональны. Небольшая иллюстрация сказанного приведена на Рис.1.



    Источник Рис.1. Ортогональная правда


    Отметим, что это наглядный пример всего лишь двух проекций истины. Сетевик видит Интернет как совокупность маршрутизаторов, соединённых каналами связи, и оконечных устройств, подключенных на «последней миле». Инфраструктурщик знает о наличии телекоммуникаций, но его существо отдаёт приоритет тому, на чём хранится передаваемый по сети контент и где он генерируется. Разработчики часто зашорены в рамках сред (разработка, тест, предпродажи, готовая продукция) и т.д. Системный архитектор же обязан видеть и понимать и всех вышеперечисленных персон, и пользователя, который листает ленту социальной сети, и бизнесмена, который владеет этой соцсетью, и ещё массу задействованных в процессе людей. В целом он обязан понимать, что кому и от кого нужно.


    Применительно к системным архитекторам указанные ипостаси имеют гораздо больше разновидностей. В самом простом случае «продвинутый» инженер является специалистом по конкретной системе и знает, что из нее можно построить и где ее можно применить. Да, его иногда называют системным архитектором, но он является настоящим «воином света» исключительно на своем поле. Этим полем может быть система/системы конкретного поставщика или же системы, которые производят многие поставщики, но со своими особенностями (например, системы коммутации или системы управления базами данных). В некоторых зарубежных компаниях таких специалистов называют «дипломированными инженерами», а у нас – ведущими инженерами.


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


    Система может представлять собой все что угодно от комплекса информационных систем до целых промышленных предприятий (промышленных групп), включая технологические и производственные процессы, логистику, бизнес-процессы, а также оборудование и здания. И если для ведущего инженера системой является, например, серверная ферма, объединённая в вычислительный комплекс средствами инфраструктурного ПО, то для системного архитектора систем – работающий комплекс, где такая ферма представляет собой небольшой агрегат. Например, крупный торговый центр, эксплуатируемый компанией, у которой оптимально укомплектован штат персонала (даже здесь архитектор участвует), подобрано оптимально соотношение собственного кадрового состава и подряда/аутсорса, спроектированы и внедрены все необходимый системы (информационные, парковочные, инженерные, системы безопасности…), разработан оптимальный план взаимодействия с арендаторами… Причем ИТ-инфраструктура тут занимает далеко не первое место по объёму задач, даже ИТ в целом, тут не самый ёмкий раздел. Иными словами, системный архитектор решает бизнес-задачу, а система для него – предприятие, организация, отрасль… со всеми процессами, людьми и механизмами.



    Источник


    Соответственно и междисциплинарный подход подразумевает работу отнюдь не только исключительно с инженерными специальностями, а вообще с любыми специальностями, которые будут необходимы для реализации той или иной системы (проекта). В частности, если взять всем известную госкорпорацию «Роскосмос», то в реализуемых ею проектах нетрудно увидеть место как для инженеров-механиков, инженеров-электронщиков и инженеров-строителей, так и для ракетчиков, баллистиков, криогенщиков, психологов, медиков, астрономов, связистов, программистов, финансистов, юристов и пр. и пр. И каждому проекту понадобятся системные архитекторы разных уровней. Как понять, что именно вам понадобится в конкретном проекте?


    Видеть суть проблемы


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


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


    Технологию прикладного системного анализа часто сравнивают с чемоданчиком слесаря, содержащим набор необходимых инструментов и приспособлений. Помимо инструментов в своей работе мастер использует знания, применяемые в определенной последовательности. Важная особенность прикладного системного анализа состоит в учете различия между проблемами осознанно формализованными (вплоть до построения математических моделей) и слабо структурированными, рыхлыми проблемами, излагаемыми в терминах разговорного или описательного профессионального языка, что, кстати, весьма характерно для немалого количества бизнес-заказчиков.


    К примеру, доводилось ли вам слышать слово «хотелки»? Вот довести «хотелки» до проекта без системного архитектора крайне сложно. Между заказчиком и исполнителем возникает пропасть. И если они очень сильно потянутся друг-к-другу, то возможно случится желаемое. Однако бывают ещё и «мычалки». Случай не клинический, но в реальной жизни бывает, когда заказчик толком не может объяснить, что ему нужно. У заказчика не то что не сформировавшиеся требования, у него даже «хотелки» не сформированы, у него просто проблема и он хочет, чтобы всё работало, но не знает, что для этого надо делать. В общем, опять нужен системный архитектор.



    Источник


    Итак, основной инструментарий системных архитекторов, как говорится, налицо, и теперь надо лишь научиться им пользоваться. Последнее, правда, обычно занимает целую жизнь, когда растут компетенции, «набивается рука» и неизбежно совершаются ошибки. Именно опираясь на свой опыт, знания и предыдущие ошибки (причем отнюдь не только свои), системный архитектор может научиться создавать что-то стоящее. Даже больше – системный архитектор просто обязан учиться не только на своих ошибках, но и на ошибках окружающих. Конечно, нельзя стать экспертом во всех отраслях или технологиях, но без способности накапливать и чужой опыт, как свой, системным архитектором не стать. А способность впитывать чужие знания и опыт имеют другой полезный выход – креативность. Посему системный архитектор – человек творческий и с изощрённым мышлением.


    Архитектурное многообразие


    Возвращаясь к иерархии архитекторов, заметим, что помимо уже рассмотренных выше специалистов по конкретным решениям конкретных производителей можно встретить архитекторов по конкретным технологиям и по сервисам, по безопасности и по приложениям, по конкретным направлениям или по какой-либо предметной области, по телекоммуникациям и по ИТ, по системам управления и по ПО, по ИТ- и по бизнес-процессам, по инфраструктуре и по интеграции, по технике и по функциональным решениям. Локально каждого из них могут даже называть системным архитектором, но это будет соответствовать истине только в случае, если кроме ниши, в которой работает данный архитектор, в проекте ничего больше нет. В противном случае кто-то другой должен будет находиться на вершине, с которой виден весь проект во всем разнообразии решаемых задач. Это и будет «настоящий» системный архитектор или же главный архитектор проекта. То есть специалист, обладающий множеством компетенций в разных областях с большим опытом реализации разных проектов. Причем не с точки зрения руководства ими, а именно разносторонней технической реализации.


    Очень часто в литературе (а еще чаще в интернете) системным архитектором называют архитектора программного обеспечения (очень часто это «тимлид», выросший в прикладного архитектора), что, конечно, верно и весьма уважаемо среди программистов. Но задолго до того, как к проекту приступят программисты, системные архитекторы более высокого порядка должны выстроить архитектуру всего проектного решения, декомпозировав его на составляющие с пониманием того, какие технические проблемы будут решены в каждой из них и какие будут между ними связи (и по какой части), какие информационные системы понадобятся, будут составлены спецификации, по которым начнет работать инженерный состав и руководитель проекта. Разумеется, для всего этого совсем недостаточно быть просто инженером, а уж тем более – просто руководителем проекта. Первому для начала надо приобрести большой опыт в самых разных областях проектного бытия, а вот из второго, увы, никакого системного архитектора не получится в принципе (он «заточен» на решение совсем других задач). Напротив, в процессе своей работы системный архитектор должен хорошо представлять работу руководителя проекта, которому он представляет, по сути, если не дорожную карту всего проекта, то, как минимум, ее черновик. Говоря другими словами, системный архитектор подставляет руководителю проекта свое плечо. И в такой связке у них все получится.


    Когда требуется системный архитектор?


    В практической деятельности очень часто возникает вопрос: а когда в проект необходимо привлекать системного архитектора и на каком этапе? На рис.2 изображено глобальное поле проектной деятельности с дифференциацией проектов по объемам поставки продукции и необходимых изыскательских, проектных и пр. работ (чем больше размер текста, тем больше и объем). Там же приведена условная «граница применимости» системных архитекторов, изображенная синим цветом. Соответственно есть проекты, требующие минимальных ресурсов, когда предусмотрена просто поставка оборудования, когда идет подготовка конкурса или когда весь проект может быть выполнен за счет стороннего подрядчика. И есть большие проекты, подразумевающие большой объем различных работ, включая строительство, значительные поставки оборудования и пр. И, конечно же, встречаются исключения из правил.



    Рис.2. Глобальное поле проектной деятельности исполнителя


    При появлении проекта важно сразу же оценить его сложность и комплексность. И если проект связан, например, с организацией ЛВС, установкой серверов и реализацией каких-либо виртуализированных функций, включая поддержку, которые можно без труда специфицировать уже на начальной стадии, то привлечение к такому проекту системного архитектора (а это, как правило, ресурс недешевый) будет неэффективным. В таких случаях возможно привлечение прикладных сетевых архитекторов, специалистов по виртуализации, но никак не комплексных системных архитекторов.


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


    В любом проекте, в реализации которого принимает участие системный архитектор, последний должен иметь всю картину происходящего на проекте и следить за соблюдением требований заказчика, чтобы предложенное решение им соответствовало (и это соответствие не «потерялось» в процессе реализации) по объему и установленным договором нормам качества. Именно системный архитектор первым понимает (а чаще определяет) последовательность проектирования и исполнения проекта и может не только контролировать, но и оптимизировать сроки исполнения проекта. Косвенно он может оптимизировать и стоимость проекта, поскольку вопрос оптимизации последней довольно часто возникает в процессе практически любого проектирования. Именно системный архитектор в первую очередь может указать, где можно сэкономить и что при этом получится со сроками, качеством и т.п.


    Если рассматривать проектную деятельность системного архитектора в целом, то он предлагает верхнеуровневое решение, декомпозированное по следующим задачам для проектировщиков:


    • соответствие решения (результата проекта) требованиям заказчика (решение бизнес-задачи заказчика);
    • декомпозиция работ между исполнителями (собственными и подрядными) и авторский надзор;
    • контроль работоспособности и качества решения в целом;
    • оптимизация стоимости решения.


    Важной стороной деятельности системного архитектора является участие в конкурсах (там время – деньги) где он присутствует больше своим интеллектом и опытом, чтобы оперативно подсказать, что точно получится, а что – нет, какие технические параметры реализуемы, какие требования и при каких условиях выполнимы и, главное, в какие примерно деньги можно уложиться.


    В изображенной на рис.3 «пирамиде» показана декомпозиция уровней задач комплексного проекта и приведено условное распределение обязанностей причастных к нему исполнителей. Как видно, в рамках системного подхода системный архитектор и руководитель проекта должны идти по ней «рука об руку».



    РП – руководитель проекта
    ГИП – главный инженер проекта
    Рис.3. Декомпозиция системных требований к комплексному проекту


    Разумеется, в общем случае каждый слой «пирамиды» предъявляет требования к лежащему ниже, что может создать иллюзию возможности несистемного подхода или принципиальной ненужности вообще каких-либо комплексных архитекторов. Мол, инженеры каждого слоя напишут технические требования для «нижерасположенных» коллег, и все само собой образуется. Все было бы так просто, если бы не заказчик, который зачастую отнюдь не ограничивается требованиями к бизнес-процессам, а хочет (именно хочет!) иметь определенную ИКТ-инфраструктуру, конкретную вентиляцию и кондиционирование (к примеру, в ЦОДе обязательно надо уметь управлять отдельными кондиционерами), прозрачные лифты на стене здания, а также и само здание. Впрочем, хорошо, когда сам клиент прямо заявит о своих пожеланиях. А ведь они могут присутствовать в неявном виде, что обязан распознать и перевести в понятные технические требования именно системный архитектор, имеющий в голове всю картину целиком.



    Источник


    Кстати, то же здание вполне может определяться бизнес-требованиями. Скажем, инвестиционный банк логично разместить в центре Москвы (где есть масса проблем с коммуникациями и пр.), а не где-нибудь в спальном районе (даже если оно там раз в 10 дешевле), что скорее всего и предложат инженеры (и со своей инженерной стороны будут правы). Отдельная «песня» – требования к безопасности, многочисленные угрозы которой множатся на глазах, и компетенции клиента по этой части также непрерывно увеличиваются. Поэтому возникающие на типовом проекте реальные требования целесообразно рассматривать так, как изображено на рис.4, и разрешить их все можно только в рамках системного подхода.



    Рис.4. Разнообразие требований в типовом проекте


    Возвращаясь к рис.3, следует уточнить, что при отсутствии особых пожеланий заказчика насчет стройки и обустройства инженерных систем с их созданием вполне может справиться главный инженер проекта без привлечения системного архитектора.


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


    Enterprise-архитектор


    Его еще называют корпоративным архитектором, который является «альтер эго» системного архитектора компании-исполнителя, но со стороны компании-заказчика проекта.


    В самом деле, кто-то «с той стороны» должен хорошо понимать, как исполняется заказанный проект, а также знать архитектуру всех систем собственной компании, вписывать в нее новые фрагменты, не говоря уже о перманентной корпоративной модернизации. В оптимальном случае в процессе выполнения проекта системный архитектор и enterprise-архитектор должны тесным образом взаимодействовать.


    И что в итоге?


    В настоящее время есть большая путаница с глоссарием, который по части архитекторов у всех разный. Кроме того, в принадлежности к престижной профессии всегда есть момент тщеславия, и зачастую люди стремятся называться архитекторами, дабы привлечь к себе больший почёт. При этом сия путаница реально осложняет поиск архитекторов (а это весьма дефицитная специальность) сотрудникам кадровых служб и ими же создаётся хаос, когда публикуются описания вакансий.


    Стоит ещё раз повторить, что системный архитектор тоже работает с системой, но для него система – это работающий бизнес, работающее предприятие, работающий сервис. Даже если системный архитектор выполняет проект по разработке некой информационной системы, он прорабатывает не просто саму систему, а результат работы системы. Он решает бизнес-задачу, используя технологии и меняя процессы, а не строит систему из ПО и «железа». Разница тут примерно такая же, как между «построить железную дорогу и пустить поезда между двумя населёнными пунктами» и «обеспечить железнодорожное сообщение между двумя населёнными пунктами». Многие поймут задачу, как построить дорогу и пустить поезда, некоторые продвинутся дальше, и лишь системный архитектор задумается о том, чтобы оценить пассажиропоток, продумать расписание, размер и типы составов, типы и размеры станций и остановочных пунктов, количество билетных касс, способы и контроль оплаты, обеспечение льготного проезда, возможность/необходимость перевозки грузов по этой линии, предусмотреть регламентные работы для составов и ж/д путей, безопасности объектов в соответствии с требованиями ГО и ЧС и доступность для инвалидов… Чувствуете разницу?


    Очевидно, приведенной выше информации достаточно, чтобы уточнить, кто такие и чем должны обладать системные архитекторы, а также, чтобы понять и оценить роль системных архитекторов на всем пути проектной деятельности от экспертизы до реализации. Соответственно вышесказанное должно учитываться и при осуществлении разнообразной управленческой деятельности. Ведь об ее эффективности судят, в том числе, по уровню и степени использования института системных архитекторов.


    Впрочем, как бы ни развивалось сообщество системных архитекторов, кое-что ему пока недоступно. Взять хотя бы известный проект, который Создатель сумел эффективно реализовать всего за 7 дней. Вот это возможности, вот это компетенции! Есть чему учиться и куда стремиться, чтобы быть где-то рядом. Правда, на это иногда уходит целая жизнь, но такова уж профессия. И неудивительно, что «редкая птица» из системных (комплексных) архитекторов бывает моложе 30 лет. Что делать, чтобы стать ей?


    Учиться, учиться и еще раз учиться!


    Статья опубликована на портале ИКС.
    Авторы публикации:
    Голышко А.В. – системный аналитик ГК «Техносерв»
    Грунин А.В. – начальник управления системных решений ГК «Техносерв»
    Гужвенко Д.Б. – системный архитектор ГК «Техносерв»
    Техносерв 112,34
    Компания
    Поделиться публикацией
    Комментарии 30
    • +1
      Если вы считаете, что Создатель не был первым системным архитектором, то можете не читать дальше эту статью.

      Создатель исполнял все роли одновременно — и заказчика, и разработчика, и аналитика, и архитектора, и тестировщика. Просто некому было перепоручить.
      • 0
        Это, к сожалению, нам неведомо.
        Может, и у Создателей существует своя иерархия: Создатель-заказчик, Создатель-аналитик, Создатель-разработчик. Ну а сейчас голова болит у Создателя-тестировщика.
        • 0
          Нет, у поддержки, ибо в проме.
          • 0
            У нас тут такая компания на планете — устанешь поддерживать
            • +2
              На этот вопрос есть много теорий, и часть из них утверждает, что мы сняты с поддержки. В причинах расходятся — то ли за просрочку платежей, то ли за нарушение лицензии (реинжинеринг кода), то ли за нарушение этики в общении с разработчиком.
              • 0
                Думается, что из-за последнего в первую очередь.
            • +1
              Да нет. Тут уж не одна тыща лет сплошная тестировка и мочилово.
              • 0
                Есть такое дело, но, похоже, Создатель пока еще не разочаровался и не отформатировал планету.
        • 0
          Учиться — это прекрасно) а где учиться или у кого? какие-то практические советы\курсы\книги? чтобы был хотя бы теоретический задел.
          • 0
            Могу порекомендовать www.iasaglobal.org
            У них есть курс и книга и сертификация. Они как раз пытаются определить профессию архитектора более-менее конкретно.
          • 0
            Можно порекомендовать книги по системному анализу.
            Но теория — только часть компетенций. Нужен опыт.
            Причем полезен опыт работы не только архитектором.
            А что касается системных архитекторов, то они вырастают из таких же архитекторов, но с более узкой специализацией.
            • 0
              Книг много, особенно на английском. Начать можно с книги Левенчука «Системно-инженерное мышление», бесплатно скачивается на его сайте.
              Я лично сейчас пишу тезис в Германии на тему «Энтерпрайз архитектуры» (или архитектуры предприятий), как раз рассматриваю и основы системного мышления-подхода и архитектуру в разных областях деятельности человека и тд. и тп. Сотни книг-статей на английском находятся на ура, как раз создаю базу литературы.
            • 0
              Всегда был уверен, что инженеры не решают технические задачи (на то есть техники), а решают бизнес-задачи инженерными методами. У архитекторов же лишь более широкий инструментарий, в частности административные («просто запретим делать это») и экономические («мы не будем это делать сами, а купим/закажем»). Собственно различия основные в полномочиях — инженер может предлагать бизнесу не инженерные методы решения бизнес-задач, а архитектор либо должен их предлагать, либо сам их принимает.

              Где-то я не прав?
              • 0
                Во-первых, все они, включая архитекторов, изначально — инженеры. Просто с разной специализацией и компетенциями.
                Во-вторых, техники — это исполнители того, что им скажут инженеры.
                В-третьих, системный архитектор работает с бизнесом/системой/объектом заказчика, декомпозируя его на технические составляющие (в каждой из них в зависимости от задачи может быть свой архитектор или же инженер) и говорит, «как это можно/нужно сделать». Инженер же решает узкую задачу в рамках своей инженерной компетенции, но ничто не мешает ему предложить то или иное решение своему архитектору (работающему на данном уровне).
                В общем, как правило, инженер может что-то предлагать бизнесу, если он — системный (комплексный) архитектор.
                А просто инженер — вряд ли. Ведь бизнесу интересно решение сразу всего комплекса задач, а не какое-то одно направление.
                • 0

                  По сути получается, что архитектор — это лишь ступенька(и) в инженерной иерархии компании. Грубо, если в компании один инженер, то он и архитектором является, больше у бизнеса "переводчика" с его языка на технический нет. Пять инженеров, один из которых участвует в решении практически всех бизнес-задач, хоть как-то относящихся к инженерной деятельности (по мнению бизнеса, прежде всего) на лидерской позиции — четыре инженера и архитектор. И так далее.

                  • 0
                    Допустим, у вас в компании 20 менеджеров и один инженер.
                    Вопрос на засыпку: кто будет реализовывать проект в соответствии с полученным ТЗ?

                    Архитекторы нужны и важны всякие. Но, прежде всего, все они — инженеры (софтверные, «железные», «облачные», инфраструктурные и пр.). И кто-то из них должен видеть сверху всю картину, чтобы в конце концов собрать пазл.
                    • 0

                      Более интересный вопрос, кто будет составлять это ТЗ :)

                      • 0
                        По идее — заказчик.
                        Но практически — опять же инженер.
                        • 0
                          Помощь заказчику в превращении хотелок и мычалок в ТЗ должен оказать системный архитектор.
              • 0
                Надеюсь, вариант «Создатель не был» входит в вариант «Создатель не был первым системным архитектором».
                • +1
                  Вы правы, если вы — Создатель
                  • 0
                    Из этого следует что я — Создатель (в другом топике пришёл к такому же выводу).
                • 0
                  Примите наши глубочайшие поздравления!!!

                  Желания исполняете?
                  • 0
                    Когда вырасту, хочу стать системным архитектором
                • +1
                  В разделе «О компетенциях» написано: «выстаивать из них пирамиду». Наверное имелось в виду «выстраивать» буква «р» пропущена.
                  • 0
                    Вы правы. Спасибо!

                    Впрочем, похоже, «выстаивать» по отношению к строительству пирамиды — не такое уж неправильное слово. Может, и приживется новое слово.
                    Все лучше, чем какая-нибудь «жесть».
                    • 0
                      Ошибку поправили.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое