Budowa modelu łańcucha dostaw oprogramowania

Standardowe przedstawienie strumienia wartości związanych z tworzeniem oprogramowania zaczyna się od kodowania, a kończy na produkcji kodu. Często widzisz diagramy DevOps, które zaczynają się od „firmy”, a kończą na „klient”. Jednak ten obraz nie odzwierciedla dokładnie złożoności dostarczania oprogramowania w skali przedsiębiorstwa.

Cofając się, widać o wiele więcej czynności związanych z dostarczaniem oprogramowania klientom, ale obecne podejście do zarządzania tymi działaniami jest zakorzenione w strukturach świadczenia usług, a nie w modelach produkcyjnych. W związku z tym nie łączą wszystkich działań w jeden kompleksowy system.

Model używany w innych branżach produktowych to model łańcucha dostaw, a stosując ten model do dostarczania oprogramowania, możesz poszerzyć swoją wiedzę o „systemie” dostarczania oprogramowania poza devops, dając Ci nowy wgląd w to, jak go zoptymalizować.

Co to jest łańcuch dostaw?

Łańcuch dostaw zaczyna się od pomysłu, że można koordynować wszystkie działania produkcyjne i pozaprodukcyjne jako jeden system. Zarządzanie łańcuchem dostaw jest często błędnie rozumiane jako po prostu „zarządzanie dostawcami”, podczas gdy tak naprawdę jest to tylko jeden aspekt zarządzania łańcuchem dostaw (choć krytyczny).

Wszystkie firmy zajmujące się produktami i usługami mają łańcuch dostaw, a związane z nimi działania i ich względne znaczenie dla systemu łańcucha dostaw będą się różnić. Podstawową ideą jest jednak to, że koordynując te działania jako jeden system, uzyskuje się wartość większą niż suma części i efektywne dostarczanie tej wartości interesariuszom.

Poniższe czynności to tylko kilka ważnych aspektów wszystkich łańcuchów dostaw, ale w przypadku oprogramowania są one wykonywane w wyjątkowy sposób:

Planowanie

W tradycyjnym łańcuchu dostaw działania planistyczne obejmują koordynację zasobów i optymalizację przepływu procesów w celu zbilansowania dostaw materiałów z popytem na produkty. W łańcuchu dostaw oprogramowania ta koordynacja polega na upewnieniu się, że opracowywany jest właściwy kod dla funkcji produktu, które są najbardziej potrzebne. Na dużą skalę, z setkami aplikacji i tysiącami programistów, jest to monumentalne przedsięwzięcie.

Zakres działań związanych z planowaniem jest często minimalizowany przez istniejące modele DevOps. To trochę ironiczne, że duże przedsiębiorstwa, które najbardziej potrzebują devops, muszą zmagać się ze zobowiązaniami prawnymi, regulacyjnymi, umownymi i klientami, które sprawiają, że planowanie jest długie i złożone. Podejście do planowania oparte na łańcuchu dostaw obejmuje optymalizację interfejsów między wieloma różnymi zaangażowanymi w planowanie rolami i dyscyplinami, a kluczowym czynnikiem sukcesu jest możliwość ich efektywnej integracji.

Z jednej strony zwinne metodologie, które kierują rozwojem w przedsiębiorstwie, są często powiązane z procesami kaskadowymi. Niewiele firm może uniknąć cykli planowania fiskalnego, a zwinne procesy mogą zawierać abstrakcje, które są sprzeczne z tymi cyklami; na przykład sprinty mogą nie wyrównywać się do granic kwartałów fiskalnych. Brak komunikacji i połączeń między procesami programistycznymi wykorzystującymi zwinne i nieprodukcyjne działania przy użyciu kaskady może prowadzić do marnotrawstwa i nieefektywności w całej firmie.

Z drugiej strony planowanie produktu w przedsiębiorstwie zawsze obejmowało rozbudowane systemy zarządzania wymaganiami i identyfikowalności, i nie inaczej jest w przypadku oprogramowania. Zarządzanie wymaganiami ma szczególne znaczenie w branżach podlegających ścisłym regulacjom, takich jak opieka zdrowotna, gdzie oprogramowanie może być tworzone dla urządzeń medycznych, które mogą oznaczać życie lub śmierć użytkowników. Zarządzanie wymaganiami obejmuje specjalistyczne narzędzia i metodologie, a możliwość śledzenia wierności i jakości ich implementacji w całym cyklu życia oprogramowania może mieć kluczowe znaczenie dla produktów oprogramowania dla przedsiębiorstw.   

Pozyskiwanie

W tradycyjnym łańcuchu dostaw pozyskiwanie komponentów obejmuje zarządzanie relacjami z dostawcami i opracowywanie strategii zaopatrzenia w części i materiały. Oprogramowanie również w dużym stopniu opiera się na komponentach pochodzących ze źródeł - według ostatnich badań przeprowadzonych przez Sonatype, oprogramowanie typu open source stanowi obecnie większość produktów programowych: aż 80 do 90 procent kodu we współczesnych aplikacjach pochodzi z komponentów open source. Te komponenty stwarzają wyjątkowe wyzwania w zarządzaniu.

