Архитектура ИТ решений. Часть 2. Архитекторы

С предыдущей частью статьи можно ознакомиться, перейдя по ссылке

III ОПРЕДЕЛЕНИЕ ПОНЯТИЯ АРХИТЕКТОР

Врач может похоронить свою ошибку, архитектор – разве что обсадить стены плющом. Фрэнк Ллойд Райт.
Зачастую в ИТ отрасли, говоря об ИТ архитекторе, подразумевают продвинутого разработчика, способного самостоятельно спроектировать, а главное реализовать большую сложную систему. А иногда попросту полагают, что это следующая ступенька в профессиональной иерархии разработчиков. Например, начал молодой специалист свою карьеру разработчика, ему присвоили скромное, но почетное звание Junior. Он учится, развивается профессионально, растет над собой и коллегами, и ему, в качестве компенсации за труд и упорство, торжественно присваивается звание Middle. Но он неугомонный и дальше не останавливается в развитии, совершает ряд подвигов, самоотверженно взвалив на себя ответственность за принимаемые решения. Глядишь, и его уже удостаивают высочайшего звания Sinior. А дальше? А если он не желает почивать на лаврах успеха и хочет развиваться, ему что присвоят под звуки фанфар генеральское звание Архитектора? Так ли это? Специально ИТ архитекторов, насколько мне известно, не готовят в вузах. Чаще всего архитекторы получаются путем селекции из уже маститых специалистов в какой-либо ИТ области, «прокачивая» дополнительными знаниями до определенного уровня. Кстати существует профессиональный стандарт квалификационных требований системных архитекторов (5), на основании которых архитектору может быть присвоен один из шести квалификационных уровней. Будем использовать этот стандарт в ходе нашего рассмотрения темы, чтобы не упустить ничего важного в работе ИТ архитектора. ...Далее...

Архитектура ИТ решений. Часть 1. Архитектура предприятия

I ВСТУПЛЕНИЕ

Архитектура распределяет массы и объемы. Вдохновение превращает инертный камень в драму. Ле Корбюзье.
Недавно столкнулся со следующей ситуацией, одна крупная ИТ компания подбирала для себя архитектора, с целью доработки компьютерной платформы. Такая работа, естественно, требовала привлечения специалиста высокой квалификации. То есть разработчика ПО поименовали именно архитектором, рассчитывая заполучить помимо кодировщика, еще и профессионала, способного разобраться с чужими решениями, до проектировать их, на свое усмотрение принимать самостоятельные решения и т.п… Когда стали выяснять, а как же в организации вообще обстоит дело с архитектурой, обозначились следующие тенденции. Есть ряд высококвалифицированных разработчиков, позиционируемых как архитекторы. Помимо непосредственно создания кода, они выполняют проектирование различных технологических систем и задают вектор и горизонт их развития. Решения представлены ими в основном в виде текстовых описаний, разбавленных небольшим количеством схем, в основном производных от диаграмм компонентов. Каждый из архитекторов представляется уникальным и эксклюзивным носителем знаний, а по сути — является узким местом в процессе производства программных продуктов. Ведь на практике без его постоянных уточняющих консультаций, воспользоваться результатом евонной деятельности практически невозможно. Полная, логически выстроенная, структурированная картинка сложного решения есть лишь в его голове. ...Далее...

[Перевод] Проблемы эгоистов: дорожные пробки и парадокс Браеса

Строительство более широких дорог может ухудшить ситуацию с дорожным движением. Обычно этот контринтуитивный и контрпродуктивный результат объясняют следующим образом: чем больше дороги, тем более крупные торговые центры они привлекают, что в свою очередь привлекает больше автомобилей. Но это ещё не вся история. В 1960-х Дитрих Браес обнаружил теоретическую конфигурацию дорог, в которой строительство новой соединительной дороги может замедлить движение каждого, даже если количество машин остаётся постоянным. И наоборот, закрытие одной дороги в сети Браеса позволит всем добираться домой быстрее. Такое явление настолько странно, что заслуживает собственного определения — «Парадокс Браеса». Несколько лет назад Джоел Коэн сказал мне, что парадокс Браеса может стать хорошей темой для моей колонки в «Computing Science». Я засомневался. Опубликовано уже немало обсуждений этого парадокса, в том числе потрясающие статьи самого Коэна, а также книга Тима Рафгардена (обзор которой я написал для American Scientist). Я не считал, что смогу добавить что-то новое к дискуссии. Однако недавно я начал рассматривать задачу визуализации...Далее...

