Чи врахували ви що можна зареєструвати кілька КВЕДів одночасно. І чи не врахувуєте ви тих самих людей кілька раз. В мене 3 штуки наприклад.

І в позі лотоса, щоб потім вийшов красивий відбиток.

На початку ніби йде мова про початківців, а потім «В любом случае заказчик теряет деньги, качество продукта страдает, а также зреет всеобщее недовольство. У проектного менеджера — рекрутерами, у команды — овертаймами, рекрутеры так вообще ненавидят всех — от техлида до кандидатов, которые каждый раз не подходят по критериям (ребята, без обид, но так оно и есть).» — якщо є якісь очікування стосовно продуктивності, то ми вже шукаємо мідла, а не джуна. Джуна ще 1-3 місяці треба буде бавити, що значить втрата продуктивності ще когось в команді і від людини навряд чи буде якийсь якісний результат.

Швидше за все SQL , тому що Azure і Power BI. Майкрософт незважаючи на існування в них Cosmos DB, Postgre SQL не вважає їх повноцінними БД і конектори Power BI працюють лише з варіаціями SQL Server. Припускаю що в ML схожа ситуація, ще не дивився туди.
Зараз з’явися Azure DataBricks, який дозволяє ганяти Spark і взагалі майже будь яке джерело всунути, але 20 ГБ — це не така велика БД і якщо SQL справляється , нащо гнатися за модним, якщо можна зекономити і по грошам і по часу розробки і обійтися тими інструментами що є.
Крім того якщо я правильно розумію, компанія зберігає ориганільні дані в SQL Server.

Мабуть тому що програють конкуренцію як традиційним службам так і Уберу.
Не знаю як стосовно Києва, але в Львові, час знаходження машини типово вдвічі-втричі довший, ніж Убер. Тому клієнти обирають або убер чи оптимальне чи 838, а далі смертельний цикл — нема клієнтів, нема таксистів.
Це не кажучи про дибільний інтерфейс спроектований мабуть тим самим вуйком що приборну панель літака проектував. І що головне цей інтерфейс не помінявся за 2 чи 3 роки. Відповідно навчити старше покоління користуватися ним просто немає шансів.

З димом не має проблем, якщо поставити вловлювач диму. Це ж ваше здоров’я. На моїй старій компанії , поки не поставили, монтажник постійно хворів на респіраторні захворювання.
www.astena.ru/mebel/system-250_1.jpg

informaze.wordpress.com ще можете почитати блог Інфодевів Елексу.

www.amazon.com/...​eywords=technical writing

Хороша Практика програмування Кернігана і Пайка. www.htbook.ru/...​raktika-programmirovaniya
В паралель можна проходити Прата
www.dut.edu.ua/...​loads/l_1061_59682868.pdf Мова програмування С++.
Коли досягнете певного рівня, можна взяти Йосатіса. Шаблони програмування С++.
Не рекомендую починати з Страуструпа. Він для початківця типово заскладний.
Якщо володійєте анлійською рекомендую дивитися на youtube відео про осучасний С++, бо ці книжки не встигають за розвитком стандарту і починаючи з С++ 14, стиль програмування суттєво покращився, багато речей можна робити зручніше.
www.youtube.com/watch?v=iWvcoIKSaoc
www.youtube.com/...​s?search_query=modern c+
Але тут питання ще й те що С++ — це не та мова з якої варто починати вчити програмування на мій погляд.

Бла-бла, бла. Саме тому мабуть з семи чи восьми кандидатів на Lead DevOps на попередній роботі у відповідь на питання як ви збиратесь організовувати процес розробки, топова відповідь була тадам: «Поставим Jira і будемо ассайнити тікети». Один, всього один, згадав що ще є Kanban, але суті не дуже розумів. Чи інший який такий супер-крутий, якійсь торговій організації з куою супер дорого заліза зробив високий SLA. Зате про те як маштабувати навантаження знав лише один рецепт на всі випадки життя HAProxy.
І організовувати міняти людей ви будете коли досягнете певного рівня, а до того часу поки ви Middle/Senior ви будете маєте слухати тих людей які це роблять краще і які очікують ваших навиків в fancy tool.

Тут немає суперечності. Іноді мені трапляються резюме в форматі
Дата 1 — Супер Проект — Компанія — ASP.NET MVC, JavaScript
Дата 2 — Супер Проект 2 — Компанія 2- C#, BrainFuck
і так дві сторінки. Що він робив на проектах, яка була його роль? Називається відгадай мелодію.
А стосовно коментаря Думанського, хочу побачити резюме не якусь топову позицію на 2 сторінки. В таких позиціях ціниться глибина і різноплановість досвіду. Це не черговий angular-розробник.

Показник що кандидат вміє протрати штани. Класична освіта грає роль виключно при відборі на Junior позиції і то лише за відсутністю інших критеріїв.
Один з кращих архітекторів, яких я знаю, закінчив консераторію і немає технічної освіти.

Минулого року не сплатив через вас штраф саме через те що ваш валідатор не пропускав номер. В мене був номер АР ХХХХХХ ваша програма і ще якась не дозволяла ввести такий тоді. Лише portmone/Ощадбанк прийняв.

І що заважає legacy-систему проеналізувати згідно методики і зрозуміти де ми знаходимось? Це якраз те що відрізняє лабухів який аби години відпрацювати від професіоналів. І дозволяє говорити з бізнесом однією мовою.
Більшість урядових систем в США, мінооборони розробляються згідно такого підходу. Я розробляв так і проблем не було.
Часто буває що вам више ролі простого виконавця не передбачено. Але це вже залежить від вашої здатності продавати себе і сейлів вашої компанії. Якщо ваш єдиний контакт лінійний менеджер останньої ланки то швидше за все ви мало що зміните.

