디지털 혁신의 가장 큰 영향 중 하나는 애플리케이션 개발의 중단입니다. 전통적으로, 앱 개발에 새로운 아키텍처를 도입하는 경우 본격적으로 작동하고 주류로 채택되기까지는 보통 몇 년이 걸립니다. 결국 전체 산업을 휩쓸고 지나가는 애플리케이션 아키텍처가 사실상의 표준이 됩니다. 우리는 1990년대 중반부터 후반에 J2EE가 3계층 웹 애플리케이션을 개발하기 위한 "엔터프라이즈 표준"으로 천천히 그러나 확실하게 자리 잡으면서 이러한 일이 일어나는 것을 보았습니다.
오늘날, "고정"되어 새로운 표준이 될 것으로 보이는 아키텍처는 클라우드 네이티브입니다. 이러한 컨테이너 기반 마이크로서비스 아키텍처는 모든 산업의 새로운 개발 프로젝트를 주도하는 방향으로 빠르게 이동하고 있습니다. 이러한 애플리케이션의 상당수가 배포되어 운영되는 Kubernetes의 성공적인 성장은 이 최신 앱 아키텍처가 지속될 것임을 보여줍니다. 우리 조사에 따르면 조직의 절반 이상이 디지털 혁신으로 인해 "새로운 아키텍처"를 모색하고 있는 것으로 나타났습니다.
이는 조직이 '근대화' 여정에 있다는 의미로 해석되는 경우가 많습니다. 그리고 우리(업계)는 현대화에 대해 매우 일반적이고 느슨한 용어로 이야기하는 경향이 있습니다. 마치 조직들이 마법의 지팡이를 휘두르기만 하면 모든 애플리케이션이 이 새로운 모델을 기반으로 구축될 것처럼 말입니다.
실제로 조직이 애플리케이션을 현대화할 수 있는 방법은 다양합니다. 일부(37%)만이 리팩토링 방식을 추구하고 있습니다. 리팩토링 방법은 다양하지만 가장 인기 있는 방법 중 하나는 Red Green Refactor입니다. 하지만 준비적 리팩토링과 다양한 추상화 기반 옵션을 포함하여 선택할 수 있는 다른 옵션도 있습니다. 대부분은 코드를 단순화하는 데 기반을 둡니다. 다시 말해, 그들은 애플리케이션을 다시 작성하는 데 있어 방해가 덜한 방식을 주로 사용합니다.
하지만 때로는 완전히 다시 작성하는 것이 현대화를 위한 최선의 전략인 경우도 있습니다. 일반적으로 기존 레거시 애플리케이션을 완전히 다시 작성하려면 엄청난 노력이 필요하며, 이는 가장 결단력 있는 디지털 전환 옹호자조차도 꺼리게 만들 수 있습니다. 하지만 어떤 경우에는 상당한 비용 절감 효과를 얻을 수 있습니다.
연방 기관이 애플리케이션 포트폴리오를 현대화하기 위해 취하는 접근 방식을 생각해 보겠습니다. Agile 방법론으로 전환하라는 명령에 따라 운영되는 이 기관은 기존의 폭포수 방식으로 애플리케이션을 개발하기 위해 특별 허가가 필요했습니다. 글쎄요, 제가 코딩을 할 당시에는 폭포수 방식이 주로 사용되었거든요. 그러니까 오래된 방법이죠. 이 기관은 자사 포트폴리오를 이해하고 각 신청의 필요성을 합리화하는 것부터 시작하는 것이 가장 좋다고 결정했습니다.
감사 과정에서 그들은 약 6,000개의 애플리케이션 중에서 동일한 기본 자산 관리 작업을 수행하는 애플리케이션이 거의 200개라는 것을 발견했습니다. 잠시, 기본적인 비즈니스 기능에 변화가 생겨 200개의 모든 애플리케이션을 수정해야 한다고 상상해보세요.
동일한 비즈니스 기능을 개발, 테스트, 배포하려면 개발자와 운영자가 많은 시간과 노력이 필요합니다.
해당 기관은 모든 200개 애플리케이션을 단일 마이크로서비스로 교체하여 기관 전반에서 자산을 추적할 수 있는 방식으로 현대화를 결정했습니다. Agile 방법론을 사용하여 개발되고 현대적인 환경에서 운영되므로, 지금까지 개별적이고 비공개적인 애플리케이션에 의존해 왔던 모든 기능의 요구 사항을 충족하도록 확장할 수 있습니다.
모든 현대화 노력이 리팩토링에 초점을 맞추는 것은 아닙니다. 현대화가 전체 애플리케이션 포트폴리오에 미치는 영향을 전략적으로 탐색하면 상당한 비즈니스 이점을 얻을 수 있습니다. 특히 수십 년 동안 운영되어 온 많은 조직은 동일한 포트폴리오 문제, 즉 중복에 부딪힐 가능성이 높습니다. 구조 조정, 인수, 합병 및 경영진 변경으로 인해 신청서 중복이 매우 쉽게 발생할 수 있습니다.
모든 조직에서는 현대화 전략의 일환으로 애플리케이션 감사 및 합리화를 실시하는 것이 유익할 것입니다. 수백 개의 신청서가 있지만 그 중 일부만 필요할 수도 있습니다. 이런 종류의 전략을 통해 리더는 앱 중복을 제거하고 이로 인해 발생하는 비용을 제거하기 위해 새로운 아키텍처에서 개발된 완전히 새로운 애플리케이션을 정당화할 수 있습니다.