Архитектор решений (solution architect) работает с тремя группами специалистов:
1. С бизнес-аналитиками
2. С системными аналитиками
3. С разработчиками
Представьте, что вы клиент, живете в Москве или другом крупном городе и у вас есть проблема - вы слишком много времени тратите на перемещения. До метро, от метро, по району, в поликлинику и магазин, стоите в пробках и очередях, ходите по длиннющим переходам между станциями и спускаетесь на 24 этажа вниз по эскалатору. А потом еще поднимаетесь наверх. В результате в конце дня сил нет ничем заниматься - ни детьми, ни семьей ни образованием.
Вам нужно решение, вам нужен сервис быстрого передвижения потому что связка машина + общественный транспорт не справляется.
Анализом проблемной области заказчика занимаются бизнес-аналитики. В результате своей работы они выдают верхнеуровневое описание того, как должны выглядеть поездки после реализации проекта улучшения. Они описывают контекст проблемы - поездки по району, поездки между районами, поездки на работу в часы пик, поездки по выходным, поездки в плохую погоду и зимой. И говорят - нужен такой-то сервис. Чтобы было модно-стильно и молодежно, называют свою презентацию Urban Mobility Solutions и выдают технико-экономическое обоснование, где говорится, что решение не должно стоить дороже 40 т.р., обслуживание не должно быть дороже 2 т.р. в год, срок службы должен составлять минимум 42 месяца, а пользоваться решением вы должны не меньше, чем 230 дней в году.
И тут вступают в дело архитекторы. Они начинают искать как можно принципиально реализовать такие сервисы. И выясняют, что есть несколько принципиально подходящих классов решений:
- Велосипеды
- Ролики
- Скейты
- Самокаты
- Электросамокаты
- Моноколеса
- Гироскутеры
Так как вам надо ездить на работу, то ролики отпадают, смешно ехать в рубашке с галстуком на роликах по улице. Скейты отпадают по той же причине. Самокат не устраивает т.к. не годится для езды в горку и при езде на нем можно вспотеть, особенно летом. Гироскутеры заказчика не устраивают по внешнему виду, и остаются три альтернативы - велосипеды, электросамокаты и моноколеса. И начинается архитектурное проектирование.
Архитектор должен предложить какое-то решение, которое лучше всего подходит конкретной ситуации заказчика.
А после того, как заказчик согласится, поставить задачу на разработку конкретного воплощения согласованного решения. Для этого архитектор должен изучить и понять контекст проблемы заказчика и саму проблему.
Проблема архитектора в том, что бизнес-аналитики сказали заказчику, что ему нужны сервисы городской мобильности, и заказчик согласился. Но и велосипед и самокат и моноколесо реализуют один и тот же сервис - доставляют из точки А в точку Б на небольшие расстояния. В чем же между ними отличия, которые повлияют на архитектурный выбор?
Системное проектирование находится на зыбкой грани между разработкой совсем уж концептуальных схем транспортных средств и их конкретной технической реализацией. Например, если говорить предельно абстрактно, то функция велосипедов разбивается на две - удержание равновесия и движение вперед за счет кручения педалей. Равновесие удерживается в основном за счет подруливания. Самокат похож на велосипед, но тут не надо крутить педали, равновесие удерживается за счет как подруливания так и наклона вертикального корпуса. Как видим, и в том и в другом случае для езды нужны обе руки потому что есть руль.
Моноколесо - отдельный вид решения. Езда на нем - это постоянное падение корпусом вперед. Это очень похоже на то, как спутники на орбите летают, все время падая, но не падая (поэтому на орбите и есть невесомость, потому что все всё время падают). Но если корпус падает вперед, а ноги на платформе едут с такой же скоростью, как падает корпус, то получается равномерное контролируемое движение. В схеме моноколеса есть два принципиальных решения - гироскоп удерживает его в вертикальном положении, не дает заваливаться набок и вперед, и мотор удерживает скорость постоянной неважно едете вы в горку или под горку. В этом отличие моноколеса от велосипеда и самоката. Если ноги на платформе будут неожиданно ускоряться или замедляться, то контролируемое падение превратиться в неконтролируемое.
Выбор схемы движения и способа удержания равновесия и есть первое принципиальное решение, которое надо принять в проекте. Но как вовлечь в такое решение заказчика? Какое ему дело до всей этой физики-математики? И в дело вступают системные аналитики. Они начинают выяснять, а какие же конкретно сценарии для клиента открываются в случае реализации проекта по каждой из архитектур. Например, на самокате он уже умеет ездить, переучиваться не надо. Это существенный плюс в пользу такого решения. Зато на моноколесе свободны руки, можно звонить по телефону без гарнитуры, ездить по навигатору без держателя на руле, пить кофе на ходу. А на велосипеде можно переезжать бордюры. Все эти принципиальные характеристики решений можно свести в одну таблицу и представить заказчику, пусть решает.
И заказчик смотрит во вторую версию презентации Urban Mobility Solutions и принимает еще одно решение. Он хочет моноколесо. И за дело принимается уже вся команда - и бизнес-аналитики и системные аналитики и архитектор решения и руководитель проекта.
Они анализируют возможные варианты реализации моноколес, уточняют характеристики, цвет, емкость аккумуляторов, скорость зарядки, скорость, цену, особенности эксплуатации, вопросы провоза их на самолетах и поездок в час пик, вопросы техобслуживания и ремонта, прописывают конкретные сценарии езды и снимают обучающие ролики по хитростям и приемам.
Все для того, чтобы заказчик после покупки не просто получил сервис Urban Mobility, но и смог решать свои конкретные задачи в конкретных условиях, а не обнаруживал на своем горьком опыте, что попытка переехать через невысокий бордюр с горячим кофе может закончиться конфузом. Потому что решаемые системой цели и задачи - это не то же самое, что функции и сервисы. Приобрести техническое решение, его надо освоить и встроить в свои практики.
Это очень упрощенный взгляд на то, чем реально занимаются системные архитекторы в технологических проектах, но принципиально все именно так. Они строят мостик понимания, осознанного выбора от абстрактных верхнеуровневых схем и концепций к конкретным техническим решения, воплощенным в "железе" и коде.
1. С бизнес-аналитиками
2. С системными аналитиками
3. С разработчиками
Представьте, что вы клиент, живете в Москве или другом крупном городе и у вас есть проблема - вы слишком много времени тратите на перемещения. До метро, от метро, по району, в поликлинику и магазин, стоите в пробках и очередях, ходите по длиннющим переходам между станциями и спускаетесь на 24 этажа вниз по эскалатору. А потом еще поднимаетесь наверх. В результате в конце дня сил нет ничем заниматься - ни детьми, ни семьей ни образованием.
Вам нужно решение, вам нужен сервис быстрого передвижения потому что связка машина + общественный транспорт не справляется.
- Велосипеды
- Ролики
- Скейты
- Самокаты
- Электросамокаты
- Моноколеса
- Гироскутеры
Так как вам надо ездить на работу, то ролики отпадают, смешно ехать в рубашке с галстуком на роликах по улице. Скейты отпадают по той же причине. Самокат не устраивает т.к. не годится для езды в горку и при езде на нем можно вспотеть, особенно летом. Гироскутеры заказчика не устраивают по внешнему виду, и остаются три альтернативы - велосипеды, электросамокаты и моноколеса. И начинается архитектурное проектирование.
А после того, как заказчик согласится, поставить задачу на разработку конкретного воплощения согласованного решения. Для этого архитектор должен изучить и понять контекст проблемы заказчика и саму проблему.
Проблема архитектора в том, что бизнес-аналитики сказали заказчику, что ему нужны сервисы городской мобильности, и заказчик согласился. Но и велосипед и самокат и моноколесо реализуют один и тот же сервис - доставляют из точки А в точку Б на небольшие расстояния. В чем же между ними отличия, которые повлияют на архитектурный выбор?
Системное проектирование находится на зыбкой грани между разработкой совсем уж концептуальных схем транспортных средств и их конкретной технической реализацией. Например, если говорить предельно абстрактно, то функция велосипедов разбивается на две - удержание равновесия и движение вперед за счет кручения педалей. Равновесие удерживается в основном за счет подруливания. Самокат похож на велосипед, но тут не надо крутить педали, равновесие удерживается за счет как подруливания так и наклона вертикального корпуса. Как видим, и в том и в другом случае для езды нужны обе руки потому что есть руль.
Моноколесо - отдельный вид решения. Езда на нем - это постоянное падение корпусом вперед. Это очень похоже на то, как спутники на орбите летают, все время падая, но не падая (поэтому на орбите и есть невесомость, потому что все всё время падают). Но если корпус падает вперед, а ноги на платформе едут с такой же скоростью, как падает корпус, то получается равномерное контролируемое движение. В схеме моноколеса есть два принципиальных решения - гироскоп удерживает его в вертикальном положении, не дает заваливаться набок и вперед, и мотор удерживает скорость постоянной неважно едете вы в горку или под горку. В этом отличие моноколеса от велосипеда и самоката. Если ноги на платформе будут неожиданно ускоряться или замедляться, то контролируемое падение превратиться в неконтролируемое.
Выбор схемы движения и способа удержания равновесия и есть первое принципиальное решение, которое надо принять в проекте. Но как вовлечь в такое решение заказчика? Какое ему дело до всей этой физики-математики? И в дело вступают системные аналитики. Они начинают выяснять, а какие же конкретно сценарии для клиента открываются в случае реализации проекта по каждой из архитектур. Например, на самокате он уже умеет ездить, переучиваться не надо. Это существенный плюс в пользу такого решения. Зато на моноколесе свободны руки, можно звонить по телефону без гарнитуры, ездить по навигатору без держателя на руле, пить кофе на ходу. А на велосипеде можно переезжать бордюры. Все эти принципиальные характеристики решений можно свести в одну таблицу и представить заказчику, пусть решает.
И заказчик смотрит во вторую версию презентации Urban Mobility Solutions и принимает еще одно решение. Он хочет моноколесо. И за дело принимается уже вся команда - и бизнес-аналитики и системные аналитики и архитектор решения и руководитель проекта.
Все для того, чтобы заказчик после покупки не просто получил сервис Urban Mobility, но и смог решать свои конкретные задачи в конкретных условиях, а не обнаруживал на своем горьком опыте, что попытка переехать через невысокий бордюр с горячим кофе может закончиться конфузом. Потому что решаемые системой цели и задачи - это не то же самое, что функции и сервисы. Приобрести техническое решение, его надо освоить и встроить в свои практики.
Это очень упрощенный взгляд на то, чем реально занимаются системные архитекторы в технологических проектах, но принципиально все именно так. Они строят мостик понимания, осознанного выбора от абстрактных верхнеуровневых схем и концепций к конкретным техническим решения, воплощенным в "железе" и коде.
Комментариев нет:
Отправить комментарий