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

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

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

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

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

I ВСТУПЛЕНИЕ

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

Две компетенции аналитика

Введение


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

Дуальность


Часто можно слышать: этот объект одновременно обладает и свойствами такими-то и свойствами такими-то. Например, такое часто можно услышать про квантовую частицу. Якобы она обладает одновременно и свойствами волны, и свойствами частицы. В моей модели нет дуальностей. Как только появляется дуальность, это значит, что у нас есть либо две разные точки зрения на описание 4-Д объекта, или два разных метода.
Читать дальше →

Как мы расписание общественного транспорта в 2ГИС добавляли



2ГИС помогает ориентироваться в городе. Открываешь приложение, вводишь в поиск название улицы или организации, находишь, радуешься. После того, как нужная организация найдена, возникает резонный вопрос: как же туда добраться? И если автомобильным сценариям мы в последнее время уделяли значительное внимание, то поиск проезда на общественном транспорте оказался немного подзабыт. Я расскажу про то, как создавался поиск проезда, поделюсь тонкостями сбора и обработки информации.
Поехали!

Микросервисы для Java программистов. Практическое введение во фреймворки и контейнеры. (Часть 3)

Перевод книги Кристиана Посты (Christian Posta) Microservices for Java Developers. A Hands-On Introduction to Frameworks & Containers. Продолжение. Предыдущая публикация.

ГЛАВА 1. Микросервисы для Java программистов
(Продолжение)


Проектирование с учетом обязательств


В среде микросервисов с автономными командами и сервисами очень важно иметь в виду взаимоотношения между поставщиком и потребителем сервиса. Как автономная команда обслуживающая сервис, Вы не можете предъявлять какие-либо требования к другим командам и сервисам потому, что Вы не владеете ими, они автономны по определению. Всё, что Вы можете сделать — это выбрать, будете ли Вы принимать или не принимать их обязательства функциональности или поведения. А как поставщик сервиса для других, всё, что Вы можете сделать — это пообещать им определенное поведение. Они вольны в выборе — доверять Вам или нет. Модель теории обязательств впервые предложена Марком Берджессом (Mark Burgess) в 2004 году и описана в его книге «В поисках определенности» (In Search of Certainty, O’Reilly, 2015). Это исследование автономных систем включая человеческие и компьютерные, оказывающие услуги друг другу. Читать дальше →


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