Po pierwsze, podjęcie decyzji, w jaki sposób określić jakość komponentów, może być trudne, a wiele czynników wpływa na decyzje, takie jak zużycie, testowanie, dokumentacja, społeczność, wsparcie i trendy w technologii. Konieczne jest posiadanie jasnej strategii i podejścia do doboru komponentów.

Po drugie, ponieważ liczba komponentów open source rośnie, nawet wiedza o tym, do czego są one dopuszczone, stanowi wyzwanie. Menedżerowie produktu i inżynierowie muszą zwracać szczególną uwagę na kwestie związane z licencjami i bezpieczeństwem. Stan komponentów open source może się zmieniać codziennie, gdy odkrywane są nowe luki w zabezpieczeniach, a osoby zajmujące się ich opieką zmieniają swoje strategie dotyczące własności intelektualnej. Klienci chcą wiedzieć dokładnie, co otrzymują - wiele dużych przedsiębiorstw nie kupi oprogramowania bez wykazu towarów opisującego zawartość opakowania. Zarządzanie wszystkimi tymi kwestiami związanymi z oprogramowaniem open source jest podstawowym aspektem rozwoju oprogramowania.

Dystrybucja

Dostarczanie oprogramowania do rąk klientów może wiązać się ze złożoną siecią partnerów wszelkiego rodzaju: wdrażanie, dystrybucja, integracja, odsprzedawca; wszelkiego rodzaju umowy: OEM, licencje, NDA, RFP; wszelkiego rodzaju spotkania: pokazy, PoC, prezentacje; i wiele więcej.

Relacje te służą jako dane wejściowe, wyjściowe, a nawet kroki w procesie dostarczania oprogramowania. Stan każdej z tych relacji może bezpośrednio wpływać na działania programistyczne. Bez ścisłego zarządzania nimi i łączenia ich z wykonywaną pracą powstają bardzo namacalne marnotrawstwo.

Wyobraź sobie, że dostarczasz epos dla potencjalnego klienta, który po cichu stał się straconą szansą, lub wdrażasz funkcję dla partnera, który anulował umowę miesiąc temu. Dzieje się tak regularnie, gdy oprogramowanie jest dostarczane niezależnie od strumienia wartości firmy - gdy funkcja dostarczania oprogramowania nie jest powiązana z łańcuchem dostaw.

Potok DevOps musi być ściśle powiązany z partnerstwami, umowami i celami, dla których wykonywana jest praca. Kod można prześledzić i połączyć od historii do wymagania, aż do rekordu klienta w systemie CRM, a wszystko to poprzez traktowanie dostawy oprogramowania jak łańcuch dostaw i przestrzeganie strategii integracji.

Zamiast tego wyobraź sobie, że jesteś w stanie wyświetlić wszystkie czynności w toku wykonywane dla określonej umowy lub wszystkie funkcje zaplanowane dla nowego klienta - to wynik zarządzania łańcuchem dostaw oprogramowania - widoczność i identyfikowalność w całym cyklu życia.

Przybory

Podczas gdy klasyczne narzędzia produkcyjne mogą składać się z maszyn do sztancowania i pieców do obróbki cieplnej, łańcuch dostaw oprogramowania obejmuje klasę narzędzi (nazywanych różnymi narzędziami ALM, narzędziami cyklu życia lub narzędziami DevOps), które są używane do zarządzania różnymi etapami dostarczania oprogramowania .

Strategia zarządzania tymi narzędziami bardzo różni się od klasycznego podejścia, ponieważ techniczne i intelektualne inwestycje w narzędzia do tworzenia oprogramowania są ogromne i mają duży wpływ. Ten typ narzędzia również szybko ewoluuje i jest bardzo rozdrobniony - dzisiejszy Jenkins będzie Hudsonem z przeszłości. Organizacja musi być przygotowana do posiadania odpornego, ale modułowego zestawu narzędzi, który zapewni zespołom to, czego potrzebują, zachowując jednocześnie elastyczność dostosowywania się.

Ponadto łańcucha narzędzi nie można odłączyć - musi on przepływać informacje w górę iw dół łańcucha wartości, aby uzyskać wiedzę tam, gdzie jest potrzebna. Niezwykle istotne jest zbadanie tego obszaru również z punktu widzenia integracji - w jaki sposób można połączyć działania w danej warstwie z otaczającymi ją działaniami wspierającymi zarządzanie łańcuchem dostaw?

Wniosek

Biznes od dawna oddziela zarządzanie technologią od linii biznesowych generujących przychody, traktując je jako zestaw działań wspierających, kierujących się wartościami i celami dostosowanymi do świadczenia usług. Jednak w świecie definiowanym przez oprogramowanie ten model biznesowy już nie pasuje.

Możliwości dostarczania oprogramowania wyszły poza klasycznie zdefiniowaną przestrzeń wsparcia i zaczęły definiować wszystkie podstawowe działania generujące przychody.

Dlatego musisz przemyśleć swój model jako system produkcyjny i przejść do takiego, który uchwyci złożoność relacji w działaniach strumienia wartości. Łańcuch dostaw uosabia to myślenie, a ponieważ produkcja oprogramowania ewoluowała, z pewnością dojrzymy ten model.