Когато бизнесът ви се разраства, нуждата от нови и все по-сложни системи расте с него. С времето се събира много софтуер, който трудно комуникира помежду си. За много компании този процес е започнал още когато т.н. mainframes са били основното бизнес приложение. Последните все още се използват масово от големите корпорации, защото в тях е съсредоточена почти цялата бизнес логика и никой не иска да инвестира милиони в пренаписването на един вече работещ модел. Дори сега в моя университет се предлагат лекция за mainframe технологии със съдействието на IBM и Software AG.
Щом въпросните системи работят, защо искаме да ги модернизираме въобще и какво означава това? Проблемът със старите системи е, че работата с тях става предимно през конзола. Ако някой от вас си спомня DOS, ще изтръпне при мисълта да използва такъв софтуер за критични бизнес системи. Дори в случаите, когато функционалността е достъпна през някакъв интернет протокол, той е толкова специализиран, че не е практичен за използване.
Решението е да се промени потребителския и компютърния интерфейс. Казано по-просто това е начина, по който стария софтуер комуникира с човека и останалите програми. Един начин е да се промени самата програма за да се сложи нещо шарено на екрана. Това не винаги е желателно или възможно, защото често липсва документация или човека написал кода вече не е на този свят. Така се рискува да се получат непредвидими резултати. Има обаче начини да се преобрази функционалността в web service, което дава основа за изграждане на SOA.
Друг начин за модернизиране на системата е по-често използван. При него се използва интеграционен сървър, който си комуникира директно с конзолата. Работата му е буквално да снима екрана и да идентифицира показаните данни и действията, които могат да се предприемат във всяка стъпка. Когато данните и функционалността са описани абстрактно, може да се изградят web service-и, които да изпълняват дадените действия. Резултата е същия, както при предишния метод, но няма рискованата промяна на софтуера.
Пример за един такъв случай е ако работите в банка и искате да проверите бройката на просрочените кредити. Базата данни е във mainframe и трябва първо да се впишете в конзолата, да минете пред 3-4 менюта, да изберете желаната справка, да отпечатате резултата и да го въведете на ръка в Excel таблица. Всички тези действия са стандартни и следователно могат да се автоматизират. Получения web service от модернизацията ги извършва едно след друго и ви връща справката като xml. Така може цялата операция да се извърши с натискането на един бутон и се пести ценно време и усилия.
Подобни проблеми имат учудващо голяма част от бизнеса. Причината да не се прави нищо по въпроса е, че служителите са свикнали с програмите и излиза по-евтино да се обучат новаците, отколкото да се отдели екип за да модернизира софтуера. Пример е Първа Инвестиционна Банка, чиито чиновници използваха до преди година-две една DOS програма за основните операции. В съвременния бизнес обаче нуждата от свързаност между системите на различните отдели и между компаниите (т.н. B2B). Това е немислимо без Application Modernization. Когато говорим за SOA, BPM и дори CEP, не трябва да забравяме, че голяма част от системите зад интернет услугите (web services) са точно такива модернизирани стари програми. Въпросните архитектури и методи взимат тази базова функционалност и я качват на по-горно ниво на абстракция и ефективност.
За допълнителен поглед над темата, може да видите презентациите (на немски) от Business Innovation Forum ’08 в Darmstadt, Германия.
🙂
Ти нямаше ли да разделяш блога на две (технически и личен?)?
Добре си го описал, аз мога да дам много конкретен пример:
DB с stored procedures с по 50 хил реда код в всяка писано преди 10-12 години. Никой не му се занимава да ги гледа и да го променя (проблемът е, че на времето са решили, че е добра идея дейтабейз сървъра да връща направо html код, който на днешно четене е доста архаичен и нефективен предвид ajax и прочее технологии, които позволяват корпоративния сайт да стане мнго лек и бърз (за разлика от завареното състояние, в което само докато се зареди паметта на браузъра скача на 250МБ resident), а самото ДБ логиката е много комплексна и дори само една процедура да я осмислиш отива половин ден, на много места какво трябва да прави може да ти каже само автора:)) ).
За целта се ползва междинна апликация, която си говори с остарялата template система и ДБ и представя нещата за потребители много приятно, леко, зарежда on the fly каквото е нужно и т.н. Реално логиката е същата, апликацията е същата, само представянето й е различно. Освен това позволява вграждането на интерфейса в други интерфейси, което е много удобно специално за тази апликация.
Въпросът обаче е, че това коства много пари и много време (човековреме, защото няма как да се автоматизира написването на този междинен сървис). Тоест трябва д асе очакват реални и лесно обозрими ползи от едно такова действие.
Това с разделянето го правя точно в момента. Прехвърлям статии и оправям видът на новия блог. Вече купих домейн и recrute-вам още хора да пишат в блогът. Като стане готов, го опиша тук и ще пусна препратка от всяка статия в този блог към новата там.
Наистина много глупаво е това с големите функции в базата данни, защото те имат предимно поддържаща роля, а не средство за изграждане на бизнес логика. Наистина има нужда от middleware (междинна апликация е добър превод) за да се прави каквото и да е ново нещо с тази система, но не е вярно, че е толкова трудно. На първо време е възможно да се напише директно нещо на java или дори php, което да изкара функционалността като web service или през api. По принцип този метод не го препоръчвам, защото носи със себе си доста грешки. Лесен е от гледна точка на програмирането, но изисква сериозно планиране и разучаване на целите на старата система.
По принцип е добре да се използват готовите продукти за системна интеграция, но в случая мисля, че нито Application Modernization, нито Information Integration могат да са от помощ. Всъщност ако stored procedures са отделно като C процедури може, но надали. Случаят ти е екзотичен и май спада към по-общата категория – Legacy Integration.
Интересно ми е защо въобще някой е направил такава система. Да кажем, че от днешна гледна точка изглежда глупаво, но дори и преди 20 години такива неща са били безсмислени.