Proqram mühəndisliyindəki dominant dizaynlar: bir qazancda öz dəyərlərini necə tanımaq olar

Bir M&A IT mütəxəssisi olaraq mənim işim hər bir əldə edilmənin (və ya birləşmənin) uğurlu olmasını təmin etməkdir. Əməliyyat firmalar arasında texnoloji yetkinliyin müxtəlif dərəcələrini əhatə etdikdə bu xüsusilə çətin olur ..

İnteqrasiya planlarını qurmağa kömək etmək üçün bir yol, hər iki şirkətin dominant dizaynlardan istifadəsinə (və ya olmaması) nəzər salmaqdır. Hədəf axtararkən bu xüsusilə vacibdir. Düzdür, dominant dizaynlar həmişə yaxşı olmaya bilər - bazarda daha çox işləyəcəklər.

Ancaq bir şey budur - serversiz bir arxitekturadan istifadə edən və ya buludlu yerli dizayn nümunələrini izləyən bir şirkət ana şirkətə dəyər qatmaq üçün zəmanət vermir. Əslində, dəyəri də aşındıra bilər. Beləliklə, bir əldə edilən dominant dizaynın həqiqi dəyərini necə tanımaq olar?

Şirkətə münasibətdə texnologiyanı başa düşmək

Bu seriyada müzakirə edilən üstünlük təşkil edən dizaynların hamısı, daha geniş miqyaslı, iqtisadi cəhətdən səmərəli və möhkəm tətbiqlər yaratmaqla proqram təminatının müasir problemlərini həll edir. Ancaq fərqli ticarət əlaqələri də var.

Məhsulunuz üçün düzgün dominant dizaynı seçməyiniz və alış zamanı müqavilə dəyərini / təsirini düzgün qiymətləndirməyin açarı ən böyük problemlərinizin nə olduğunu və təşkilatınıza hansı investisiya yatırmaq istədiyinizi bilməkdir.

Məsələn, bir monolitik bir arxitekturanı izləyən və getdikcə bazarın artması səbəbindən itirən bir şirkəti götürək - bir rok ulduzu DevOps mühəndisləri ilə dolu bir DevOps başlanğıc şəklində yeni qan əldə etməklə həll etməyə çalışan bir problemi.

DevOps mühəndislərinin mikroservislərdən istifadə etmək üçün istifadə etdikləri mövcud monolit mühit səbəbindən alınma nəticədə uğursuz olur.

Bu, çox böyük bir nəzarət və qeyri-kafi səy nəticəsində yaranan nadir bir uğursuzluq kimi görünə bilər. Ancaq oxşar hallar olmalı olduğundan daha tez-tez olur və üstünlük təşkil edən dizaynları daha yaxşı başa düşməklə, həmçinin profilaktik tədbirlər görməklə qarşısını almaq olar.

Alınması zamanı müəyyən bir texnologiyanın həqiqi dəyərini tanımağa kömək edən 5 aktiv tədbirdir.

  1. Tam Mülkiyyət Proqramı nəzərdən keçirin

Sahibkar bir proqram araşdırması lazımi araşdırmanın bir hissəsidir, lakin həmişə satın alan tərəfindən həyata keçirilmir. Mülkiyyət proqramı (rəfdən kənar proqram təminatından fərqli olaraq) çox vaxt texnoloji satınalmaların əsas aparıcısıdır və əgər belədirsə, paketin həqiqi işini qiymətləndirmək üçün tam mülkiyyət proqramı nəzərdən keçirilməlidir.

Proqram təminatının nəzərdən keçirilməsinin əsas məqsədlərindən biri mülkiyyətçi proqramın ana şirkətin İT platforması ilə uyğunluğunu və miqyasını müəyyənləşdirmək və alıcının ehtiyaclarını ödəmək üçün proqramın miqyasının nə dərəcədə qiymətləndirilməsidir.

Alıcıların baxmalı olduqları bir şey, mülkiyyət proqramının digər platformalarla zəif ölçülənliyi və uyğunluğudır. Çox vaxt hədəf şirkət yalnız öz platforması üçün xüsusi proqram təminatını optimallaşdırmağa yönəldər və çox genişlənə bilən hala gətirilməsinə çox sərmayə qoymaz (xüsusilə hədəf şirkətinin son hədəfi sonda əldə edilsə idi). Bu, xüsusi proqram təminatının gözləntiləri yerinə yetirməməsi və nəticədə şişirdilmiş əməliyyat qiymətini ödəmək riskini artırır.

2. Buludlu texnologiyaların modulu və düzgün tətbiq olunmasını təmin edin

Buludlu yerli texnologiyalardakı modulluq, asanlıqla dəyişdirilmək qabiliyyətinə aiddir. Bu, miqrasiya / inteqrasiya dövründə proqram və platformanın dəyişdirilməsini təmin etmək üçün satınalmalarda əsas tələbdir. Platformaları dəyişdirərkən bu modulu məhdudlaşdıran buludlu texnologiyaların müxtəlif xüsusiyyətləri var.

