Артем Воронов

Сейчас работаю над аналогичной задачей:
- сотни источников данных, на разных языках и в разных региональных форматах
- данные фрагментированы, разные атрибуты одной и той же записи приходят из разных источников
- встречаются опечатки и мусор в данных

Что попробовали, но работает не очень:
- собственный DSL. Слишком дорого в поддержке, онбоардинг разработчиков превращается в ад.
- Использование шаблонов и маппингов специфичных для каждого истончика с помощью специфичного софта типа Xceptor. Опять таки дорого в поддержке и недостаточно гибко.

Что работает хорошо:
- Разделение процесса на этапы, все по классике Data Science: очистка данных от мусора, стандартизация форматов и т.п. Это позволяет не дублировать одну и ту же логику в отдельном обработчике для каждого источника, а консолидировать правила в одном месте.
- Elastic для перевода, синонимов и обработки опечаток
- Кросс проверки с дополнительными источниками данных, где это возможно

Это вам в Airtable надо, там есть контроль доступа на уровне таблицы, листа или view.

У ASP.Net есть scaffolding, еще лет 8 назад собирал на нем базовые админки. Валидации задаются через атрибуты моделей.
Сейчас админки собираю за минуты в Retool, без гемороев с деплоями и быстрыми изменениями. У Mendix и OutSystems базовая автогенерация кода из моделей тоже есть.

Как показывает моя практика, если нужно сделать какие-то сложные расчеты, то без flow diagram что разработчки, что QA ничего не поймут и задача будет 100 перекидываться между ними. Однако для обычной рутины, которой 99%, ничего рисовать не нужно.

Pluralsight

С помощью PushSharp можно сделать свой API для рассылок уведомлений. По сути это обертка над стандартными FCM, APNS.

тут нет единственно верного решения. Условно протоколы можно разделить на 3 группы:
- json\soap\xml. Там уже все описано, даже мозг включать не надо;
- текстовые протоколы без описания структуры. Придется немного подумать, но весь текст у тебя перед глазами, выявить закономерности довольно просто. Записываешь, что настраивал на клиенте, смотришь как изменился запрос и ответ сервера. На крайняк декомпилируешь клиента и смотришь разбор протокола :)
- бинарные протоколы. Вот тут реально хардкор. Если не получиться декомпилировать код клиента, то можно зависнуть надолго. Нужно будет строить предположения о структуре данных, проводить огромное количество экспериментов. И если для простых протоколов это еще реально, то для сложных проще заплатить кому-то из разработчиков, чтобы слили структуру. Например, мы реверсили протокол автомобильных весов. Клиентской программы не было, за нее просили несколько сот тысяч рублей, больше чем стоимость весов. Но в течение пары дней подобрали структуру и успешно расшифровали протокол, интегрировали весы в систему. А вот с протоколом навигационного оборудования это не прокатило- слишком сложный протокол, очень много переменных. Оказалось дешевле закупать другие приборы с открытым протоколом.

Если внимательно почитать MSDN Split, то окажется, что в метод передается массив символов. Символы выделяеются одинарными ковычками. Что мешает передать в метод массив символов?
var num = str.Split(new [] {' ', ','});

Работа с потенциальными клиентами первична, только с ее помощью можно сделать продукт. Гуглите Customer Development.
А если сначала сделать какую-то хрень, а потом пытаться ее всем впарить - никакой продажник не поможет. И будет это выглядеть крайне убого.

Паника на пустом месте. Троелсон понятен? Тогда не парьтесь, изучайте дальше. Если нет, перейдите на Шилдта. Легкость материала субъективна, тем более на начальном уровне. Никто не мешает читать параллельно обе книги.

Ребята из Стратоплана сделали отличный курс о том как стать менеджером и развиваться дальше. И, конечно, в курсе они учат решать такие вопросы. Но нужно понимать, что конкретные действия зависят от множества факторов: от самой команды, от менеджера, от устоявшихся процессов в компании и еще много чего. Сейчас же ваши вопросы поставлены так, что однозначного ответить на них невозможно.

Смешались в кучу кони, люди.
WinForms - это уже устаревшее API для разработки UI на .Net.
WPF - современное API для того же дела.

Дайте что ли определение своему "быть перспективным", а то непонятно, что вы вообще хотите получить.
Как ни странно, но гугл в течение 0.05 секунды находит годную книгу по WPF.

Читать книги, статьи, блоги и пробовать, собирать грабли, анализировать результат, опять пробовать. Технологии нужны, чтобы решать задачи новым методом. И опять придется пробовать и набивать шишки.
Само по себе понимание архитектуры не придет.
Архитектор, не интересующийся новым технологиями - не архитектор.

Можно изучать все подряд языки, но какой в этом смысл? Практической пользы это архитектору не принесет, в отличие от умения собирать и анализировать требования.

Я прошу Вас помочь оценить эту идею, нужна ли она?

Идея не нужна. Потому что идея без реализации - ничто. А ведь на рынке уже +100500 реализованных подобных проектов.

Может у Вас есть какие-то предложения и замечания?

Посмотрели бы для начала ситуацию на рынке. Составьте хотя бы список существующих решений, изучите их. Можете сделать лучше, чем они?

На остальные вопросы отвечать смысла нет, так как вы не проработали свою идею.

DLL-injection и в путь, парсить память консольной проги.

Вариантом на самом деле очень много:
- если программа сетевая, то можно перехватывать трафик;
- если написана на Java - можно использовать accessibility;
- WinAPI;
- DLL Injection;
- и т.д.

Как сказал Владимир Мартьянов, без конкретики нельзя что либо порекомендовать.

Крутые программисты сами себя делают, а не вузы их.

Очень зависит от масштаба проекта. Где-то нужно больше технического опыта, где-то менеджерского.

А требования в общем такие:
1. Знать современные подходы к разработке архитектуры ПО и уметь их применять на практике.
2. Уметь собирать требования к продукту и валидировать их.
3. Уметь делегировать задачи и контролировать их исполнение.
4. Владеть управлением проектами. Как минимум знать, чем отличаются методолгии waterfall or scrum и понимать, в каких случаях какую методологию применять.
5. Базовые навыки HR тоже необходимы. CTO нужно уметь подбирать людей, с которыми будет комфортно работать и которые смогут выполнять поставленные задачи.

CTO, занимающийся непосредственно разработкой, уместен только в стартапе на ранних этапах. В иных случаях задача СТО - управление процессом разработки.