Терабит смерти. Министерство обороны США под угрозой кибератак



11 января 2018 года руководитель Агентства защиты информационных систем Министерства обороны США заявил, что в настоящее время глобальные сети Департамента обороны находятся под постоянной угрозой, кроме того заметно возрастает изощренность кибератак и усовершенствуются технологии нападений.

Генерал-лейтенант армии США, Алан Р. Линн, который помимо этого является командующим Штаба объединенных сил Агентства защиты информационных систем Министерства обороны США, рассказал о некоторых интересных и неожиданных открытиях, которые он отметил во время своей работы, начиная с назначения на этот пост в 2015 году.
Читать дальше →

Разбор доклада Ивана Круглова «Строим свой Service Mesh»

На каждой крупной регулярной конференции есть докладчики, которые приходят каждый год, рассказывают что-нибудь новое и всегда нравятся аудитории. Всегда быть в самом-самом топе для человека, который не занимается выступлениями профессионально, очень трудно (да и зачем), но всегда выдавать уверенно хороший материал — реально. Один из спикеров, сделавших несколько успешных докладов и на Highload++, и на РИТ++, — Иван Круглов из Booking.com. Несколько дней назад в блоге Онтико уже была статья о подготовке докладчиков, посвящённая больше подаче материала, а сегодня хотелось бы рассказать о другом аспекте подготовки, которым на РИТ++ и Highload++ я в основном и занимаюсь. Давайте на примере последнего выступления Ивана рассмотрим, что важно и над чем мы при подготовке конференции работаем с докладчиками в области содержания.
Слайды тут...Далее...

[recovery mode] Data Modeling Zone EU 2017

В самом начале нового рабочего года — несколько слов об одном из событий года прошедшего.

Введение

Data Modeling Zone — франшиза, которая объединяет конференции по вопросам построения логической архитектуры баз данных. Последние несколько лет проводилась в США и Европе, а в этом году впервые пройдет в Австралии. В 2017 году под брендом DMZ было организовано два форума, оба прошли осенью: 16—18 октября — в Хартфорде, США, а 23—25 октября — в немецком Дюссельдорфе. Мне довелось принять участие в роли слушателя в последней из них. В этой статье представлен краткий обзор презентаций, которые я увидел на конференции, и мои впечатления о ней в целом. Название конференции недвусмысленно намекает, что ключевой вопрос — разные аспекты построения модели данных. Большинство анонсированных тем связаны с хранилищами данных, но были и актуальные для любой информационной системы. Мои ожидания были противоречивыми: с одной стороны, в числе выступающих — признанные лидеры сообщества, с другой — обилие часовых презентаций, не предусматривающих глубокого рассмотрения вопросов. Основная программа была представлена пятью треками:
  • Foundational Data Modeling
  • Agile and Requirements
  • Big Data and Architecture
  • Hands-On and Case Studies
  • Advanced Data Modeling
каждый из которых был поделен на 11 временных слотов в течение двух дней. Временная нарезка у всех пяти треков была общая, что позволило комбинировать презентации из разных блоков.

1-й день

...Далее...

[Перевод] Управление техническим долгом

Екатерина Сазонова, переводчик-фрилансер и студентка «Нетологии», специально для блога перевела статью Carl Tashian о том, как продакт- и проджект-менеджерам справляться с техническим долгом.

image

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

On-Premise vs. Cloud IaaS — преимущества и недостатки

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

Предпроектный анализ

Сергей Нужненко darkboatman, ведущий системный аналитик SuperJob, делится опытом запуска IT-проектов с точки зрения аналитика.

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

Это пригодится представителям заказчика, системным, бизнес-аналитикам, менеджерам проектов, другим участвующим в запуске ИТ-проектов, итераций или спринтов.


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


Читать дальше →

Операции над конструкциями

Вступление

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


Последние посты