Məsələn, müzakirə olunan texnologiya serversiz olduqda, müəssisələr satıcı kilidinin dəyərini nəzərə almalıdırlar (hədəf şirkət alıcıdan fərqli bir bulud xidmətləri təminatçısından istifadə edirsə).

3. Uğursuzluqların vahid nöqtələrini tapın

Tək bir uğursuzluq nöqtəsi (SPOF), infrastrukturda uğursuz olduqda, bütün sistemi özü ilə götürən bir elementdir. SPOS-ların mövcudluğu, buludlara əsaslanan texnologiyalar, mikroservislər kimi, hətta mikroservislərdə bir nöqsan ola bilər. Və daha əhəmiyyətlisi, artan sayda birləşmə və satınalma texnoloji və qeyri-texnoloji şirkətlər arasındadır və bu da bir qurumun monolit memarlığa sahib olma ehtimalının çox yüksək olduğunu göstərir.

Mənbə

Bir əldə edildikdən sonra sistemin uğursuz olmasının qarşısını almaq üçün, inkişaf etdiricilər və idarəçilər məlumat köçürməsindən və inteqrasiyadan əvvəl bu tək nöqsan nöqtələrinin tapılmasına və aradan qaldırılmasına diqqət yetirməlidirlər. SPOFs buludlu mühitlərdə mövcud ola bilər, buna görə də bu narahatlıqları müəyyənləşdirmək və aradan qaldırmaq üçün hərtərəfli platforma araşdırması aparmaq çox vacibdir.

4. Qızıl nisbətini təyin edin

Təqaüdçü texniki borc, xalis yeni inkişaf və texniki triage arasındakı nisbət əslində Qızıl nisbət adlandırılmır, lakin mütləq belə adlandırmaq üçün kifayət qədər vacibdir - bunun səbəbi budur.

Texniki borcun bir hissəsi müntəzəm olaraq yenilənən və yenidən işlənən təxminən hər proqrama xasdır. Texniki borcun məbləğinin * 20 faiz arasında olması lazım olduğunu söylədi. Və daha əhəmiyyətlisi, texniki borcun geri alınması prosesi davamlı olmalıdır, çünki bütün proqram vaxt keçdikcə çürüyür, çünki performans, ölçülenebilirlik və etibarlılığı yaxşılaşdırmaq üçün daha yeni metod və texnikalar icad olunur.

Xalis yeni inkişaf * 60% -70% aralığında olmalıdır, qalan vaxt səhvləri və ağır problemlərin həllinə sərf edilməlidir. Səhvlər və şişkinliklərin düzəldilməsinə daha çox vaxt sərf olunarsa, diqqətinizi tələb edən daha böyük problemlər ola bilər.

Qeyd * - Texniki borcun alınmasına, yeni inkişafa və səhvləri düzəltməyə sərf olunan vaxtın miqdarı hədəfdən, sənayedən və texniki yığımdan çox asılı olacaq, lakin ümumiyyətlə qeyd etdiyim 20:60:20 nisbətinə yaxındır burada.

5. Hədəfin Gələcək Böyümə üçün Yol Xəritələrini nəzərdən keçirin (varsa)

Ölçülük hər hansı bir buludlu texnologiyaların mərkəzindədir və şanslarınız da, investisiya tezisinizin də mərkəzindədir. Bununla birlikdə, bütün şirkətlər gələcək ölçeklenebilirlik üçün buludlu texnologiyalardan istifadə etmir və ya düzgün tətbiq etmirlər.

Müvafiq araşdırma prosesini inkişaf etdirməyin bir yolu hədəf şirkətin gələcək böyüməsi üçün yol xəritəsinə baxmaqdır (məhsul mühəndisliyi baxımından). Yol xəritəsi, tətbiq olunan texnologiyaların və dominant dizaynların genişləndirilməsi planlarını təsvir etməli və hədəf şirkətin genişlənə bilən bir platforma qurmağa sədaqətinin sağlam bir göstəricisidir.

Bir yol xəritəsinin olmaması əla bir əlamət deyil və belə bir vəziyyətdə hədəf şirkətinin buludlu texnologiyaların düzgün şəkildə tətbiq olunmasını təmin etmək üçün daha ciddi araşdırma tələb olunur.

Qoşulur…

Və bununla, Proqram Mühəndisliyindəki Dominant Dizaynları mövzusunda 5 hissədən ibarət seriya sona çatır. Seriya, müəssisə rəhbərlərini sənayedə mövcud dominant dizaynların əsasları, niyə vacib olduqları və əldə etdikləri dəyərləri necə tanımaq barədə məlumatlandırmaq məqsədi daşıyırdı.

Əvvəlki hissələrə aşağıdakı linkləri tıklayaraq oxuya bilərsiniz: mikroservislər memarlığı, serversiz hesablama, DevOps və buludlu yerli dizayn nümunələri.