추상
IBM i 애플리케이션을 현대화하거나 미래형 플랫폼으로 마이그레이션하는 것에 대한 강력한 권장 사항이 있으며 마이그레이션 반대 정서를 유발하는 강력한 주저도 있습니다. 이것은 우리를 질문으로 이끕니다. 우리는 기술에 투자해야합니까
기존 플랫폼의 여부
살펴보기
IBM i는 레거시 시스템이므로 여러 가지 이유로 많은 기업에서 마이그레이션 대상입니다. 여기 이 블로그에서 우리는 오늘날의 시나리오에서 사용 가능한 마이그레이션 옵션, 채택 가능성, 빠른 추적이 불가능한 이유에 대해 알아볼 것입니다.
마이그레이션 또는 퇴장 및 개발 인력 향상의 필요성.
IBM i(일반적으로 AS/400으로 알려짐)는 BFSI(은행, 금융 서비스 및 보험)를 비롯한 많은 중견 기업을 위한 가장 전략적인 시스템 중 하나였습니다. 이 모든 기업에서 25~30년 이상 사용하고 있습니다. 그것은 핵심을 호스팅
Core Banking, Card Management, Policy Administration 등을 포함한 은행 및 보험사를 위한 애플리케이션입니다. 여기서 논의하는 IBM i는 IBM i, 하드웨어, 운영 체제, RPG와 같은 프로그래밍 언어와 함께 제공되는 전체 에코시스템입니다.
COBOL 및 CL, i용 데이터베이스 DB2, 메시징, 작업 관리, 사용자 액세스, 보안용 IBM MQ 도전
IBM i 플랫폼 관련 기술(RPG, COBOL), 민첩성 문제로 이어지는 애플리케이션의 모놀리스 아키텍처, 다른 플랫폼 및 DevOps 도구와의 상호 운용성, 전략적 투자에 부합하지 않음, 대부분의 클라우드 이점(예:
온디맨드 용량) 등. 동시에 마이그레이션이 연기되는 데에는 여러 가지 이유가 있습니다. 그 중 일부는 새로운 하드웨어 릴리스, OS 릴리스, 확장된 지원 기간, 현재 대규모 인프라에 대한 투자, 마이그레이션 위험 및 비용입니다.
여기서 우리는 중소기업에 대한 의존도를 예측할 수 있도록 조기 철수 가능성을 측정하려고합니다.
우리의 관점
그 기간 동안 비즈니스가 성장하고 비즈니스 요구 사항이 증가했으며 다양한 위험이 증가했으며 규정 준수 및 규정 요구 사항이 증가했으며 결국 이러한 모든 사항이 각 단일 단일 애플리케이션 내에서 포착 및 처리되었습니다.
기업. 따라서 모든 지식, 비즈니스 규칙, 비즈니스 프로세스가 집중된 높은 수준의 복잡성이 발생합니다. 여기에 멀티 스레딩, 메시징, 작업 스케줄링, 작업 제어 등과 같은 모든 기술 구현이 추가되었습니다.
또한 모놀리스 구현의 일부입니다.
클라우드, DevOps 및 Agile 사례의 출현으로 은행가와 보험사를 포함한 산업 및 기업은 최신 기능과 이점을 활용하기 위해 IBM i 애플리케이션의 혁신을 모색하고 있습니다. 기업에는 다양한 옵션이 있습니다.
그들 앞에서. 이 플랫폼은 애자일 방식을 따르고 ARCAD 솔루션을 통해 DevOps 세계의 일부가 될 수 있습니다. 영국의 한 대형 은행이 IBM i에서 DevOps를 성공적으로 채택했습니다. 최근 출시된 IBM i Merlin Platform(Modernization Engine for Lifecycle
통합)은 IBM i 가상 머신 프로비저닝, REST API 관리 등과 함께 DevOps 경험을 위한 통합 IDE, CI/CD Merlin 도구를 사용하여 이를 돕고 향후 완전한 DevOps 에코 시스템에 대한 희망을 가져옵니다. 최근 개발은 민첩성에 도움이 됩니다.
IBM i 환경 및 해당 애플리케이션을 다시 호스팅합니다. 이 플랫폼의 시스템 관리는 인프라를 IBM Cloud, Skytap on Azure 및 IBM Cloud 또는 Connectria on AWS로 직접 마이그레이션하여 오프로드됩니다. 인피니트 아이가 재회를 위해 구출 중입니다.
Azure, AWS 또는 Google Cloud의 애플리케이션. 이러한 모든 옵션은 현재 위치 현대화 또는 유사 현대화로 분류되며 IBM i 기술 세트에 종속됩니다.
Fresche, Google(G4)의 도구 세트는 IBM i 기본 소스 코드의 일대일 변환(리팩터링)을 제공하고 개방형 시스템 및 클라우드에 애플리케이션을 배치하기 위한 게이트웨이를 엽니다. 그러나 이 옵션에 대한 선호도는 유지 관리 가능성을 고려하여 희미해지고 있습니다.
은행과 같은 대기업에 대한 미래적 관점. 은행, 특히 보험사는 규제 및 규정 준수 요구가 계속 증가하고 따라서 유지 관리가 용이한 코드 기반이 필요한 것과 같이 매우 역동적인 비즈니스 요구 사항을 가지고 있습니다.
현재 위치 현대화(최후의 수단) 및 리팩터링을 남겨두고 다른 옵션은 COTS 대체 또는 전체 애플리케이션 다시 작성이라는 두 가지 옵션 중 하나로 크게 그룹화할 수 있습니다. 이러한 옵션에는 장단점이 있습니다. 대부분의 경우
중대형 은행과 여러 국가 또는 여러 지역에서 운영되는 은행의 경우 핵심 애플리케이션은 자산, 강점, 존재의 원동력입니다. 따라서 COTS 응용 프로그램의 정확한 장착으로 인해 COTS 채택률이 제한됩니다.
카드 처리, 충성도 및 보상 관리와 같은 은행의 풍부한 기능을 위해
이제 은행에는 다시 쓰기라는 다른 옵션이 남아 있습니다. 모두가 알다시피 기존 애플리케이션(기능적으로 동일하지만 구조적으로 최신)을 대상 환경에 다시 작성하는 것은 새 애플리케이션을 구축하는 것과 거의 같습니다. 리버스 엔지니어링
Fresche 및 ARCAD의 도구는 규칙 추출 속도를 높이는 데 도움이 됩니다. Agile, DevOps, Test Automation 등으로 구동되는 새로운 개발 방식으로 재작성은 그리 오래 걸리지는 않지만 짧지도 않을 것입니다. 일부 대형 은행에서 재작성 시도
그리고 실험하고 있습니다. 많은 은행들이 재작성에 관심을 보이고 있지만 비용 효율적이고 강력하며 위험이 없거나 아직 덜한 위험 마이그레이션을 찾고 있습니다.
재작성에 대한 예상 일정 외에도 대상 환경에 대한 전략적 결정, 대상 기술, 대상 아키텍처, 규정 및 규정 준수 문제, 혁신 활동을 채택하기 위한 조직 변경,
현재 대규모 인프라 등에 대한 투자는 대부분의 은행에 대한 전체 IBM i 마이그레이션 일정에 영향을 미칠 것입니다.
또한 IBM은 이 플랫폼을 유지하기 위한 추진력을 유지하기 위해 개방형 기술에 대한 지원과 함께 Power 서버(10년 출시된 Power2021 기반 서버) 및 IBM i(7.5년 2022월 출시된 XNUMX)를 지속적으로 투자하고 업그레이드하고 있습니다.
지원 기간(일반적으로 7+3년 – 일반 + 연장)과 다른 환경(AIX)에 대한 Power 서버의 재사용성은 의사 결정을 위한 추가 공간을 제공하는 중요한 요소 중 일부입니다(플랫폼을 종료하기 위해 서두르지 않음).
결론
이러한 모든 요인으로 인해 IBM i 애플리케이션을 실행해야 하는 필요성은 앞으로도 계속 높게 유지됩니다. 이는 기업이 실행 가능한 효과적인 대안을 찾을 때까지 이러한 응용 프로그램을 지원, 유지 관리 및 향상해야 함을 의미합니다. 그러나
동시에 IBM i 기술 세트에 인력을 참여시키는 것이 점점 더 어려워지고 있습니다. 이제 이 플랫폼을 위한 향상된 IDE 및 도구를 활용하여 개발 인력을 향상할 때입니다.
