Архитектура как информационная система строительство

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

Неважно, ведется ли разработка в одиночку либо небольшой командой, сроки всегда сжаты, что увеличивает стоимость ошибок, совершенных на этапе проектирования, так как это может привести к необходимости возврата за «чертежи» в ходе реализации проекта.

Проблемой маленьких команд или проектов является то, что не все методологии написанные и публикуемые в сети к ним применимы. И команды зачастую не состоят из “ветеранов проектирования” — потому что те просто “не по карману” стартапам и частным командам.

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

Информационная архитектура

Любое решение строится вокруг какого-то процесса — например совершение покупки, или подача заявки, даже публикация поста. Здесь речь идет не только о последовательности действий пользователей — участников будущей системы, но и про внутренние процессы: проверки одной системой, регистрация другой, подготовка публикации и так далее.

Описание процесса лучше делать «сверху вниз» то есть начинать с более высокого уровня детализации, а потом “спускаться» из абстракций в детали. Например:

Здесь можно не бояться добавлять детали не только на текущем уровне детализации, но и возвращаться на “верхний уровень” — добавлять большие блоки и детализировать их. Например:

В конце должна получиться картина, которая полностью закрывает ожидания от будущего решения для всех участников проекта.

Ввиду того, что на данном этапе отсутствует структура как таковая, я предлагаю использовать простой текстовый редактор например https://docs.google.com/, потому что любой другой инструмент, требующий более структурированного подхода, на текущем этапе будет только ограничивать свободу мысли. Например, если, для того чтобы добавить простую функцию, надо переработать структуру документа, мозг подсознательно начнет оценивать целесообразность затрат и многие мысли не будут зафиксированы. А в IT фраза «Дьявол кроется в деталях» может запомниться как очень дорогой урок.

После того, как описан основной процесс, таким же образом формализуются остальные — служебные процессы, которые зависят от основного.

После того, как список действий определен, становится возможным понять кто и какое действие выполняет. То есть для каждого шага мы определяем исполнителей, кто должен или может делать какое-то действие в рамках процессов.

Для простоты исполнителей можно просто указать в скобках напротив каждого действия:

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

Архитектура информационных систем

В современном мире, текст не является самым быстрым способом донести структурную информацию, поэтому необходима визуализация работы, проведенной на предыдущих этапах.

Для этого, корпоративный мир использует диаграммы процессов, и для них существует множество стандартов и нотаций. Для нашего контекста я бы посоветовал BPMN.

Несмотря на определенные неудобства, я рекомендую использовать https://app.diagrams.net/, ввиду того, что этот инструмент бесплатный и предоставляет очень много шаблонов, которые окажутся очень полезными для новичков.

BPMN как язык диаграмм, предоставляет очень богатый инструментарий, который… нам с вами не нужен. В рамках объявленного в заголовке масштаба задачи, нам достаточно использования:

• Действия
• Связ
• Условий

Остальное — оставим корпоративщикам.

В итоге получается диаграмма, которую можно согласовать с клиентом.

Диаграмма помогает понять “кто?”, “что?” и “когда?”, однако не отвечает на вопрос “с чем?”.

Для этого нам необходимо построить модель данных — совокупность объектов, их атрибутов и связей между ними. На основании именно этой модели, впоследствии, будет строиться архитектура Базы данных, разбиваться система на сервисы и формироваться форматы вызовов сервисов и многое другое.

Здесь есть следующие понятия:

• Бизнес атрибуты — в которые, например, входят Табельный номер сотрудника и его Адрес
• Служебные атрибуты — здесь речь идет о таких, как дата регистрации или логин

Для каждого блока “Действие” в нашей диаграмме, необхродимо описать какие именно данные нужны этому участнику процесса для выполнения этого действия. Например:

Этот шаг, выполненный для всех действий позволит сформировать общее понимание всей модели данных с Бизнес-перспективы.

Дальше на основании собственного опыта и подходов самих разработчиков, сюда же добавляются и служебные атрибуты. В скором времени я планирую написать отдельную статью о том, какие из них спасают время при дебаге и разбирательствах (напишите в комментариях, интересно ли это).

