Ескі жүйелермен жаңа бағдарламалық құралдарды енгізу

Кіріспе

Қолданыстағы (мұражайлық) бағдарламалық қамтамасыздардың тікелей қатысуымен жаңа бағдарламалық жүйелерді енгізу.

Браунфилд дамуы – ақпараттық технология саласында қолданыстағы (мұражайлық) бағдарламалық қолданбалар/жүйелердің тікелей қатысуымен жаңа бағдарламалық жүйелерді әзірлеу және енгізуді талап ететін мәселелерді сипаттау үшін жиі қолданылатын термин. Бұл жаңа бағдарламалық архитектура кез келген жаңа бағдарламалық архитектура қолданыстағы бағдарламалық қамтамасыздармен есептесіп, олармен қатар жұмыс істеуі керек екенін білдіреді. Қазіргі заманғы азаматтық инженерияда "қоңыр жер" дегеніміз – қауіпті заттың, ластағыш немесе зиянды заттың болуы немесе болу мүмкіндігі салдарынан кеңейтуі, қайта құруы немесе қайта пайдалануы қиын мүлік. Браунфилд дамуы дәстүрлі бағдарламалық инженерия тәжірибесіне бірнеше жақсартулар енгізеді. Дәстүрлі тәсілдер бағдарламалық жасақтаманы әзірлеудің жобалау және іске асыру кезеңдерінде "таза парақ", "tabula rasa" немесе "жасыл жер" сияқты бастапқы ортаны қарастырады. Браунфилд осындай дәстүрлерді кеңейте отырып, құрылып жатқан жүйенің контекстін (жергілікті ортасын) кез келген даму жұмысына ескеруді талап етеді. Бұл құрылып жатқан шешімге жақын орналасқан жүйелер, қызметтер және деректер туралы толыққанды білімді қажет етеді.

Қоршаған ортаның күрделілігін шешу

Қазіргі бизнес және IT ортасын қазіргі заманғы бәсекеге қабілетті, интеграцияланған архитектураларға сенімді түрде қайта құру оңай емес. Бизнес және IT ортаның күрделілігі соңғы қырық жыл бойы бақылаусыз жинақталып, өзгерістерді одан әрі қымбатқа айналдырды. Себебі:

Ортаның күрделілігі көбінесе ескі кодта көрінеді. Мұрағатталған білім мен тәжірибе жетіспеуі техникалық қолдау және интеграциялау шығындарын арттырады. Қазіргі күрделі ортаны бизнес процестеріне сәйкес келетін кезеңдерде қайта құру қажет. Бұл кезеңдер көбінесе жүйелерді толығымен ауыстыруға баса назар аударады, себебі қолданыстағы күрделілікті түсінбеу, ұсынылатын шағын өзгерістерді түсіну және жүзеге асыру қиынға соғады. Жеделдетілген әзірлеу әдістері кәсіпорындарды қазіргі заманғы мұралық жүйелермен қалдырды. Күрделі Java және .NET қолданбаларында COBOL қолданбаларындағы сияқты көптеген мәселелер бар. Нәтижесінде, жаңа бизнес мүмкіндіктерін дамытуға жұмсалатын күш-жігердің үлкен бөлігі құндылықты жеткізудің орнына, қазіргі күрделі жүйемен және бизнес-ортамен интеграциялауға және оны түсінуге жұмсалады. Қазіргі таңда жобаның жалпы күш-жігерінің 75%-ы жаңа функционалдыққа емес, бағдарламалық жасақтаманы интеграциялауға және көшіруге жұмсалады. IT индустриясы клиенттері үшін мұндай ауқымды өзгерістерді табысты жүзеге асыруда нашар нәтижелерге ие. Standish Group CHAOS зерттеуі соңғы жиырма жылда IT жобаларын жүзеге асырудағы табыстың жалпы жақсарғанын көрсетті, бірақ тіпті 2006 жылы да IT жобалары табысқа жеткеннен гөрі көбірек сәтсіздікке ұшырады. Мұндай ортада инженерлік өзгерістерді жүзеге асыру құрылыс индустриясының өнеркәсіптік немесе ластанған жерлерді қайта дамыту мәселесімен көптеген ұқсастықтарға ие. Олар қауіп-қатерге толы, күтілмеген күрделіліктерге толы, оларды қайта құру тәуекелді және қымбатқа соғады. IT орталарының жинақталған күрделілігі оларды "қоңыр дала" (Brownfield) учаскелеріне айналдырды. Үлкен жобалардың сәтсіздігінің түпкі себебі жаңа функцияның күрделілігі немесе жаңа жүйелік сипаттамалары емес – бұл біздің жалпы талаптарды түсінуіміз және оларды жеткізуіміз (The Mythical Man Month кітабында көрсетілгендей). Сәтті болу үшін талаптарға қолданыстағы бизнес пен IT-ның шектеулерін нақты және толық түсіну кіруі керек. Қазіргі "жасыл дала" (Greenfield) құралдары мен әдістері ерте, бейресми және көбінесе дәл емес абстракцияларды қолданады, олар мұндай күрделілікті елемеді. Ертерек, нашар ақпараттандырылған абстракциялар көбінесе қате болады және көбінесе құрылыс кезінде кеш анықталады, нәтижесінде кешіктірулер, қымбат қайта өңдеулер және тіпті сәтсіз дамулар болады. "Қоңыр далаға" бағдарланған тәсіл қолданыстағы күрделілікті қабылдайды және мүмкіндігінше кезеңді, шағын өзгерістерді жүзеге асыруды қамти отырып, жалпы шешімді жасау процесін сенімді түрде жеделдету үшін қолданылады. Brownfield стандартты OMG модельдік/үлгіге негізделген әдісті қолданады және оны кері айналдырады. Тұжырымдамалық модельден бастау және платформаға арналған модельдер мен кодты құруға дейін төмендеудің дәстүрлі әдісін қолданудың орнына, Brownfield кодты және басқа да қолданыстағы артефакттарды жинаудан бастайды және архитектура мен бизнес деңгейіне қарай жоғары қарай формалды түрде абстракциялауға арналған үлгілерді қолданады. Содан кейін стандартты Greenfield әдістері таңдалған бизнес мақсатын анықтау үшін біріктіріледі. Бұл "орталықта кездесу" әдісі басқа даму әдістерінен таныс, бірақ формалды абстракцияны кеңінен қолдану және модельдерді табу мен өндіру үшін үлгілерді пайдалану жаңалық. Brownfield құралдарының барлық негізгі тұжырымдамалық архитектурасы VITA деп аталады. VITA – Көріністер, Инвентаризация, Трансформация және Артефакттар. VITA архитектурасында мақсатты кеңістіктің проблемалық анықтамасы көріністер деп аталатын жеке (бірақ байланысты) тума "білім" ретінде сақталуы мүмкін. Көріністің негізгі артықшылығы – ол кез келген ресми құралға негізделуі мүмкін. Brownfield проблемалық кеңістікке бір құрал немесе тілді таңдамайды – негізгі қағида, бұл "білім" өздерінің туған формалары мен құралдарында сақталады. Содан кейін жергілікті көріністер біріктіріліп, бір инвентаризацияға қосылады. Инвентаризация кейін шешімге қажетті артефакттарды өндіру үшін трансформациялау мүмкіндіктерінің сериясымен бірге қолданылады. Көріністерді қазіргі уақытта UML, XML көздері, DDL, электрондық кестелер және т.б. сияқты әртүрлі көздерден импорттауға болады. 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.