Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ИТ-архитектура: опыт преподавания

ИТ-архитектура: опыт преподавания

На следующей встрече клуба программистов нас ждут доклад и обсуждение. Во-первых, Евгений Погребняк и Дмитрий Лимашов
на материале прочитанных лекций расскажут, сложно ли обучать архитектуре, надо ли это студентам
(конечно, надо!) и для чего практикующим программистам важно разбираться в архитектурных вопросах.

В докладе Евгения и Дмитрия понятие архитектура даётся чуть шире, чем принято. Скажем, книга Роберта Мартина «Чистая архитектура» нужна для software architect. Помимо них, Евгений расскажет
о solution architect и enterprise architect.

Обычному программисту тема полезна с точки зрения профессионального самоопределения.

https://www.meetup.com/ru-RU/progmsk/events/262121156/

Evgeny Pogrebnyak

June 13, 2019
Tweet

More Decks by Evgeny Pogrebnyak

Other Decks in Programming

Transcript

  1. ИТ-архитектура: вопросы преподавания Московский клуб программистов 13 июня 2019 года

    Евгений Погребняк +7 910 4362724 Telegram: epoepo https://epogrebnyak.github.io/ Дмитрий Лимашов
  2. 1. О какой архитектуре идет речь? 2. Есть ли спрос

    на архитектуру предприятия (EA)? 3. Как мы преподавали и чего нам не хватает в классе
  3. О какой архитектуре идет речь?

  4. https://mxsmirnov.files.wordpress.com/2016/07/arch-roles.png

  5. TOGAF – известный метод описания архитектуры предприятия, 2003 год Ценное

    из TOGAF
  6. http://yowconference.com.au/slides/yow2017/Hohpe-EnterpriseArchitectureArchitectingTheEnterprise.pdf

  7. Есть ли спрос на архитектуру предприятия (EA)?

  8. Архитектура предприятия не нужна • Актуально только для очень больших

    компаний • Даже в них редко когда пригодится • с нуля • migration plan • Сложная область, нужно много опыта • Не приносит текущих (денежных) выгод Архитектура предприятия очень нужна • Высокая цена ошибки • Мало качественной экспертизы • Какая-то архитектура есть везде • Выгоды есть, но разные • Важно знать, что творится «этажом выше»
  9. Кейс «Цифровизация банка» и роль архитекутры

  10. 10 http://bit.ly/2K5im2T Есть кейс для трансфера технологий из России

  11. Почему банки не внедряют новые технологии? 11 https://www.pymnts.com/artificial-intelligence-study

  12. Example: Nubank (Brazil) domain model, greenfield http://bit.ly/2PePi7U While building this…

    12
  13. Try to avoid this https://en.wikipedia.org/wiki/Spaghetti_code https://2018.flatmap.no/talks/torreborre 13

  14. Архитектура влияет на UX 14

  15. Провалы • Кейс Hertz vs Accenture (http://bit.ly/2W6XPwl) • Кейс Dell

    https://www.youtube.com/watch?v=gfh-VCTwMw8&t=10s One of the primary reasons for these delays was Accenture’s difficulty in developing the “integration layer,” which allowed the customer-facing front- end code to communicate with Hertz’s back-end systems. "Бэкэнд настолько плох, что к нему ничего не прикручивается."
  16. Успехи • Реинжиниринг высоконагруженных сервисов (Netflix) • Примеры из банков,

    но проверить сложно • Using Event Driven Architecture to Transform Core Banking -- Matthew Lancaster - http://bit.ly/2OGoEEQ • How Do You Fit a Core Banking System Into a Few Containers? - Nordea & Accenture - http://bit.ly/2RdQObo • N26 , Monzo и т.д. • «Земные» примеры: • http://www.moscowpython.ru/meetup/57/monolith-microservices-love/
  17. Как мы преподавали «Введение в ИТ-архитектуру», лекции + кейс

  18. EA – сложная тема 18 http://bit.ly/2RaLe9Z

  19. План: 2-3 лекций в мае 2019 г. (по 1h20’) +

    опрос студентов 1. Введение: ИТ-системы современной компании. Связь ИТ-систем и бизнес- функций. Расходы на ИТ по отраслям и их структура. • Кейс «Анализ продуктового предложения Oracle, SAP, 1C.» 2. Уровни архитектуры: какие задачи решают «software architect», «solution architect», «enterprise architect». Типичные сценарии их работы. • Software architecture: как правильно структурировать программу (например, паттерны). • Solution architecture: как использовать ИТ-решения в отдельных бизнес-процессах. • EA: каким должен быть ландшафт и инфраструктура ИТ-систем предприятия. 3. Основная часть: данные и API. Проанализировать и описать требования к данным и API на примере условного предприятия (кейс «Бублики и валенки»). 4. Дополнительные темы. Связь ИТ-архитектуры и оргструктуры предприятия, закон Конвея. Работа над продуктом. Agile vs. Waterfall. DevOps. + Опрос: какие темы студенты хотят изучать углубленно и в чем практиковаться. Введение в ИТ-архитектуру
  20. Обоснование подхода • Для упрощения делим архитектуру на три уровня

    – software, solution и enterprise (Смирнов). • Как правило, студентам не хватает знаний и опыта, чтобы квалифицированно обсуждать ИТ-архитектуру предприятия. • Поэтому подходы к архитектуре предприятия даем обзорно – Zachman, TOGAF (фреймворки скучны без достаточного опыта обучающегося). • Выделяем два аспекта архитектуры – модель данных и API предприятия, и просим разработать их в произвольной форме для любого бизнеса или организации. Это основной учебный кейс.
  21. None
  22. https://www.youtube.com/watch?v=mS0AJLqmnvQ http://yowconference.com.au/slides/yow2017/Hohpe-EnterpriseArchitectureArchitectingTheEnterprise.pdf Gregor Hohpe

  23. https://mxsmirnov.files.wordpress.com/2016/07/arch-roles.png

  24. Конференция Ланит: видео и презентации Архитектура ИТ – Ланит https://habr.com/

    ru/company/lanit /blog/450196 Эдуард Галиаскаров, доцент, кафедра информационных технологий и цифровой экономики, Ивановский государственный химико- технологический университет Евгений Асламов, руководитель сектора архитектуры департамента корпоративных систем, ЛАНИТ.
  25. Продукт https://vimeo.com/user45919784

  26. Кейс: опишите архитектуру предприятия 1. Опишите цель работы выбранного предприятия.

    • Что и зачем оно делает? Для кого? • Какие проблемы своих клиентов оно решает? • Собирается ли стать лучше и как? 2. Какие данные предприятие будет использовать? • Какие будут таблицы - столбцы (переменные) и строки (новые объекты) • Откуда эти данные берутся? • Как используются? 3. Какие API должны быть у предприятия? • API = вызовы функций. • Вызовы предоставляют информацию или меняют значения хранимой информации • Кто будет пользоваться этими API? Какую задачу будет решать пользователь?
  27. Анализ работы над кейсом Техника: • Не хватает знаний по

    базам данных • API мне «сделает все» (лучше про партнеров, просто CRUD над основными таблицами) • Не хватает «опорной архитектуры» (клиенты, заказы, продукт, сотрудники, поставки) – простая ERP/CRM Бизнес: • Споры о внешней среде («как бывает по жизни»), а не о данных и их обработке • Нет бюджетов (во что обойдется) • Иногда - «девиантные» бизнесы (куда все равно придут клиенты – кальянные, вейпы)
  28. Чего нам не хватает в учебном процессе?

  29. Стандартные вещи: •Базы данных, SQL, ORM (python - `dataset`) •Написать

    свой API (хотя бы просто публичные методы) •Навыки DevOps (git+Travis, удаленная машина) Нестандартные вещи (нужна помощь!): •DDD или аналог для описания бизнеса •«Учебные» ERP/CRM , «учебный» интернет-магазин •Работа с сообщениями (MQ), но очень простое •Рисование схем и картинок •Словарь терминов «в противопоставлениях»
  30. Domain driven development (DDD) • Потребность из кейса: работать над

    частью функционала, а не над всем предприятием. • Общий подход: более изолированные, автономные подсистемы лучше поддерживаются Нужна помощь: • Есть ли «упрощенная DDD»? • А если не DDD – то как? • Читать Эванса или что-то еще? https://leanpub.com/ddd_first_15_years/c/dddeu
  31. Бывают ли «учебные» ERP-системы? • Odoo? • Пример MS Access

    Northwind? • Учебный интерне-магазин?
  32. Работа с сообщениями https://ndcoslo.com/workshop/practical-messaging/ Day 1: Messaging Architectures and Simple

    Patterns •Integration Styles •Why Prefer Messaging? •Decoupled Invocation •Work Queues •Messaging Systems •Pipes and Filters Architectures •Channels, Endpoints, Routers •Types of Messages •Command. Events, & Documents •Request-Reply •Channels •Point-to-Point •Publish-Subscribe •Data Type Channel •Invalid Message Channel •Dead Letter Channel •Endpoints •Polling Consumers •Event Driven Consumers •Competing Consumers •Service Activator Day 2: Distributed Systems Advanced Patterns •Routers •Content Based Router •Routing Slip •Process Manager •Management •Message Store •Control Bus •Reliability •CAP Theorem •Eventual Consistency •Guaranteed Delivery •At Least Once •Exactly Once •Durability & Persistence •Rabbit MQ Clusters •.NET Frameworks •Brighter •Mass Transit •NServiceBus •Message Oriented Middleware •Rabbit MQ •Redis •RDBMS •Kafka •SQS + SNS •Kinesis •Azure Service Bus Increasingly developers are relying on distributed architectures to solve the problems of scaling their applications and their development teams. But that means they now have to consider the problem of getting the parts of their systems to talk to each other. There will be hands on coding exercises in C#, JavaScript, and Python enabling you to implement simple and more complex messaging scenarios. Computer setup: We will use Rabbit MQ for examples. You need not have the latter installed on your machine, but if not you should have Docker installed on your machine, as the exercises provide Docker Compose files to run RMQ for use with the exercises.
  33. Рисование картинок https://twitter.com/simonbrown/status/1138036728307027968

  34. Словарь? http://bit.ly/2PkIw0u Лучше работает в противопоставлениях (например, ООП-ФП)