На текущем шаге, мы уже имеем на руках процесс, его визуализацию, данные, которые нужны участникам и нам самим, самое время строить модель данных.

В качестве инструментов можно использовать все тот же https://app.diagrams.net/, однако для случае, когда связей много а модели простые, я бы предложил использование https://start.jhipster.tech/jdl-studio/ который является окном в мир кодогенераторов и hgjfrnbdyjuj прототипирования и точно заслуживает отдельной статьи. Здесь мы только поскребем по поверхности и используем бесплатный инструмент JDL-studio.

Синтаксис достаточно простой, разобраться может любой новичок минут за 5, тем более что все изменения применяются сразу и диаграмма моделей перестраивается.

Теперь мы должны вернуться к самому первому документу и извлечь из него данные в следующем формате:

Либо, как делается в корпоративных проектах, ввиду сложной иерархии:

Где, для каждого раздела необходимо расписать набор из:

• Данных для отображения: Какие данные и из какой модели отображаются
• Органов управления: Какие кнопки / фильтры / виджеты должны присутствовать и какие функции они выполняют

Эта структура позволяет дать более-менее структурированное понимание функций системы “from user perspective”, что очень удобно дизайнерам.

На текущем этапе у нас есть достаточно данных для того, чтобы приступить к шагу, который легче всего оценить клиенту — прототипирование.

Здесь есть множество решений платных и бесплатных, сложный и простых, интерактивных и нет.

На собственном опыте, принимая во внимание распространенность, бесплатность и интерактивность я бы порекомендовал https://www.figma.com/. Единственное, что он не умеет (хотя бы из коробки) — это давать возможность заполнять текстовые поля в режиме Презентации.

Важно упомянуть — что работа с Figma станет гораздо удобнее при использовании готовых шаблонов и наборов компонентов, доступных в сети.

Мобильные прототипы можно “скачать” и посмотреть как они выглядят на устройстве (обязательно делайте эту проверку)

Прототип можно продемонстрировать клиенту, получить обратную связь, и внести какие-либо исправления назад в документы (вплоть до описания процессов). Это на первый взгляд кажется растратой времени и ресурсов, но по опыту, это инвестиции в более предсказуемую разработку самого решения.

Этот этап вынесен в самый конец неспроста — в ходе демонстрации прототипа, зачастую всплывают изменения в том, кто и в каком устройстве должен что-то делать, что накладывает достаточно драматические изменения в архитектуру API систем и сервисов.

Более того, проектирование API критично еще и потому, что структура API — это контракт между разработчиками разных компонентов, например Front-end и Back-end систем. И управляемость совместной разработки напрямую зависит от того, насколько детально прописаны API-calls, и насколько полно они удовлетворяют вызывающую и принимающую сторону.

На этом этапе, имея на руках формализованный процесс, диаграмма которого показывает точки “соприкосновения” систем, структурированную модель данных, интерфейсы и их функции, разработка архитектуры завершается тем, что команда (или все альтер-эго одного разработчика) совместно прописывает API-calls, расходится и приступает к планомерной разработке итогового решения, имея на руках все, необходимые для этого документы, данные и диаграммы.

Весь этот процесс, в зависимости от сложности проекта, “размера” клиента и количества вовлеченных человек, занимает от одной до двух недель. Но эти затраты ничто по сравнению с теми, которые придется нести в случае, если это процесс не выполнять в каждом проекте. И, по опыту, они окупаются со 100% вероятностью.

Источник: vc.ru

АРХИТЕКТУРА ИНФОРМАЦИОННЫХ СИСТЕМ В СТРОИТЕЛЬСТВЕ

1. Функциональные задачи информационных систем в строительстве (ИСС).

2. Классификация ИСС, обеспечения ИСС, функциональная и системная архитектуры.

