Comments 13
Вы ведь понимаете, что доступность для пользователя системы с облачным сервисом будет равна устойчивости машины, соединения, электроснабжения и только потом эти хвалёные 99.99999. Заказчика мало волнует то, что где-то в облаке всё работает, если конкретный человек в конкретном офисе не сможет этим воспользоваться. Так что объясните это хорошо своим коллегам (на пальцах, как у якудза), которые будут подписывать.
Объяснить это можно если у тебя доступ к гендиру. Если ты в цепочке ниже техдира на 2 ступеньки, то объяснить не возможно. Т.к. не в их интересах это объяснять и понимать. Они пользуются теми-же метриками. И наверх объявляют о том, что у них 4-е девятки и им за это KPI отмечается и выплаты идут. Им важно знание, что они могут найти виноватого и уволить. Виноватым назначить можно кого угодно, ниже в цепочке. Желательно упоротого, который умеет считать и постоянно говорит: «Какие 4-е девятки? Из за проблем с UPS и питанием простой в ЦОД в этом году уже 8 часов составил, а из за сбоя инфраструктуры из за многократного повторного сбоя питания при DRS, и повреждения ФС тысячи ВМ, простой 30% сервисов составил 72 часа.»
вам просто не довелось слушать запись звонка почтальона из деревеньки на Корсике в службу поддержи вашего продукта
Не злите Корсику
Да, если запустить, то будет больно.
Сходу в бой. Запустить кого, что? Аппендикс до воспаления? Ну ок.
Ну а пока, возрадуемся же выигранному конкурсу
Какой конкурс, кто выиграл, зачем? Ответы в предыдущих сериях?
Дальше до конца абзаца графоманство, на мой субьективный взгляд, из которого важна одна фраза — давайте читать контракт после выигрыша конкурса.
Следующие 2 абзаца я перечитывал раза 3, и осталось дохрена вопросов.
Обкаты и обсосы, откуда то вылезли первичный тест и аудит, к чему это, это на этапе выбора вендора было в предыдущей статье? Ну ок, теперь я знаю что были предыдущие статьи, а когда читал первый раз — к чему говорить об этом вот здесь и сейчас?
Обмануть аудиторов? Ну я не знаю, я вообще не понял кто даст аудитору читать сорцы какого нить среднекрупного аутсорсера, у которого сотни разных клиентов, с каждым свой NDA, уровень команд очень неровный(хотя и стараются выровнять) и так далее. Да и вообще зачем аудиторам код смотреть? Им нужно финансовые показатели и статистику по сделанным-зафейленным проектам в разных разрезах. Код? Серьезно?
Есть ли у компании продукты? Какие продукты, повторюсь мы про аутсорц или продуктовую разработку(если второе, то откуда взялся вендор селекшн и заказчики?).
Где то здесь я остановилися с вычитыванием и по диагонале просмотрел до конца. ФР/НФР есть и то хорошо. Удивили примеры со статистикой аптайма своего ноутбука(в сравнении с промышленными решениями).
Каг то так.
Какая то странная статья и совсем не то, как учили меня.
Всё наше дело — ИТ, имеет смысл не только внутри ИТ, как об этом написано в статье, но и во внешнем мире. И в первую очередь во внешнем мире.
И весь этот ИТ должен придать живому бизнесу новый функционал, о котором эти бизнесмены только мечтают и зачастую и не представляют себе что это такое им нужно.
Если вам поручают создать хорошо известный и понятный функционал — бегите, это лузеры бизнеса, они идут по объедкам чужих прибылей.
А в живом мире все наши матрицы, строки, ООП, оконные функции, классы и пр. пр. не существуют, это наши придумки и наши условности.
И это забота, задача и главный профессинализм наш, как правильно провести эту формализацию из реального мира в наши классы, модули, ИИ и пр.пр.
Например: бизнес должен отреагировать через 1 сек, вот так ему нужно, так у него в голове повернулось победить конкурентов, а ваше облако реагирует за 2 сек.
Так вот, если вы не выбросили облако, то грош вам и вашей системе цена. Она не нужна бизнесу. Даже если вы и уговорили его сотрудников согласиться на 5 сек.
Вот как то так учили — аксиомы предметной области + аксимы логики.
И нет и не было задачи подогнать свои знания под то, как выглядят для себя задачи бизнеса, в котором зачастую нужно много лет учиться, что бы хоть набор терминов понимать.
Когда корректно выбрали формализацию реальности, тогда да, статья самое в точку — классы аудировать и наличие формальной логики в бизнес схемах искать.
Но в основа статьи, на мой взгляд, оставляет вне рассуждений главный и основной смысл нашего дела — решать задачи реального мира.
Статья — четвёртый шаг из жизненого цикла архитектуры в энтерпайзе. Свои идеи решения бизнес-проблем вы выдвигали на пару шагов раньше.
Может и так, но лучше, на мой взгляд, проследить путь денег от образования прибыли в реальном мире и до своего кармана.
И выкинуть любой свой шаг препятствующий этому.
Но если Вы уговариваете заказчика на компромисс в его бизнесе, то Вы сами и сужаете этот путь денег в свой карман.
Вот собственно мое замечание в этом и состоит — нужно смотреть на задачу реального мира или её часть.
Архитектор редко уговаривает заказчика. Основные баталии внутри своей компании. И ещё одно немаловажное замечание — заказчик не посвящает вас в свои планы. В энтерпрайзе планирование идет декадами. Так что если сейчас вам кажется, что заказчику не нужен клауд, то это может быть лишь потому, что вам не показывают всей картины. Может у него через 5 лет уже совсем другая бизнес модель будет и куча сервисов в том же облаке. Солдат не всегда может понять замыслы командования. Тем более вражеского командования.
Так что при возникновении ситуации типа «семь перпендикулярных красных линий, часть из которых синим цветом» настоящий профессионал рисует черную точку и методично выносит мозг недоговороспособным представителям бизнеса рассказом про многомерные измерения, неэвклидову геометрию с примерами из геометрии Лобачевского, проекции в точку и т.д. пока они таки не увидят эти свои линии в точке. PROFIT!
С договороспосбными — процесс выработки договора. Ну хочет бизнес «яблони цветущие на Марсе» — ок, 500 лет и хреннилиард долларов. В процессе пошаговых уступок — сводим все к плесени цветущей на МКС за три года и пару миллиардов. Миллиард заносим НАСА на программу биологических опытов с плесенью на МКС, фоточки цветущей плесени с подтверждающими документами от НАСА заносим заказчику. PROFIT!
Так что при решении задач реального мира — первая итерация это выловить противоречия хотелок заказчика и реальности. И сводить их к общему знаменателю, учитывая что изменение реальности — дороже изменения пожеланий заказчика.
Архитектура архитектуры. Шаг 4: воспалённый аппендикс