Майкл Б.Т. Белл
 | В этой статье есть несколько проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти сообщения )
|
Майкл Б.Т. Белл | |
|---|---|
 | |
| Национальность | Американский |
| Другие имена | Микки Белл |
| Альма-матер | Городской университет Нью-Йорка |
| Род занятий | Писатель, художник, продюсер, корпоративный архитектор |
Майкл Б.Т. Белл — американский писатель. [ 1 ] художник, продюсер и архитектор корпоративного программного обеспечения , получивший наибольшее признание за разработку методологии инкрементной архитектуры программного обеспечения, [ 2 ] среда сервис-ориентированного моделирования (SOMF) , [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] построение многомерной архитектуры программного обеспечения (MSAC), [ 8 ] и нотация моделирования облачных вычислений (CCMN). [ 9 ] Его инновационные исследования и публикации в области архитектуры программного обеспечения , искусственного интеллекта , сервис-ориентированной архитектуры , микросервисов , модельно-ориентированного проектирования , облачных вычислений и больших данных получили международное признание за вклад в сообщества разработчиков программного обеспечения .
Биография
[ редактировать ]Белл получил степень магистра компьютерных наук в 1992 году в Городском университете Нью-Йорка ( CUNY ).
После окончания учебы в качестве разработчика программного обеспечения и консультанта по архитектуре предприятия он посвятил свою карьеру совершенствованию бизнеса и технологических операций финансовых учреждений на Уолл-стрит . Он разработал инновационные программные алгоритмы и методологии для крупных электронных торговых платформ . Сюда входили модули для выполнения торговых приложений, методы сохранения больших объемов данных, а также разработка реализаций программного обеспечения для высокоскоростных сетей и Интернета .
Он работал в JP Morgan Chase , Citibank , UBS-Paine Webber , Deutsche Bank , American Express , TD Waterhouse , Pfizer , AIG , Prudential . и Департамент по делам ветеранов США .
Построение многомерной архитектуры программного обеспечения
[ редактировать ]Методология построения многомерной архитектуры программного обеспечения (MSAC) описана в книге г-на Белла «Архитектор программного обеспечения». [ 10 ] опубликовано в 2023 году Wiley (издатель) . В разделе «Инструменты архитектора программного обеспечения» в книге подробно рассматриваются два основных взгляда на MSAC:
1) Геометрическая и топологическая экосистема квантовой программной архитектуры, в которой развертываются приложения и системы.
2) Основы проектирования 3D-программ .
Экосистема квантовой архитектуры программного обеспечения
[ редактировать ]
Построение многомерной архитектуры программного обеспечения (MSAC) представляет постоянно развивающуюся квантовую производственную среду, топологическое пространство , которое подвержено геометрическим структурным изменениям во время выполнения и/или во время разработки.
фабрики Эти изменения в трехмерном пространстве экосистемы развертывания обусловлены эволюцией атрибутов архитектурной среды и непредсказуемым поведением программных реализаций, которые влияют на производственную среду в целом.
На анимированном изображении ниже изображена динамическая производственная среда, в которой размещаются программные объекты и вмятины, которые они оставляют на ткани своего пространства .
Трехмерные программные реализации в экосистеме MSAC
[ редактировать ]
Каждая реализация программного обеспечения, например программное приложение , служба или система , развернутая в геометрической и топологической экосистеме MSAC, представлена в трех измерениях: ширина/ширина, длина /глубина и высота (как показано на анимированном изображении ниже).
Эта трехмерная модель реализации разработана для повышения уровня специфичности проектирования программного обеспечения, необходимого для создания, развертывания, интеграции и поддержки в производственных средах. Методология MSAC предназначена для просмотра и проектирования 3D-конструкций программного обеспечения в любом пространстве, здесь, на Земле, на любом континенте, регионе или штате, и даже программного обеспечения, развернутого в космосе или на других планетах.
Каждое из этих измерений программного обеспечения определяет уникальные структурные атрибуты архитектуры в системе координат . Например:
Ширина : степень детализации, модульность, уровень структурной сложности, уровень сложности исходного кода.
Длина : масштабируемость, количество потребителей, количество интерфейсов, показатели потребления вычислительных ресурсов.
Высота : уровни архитектуры программного обеспечения, стек решений (стек технологий), стек среды архитектуры программного обеспечения, стек бизнес- или технических возможностей.
Платформа сервис-ориентированного моделирования
[ редактировать ]В 2008 году Bell представила среду сервис-ориентированного моделирования (SOMF). [ 11 ] [ 12 ] сообществу разработчиков программного обеспечения в своей книге «Сервис-ориентированное моделирование». [ 13 ]
Структура обслуживания, основанная на моделировании конкретной дисциплины , была разработана для поощрения консолидации активов программного обеспечения, сокращения избыточности систем и ускорения вывода продукта на рынок. СОМФ [ 14 ] включает язык моделирования и методологию жизненного цикла (см. изображение ниже), подходящие для сокращения разрыва между бизнесом и организациями, занимающимися информационными технологиями на предприятии.
Структура также включает в себя дисциплины и методы моделирования программных систем с целью разработки программных приложений. Кроме того, СОМФ [ 15 ] предлагает различные архитектурные стили, такие как архитектура предприятия , архитектура приложений , сервис-ориентированная архитектура , [ 16 ] и облачные вычисления .
Кроме того, SOMF состоит из трех основных сегментов, как показано в видеоклипе ниже:
Сегмент «Практика и среда моделирования». Перекрытие практик абстракции и реализации с соответствующими тремя средами моделирования: концептуальной средой, средой анализа и логической средой.
Сегмент «Моделирующие дисциплины». Каждая из сред моделирования содержит соответствующие дисциплины: дисциплину концептуальной архитектуры, дисциплину обнаружения и анализа сервисов и дисциплину логической архитектуры.
Сегмент Артефакта. Эта часть SOMF определяет основные артефакты, необходимые для каждой среды моделирования.
Методология инкрементной архитектуры программного обеспечения
[ редактировать ]Традиционно, чтобы способствовать созданию и развитию конечной архитектуры предприятия, архитекторы, обычно старшие ИТ-специалисты, создают диаграмму, изображающую будущую производственную среду. [ 17 ] В большинстве случаев эти разработчики программного обеспечения заявляют, что такая «будущая» архитектура нерушима и может выдержать быстрые рыночные тенденции и сложную технологическую эволюцию. Их заявление также, кажется, гарантирует, что иллюстрированная архитектура будет безупречно работать в производстве. Будет ли это?
Однако во многих случаях такая архитектура, записанная на бумаге, является всего лишь академическим предложением, которое впоследствии не может обеспечить стабильность системы, непрерывность бизнеса и превосходную производительность. Другими словами, эта спекулятивная архитектура имеет тенденцию разрушаться из-за недостатков проектирования и, что наиболее важно, отсутствия стратегии организационной архитектуры.
Чтобы решить проблему развертывания неисправных приложений и систем в рабочей среде и снизить риск нанесения вреда операционной среде, Майкл Белл представил подход поэтапной архитектуры программного обеспечения, который требует предоставления чертежей пуленепробиваемой архитектуры. Этот проект предприятия также должен быть сертифицирован широким кругом заинтересованных сторон организации, чтобы избежать финансовых катастроф и перерывов в работе бизнеса.
Как тогда можно гарантировать, что иллюстрированный дизайн на бумаге действительно создаст стабильную производственную среду? Термин «стабильный» означает, что развернутые системы будут соответствовать бизнес-требованиям и нефункциональным требованиям. Таким образом, перспективность инкрементальной архитектуры программного обеспечения коренится в главном принципе: «Сначала проектируем, затем разрабатываем». Но одного этого недостаточно, чтобы избежать финансового бремени, вызванного неудачной реализацией. Не менее важен и другой связанный с этим принцип, призывающий к изменению устава организаций-разработчиков: этап создания программного обеспечения, каким мы его знаем сейчас, должен быть сосредоточен на доказательстве того, что архитектурные предположения наверняка будут работать в производстве. Итог: «Создание программного обеспечения должно следовать темпам эволюции дизайна». Очевидно, что не наоборот. Термин «эволюция дизайна» означает, что архитекторы должны управлять жизненным циклом разработки продукта, в течение которого конечная архитектура может постепенно модифицироваться, в то время как создание программного обеспечения следует за изменениями дизайна до тех пор, пока не будет достигнута зрелость архитектуры.
Чтобы доказать, что конечная архитектура действительно будет безупречно работать в производстве, грандиозный проект предприятия следует разложить на подархитектуры. [ 18 ] Таким образом, такая декомпозиция конечной архитектуры позволит дизайнерам углубиться в детальную архитектуру и позволит разработчикам сосредоточиться на построении сегментов архитектуры — по одному или несколько параллельно. Но доказательство того, что каждый отдельный сегмент конечной архитектуры работает так, как задумано, не означает, что вся архитектура предприятия в целом действительно будет работать безупречно. Чтобы проверить, стабильна ли конечная архитектура и может ли она выдержать давление производственной среды, следует провести общее стресс-тестирование архитектуры, чтобы убедиться в ее стабильности и пригодности.
Рассмотрим процесс поэтапной архитектуры программного обеспечения. [ 19 ] как показано на представленной схеме ниже:
1. Открытие и анализ конечной архитектуры. Определение систем и связанных с ними приложений в предложении по конечной архитектуре
2. Декомпозиция конечной архитектуры. Процесс декомпозиции осуществляется путем разделения генерального проекта предприятия на структурные, поведенческие и изменчивые области, чтобы разработчики могли доказать, что эти подархитектуры действительно будут работать в производстве.
3. Проверка конечной архитектуры. Задачи аутентификации включают обоснование проекта (создание программного обеспечения), стресс-тестирование конечной архитектуры и планирование мощности предприятия.
Публикации
[ редактировать ]Майкл Белл опубликовал несколько книг и статей. Ниже приводится выбор:
- 2005. «Организационная модель: AOM-3, архитектурная организационная структура и ролевые модели». ИП Издательство. ISBN 978-0-9896935-3-0
- 2006. «Сервис-ориентированная архитектура: Руководство по планированию и реализации для бизнеса и технологий». С Эриком Марксом. Уайли и сыновья. ISBN 978-0471768944
- 2008. «Сервис-ориентированное моделирование: анализ, проектирование и архитектура сервисов». Уайли и сыновья. ISBN 978-0470141113
- 2010. «Шаблоны SOA-моделирования для сервис-ориентированного обнаружения и анализа». Уайли и сыновья. ISBN 978-0470481974
- 2011. Спецификации сервис-ориентированного моделирования для SOMF. Включает дизайн услуг и облачные вычисления.
- 2016. «Инкрементальная архитектура программного обеспечения: метод спасения неудачных ИТ-внедрений». Уайли и сыновья. ISBN 978-1119117643
- 2020. «Затерянный в городе @». Майкл Белл. ISBN 978-0-9896935-6-1
- 2023. «Архитектор программного обеспечения». Майкл Белл. ISBN 978-1119820970
Ссылки
[ редактировать ]- ^ Майкл, Белл (2020). Затерянный в городе @ . Майкл Белл. ISBN 978-0-9896935-6-1 .
- ^ Белл, Майкл (2016). «Необходимость поэтапной архитектуры программного обеспечения». Инкрементная архитектура программного обеспечения: метод спасения неудачных ИТ-внедрений . Уайли и сыновья. п. 1. ISBN 978-1119117643 .
- ^ Белл, Майкл (2008). «Введение в сервис-ориентированное моделирование». Сервис-ориентированное моделирование: анализ, проектирование и архитектура сервисов . Уайли и сыновья. ISBN 978-0-470-14111-3 .
- ^ Турайсингем, Бхавани (2010). Безопасные семантические сервис-ориентированные системы . ЦРК Пресс. стр. 42, 43, 152, 153. ISBN. 9781420073324 .
- ^ Хайбертсон, Дуэйн (2012). Модельно-ориентированная системная инженерия: объединяющая основа для традиционных и сложных систем (комплексная и корпоративная системная инженерия) . Публикация Ауэрбаха. стр. 256, 329. ISBN. 978-1420072518 .
- ^ Турайсингем, Бхавани (2013). Разработка и обеспечение безопасности облака . ЦРК Пресс. п. 87. ИСБН 9781439862919 .
- ^ Буя, Ругкумар (2013). Освоение облачных вычислений . Тата МакГроу-Хилл. стр. 2–30. ISBN 9781259029950 .
- ^ Белл, Майкл (2023). Архитектор программного обеспечения . Уайли и сыновья. ISBN 978-1119820970 .
- ^ «Обозначение моделирования облачных вычислений» . Системы Спаркс.
- ^ Белл, Майкл (2023). Архитектор программного обеспечения . Уайли и сыновья. ISBN 978-1119820970 .
- ^ Сосинский, Барри (2010). Библия облачных вычислений . Уайли и сыновья. стр. 288, 289. ISBN. 9781118023990 .
- ^ Трухильо, Хуан (2010). Достижения в концептуальном моделировании – приложения и проблемы . Springer Science & Business Media. стр. 87, 88. ISBN. 9783642163845 .
- ^ Белл, Майкл. «Сервис-ориентированное моделирование» . Уайли и сыновья.
- ^ Дустдар, Шахрам (2010). Сервисная инженерия: результаты европейских исследований . Springer Science & Business Media. стр. 112, xi. ISBN 9783709104156 .
- ^ Белл, Майкл (2009). Шаблоны SOA-моделирования для сервис-ориентированного обнаружения и анализа . Уайли и сыновья. стр. 185, 240. ISBN. 9780470579695 .
- ^ Белл, Майкл. «Сервис-ориентированная архитектура» . Уайли и сыновья.
- ^ Белл, Майкл (2016). «Необходимость поэтапной архитектуры программного обеспечения». Инкрементальная архитектура программного обеспечения: метод спасения неудачных ИТ-внедрений . Уайли и сыновья. стр. 2, 3, 4. ISBN 978-1119117643 .
- ^ Белл, Майкл (2016). «Необходимость поэтапной архитектуры программного обеспечения». Инкрементальная архитектура программного обеспечения: метод спасения неудачных ИТ-внедрений . Уайли и сыновья. стр. 5, 6. ISBN 978-1119117643 .
- ^ Белл, Майкл (2016). «Необходимость поэтапной архитектуры программного обеспечения». Инкрементальная архитектура программного обеспечения: метод спасения неудачных ИТ-внедрений . Уайли и сыновья. п. 9. ISBN 978-1119117643 .
Внешние ссылки
[ редактировать ]- «Примеры SOMF и языковые обозначения» . Майкл Белл/Корпорация методологии. Архивировано из оригинала (электронная копия) 24 октября 2013 г. Проверено 3 февраля 2014 г.
- «Интервью с Майклом Беллом о нотации моделирования облачных вычислений» (электронная копия) . Интернет-публикация tknowledgeexchange.techtarget.com.
- «Государственный университет Аризоны: исследования и исследования в рамках сервис-ориентированной модели моделирования (SOMF)» (Softcopy) . Университет штата Аризона.
- «Видео о стратегиях сервис-ориентированной архитектуры» (электронная копия) . Майкл Белл.
- «Инструменты моделирования SOMF для сервис-ориентированных и облачных вычислений» (Softcopy) . Системы Спаркс.
- «Решения для моделирования SOMF для сервис-ориентированных и облачных вычислений» (Softcopy) . Корпорация CEPHAS.