Процессы проектирования и возведения объекта при современной концепции строительства, как правило, выполняются параллельно, что определяет необходимость интенсивного обмена результатами работы между проектными и строительными организациями, включая генерального подрядчика, субподрядчиков, поставщиков и других участников проекта, зачастую географически удаленных друг от друга и использующих несовместимые компьютерные платформы и программные средства. Взаимодействие участников может быть эффективным, только если оно базируется на единой информационной модели объекта. Длительность жизни такой структуры определяется временем выполнения заказа на изыскательские, проектные и строительные работы, составляющие значительную часть жизненного цикла создаваемого строительного объекта.

Структура организационного построения строительного процесса позволяет всех участников этого рынка разделить на несколько крупных классов согласно их специализации. Причем крупные строительные концерны, как правило, охватывают сразу несколько видов деятельности.

Специфика деятельности инвестора/управляющей компании заключается в развитии проекта как бизнес-идеи. Основным показателем, который отслеживают такие структуры, является эффективность проекта как бизнеса. Поэтому инвестору прежде всего необходимы системы, позволяющие эффективно вкладывать деньги, контролировать и возвращать свои инвестиции. Это относится к процессам бюджетирования и управленческого учета на верхнем уровне, казначейским операциям, договорной работе, финансовому моделированию как компании в целом, так и отдельных ее проектов. Управление проектом для инвестора/управляющей компании интересно в смысле портфельного управления или управления ключевыми событиями проекта при условии, что заказчики/подрядчики работают с инвестором в поле одной идеологии, иначе возникают сложности в интерпретации первичных данных из-за разницы в их детализации и агрегации.

Заказчик по сути своей деятельности управляет движением проекта на основной производственной стадии — предпроект, проект, строительно-монтажные работы. Именно от заказчика зависит коммерческий образ проекта, его технико-экономические показатели и движение. В силу этого особое внимание уделяется управлению проектами, детальному отслеживанию их технико-экономических показателей, сроков и бюджетов, что накладывает соответствующие требования на детализацию данных в системах. При тех же основных бизнес-процессах, требующих автоматизации, глубина детализации может и должна на порядки превосходить детализацию инвестора. И совершенно естественно, что система отчетности заказчика является более сложной и более многоуровневой, чем отчетность инвестора.

Основные процессы подрядчика — это реализация делегированного объема работ в сроки и бюджеты, установленные заказчиком. По сути он работает по установленному заказчиком лимиту стоимости. Таким образом проектное управление выходит на первое место, бюджетирование и управленческий учет ведутся строго в рамках учета проектного. Графики мероприятий, бюджеты проектов и фактическое их исполнение, оперативное планирование и казначейские операции — всё это может проводиться в рамках системы управления проектами. Заказчику передается отчетность в установленном виде с требуемым уровнем детализации.

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

Бизнес проектировщика основан на предоставлении услуг по проектированию и разработке документации и кроме документооборота специализированных систем, таких как AutoCad или ArchiCad, и бухгалтерской программы других систем не требует. Более того, данный элемент процесса весьма специфичен и обособлен от остальных и может работать в рамках единой системы только в области документооборота.

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

Источник: studopedia.ru

Архитектура как информационная система строительство

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

Когда компания занимается информатизацией, она регулярно решает такие группы задач:

• Анализ и проектирование архитектуры
• Планирование и реализация
• Эксплуатация и развитие

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

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

К этой карте всё время будет идти тонкий «ручеёк» новых требований: требования заказчика будут расширяться, обновляться и добавляться. Этот «ручеёк» всегда необходимо анализировать на предмет соответствия корпоративной архитектуре. Если новые требования не вписываются в архитектуру, но являются значимыми, надо понять, как адаптировать к ним архитектуру.

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

Когда мы убеждаемся в правильности реализации ИТ-решений, встают задачи по их вводу в эксплуатацию с последующим мониторингом и контролем возможных изменений. Мониторинг является важной частью эксплуатации ИТ-решения, так как позволяет отслеживать эффективность его работы и своевременно выработать рекомендации по развитию или замене ИТ-решения. Помимо этого немаловажной является необходимость контроля вывода ИТ-решений из эксплуатации.

