Implementarea proiectelor de integrare este rareori fără complicații. Luăm în considerare modalități de a le depăși
În primul rând, menționăm că scopul proiectelor de integrare nu este organizarea transferului de date între mai multe sisteme, așa cum se presupune uneori. De fapt, trebuie să obțineți o automatizare optimă a proceselor de afaceri, în care doriți să transferați date. Și această discrepanță conceptuală poate duce nu numai la o creștere a termenilor proiectului de integrare. dar și la colapsul său complet. Clientul, gândindu-se că sarcina din fața lui este locală, el însuși, fără examinare, determină fluxurile de integrare. iar integratorul este lăsat să le conecteze, fără a implica specialiștii companiei pentru acest lucru. Dar, în abordarea "aici este lista de fluxuri - integrați" există un risc imens: după integrare, pot fi identificate lipsele de fire care blochează automatizarea proceselor de afaceri. În acest articol, descriem posibilele probleme care apar în cursul proiectelor, împreună cu rețetele pentru soluționarea lor.
Problema numărul 1. Eu nu sunt eu și vacă nu este a mea, sau probleme de interacțiune
Proiectele de integrare nu includ întotdeauna integrarea a două sisteme, așa cum se presupune adesea inițial, mai des decât nu, "a face prieteni" necesită 3 până la 5 sisteme. În acest caz, 90% din riscul de schimbare a calendarului se datorează întârzierii în acordarea muncii necesare. Numărul participanților la proiect crește din partea clientului și nu toți înțeleg importanța interacțiunii cu echipa de integrare. abordarea responsabilă a procesului etc.
Problema numărul 2. "Tăcerea liniștită - veți continua" nu funcționează întotdeauna
Un alt factor, care de-a lungul timpului poate "umfla" foarte mult calendarul proiectului, este desincronizarea acțiunilor tuturor participanților săi, în primul rând companiile executante. De exemplu, un sistem care trebuie să se "creeze" cu o aplicație adiacentă nu a fost încă implementat la începutul lucrărilor de integrare și nu este complet documentat în ceea ce privește cerințele și procesele.
Un flux de integrare este un set de date transferate de la un sistem sursă la un sistem receptor folosind o interfață de integrare a magistralei. În cadrul fluxului de integrare, sunt posibile mai multe interacțiuni între sistemul sursă, magistrala și sistemul receptor.
Complexitatea debitului este determinată de compoziția atributului datelor transmise și de numărul de apeluri adiacente:
- complexitatea medie - un serviciu la ieșire, nu mai mult de 50 de atribute de date;
- complexe - 1-3 servicii la ieșire, mai mult de 50 de atribute de date;
- complexitate crescută - mai mult de 3 servicii la ieșire.
Aceste două probleme au o soluție comună. Trebuie să înregistrați cel puțin un regulament la nivel înalt a interacțiunilor, în cazul în care secvența de acțiuni în toate etapele proiectului este clar definite, pentru a pregăti documentele de ieșire, de potrivire a numărului de participanți și condițiile de note de coordonare / livrare. Acest lucru va reduce riscul de eroare și probabilitatea urmăririi ulterioare a persoanei care se află pe minge, care este responsabilă în cazul documentelor irelevante care descriu sistemul sau a cerințelor nedezvoltate.
Apoi vom analiza "imaginea colectivă" a proiectului de integrare într-o bancă rusă de dimensiuni medii, creată pe baza experienței noastre. Să presupunem că trebuie să ne "facem prieteni" cu sistemele front-și back-office.
Problema numărul 3. Puii în toamnă
Inițial, banca "declară" aproximativ 3 zeci de fluxuri de integrare în proiect. Principalele procese care trebuie automatizate sunt crearea și întreținerea clientului, crearea unui contract de împrumut și servirea ulterioară a împrumutatului.
După sondajul proceselor de afaceri, numărul de fluxuri crește de mai mult de 1,5 ori. Acestea sunt „multiplicate“, inclusiv datorită faptului că sistemul de front-line nu este „ia în considerare“ o serie de fluxuri de produse bancare comune (contract de credit, linia de credit, etc.), așa cum sa anticipat inițial. Pentru ea, pentru fiecare produs similar există unul, un flux separat.
În același timp, 5 dintre fluxurile bancare indicate - crearea unei cereri de credit în back office, transferul unei cereri de credit la un contract de împrumut etc. - sunt excluse din proiect, deoarece aplicațiile din sistemul back-office nu sunt stocate, imediat după aprobarea aplicației în sistemul frontal, se creează un contract de credit.
Fără o anchetă preliminară și o descriere a proceselor de afaceri, este absolut indispensabilă, chiar dacă banca are încredere că "știe ce se integrează". Sondajul determină domeniile fluxurilor de integrare, identifică succesiunea acestora, prioritizează punerea în aplicare, se poate stabili că sistemele trebuie îmbunătățite.
Numărul de problemă 4. Aluatul de tip Tylityl sau Incompatibilitatea sistemelor
Chiar și o descriere detaliată a proceselor de afaceri nu poate garanta absența erorilor în logica implementării fluxurilor de integrare. La determinarea fluxurilor și a atributelor lor, se poate ajunge la incompatibilitatea sistemelor adiacente în termenii logicii funcționării lor. Ne întoarcem la exemplul nostru cu sistemul frontal și back-office.
În cadrul procesului de "creare a unui contract de împrumut" definim 2 fluxuri de integrare pentru a crea un contract de asigurare suplimentar: primul - crearea unui contract de asigurare, al doilea - obligarea acestuia la un contract de împrumut. Prin urmare, pentru aceste fluxuri de sistem implementat în față două metode diferite: prima - pentru a începe crearea contractului în sistemul de back-office, la 2 - pentru legarea sa la un acord de împrumut.
Se pare însă că logica sistemului back-office nu permite crearea unui contract de asigurare fără definirea simultană a unui contract de împrumut, în plus un contract de împrumut se poate referi la un contract de asigurare generală.
Astfel, fluxul pentru crearea unui contract de asigurare trebuie să fie unul, iar metoda de creare a acestuia trebuie să includă "tragerea" datelor privind contractul de împrumut la care se face obligativitatea. Este clar că metodele existente în sistemul frontal nu vor putea să implementeze acest flux.
Pentru a identifica această situație înainte de începerea dezvoltării și pentru a nu întrerupe perioada de timp a proiectului, este necesar să se simuleze schemele fluxului de date pentru fiecare flux de integrare. Acest lucru ne va permite să identificăm scenarii alternative pentru comportamentul diferit al sistemelor conexe, precum și îmbunătățirile necesare pentru aplicațiile business integrabile. Pentru a dezvolta diagrame de flux ale datelor, puteți utiliza diagramele de notație UML.
Numărul problemelor 5. Aveți un jgheab defect?
În timpul anchetei și descrierilor tuturor diagramelor de flux, cerințele clientului atât pentru procesul de integrare cât și pentru sistemele conexe se pot schimba. Nu este exclus faptul că va fi necesar să se revizuiască lingura firului.
În acest caz, trebuie să efectuați o comparație a tuturor, inclusiv a celor în curs de dezvoltare în cadrul proiectului, integrarea fluxurilor și a cerințelor pentru completări în original aceste procese de afaceri pentru a identifica posibilele lacune și incoerențe. După eliminarea acestora, este posibil să modificați prioritatea modificărilor.
Problema numărul 6. Bonnie și Clyde, sau incompatibilitatea sistemelor 2
Este logic faptul că, în sisteme, entități și compoziții complet diferite, este posibil să nu coincidă. Astfel, în proiectul nostru ipotetic, atunci când se creează un contract de împrumut, este necesar să se transmită date despre persoana responsabilă, precum și modul în care clientul este atras, ceea ce nu este suportat în sistemul sursă.
În cazul în care banca nu dispune de un sistem unificat pentru menținerea centralizată a informațiilor normative și de referință (NSI), rolul său este adesea luat prin decizia de integrare.
Astfel de probleme pot fi identificate numai atunci când se definesc entitățile transferate, tipurile și transformările lor. Este recomandabil ca, într-o etapă timpurie a proiectului, să se dezvolte specificații complete pentru fiecare flux de integrare, să se evidențieze logica și dependența atributelor, să se descrie separat serviciile utilizate în fluxurile de integrare. Apoi, informația conform căreia acoperirea atributelor necesare este incompletă și o rafinare suplimentară a sistemelor adiacente este necesară nu va deveni un obstacol serios în calea proiectului.
Numărul de problemă 7. Timpul de funcționare, ora amuzantă sau planul Calendar
Deci, avem o descriere completă a proceselor de afaceri, specificațiile tuturor fluxurilor și multe alte informații foarte importante, este timpul să implementăm direct soluția de integrare. Dar, înainte de a începe să se dezvolte, este important să nu pierdeți toate modificările aduse domeniului original.
Ne întoarcem la proiectul nostru: atunci când examinăm procesele de afaceri, am identificat 5 fluxuri de integrare inițiate de sistemul back-office. Prima a fost legată de procesul de "creare a unui contract de împrumut", iar restul de "servirea împrumutatului". Implementarea fluxurilor a necesitat finalizarea aplicației back-office, deci la etapele inițiale ale proiectului sa stabilit că primul fir a avut o prioritate mai mare decât celelalte. După descrierea specificațiilor tuturor celor 5 fire, sa dovedit că acestea au o structură comună și pot fi implementate ca un singur serviciu pe partea din spate a biroului. Aceasta a dus la consolidarea acestor îmbunătățiri și la creșterea priorității acestora.
Pe lângă problema asociată lipsei unei imagini generale, nu trebuie să uităm de problema testării soluțiilor de integrare. Deoarece toți participanții la proiect sunt "legați" de testare, acțiunile lor trebuie să fie clar sincronizate.
Pentru ca proiectul să răspundă tuturor așteptărilor, este necesar să se efectueze o revizuire finală a tuturor fluxurilor detectate, formând astfel o imagine generală. Acest lucru va permite pregătirea unui plan calendaristic pentru dezvoltare și testare. În acesta este necesar să se stabilească date specifice pentru finalizarea, dezvoltarea fluxurilor și testarea, precum și pentru toți participanții la proces. În viitor, planul va marca stadiul dezvoltării și testării.
Este evident că pot apărea probleme în orice etapă a implementării proiectului de integrare. Sperăm că "rețetele" pentru integrarea descrisă de noi vă vor ajuta să le evitați.