Więcej krótszych projektów dla biznesu

Biznes zwykle nie chce czekać na nowe narzędzia informatyczne. Oczekuje, że zostaną stworzone niemal natychmiast. Odpowiedzią na ten problem ma być architektura SOA.

Coraz rzadziej mówi się o pojedynczych aplikacjach opartych na architekturze usługowej. I nic dziwnego. Idea tego modelu zakłada przecież tworzenie całego środowiska aplikacyjnego w oparciu o maksymalne wykorzystanie tych samych elementów. Stąd wynika jednak konieczność długofalowego planowania rozwoju organizacji SOA. "Planowanie w tym kontekście, to ocena, gdzie jesteśmy w kontekście potrzeb biznesu, gdzie chcemy być, jakie zmiany potrzebujemy wprowadzić i wreszcie jakie usługi SOA będą im służyć" - mówił Ian Goldsmith, wiceprezes firmy SOA Software podczas zorganizowanej przez Computerworld III konferencji SOA Executive Forum.

Zarządzanie środowiskiem aplikacyjnym opartym na architekturze SOA wymaga skrócenia procesów decyzyjnych. "Cykl życia typowych aplikacji to okres od kilkunastu miesięcy do nawet kilku lat. W przypadku SOA trzeba błyskawicznie decydować o tym, co w danym momencie ma priorytet" - twierdzi Ian Goldsmith. Jednak im więcej komponentów potencjalnie składających się na określone funkcjonalności biznesowe, tym trudniejsze jest zarządzanie środowiskiem aplikacyjnym. Pojawia się więc potrzeba wdrożenia metod i narzędzi pozwalających na automatyzację procesów. Praktyka pokazuje również, że wiele problemów pojawiających się na etapie tworzenia aplikacji opartych na założeniach SOA wynika z braku jasnych procedur postępowania oraz ubogiej dokumentacji technicznej. Ian Goldsmith uważa, że szczegółowe opisanie mechanizmów integracji i zasad zgodności dla różnych klas komponentów może w istotnym stopniu skrócić cykl tworzenia oprogramowania. Na każdym etapie tworzenia aplikacji w architekturze zorientowanej usługowo muszą być brane pod uwagę kwestie bezpieczeństwa i wydajności komponentów oraz usług, a także ich spójności z innymi rozwiązaniami korporacyjnymi. Z drugiej jednak strony, cały proces akceptacji i weryfikacji tworzonych elementów systemu powinien być maksymalnie skrócony.

Natomiast z punktu widzenia twórców aplikacji kompozytowych, czy raczej ich samodzielnych komponentów, konieczne jest przejście na wyższy poziom abstrakcji i odejście od typowego modelu tworzenia oprogramowania. "Aplikacje kompozytowe to święty Graal SOA. Ideałem jest, żeby klient biznesowy mógł z gotowych komponentów sam tworzyć dla siebie takie aplikacje, jakich mu potrzeba" - mówi Ian Goldsmith. Zadaniem deweloperów jest tylko tworzenie poszczególnych usług lub ich integracja. Kontekst całej aplikacji schodzi na dalszy plan. Wobec tego rośnie waga dopracowania wszystkich elementów składowych oprogramowania opartego na architekturze SOA.