Практика показывает, что при планировании систем всегда существуют ожидания определённого эффекта от внедрения. При инициации проекта и его выполнении об этих ожиданиях часто забывают, но, упустив из вида ожидаемый бизнес-эффект, мы по завершении проекта обнаружим, что система разработана и внедрена, но бизнес-эффекта не приносит.

По статистике, треть проектов в ИТ-сфере не приносят ожидаемого эффекта, поэтому задача своевременного мониторинга соответствия системы бизнес-целям становится очень актуальной.

Что представляет собой корпоративная архитектура? Корпоративная архитектура — это симбиоз, согласованная совокупность бизнес-архитектуры, то есть модели хозяйственной деятельности предприятия, и ИТ-архитектуры, то есть набора моделей данных, информационных систем и ИТ-инфраструктуры.

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

Модели деятельности, информационные системы, проекты, бизнес-требования, внедрённые системы — все это объекты, имеющие разный подход к управлению. Архитектура при этом является средством, позволяющим объединить такие объекты путём установления связей между ними. Когда все эти сущности связаны друг с другом, мы можем говорить об архитектуре как о наборе взаимосвязанных моделей. Эти модели позволяют хорошо управлять информатизацией.

В чём заключается сущность архитектурного подхода в информатизации? Архитектурный подход предполагает ни что иное, как взаимосвязанное и согласованное рассмотрение бизнес-архитектуры и ИТ-архитектуры при разработке информационных систем предприятия.

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

Являясь набором моделей и средством для управления информатизацией, архитектура устанавливает общий язык между участниками деятельности в сфере IT. Инвестиции в слаженное взаимодействие дают ценность, которую достаточно легко донести до бизнеса. Безусловно, архитектура позволяет увидеть бизнес со всех ракурсов, демонстрирует недочеты, помогает понять, как их исправлять, какие системы развивать и почему, что делать с ИТ-инфраструктурой, и так далее. Но гораздо убедительнее для бизнеса тезис о том, что с появлением корпоративной архитектуры все участники, имеющие разные точки зрения на уровне целей и задач компании, начнут говорить на одном языке.

Изначально все участники имеют разные точки зрения на бизнес, разные вопросы и приоритеты. Каждый смотрит «со своей колокольни». Акционеры смотрят на компанию с точки зрения целевых показателей. Они ставят показатели и ожидают, что высшее руководство придумает, как этих показателей достичь.

Высшее руководство формирует бизнес-стратегию и ставит задачи функциональным направлениям, в том числе и ИТ-блоку. Интерес руководителей функциональных направлений заключается в том, чтобы сделать свои регулярные функции наиболее эффективными. ИТ-блок, в свою очередь, готов внедрять решения. Его задача состоит в том, чтобы «хорошо внедрять и эксплуатировать». Бизнес-партнеров волнует эффективность процессов взаимодействия между компаниями, а контрагенты предлагают внедрить различные продукты и услуги, потому что это в их интересах.

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

Именно архитектура позволяет показать любому участнику бизнеса, какой эффект для бизнеса имеет внедрение того или иного ИТ-решения.

В соответствии с открытым международным стандартом TOGAF, архитектура — это структурированное поэлементное описание перспективного состояния предприятия, включающее его цели, функции, информацию, информационные системы, информационно-коммуникационную инфраструктуру и связи между элементами.

С учётом рекомендаций стандарта TOGAF архитектура предприятия должна состоять из нескольких слоёв или доменов. Эти слои в TOGAF обозначаются как рекомендательные, их структура и описание не являются догмой. Выбор конкретных описаний, нотаций, представлений и их наименований остаётся за пользователем стандарта. На рисунке ниже показано классическое представление архитектуры в соответствии со стандартом TOGAF.

Каждый слой содержит одну или несколько моделей (различные представления сущностей в рассматриваемом слое архитектуры).

В основе архитектуры предприятия лежит архитектура деятельности, которая определяет границы и состав решений в других слоях архитектуры. Этот слой не содержит ничего, связанного с технологиями.

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

