Specyfikacja projektu architektury obciążenia
Specyfikacja projektu architektury obciążenia to szczegółowa specyfikacja, która opisuje opcje projektowania i towarzyszy diagramom. Wybory projektowe muszą spełniać wymagania funkcjonalne i niefunkcjonalne oraz uwzględniać przepisy dotyczące rutynowych, ad hoc i operacji awaryjnych.
Aby uzyskać informacje na temat diagramów, zobacz Diagramy projektowe architektury.
Projektowanie architektury obciążenia, zwykle ekspansywne, rozpoczyna się od projektowania aplikacji i postępu wyboru usługi w chmurze. Te fazy wzajemnie się informują. Połączony projekt aplikacji i infrastruktury musi spełniać wszystkie wymagania.
Osiągnięcie rozwiązania, które spełnia wszystkie wymagania, to współpraca między uczestnikami projektu, deweloperami, testerami, zespołami operacyjnymi i właścicielami produktów. Proces projektowania powinien obejmować udoskonalanie wymagań z jasnością i negocjacjami. Proces jest iteracyjny i często wymaga wielu przeglądów.
Zalecamy dostosowanie projektu do podstawowych wskazówek dotyczących platformy Azure Well-Architected Framework, które obejmują zasady projektowania i przewodniki dotyczące rekomendacji oraz potwierdzanie kompromisów.
Ostatecznie specyfikacja projektu architektury obciążenia jest implementowana przez zespół deweloperów obciążeń, dlatego musi być jasna i jednoznaczna. Specyfikacja powinna być łatwo dostępna i przechowywana w dokumentacji obciążenia.
Specyfikacja funkcjonalna
Specyfikacja funkcjonalna obciążenia zawiera szczegółowe informacje o tym, co i dlaczego system lub funkcja jest opracowywana, ale nie implementacja. Ten dokument musi wyjaśnić bieżące problemy, które istnieją i jak ta funkcja lub system poprawi to środowisko. Ten dokument zawiera większość wymagań biznesowych.
Architekt może pomóc w kształtowaniu tego dokumentu, ale przede wszystkim jest to funkcja własności produktu. Architekt powinien pomóc zaprojektować dane przechwycone w tej specyfikacji. To zaangażowanie zapewnia efektywne i wydajne projektowanie techniczne specyfikacji funkcjonalnej.
Poniżej przedstawiono kilka przykładowych tematów, które powinny zostać omówione w tej specyfikacji.
Oprócz szczegółów tego, co znajduje się w zakresie tego projektu, należy również wyraźnie określić sąsiadujące obawy, które są poza zakresem. Ustawianie jasnych zakresów zmniejsza pełzanie zakresu przez zdefiniowanie granic wokół funkcji.
Warto uwzględnić szczegółowe informacje na temat tego, jak ta zmiana ma być mierzona. Jakie pomiary należy zebrać i jakie cele biznesowe te pomiary obsługują.
Przepływy użytkowników powinny być jasno opisane. Makiety o niskiej fedelity mogą być również pomocne. Jeśli w przypadku tych przepływów ważne są sytuacje obsługi błędów, upewnij się, że opisano oczekiwane zachowanie.
Zawsze uwzględniaj wszelkie określone wymagania dotyczące ułatwień dostępu, zgodności, wydajności, prywatności lub zabezpieczeń.
Uwzględnij dowolną zaplanowaną strategię wdrażania. Na przykład "Ta funkcja będzie dostępna dla naszych użytkowników wersji beta przez dwa miesiące przed podjęciem decyzji o pełnej wersji".
Unikaj określonych szczegółów implementacji technicznej w tej specyfikacji. Te specyfikacje funkcjonalne będą napędzać specyfikacje techniczne utworzone przez architekta.
Specyfikacja techniczna
Specyfikacja techniczna opisuje sposób na podstawie zakresu i celów opisanych w specyfikacji funkcjonalnej. Ta specyfikacja jest przeznaczona dla zespołu inżynierów do użycia jako plan rekordu podczas implementacji.
W tej specyfikacji znajdują się elementy, takie jak:
- Decyzje technologiczne, w tym: kupowanie, kompilowanie, ponowne używanie, rozszerzanie lub likwidowanie.
- Kontrakty interfejsu API i danych (schematy), w tym strategia implementacji zgodności z poprzednimi wersjami
- Szczegóły implementacji wdrażania i wycofywania
- Unikatowa implementacja bezpiecznego cyklu projektowania (SDL) i prywatności
- Plan testu
- Kluczowe źródła sygnałów monitorowania i alertów
- Alternatywne projekty, które zostały uznane
Specyfikacja techniczna będzie prowadzić do wysiłków inżynieryjnych. Elementy robocze inżynieryjne są tworzone głównie na podstawie zawartości tej specyfikacji. Zespoły implementacji odwołują się do elementów roboczych, specyfikacji technicznej i specyfikacji funkcjonalnej, aby upewnić się, że ostateczny wynik spełnia zarówno wymagania funkcjonalne, jak i niefunkcjonalne.
Plany odzyskiwania po awarii
Aby spełnić wymagania dotyczące niezawodności obciążenia, architekt musi zaprojektować system, który może odzyskać dane w ramach docelowego celu czasu odzyskiwania (RTO) i celu punktu odzyskiwania (RPO). Specyfikacja projektu architektury musi zawierać plan odzyskiwania. Ten plan musi obejmować powiązane składniki architektury, mechanizmy trybu failover i wpływ na przepływ użytkowników i danych oraz zalecenia operacyjne. Powinien on opisywać cele odzyskiwania, które są spełnione zgodnie z projektem i w jaki sposób.
Mimo że początkowy plan ma ewoluować w oparciu o szczegółowe informacje z przeglądów przechodzenia do szczegółów i przeglądów po zdarzeniu, jest to odpowiedzialność architekta za dostarczenie początkowego planu dla całej nowej architektury.
Dokumentacja dotycząca zabezpieczeń i zgodności
Architekt jest odpowiedzialny za projektowanie rozwiązania zgodnego z obowiązującymi ograniczeniami zabezpieczeń i zgodności. Ważne jest, aby artefakty projektowe wyróżniały dostępność uwzględnioną w projekcie, aby obsługiwać te wymagania, oraz zidentyfikować wszelkie niezbędne mechanizmy kontroli wyrównujących, gdy wymagania nie mogą być spełnione bezpośrednio.
Spójność
Użyj szablonu, aby udokumentować różne specyfikacje obciążenia. Spójność pomaga uczestnikom projektu, stronom odpowiedzialnym i zespołom ds. implementacji podczas odczytywania specyfikacji.
Upewnij się, że specyfikacje mają kluczowe pola metadanych, takie jak:
- Stan: Stan jako Wersja robocza, W przeglądzie i Zatwierdzony.
- Link do elementu roboczego: link do podstawowego elementu roboczego na liście prac zespołu.
- Kluczowe linki krzyżowe: linki do powiązanych specyfikacji lub inną dokumentację, która obsługuje specyfikację.
- Kluczowe osoby: miejsce do wyświetlenia listy nazwisk zaangażowanych kluczowych osób podejmujących decyzje. Ta lista może obejmować role, takie jak: analityk biznesowy, partner biznesowy, lider techniczny oraz właściciel produktu lub potencjalnego klienta, który podpisał specyfikację.