Власне те що згадує автор покривається базовим курсом по Software Architecture, наприклад SEI Software Architecture: Principles and Practices www.sei.cmu.edu/training/p35.cfm
А архітектура рішень є підгалузю системної інженерії www.linkedin.com/...​re-vs-systems-engineering

alistair.cockburn.us/Hexagonal architecture
8thlight.com/...​e-clean-architecture.html

Щоб достягти такого підходу і ізолювати те що потрібне різним фреймворкам, а що вашому застосунку, колись кілька років тому мені дуже добре прочистив мізки підхід Mark Seesman по DI blog.ploeh.dk/2014/06/10/pure-di, хоча краще читати книжку. Коли ти чітко розмежовуєш сутності твоєї предметної області, сутності твого додатку і сутності фреймворку і через власний DI просто фізично не можеш використовувати те що дає DI фреймворку ти починаєш задумуватися як конструювати свій застосунок, що є твоєю предметною областю, а що є черговми фасадом до фрейморку щоб він просто працював.
До речі власне до Java цей підхід слабо дійшов, навіть google guice di занадто багато на себе бере. Spring DI — це взагалі просто набір антипатернів, він гарно виглядає лише в порівнянні з класичним Java EE.

Висновок швидше ви просто не вмієте його готувати.

Чесно кажучи стаття називається «як хреначити enterprise і при цьому нічорта не зрозуміти». Автор в розумінні підходів до розробки залишився максимум на senior engineer з зачатками application architecture. І кількість років тут нічого не дає. Ти можеш продовжувати винаходити велосипед з квадратними колесами, а можеш взяти підходи які вже в 90-х досить добре пророблені.
Якщо взяти рівень нижче solution architecture візьміть наприклад SEI ADD(Attribute-Driven Design) resources.sei.cmu.edu/...​set-view.cfm?assetid=8147 і дитячих питань не виникатиме.
Такі проблеми виникають коли починають спочатку ліпити щось як виходить, людьми які в принципі хороші розробники, але архітектурного мислення і розуміння немає, а потім згадують що це треба якось супроводжувати, інтегрувати.
ADD — починаює з виділення і формалізації потреб бізнесу в IT рішенні, виділяють які атрибути якості ми хочемо досягнути, сценарії використання цих атрибутів, а потім шукають кандидатів на архітектуру. В TOGAF схоже. Про конкретні рішення, технологічний стек, мови, фреймворки, бібліотеки розмова починається лише після достатньої деталізація і розуміння чого з точки зору бізнесу та зовнішньо видимих характеристик системи ми хочемо досягти.
Автор навіть не підозріває про цілий розділ науки який покриває цей напрям мабуть десятком методів від легких до дуже ентерпрайзних і складних. Дуже хороша серія вступу в професію є від Oreilly www.oreilly.com/...​ideo-training-series.html
Про інтеграцію є ціла біблія Enterprise Integration Patterns ще з 2004-го року, де можна прочитати що shared database — це швидше антипатерн. Ну і платформа Java має зо два десятки платформ для інтеграції починаючи від Apache Camel закінчуючи IBM WebSphere.
Було згадано про конференції де не розповідають, так для цього не треба їздити по конференціям для розробників. Архітекторських конф є значно менше вони суттєво дорожчі. Наприклад conferences.oreilly.com/...​ftware-architecture/sa-ny
На InfoQ дуже багато матеріалів.
От наприклад одна з кращих доповідей Simple Made Easy www.infoq.com/...​ntations/Simple-Made-Easy по загальним архітектурним принципам. Порівняйте з кашою в голові і статті автора.
Про комунікацію рекомендую прочитати закон Конвея, це те що згадують у вступі до більшості архітекторських книжок.

Це може бути й не вина автора, в Україні змогли дорости до розуміння що треба виховувати архітекторів в себе і що самі вони не виростуть мабуть до десяти компаній. Ще менше вміють і можуть продавати послуги архітектора. Без цього ви завжди матимете справу з наслідками чиїхось рішень.
А ще те що це enterprise рішення і в нього вкладено надцять мільйонів зелених не значить що рішення будуватимуть з використанням якогось цілісного підходу. «Кускова» автоматизація — це хвороба великих компаній в яких основний бізнес не айті(та й в айті теж). Якщо їм повезло і мають хорошого CIO чи CTO який курує цей напрямок, то буде якийсь порядок, якщо ні, будуть віддавати на зовнішній підряд фіксовані фрагменти без врахування як це рішення буде грати з рештою існуючих рішень та майбутніми потребами. Коли вартість супроводу такого рішення стане зашкалювати наймуть чуваків по оптимізації бізнес-процесів в костюмах з BCG, McKinsey, Accenture які зроблять це по підручнику, або скажуть звільнити всіх нахрін і купити готове рішення зкастомізоване під індустрію. Ті хто пише «кривавий ентерпрайз» від центру прийняття таких рішень зазвичай на дві-три сходинки нижче.

Стаття ні про що. Автор ознайомтесь з такою дисципліною як Enterprise Architecture та відповідальностями Enterprise Architect і не видумуйте своїх велосипедів з квадратними колесами.
На LinkedIn є два десятка статтей від Matthew Kern по Enterprise Architecture для чайників.
Якщо вже хочете так сильно enterprise по методології то TOGAF в зуби і вперед.
Хоча вам достатньо SEI Documenting Software Architecture. Тому що швидше за все вище рівня Solution Architecture вас не пустять.
Дві статті ні про що, змішались коні, люди, в купу. Проблеми рівня бібліотек, мов програмування, технологічних платформ, архітектурних підходів.

На стадіоні Чорноморець є офісні приміщення