Третий слой архитектуры — это архитектура систем. Системы внедряются ради управления данными. При построении архитектуры необходимо показать, что определённый набор регулярных функций должен поддерживаться определёнными данными. У этих данных есть характеристики, которые нужно принимать в расчёт, когда мы решаем, какими должны быть системы для работы с этими данными.

Системы живут в инфраструктуре, и следовательно четвёртый слой архитектуры — это слой информационно-коммуникационной инфраструктуры.

Залог успеха при проектировании корпоративной архитектуры — выбор правильного архитектурного стиля. Главное здесь — увидеть факторы, показывающие, какие принципы необходимо применять здесь и сейчас. Эти факторы зависят по сути от самой компании.

На рисунке ниже показаны три основных архитектурных стиля с интересной бытовой аналогией.

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

«Слабая» интеграция делает акцент на создание интеграционного комплекса, позволяющего установить взаимодействие между разными, лучшими в своём классе системами.

«Сильная» интеграция предполагает применение ERP-систем и действительно интегрированное информационное пространство.

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

Очень важно уметь распознавать «звоночки», указывающие на необходимость использования того или иного архитектурного стиля. Например, когда регулярно накапливаются проблемы связанные с потерей клиентов, увеличением времени обработки данных, увеличением объёмов деятельности, ухудшением уровня консистентности данных, очевидно, что пора переходить на «сильную» интеграцию — внедрять хорошую систему и делать интегрированную IT-среду.

В противовес этому можно привести ситуацию, когда полностью интегрируемые модули ERP-системы перестают отвечать функциональным требованиям по любым направлениям. Например, у нас сильно усложнился складской модуль и стало понятно, что часть функции стоит выделить в отдельную систему класса WMS, то есть переходить к «слабой» интеграции.

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

Ранее мы говорили о том, что верхним и определяющим слоем корпоративной архитектуры является архитектура деятельности.

Бизнес-модель, модель деятельности, процессная модель, альбом бизнес-процессов — все эти понятия по сути являются синонимами понятия «архитектура деятельности».

Для описания деятельности существует очень много подходов. Традиционным является описание процессов, в результате которого формируется альбом бизнес-процессов. Существуют и другие нотации: модель Захмана, модель Портера.

В целях построения корпоративной архитектуры я рекомендую использовать функциональную компонентную модель. Компонентная модель фактически демонстрирует весь бизнес буквально на одной странице. По сути модель показывает, какие значимые процессы и активности регулярно происходят в бизнесе. Эта модель позволяет объединить как внутренние регулярные активности, так и внешние, предоставляемые бизнесу партнёрами.

Столбцы отражают компетенции бизнеса, определяемые как крупные предметные области с характерными особенностями и необходимыми навыками, такие как производство продукции или управление цепочкой поставок (логистика).

Например, для крупного металлургического комбината такими областями могут быть: разведка, добыча, обогащение, выплавка, изготовление изделий, управление оборудованием и бэк-офис, т. е. управление бизнеса (финансы, кадры, юристы и т. д.).

Бизнес-компонент представляет потенциально самостоятельную часть организации, которая в принципе может быть частью другой компании. Компонент имеет определённую бизнес-ценность, использует ресурсы, информацию и приложения.

Уровень управления и ответственности характеризует границы и цели действий и принимаемых решений. В компонентной модели рассматриваются три подуровня управления и ответственности:

• Стратегия (Directing) определяет общие стратегические направления и политики.
• Контроль (Controlling) охватывает мониторинг, управление по отклонениям и принятие тактических решений.
• Исполнение (Executing) фокусируется на реальном выполнении операций.

Как построить компонентную модель?

Проще всего оттолкнуться от организационной структуры и идентифицировать в ней ключевые подразделения, дополнительно выделив внешние структуры, которые интегрированы с нашим бизнесом. У этих ключевых подразделений необходимо сначала определить основные функции, а затем объединить смежные или сопутствующие друг другу функции в укрупнённые группы.

