Если «общение — король», то ясность и лидерство — его верные слуги.
Марк Ричардс (Mark Richards) — директор и ведущий архитектор в фирме Collaborative Consulting, LLC, где он занимается разработкой архитектуры и проектированием крупномасштабных сервис-ориентированных решений на базе J2EE и других технологий главным образом в области финансовых операций. Работает в программной отрасли с 1984 года, обладает значительным опытом проектирования и разработки на J2EE, объектно-ориентированного проектирования и разработки, а также опытом системной интеграции.
Производительность приложения определяется его архитектуройРэнди Стаффорд
Производительность приложения определяется его архитектурой. На первый взгляд кажется, что это утверждение должно быть очевидным, но опыт реальной работы показывает обратное. Например, архитекторы программного обеспечения нередко полагают, что проблемы с производительностью приложения можно решить простым переходом на программную инфраструктуру от другого производителя. Источником этой веры может быть рекламная шумиха вокруг результатов тестирования — например, заявляется, что продукт фирмы-лидера на 25 % превосходит по производительности ближайшего конкурента. Однако если продукт-лидер выполняет операцию за 3 миллисекунды, а конкурирующий продукт — за 4 миллисекунды, заявленные 25 % (одна миллисекунда) значат очень мало на фоне общей низкой производительности, уходящей корнями в неэффективность архитектуры.
Помимо ИТ-менеджеров и команд тестирования производительности есть и другие группы людей, например служба поддержки фирмы-разработчика и авторы книг по управлению производительностью приложений, которые рекомендуют заняться тонкой настройкой инфраструктуры приложения: поиграть с операциями выделения памяти, размерами пулов подключений, размерами пулов потоков и так далее. Но если приложение спроектировано недостаточно эффективно для ожидаемой нагрузки или его функциональная архитектура нерационально использует вычислительные ресурсы, то никакая тонкая настройка не обеспечит желаемого быстродействия и масштабируемости. Потребуется полное перепроектирование внутренней логики и/или стратегии развертывания.
В конечном счете за фасадом продукта любого производителя и архитектуры любого приложения действуют одни и те же фундаментальные принципы распределенной обработки данных и физические закономерности: приложения и используемые ими продукты выполняются как процессы на компьютерах ограниченной мощности, взаимодействуя друг с другом через стеки протоколов и каналы связи с ненулевыми задержками. А значит, людям следует понять и принять мысль о том, что архитектура приложения является главным фактором, определяющим его производительность и масштабируемость. Эти качественные характеристики невозможно улучшить как по волшебству — чудодейственной сменой технологий или тонкой настройкой инфраструктуры. Любые усовершенствования в этих областях требуют упорного труда по тщательной проработке архитектуры.
Рэнди Стаффорд (Randy Stafford) — профессионал, в области создания программного обеспечения, обладающий 20-летним опытом работы в качестве разработчика, аналитика, архитектора, менеджера, консультанта и автора/лектора. В настоящее время занимается разработкой промежуточного (middleware) программного обеспечения в составе группы А-Team фирмы Oracle, а также участвует в концептуальных проектах, занимается оценкой архитектуры и помогает устранять кризисы производства различным организациям во всем мире. Основные области его специализации — сервис-ориентированные архитектуры, производительность, высокая доступность и JEE/ORM.
Ищите истинный смысл требованийЭйнар Ландре
Заказчики и конечные пользователи часто под видом требования выдвигают то, что им кажется эффективным решением некоторой задачи. Классический пример такого рода приводит Гарри Хиллейкер (Harry Hillaker), ведущий конструктор истребителя F-16 Falcon. Перед его группой была поставлена цель спроектировать самолет, развивающий скорость М2-2,5, что было (и вероятно, остается) весьма нетривиальной задачей, особенно если сопутствующая цель состоит в создании «дешевого» легкого самолета. Учтите, что сила, необходимая для преодоления сопротивления воздуха, при удвоении скорости полета возрастает вчетверо, и представьте себе, как это обстоятельство влияет на вес самолета.
Когда конструкторская группа спросила заказчиков из ВВС, зачем им нужна скорость М2-2,5, те ответили: «Чтобы самолет мог при необходимости выйти из боя». Когда настоящая потребность стала очевидной, конструкторы смогли решить главную проблему и представить работоспособное решение: подвижный самолет с высокой тяговооруженностью, обеспечивающей хорошее ускорение и маневренность вместо высокой максимальной скорости.
Выводы из этого урока в равной степени справедливы и в области разработки программного обеспечения. Узнав у заказчика истинный смысл запрашиваемой возможности или требования, архитектор сможет проникнуть в суть проблемы и, если повезет, предложить решение более качественное и экономичное по сравнению с тем, на котором настаивает клиент. Повышенное внимание к сути требований упрощает и расстановку приоритетов: самые значимые для заказчика требования становятся определяющими.
Как же следует действовать? В манифесте гибкой (agile) разработки есть принцип, который ко многим случаям подходит очень хорошо: «Сотрудничество важнее контракта». С практической точки зрения это подразумевает проведение семинаров и встреч, на которых архитекторы анализируют потребности заказчика, помогая ему ответить на вопрос «Почему?». Учтите, что поиск ответа на этот вопрос может оказаться весьма непростой задачей, потому что в процессе анализа требований речь зачастую идет о неявных допущениях и подразумеваемых знаниях. На таких встречах следует избегать дискуссий по поводу технических решений, потому что они переводят обсуждение из предметной области заказчика в область программирования.
Эйнар Ландре (Einar Landre) — профессионал в области программного обеспечения с 25-летним опытом работы в качестве разработчика, архитектора, менеджера, консультанта и автора/лектора. В настоящее время работает в группе коммерческих приложений фирмы StatoilHydro, где занимается разработкой приложений, критических для бизнеса, оценкой архитектуры и оптимизацией процессов разработки. Основные сферы его интересов — сервис-ориентированные архитектуры, проектирование на основе предметной области (domain-driven design), применение мультиагентов и проектирование интенсивно используемых крупномасштабных сетевых систем.
Встаньте!Уди Дахан
Для многих из нас карьера архитектора начиналась с какой-либо чисто технической должности, где успех определялся в основном способностью общаться с компьютерами. Однако в роли архитектора нам приходится общаться главным образом с другими людьми. Обсуждаете ли вы с разработчиками преимущества того или иного шаблона или объясняете руководству плюсы и минусы покупки промежуточного программного обеспечения, залогом успеха являются ваши навыки общения.
Объективно измерить степень влияния архитектора на проект довольно сложно, но одно совершенно ясно: если разработчики постоянно игнорируют указания архитектора, а руководство не придает значения его рекомендациям, «правильность» действий архитектора никак не повлияет на развитие его карьеры. Опытные архитекторы понимают, что они должны «продвигать» свои идеи, а эта задача требует умения эффективно общаться.
На тему межличностного общения написано множество книг, но я хотел бы предложить вашему вниманию один простой и практичный прием, который радикально повысит эффективность вашего общения и соответственно упрочит ваш успех в роли архитектора. В какой бы ситуации вам ни приходилось объяснять свою позицию сразу нескольким слушателям, встаньте. Неважно, где вы при этом находитесь — на официальном анализе проекта системы или неформальном обсуждении пары диаграмм. Встаньте — особенно если все остальные сидят.
Когда вы встаете, окружающие автоматически начинают воспринимать вас как авторитетного и уверенного в себе человека. Вы становитесь центром внимания. Вас будут реже перебивать. Все это окажет существенное влияние на обсуждение независимо от того, будут приняты ваши рекомендации или нет.
Также следует отметить, что стоящий человек более интенсивно использует жестикуляцию и мимику. Если вы общаетесь с группой из 10 и более человек, вставание поможет установить зрительный контакт со всей аудиторией. Зрительный контакт, жестикуляция, мимика и другие визуальные элементы играют важную роль в общении. Кроме того, положение стоя изменяет тональность и громкость голоса, а также темп речи: вы начинаете говорить так, чтобы вас было слышно в большом помещении, делая паузы для выделения важных моментов. Все эти элементы вносят существенный вклад в эффективность общения.
Хотите повысить эффективность передачи своих идей в процессе общения более чем вдвое? Это очень просто: встаньте.
Уди Дахан (Udi Dahan) — Шаман от Программирования; его заслуги были признаны корпорацией Microsoft и в течение трех лет оценивались престижным званием «Наиболее ценного специалиста» (Most Valuable Professional) в области архитектуры решений. В качестве советника по коммуникационным технологиям Уди работает с компанией Microsoft над WCF, WF и Oslo. Он также участвует в работе консультативных комитетов Microsoft Software Factories Initiative и проекта Prism группы Patterns & Practices. Он оказывает консультации в области современных архитектур и обучает клиентов по всему миру. Его основной специальностью является проектирование сервис-ориентированных, масштабируемых и безопасных архитектур на базе платформы. NET.
Сбои неизбежныМайкл Найгард
Оборудование подвержено сбоям, поэтому мы вводим в наши системы избыточность. Она позволяет пережить отдельные сбои оборудования, но повышает вероятность того, что в любой момент времени в системе будет присутствовать хотя бы одна неисправность.