Есть три фундаментально разных способа описания объектов. Первый – это описание объекта как целого. В таком описании объект рассматривается как целое и неделимое. Например, «Самолет – это транспортное средство для перевозки грузов и пассажиров по воздуху». Второй способ описания – это описания объекта как конструкции. Такой метод описаний называется представление в виде композиции. Например, «Самолет – это конструкция из фюзеляжа, крыльев и двигателей». И третий способ – это описание объекта как агрегации других объектов. Например, «Песок, что лежит во дворе – это тот песок, что привезли вчера плюс тот, что привезли сегодня». Далее мы рассмотрим два из них, как наиболее востребованные: описание объекта как целого и описание объекта как композиции.
Data Access Layer как инструмент управления хранением данных
20 min
При проектировании полного жизненного цикла Enterprise-приложений большое значение приобретает вопрос организации их доступа к данным. Тому есть ряд причин:
Все это может привести к тому, что в какой-то момент предприятие захочет (или будет вынуждено) сменить технологию хранения данных либо начать использовать новые технологии одновременно с текущими. Однако если при проектировании автоматизированных систем их бизнес-логика не была отделена от работы с хранилищами данных, то смена инструмента хранения может привести к дорогостоящей и плохо управляемой миграции.
Проблему разделения бизнес-логики и работы с данными на уровне отдельного приложения решает широко известный и не раз описанный на «Хабрахабре» архитектурный шаблон Data Access Layer (DAL). Для того, чтобы этот шаблон можно было масштабировать до уровня всего предприятия, необходимо дополнить его рядом архитектурных принципов, которые рассматриваются в данной статье. Следование этим принципам позволит предприятию осуществлять контролируемую (управляемую) замену или добавлять технологии хранения данных в свою архитектуру ИТ.
- ценовые или иные политики поставщиков хранилищ данных регулярно меняются, но предприятия, использующие данные хранилища, не всегда согласны с этими изменениями;
- с ростом самого предприятия и масштабов его ИТ-инфраструктуры существующие решения по хранению данных могут перестать удовлетворять его потребностям или финансовым возможностям;
- технологии хранения данных развиваются, появляются новые средства, предназначенные для решения специализированных задач;
- в рамках проектов Open Source вырастают дешевые или даже бесплатные альтернативы дорогим коммерческим решениям.
Все это может привести к тому, что в какой-то момент предприятие захочет (или будет вынуждено) сменить технологию хранения данных либо начать использовать новые технологии одновременно с текущими. Однако если при проектировании автоматизированных систем их бизнес-логика не была отделена от работы с хранилищами данных, то смена инструмента хранения может привести к дорогостоящей и плохо управляемой миграции.
Проблему разделения бизнес-логики и работы с данными на уровне отдельного приложения решает широко известный и не раз описанный на «Хабрахабре» архитектурный шаблон Data Access Layer (DAL). Для того, чтобы этот шаблон можно было масштабировать до уровня всего предприятия, необходимо дополнить его рядом архитектурных принципов, которые рассматриваются в данной статье. Следование этим принципам позволит предприятию осуществлять контролируемую (управляемую) замену или добавлять технологии хранения данных в свою архитектуру ИТ.
Что такое архитектура предприятия, и почему Захман ошибся?
6 min
Вторая статья про мифологическое сознание тоже будет короткой. Сегодня я расскажу, к каким проблемам приводит мифологическое сознание при моделировании архитектуры предприятия.
Известная модель Захмана пытается ответить на вопрос, что такое архитектура предприятия, и рассказывает о том, как она должна моделироваться. Основой этой модели являются вопросы, на которые предлагается ответить: кто, когда, где, почему и как совершает что-то над чем-то. Кажется, что это логичный фреймворк для описания архитектуры предприятия, и многие думают, что так оно и есть.
Однако, даже беглый взгляд на этот фреймворк оставляет чувство неудовлетворенности, потому что не понятно, как ответить на вопрос: кто и почему выточил деталь? Кто: Иван Иванович, или токарь, роль которого исполнял Иван Иванович? Почему: потому что токарь получил задание, или потому что Иван Иванович заключил контракт, в соответствии с которым он обязуется выполнять роль токаря в обмен на еду? Почему: потому что Иван Иванович хочет покушать, или затем, что деталь нужна в сборочном цехе?
Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!
Известная модель Захмана пытается ответить на вопрос, что такое архитектура предприятия, и рассказывает о том, как она должна моделироваться. Основой этой модели являются вопросы, на которые предлагается ответить: кто, когда, где, почему и как совершает что-то над чем-то. Кажется, что это логичный фреймворк для описания архитектуры предприятия, и многие думают, что так оно и есть.
Однако, даже беглый взгляд на этот фреймворк оставляет чувство неудовлетворенности, потому что не понятно, как ответить на вопрос: кто и почему выточил деталь? Кто: Иван Иванович, или токарь, роль которого исполнял Иван Иванович? Почему: потому что токарь получил задание, или потому что Иван Иванович заключил контракт, в соответствии с которым он обязуется выполнять роль токаря в обмен на еду? Почему: потому что Иван Иванович хочет покушать, или затем, что деталь нужна в сборочном цехе?
Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!
Повышаем степень клиентоориентированности с помощью корпоративной архитектуры на основе TOGAF®
6 min
Translation
Область бизнес-архитектуры в рамках Enterprise Architecture (Архитектура предприятия) — это не только бизнес-возможности и бизнес-процессы. В первую очередь это касается оптимизации ценности (value) для ваших клиентов и усилий в построении организации, в большей степени ориентированной на них.
Методы архитектуры предприятия
13 min
В преддверии старта курса "Enterprise Architect" подготовили для вас текстовую версию демоурока, который провел эксперт OTUS - Петр Подымов.
В рамках урока поговорили:
- об обоснованных структурных изменениях в компании в быстро меняющихся условиях;
- о применении архитектурного подхода в вопросах трансформации;
- видели, что же такое архитектурный подход, для чего он нужен, чем обусловлено его применение.
Архитектура предприятия в гигантах индустрии
12 min
Архитектура предприятия — это дисциплина, которая фокусируется на проектировании и управлении системами, процессами и структурами организации. Она направлена на то, чтобы они соответствовали бизнес-целям и задачам и были эффективными, результативными и адаптируемыми.
IBM, Google, Microsoft, Meta и Amazon — крупные технологические компании, разработавшие собственные фреймворки и инструменты корпоративной архитектуры. Статья представляет обзор подходов к архитектуре предприятия, используемых каждой из этих компаний.