Полученные группы являются функциональными компонентами. В качестве примера можно привести такой функциональный компонент как «Договорная деятельность». Это компонент, так как в него хорошо встраиваются такие функции как подготовка договоров, заключение договоров, контроль исполнения договоров и т. д.

Важно помнить, что каждый компонент должен быть уникален и по отношению друг к другу компоненты должны обладать примерно одинаковым весом. Основываясь на практике, можно сказать, что компонентная модель крупного предприятия будет состоять из 50−80 компонентов, которые будут распределяться по 5−8 областям деятельности.

Такая модель является представлением деятельности AS-IS. При этом, учитывая, что компания предполагает развитие и оптимизацию, необходимо также сформировать и целевую модель деятельности.

Хорошим инструментом для формирования целевой модели деятельности является матрица Игоря Ансоффа (матрица товар-рынок).

Матрица задает возможные сегменты, в который нужно попытаться найти сценарии развития бизнеса. Ансофф предлагает рассматривать все возможные направления развития в контексте клиентов и продуктов/услуг.

Использование этого инструмента позволяет построить карту сценариев развития бизнеса. Полученные сценарии можно представить в виде набора требований к функциям модели деятельности.

Чтобы трансформировать модель AS-IS в целевую модель TO-BE, необходимо трансформировать или дополнить функциями компоненты исходной модели таким образом, чтобы это позволяло реализовать выбранный сценарий развития.

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

1. Архитектурные задачи занимают важное место в информатизации. Архитектура позволяет не только описать все бизнес-сущности и взаимосвязи между ними, но и осуществлять контроль сопутствующих проектов и мониторинг соответствия систем бизнес-целям.

2. Архитектура позволяет не только увидеть бизнес со всех ракурсов, но и установить общий язык между участниками деятельности в сфере ИТ: для руководителей подразделений архитектура поможет расставить приоритеты и показать, какие функции нуждаются в автоматизации в первую очередь; ИТ-блок сможет увидеть ценность реализации проектов для компании; бизнес-партнеры смогут построить эффективное взаимодействие между компаниями.

3. В основе архитектуры предприятия согласно стандарту TOGAF лежит архитектура деятельности. Для её построения лучше всего использовать функциональную компонентную модель. Компонентная модель фактически демонстрирует весь бизнес буквально на одной странице. Модель показывает, какие значимые процессы и активности, как внутренние, так и предоставляемые партнёрами, регулярно происходят в бизнесе.

4. Для построения компонентной модели проще всего обратиться к организационной структуре предприятия, выделив в качестве компонент основные функции подразделений. Полученная таким образом модель является моделью AS-IS. Для построения целевой модели можно применить такой инструмент, как матрица Игоря Ансоффа, и описать релевантные бизнес-модели, для реализации которых компании потребуется развернуть дополнительные функции — эти функции должны быть добавлены в компонентную модель компании, что сделает её «целевой» моделью.

В следующей части мы поговорим о том, с помощью каких инструментов можно осуществлять анализ компонентной модели, анализ данных и систем предприятия.

Источник: systems.education

Методика построения архитектуры предприятия при интеграции информационных систем

Данная статья включает основные понятия по теме «архитектура предприятий», а также анализ популярных методик, предназначенных для описания таких архитектур, с выявлением наиболее подходящей модели при создании такого комплексного решения, как ESB (enterprise service bus) — корпоративной интеграционной шины [1] информационных систем компаний, занимающихся проектированием и сооружением сложных инженерных объектов.

Введение

В ходе конкурентной борьбы предприятий, занимающихся проектированием и сооружением сложных инженерных объектов, возникает вопрос об оптимизации рабочей деятельности для достижения конечной цели в срок (или раньше) без потери качества. Ведь получение конечного продукта проекта в запланированное время и в рамках запланированных ресурсов является общим критерием успешности проекта [2]. Остановимся на таком важном критерии, как время. В качестве эффективного способа сокращения сроков на проектирование сложных инженерных объектов можно выделить интеграцию различных программных и расчетных комплексов, используемых предприятием. Ведь каждый день проектировщики затрачивают значительные ресурсы на поиск, обработку, актуализацию и перенос данных между инженерными и расчетными комплексами, в то время как это можно выполнить автоматизированно за считаные минуты.

