Введение
Развертывание новых программных систем в непосредственном окружении существующего (устаревшего) программного обеспечения.
Разработка в условиях Brownfield – это термин, широко используемый в индустрии информационных технологий для описания задач, требующих разработки и развертывания новых программных систем в непосредственном окружении существующих (устаревших) программных приложений/систем. Это подразумевает, что любая новая программная архитектура должна учитывать и сосуществовать с работающим программным обеспечением, уже внедренным в эксплуатацию. В современной строительной инженерии, участок земли, требующий рекультивации (brownfield land), означает недвижимость, расширение, перепланировка или повторное использование которой может быть осложнено наличием или потенциальным присутствием опасных веществ, загрязнителей или загрязнений. Разработка в условиях Brownfield вносит ряд улучшений в традиционные практики разработки программного обеспечения, которые обычно исходят из предположения о наличии "чистого листа", tabula rasa, или "зеленого поля" в качестве целевой среды на протяжении этапов проектирования и реализации. Brownfield расширяет эти подходы, настаивая на том, чтобы контекст (окружающая среда) создаваемой системы учитывался при любой разработке. Это требует детального знания систем, сервисов и данных, находящихся в непосредственной близости от разрабатываемого решения.
Решение проблемы сложности окружающей среды
Надежная переработка существующих бизнес- и ИТ-средств в современные конкурентоспособные, интегрированные архитектуры – непростая задача. Сложность бизнес- и ИТ-средств накапливалась почти бесконтрольно на протяжении сорока лет, что делает изменения все более дорогостоящими. Это происходит потому, что: сложность среды часто выражается в устаревшем коде. Дефицит квалифицированных специалистов, обладающих опытом работы с устаревшими системами, приводит к росту затрат на поддержку и интеграцию. Существующие сложные среды необходимо перерабатывать поэтапно, с учетом операционных потребностей соответствующих бизнес-функций. Зачастую эти этапы сводятся к полной, рискованной замене систем, поскольку незнание существующей сложности делает потенциальные постепенные изменения слишком сложными для понимания и реализации. Ускоренные методы разработки привели к появлению у предприятий современных устаревших систем. Сложные приложения на Java и .NET имеют многие из тех же проблем, что и более старые приложения на COBOL. В результате все большая часть усилий по разработке новых бизнес-возможностей тратится на понимание и интеграцию с существующей сложной системой и бизнес-ландшафтом, а не на создание ценности. Отмечается, что сейчас до 75% общих трудозатрат по проекту уходит на интеграцию и миграцию программного обеспечения, а не на разработку новой функциональности. В целом, IT-индустрия демонстрирует невысокий процент успешной реализации столь масштабных изменений для своих клиентов. Исследование CHAOS, проводимое Standish Group, зафиксировало общее улучшение успешности реализации IT-проектов за последние двадцать лет, но даже в 2006 году крупные IT-проекты чаще оказывались неудачными, чем успешными. Инженерные изменения в таких средах имеют много общего с проблемами строительной отрасли при реконструкции промышленных или загрязненных объектов. Они полны рисков, неожиданных сложностей и, как правило, дороги и сложны в реализации. Накопленная сложность IT-средств превратила их в объекты, требующие рекультивации ("brownfield" sites). Корень масштабных неудач проектов заключается не в сложности новой функции или характеристик новой системы, а в нашем понимании и коммуникации общих требований (как это описано в книге "The Mythical Man Month"). Для достижения успеха требования должны включать точное и всестороннее понимание ограничений существующего бизнеса и IT. Современные инструменты и методы, ориентированные на создание новых систем ("greenfield"), используют ранние, неформальные и часто неточные абстракции, которые по сути игнорируют такую сложность. Ранние, недостаточно обоснованные абстракции обычно ошибочны и часто выявляются на поздних этапах реализации, что приводит к задержкам, дорогостоящей переработке и даже к срыву разработки. Подход, ориентированный на "brownfield", учитывает существующую сложность и используется для надежного ускорения общего процесса разработки решения, включая возможность поэтапных, постепенных изменений, где это возможно. Brownfield использует стандартный подход, основанный на моделях и шаблонах OMG, но переворачивает его с ног на голову. Вместо традиционного подхода, начинающегося с концептуальной модели и переходящего к платформа-специфичным моделям и генерации кода, Brownfield начинается со сбора кода и других существующих артефактов и использует шаблоны для формальной абстракции, направленной вверх, к уровню архитектуры и бизнеса. Затем стандартные методы "greenfield" используются в сочетании для определения желаемой бизнес-цели. Этот метод "встречи посередине" знаком по другим методам разработки, но широкое использование формальной абстракции и шаблонов как для обнаружения, так и для генерации является новым. Базовая концептуальная архитектура всех инструментов Brownfield известна как VITA. VITA расшифровывается как Views, Inventory, Transformation и Artifacts (Виды, Инвентарь, Трансформация и Артефакты). В архитектуре VITA определение проблемы целевого пространства может поддерживаться в виде отдельных (хотя и связанных) "головоломных" знаний, известных как Виды. Основное преимущество Видов заключается в том, что они могут быть основаны практически на любом формальном инструменте. Brownfield не навязывает единый инструмент или язык в проблемном пространстве – основополагающий принцип заключается в том, что "головоломки" продолжают поддерживаться в их исходных формах и инструментах. Затем Виды объединяются и связываются в единый Инвентарь. Инвентарь затем используется с серией возможностей Трансформации для создания Артефактов, необходимых для решения. Виды могут быть импортированы из широкого спектра источников, включая UML, XML, DDL, электронные таблицы и т.д. Инструмент Analysis and Renovation Catalyst от IBM расширил эту возможность благодаря использованию формальных грамматик и абстрактных синтаксических деревьев, позволяющих анализировать и токенизировать практически любую программу и преобразовывать ее в Вид для включения в Инвентарь. Быстрый циклический характер процесса обнаружения, переработки, генерации и тестирования, используемого в этом подходе, позволяет итеративно совершенствовать решения с точки зрения их логических и физических определений по мере выявления все большего числа ограничений и уточнения архитектуры решения. Итеративная разработка Brownfield может позволить постепенное совершенствование логических и физических архитектур и инкрементное тестирование всего подхода, что приводит к ускорению разработки, повышению качества решения и снижению затрат на исправление дефектов. Brownfield также может использоваться для генерации документации по решению, обеспечивая ее актуальность и согласованность с различных точек зрения. Инвентарь, созданный в процессе Brownfield, может быть очень сложным, представляя собой взаимосвязанную многомерную семантическую сеть. Уровень детализации знаний в Инвентаре может быть очень высоким, подробным и взаимосвязанным. Подобные вещи трудно понять и могут создавать барьеры для коммуникации. Однако Brownfield решает эту проблему, абстрагируя понятия, используя "лучшее предположение" специалиста, используя известные шаблоны в своих Инвентарях для извлечения и вывода отношений более высокого уровня. Формальные абстракции позволяют преобразовать сложность Инвентаря в более простые, но при этом точные представления для облегчения понимания теми, кому необходимо понять проблемное пространство. Эти абстрагированные модели Инвентаря могут использоваться для автоматического создания многослойных архитектурных представлений в таких инструментах, как Second Life. Такие визуализации позволяют обмениваться сложной информацией и получать опыт от нескольких человек со всего мира в режиме реального времени. Это улучшает как понимание, так и ощущение единой команды.
Environmental complexity is often expressed in legacy code. Legacy skills shortages are driving up maintenance and integration costs. Existing complex environments must be re engineered in phases that make operational sense to their associated business function. These phases often default to wholesale, risky replacements of systems as ignorance of existing complexity means that potential incremental changes are too difficult to understand and engineer. Accelerated development methods have left enterprises with modern legacy systems. Complex Java and NET applications have many of the same problems as older COBOL applications. As a result, an increasing proportion of the effort of developing new business capabilities is spent on understanding and integrating with the existing complex system and business landscape rather than delivering value. It has been observed that up to 75% of overall project effort is now spent on software integration and migration rather than new functionality. The IT industry as a whole has a poor success rate at delivering such large scale change for its clients. The CHAOS survey from the Standish Group has tracked an overall improvement in IT project delivery success over the last twenty years, but even in 2006 large IT projects still failed more often than succeeded. Engineering changes and in such environments has many parallels with the concerns of the construction industry in redeveloping industrial or contaminated sites. They are full of hazards, unexpected complexities and tend to be risky and expensive to redevelop. The accumulated complexity of IT environments has made them “Brownfield” sites. It is not the complexity of the new function or any new system characteristics that are the root of large project failures – it is our understanding and communication of the overall requirement (as identified in The Mythical Man Month). To succeed, the requirements need to include a precise and thorough understanding of the constraints of the existing business and IT. Current “Greenfield” tooling and methods use early, informal and often imprecise abstractions that essentially ignore such complexity. Early, poorly informed abstractions are usually wrong and are often detected late in construction, resulting in delays, expensive rework and even failed developments. A Brownfield oriented approach embraces existing complexity, and is used to reliably accelerate the overall solution engineering process, including enabling phased, incremental change wherever possible. Brownfield takes the standard OMG model/pattern driven approach and turns it on its head. Rather than taking the conventional approach of starting with a Conceptual model and driving down to Platform Specific Models and code generation, Brownfield starts by harvesting code and other existing artifacts and uses patterns to formally abstract upwards towards the Architecture and Business tier. Standard Greenfield techniques are then used in combination to define the preferred business target. This “meet in the middle” technique is familiar from other development methods, but the extensive use of formal abstraction and the use of patterns for both discovery and generation is novel. The underlying conceptual architecture of all Brownfield tools is known as VITA. VITA stands for Views, Inventory, Transformation and Artifacts. In a VITA architecture, the problem definition of the target space can be maintained as separate (though related) native "headfulls" of knowledge known as Views. The core advantage of a View is that it can be based on pretty much any formal tool. Brownfield does not impose a single tool or language on a problem space – a core tenet is that the headfulls continue to be maintained in their native forms and tools. Native Views are then brought together and linked into a single Inventory. The Inventory is then used with a series of Transformation capabilities to produce the Artifacts that the solution needs. Views can currently be imported from a wide variety of sources including UML, XML sources, DDL, spreadsheets, etc. The Analysis and Renovation Catalyst tool from IBM has taken this capability even further via the use of formal grammars and Abstract Syntax Trees to enable almost any program to be parsed and tokenized into a View for inclusion into the Inventory. The rapid cyclic nature of the discovery, re engineer, generate and test cycle used in this approach means that solutions can be refined iteratively in terms of their logical and physical definitions as more of the constraints become known and the solution architecture is refined. Iterative Brownfield development can allow the gradual refinement of logical and physical architectures and incremental testing for the whole approach, resulting in development acceleration, improved solution quality and cheaper defect removal. Brownfield can also be used to generate solution documentation, ensuring it is always up to date and consistent across different viewpoints. The Inventory that is created through Brownfield processed may be highly complex, being an interconnected multi dimensional semantic network. The level of knowledge in the Inventory can be very fine grained, highly detailed and interrelated. Such things are hard to understand and can provide barriers to communication, however. Brownfield solves this problem by abstracting concepts via an artisan’s best guess, using known patterns in its Inventories to extract and infer higher level relationships. Formal abstractions enable the complexity of the Inventory to be translated into simpler, but inherently accurate, representations for easier consumption by those that need to understand the problem space. These abstracted Inventory models can be used to automatically render multi layered architecture representations in tools such as Second Life. Such visualizations enable complex information to be shared and experienced by multiple individuals from around the globe in real time. This enhances both understanding and a sense of a single team.