Одним из наиболее эффективных вариантов интеграции информационных систем является создание единой платформы, где все инженерные и расчетные системы будут взаимоувязаны, то есть связаны между собой посредством корпоративной интеграционной шины, доказавшей свою состоятельность и успешность в банковской и страховой сфере.

Создание такой платформы — дело нетривиальное. Это объясняется тем, что каждый программный комплекс оперирует своим форматом данных и используется для обеспечения актуальных бизнес­процессов компании, причем совокупное количество инженерных и расчетных систем в крупной инжиниринговой компании исчисляется десятками и охватывает большую часть ее операционной деятельности.

В результате применение фреймворков Solution Architecture (Архитектура прикладных решений) оказывается недостаточным для проектирования и успешной реализации такого сложного продукта, как ESB. Логичным становится использование Enterprise Architecture (Архитектура предприятия). Остается вопрос выбора наиболее подходящей методологии описания архитектуры при создании интеграционных решений на предприятиях по проектированию и сооружению сложных инженерных объектов.

Архитектура предприятия

Архитектура — фундаментальная организация системы, воплощенная в ее компонентах, их взаимоотношениях друг с другом и окружением, а также принципы ее разработки и эволюции [3].

Корпоративная архитектура, или архитектура предприятия, — это описание целей организации, способов достижения этих целей с помощью бизнес­процессов и методик повышения эффективности обслуживания бизнес­процессов с применением различных технологий [4].

Архитектура предприятия помогает достичь детального описания и видения сформулированных требований для решения поставленных задач, в комбинации со всеми остальными требованиями. Кроме того, она предлагает посмотреть на эту проблему с различных точек зрения и на разных уровнях детализации.

Методики и модели, созданные для описания таких архитектур, именуются архитектурным framework (фреймворк). Существует несколько методик, позволяющих разделить главные области архитектуры, описать правила, стандарты, процессы, объекты, задействованные для описания элементов архитектуры.

В качестве примеров, позволяющих решить вопрос интеграции информационных систем, можно привести следующие методики:

• методика TOGAF;
• методика Gartner;
• методика META Group.

Методика TOGAF

Методика TOGAF является описанием архитектуры предприятия, которая предлагает способы и подходы для выстраивания, планирования, применения IT­архитектуры предприятия и, впоследствии, управления ею. TOGAF принимает, но не строго придерживается определения ISO/IEC 42010:2007. В TOGAF термин «архитектура» имеет два значения, в зависимости от контекста:

1. Формальное описание системы или детальный план системы на уровне ее компонентов для руководства ее реализацией.
2. Структура компонентов, их взаимосвязь, а также принципы и руководящие указания по их разработке и эволюции во времени [6].

Архитектура предприятия по TOGAF представлена четырьмя направлениями:

1. Архитектура бизнеса.
2. Архитектура приложений.
3. Архитектура данных.
4. Архитектура технологии.

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

Методика TOGAF включает два направления:

1. Методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры.
2. Базовая архитектура (Foundation Architecture).

Методика ADM включает несколько фаз, которые представлены на рис. 1.

Рис. 1. Методика ADM TOGAF

Последовательное описание архитектуры на каждой фазе формулирует полную картину архитектуры предприятия.

Концепция Базовой архитектуры основывается на иерархии архитектур, а именно:

• архитектуры общих систем;
• отраслевой архитектуры;
• архитектуры организации [5].

На каждом этапе проработки мы всё больше детализируем систему за счет интеграции каких­либо служб, комбинируемых в блоки, которые в дальнейшем могут использоваться в различных функциональных областях. При добавлении специфики области создаваемого решения, а также архитектуры IT­систем конкретного предприятия, с учетом всех его особенностей, мы получаем архитектуру организации.

Основной областью применения TOGAF является программная инфраструктура информационной системы (описание интеграционных компонентов). Данная методика довольно детально описывает процесс создания архитектуры, а также позволяет управлять требованиями заинтересованных лиц на каждом из этапов проработки.

Методика Gartner

Компания Gartner трактует понятие «архитектура предприятия» как процесс перевода видения и стратегии бизнеса в эффективное изменение компании посредством создания, обсуждения и улучшений ключевых требований, принципов и моделей, которые описывают будущее состояние компании и делают возможным ее развитие [7].

Общая идея Gartner включает создание «идеальной» картинки будущего в бизнес­представлении и, на ее основе, определение изменений архитектуры (в приоритетном порядке) для достижения конечной цели. Цель данной архитектуры предприятия — стратегия, а не ее техническая реализация.

Суть методики Gartner — создание процесса, который позволит развивать архитектуру в соответствии с высокоуровневой архитектурой бизнес­стратегии. Она образует только общее видение системы и не определяет ни формата, ни языка для описания архитектуры.

Методика META Group

Данная методика рассматривает архитектуру предприятия в интеграции с другими процессами, к примеру с процессом управления корпоративными IT­программами и проектами и процессом выработки стратегии и планирования.

Основными этапами разработки архитектуры предприятия являются:

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

При создании концептуальной архитектуры мы получаем набор принципов (правил), обеспечивающих развитие информационных систем предприятия и технологической инфраструктуры. В технологической архитектуре определяется набор предметных областей (доменов), которые связывают между собой компоненты и технологии.

Сравнительный анализ

Какая же из методик позволит нам доступно и детализированно отобразить архитектуру ESB, которая могла бы послужить основой для последующего воплощения решения?

Можно заметить, что у всех методик есть как общие линии пересечения, так и кардинальные отличия друг от друга. Для сравнения методологий выделим несколько критериев, основываясь на экспертном мнении Роберта Сешнса [8] — известного практика компании Microsoft в области архитектуры предприятий, и с помощью таблицы соответствий определим, какая из методик более подходит для решения ранее поставленной задачи.

Из таблицы соответствия явно видно преимущество методики TOGAF. Как же выглядит применение методики на реальном проекте?

Таблица сравнения методик

Критерий/Методика

Методика
TOGAF

Методика
Gartner

Методика
Meta Group

Возможность описания различных структурных элементов

Описание процесса создания архитектуры предприятия

Полезность использования архитектуры предприятия в целом

Полезность использования архитектуры предприятия по предметным областям

Визуальное схематичное отображение архитектуры предприятия

Восприятие архитектуры предприятия любыми специалистами

Доступность методики (ее инструментов и сервисов)

Рекомендации по управлению архитектурой

Archimate — фреймворк, представляющий логическую структуру для классификации этой информации и содержащий набор понятий для описания архитектуры предприятия [9]. Воспользовавшись данным графическим языком, мы получаем визуализацию нашей архитектуры с различных предметных областей, а также можем объединить их в единую архитектуру предприятия (рис. 2).

Рис. 2. Применение Archimate при интеграции двух программных комплексов

Данная иллюстрация отображает интеграцию двух компонентов корпоративной шины — САПР (система автоматического проектирования) и расчетного комплекса. Архитектура включает проработку с разных точек зрения, а именно: бизнес­уровень, уровень приложений и технологический уровень, а также их объединение в общую архитектуру решения, что позволяет выделить основные векторы развития и определить, какие области архитектуры требуют детализации.

Заключение

Таким образом, на основании проведенного сравнения архитектурных фреймворков можно заключить, что применение методологии TOGAF при проектировании и реализации таких комплексных систем, как ESB, позволяет оперативно реагировать на изменения требований бизнеса и учитывать их при реализации системы. При этом, благодаря инструменту визуализации ArchiMate, полученное архитектурное описание остается простым и понятным как для исполнителей, так и для заказчиков от бизнеса, что делает нашу систему гибкой и прозрачной.

Источник: sapr.ru