기업의 IT 환경은 복잡합니다.
예전과는 달리 어느 한두가지 표준과 아키텍쳐를 정의하여 모든 부분에 강제 할 수 없고, 아웃소싱 회사들이 권유하는 다양한 표준과 방법론, 아키텍쳐가 공존 합니다. 패키지 솔루션과 Business-in-a-Box, 서비스로서 완결된 사업 솔루션의 도입과 최근 유행하는 SaaS 기반 솔루션 도입으로 인해서 복잡성은 예측하기 어려운 수준으로 증가하고 있습니다. 표준화를 통해서 생산성을 제고하는 방안은 이제는 진부한 느낌이고 다양성을 IT 운영의 뉴노멀로 인식하여 관리와 품질 수준을 유지,개선 시켜나갈 방안을 모색해야 합니다.
사업혁신과 사업환경 변화에 발맞춰가려면 개발과 운영 조직간의 소통과 협업이 더욱 강조되어야 하지만 기존의 프로세스와 관행으로는 이 또한 쉽지 않습니다
기업의 IT 아키텍쳐는 다양해지고 복잡해지고 있습니다.
과거 메인프레임에서 Client-Server, 웹, 인트라넷에서 2000 년 이후 SOA, SaaS 와 같은 콤포짓 애플리케이션과 국내에서는 차세대 프레임워크의 도입, Web2.0 으로 발전해가고 있고
복잡성은 더욱 심화 되어 갑니다. 복잡도의 증가는 비용, 제약조건의 증가와 조직 측면에서 아웃소싱 비율의 증가, 공정 분리, 비즈니스 요구의 증가를 동반 하는 양상을 보입니다. 그럼에도 불구하고 레거시웹 출현이후로 소프트웨어 딜리버리 주기를 관리하는 역량과 이를 지원하는 관리도구에는 눈에 띄는 변화가 없었다는 점에 주목할 필요가 있습니다
기업에서 운영이관 또는 릴리즈 절차는 과거나 지금이나 여전히 수십명이 철야로 대기하는 작업이고 개발과 운영서버를 가급적 동일하게 맞춘다 해도 완전히 같지는 않아서 예측하기 어려운 오류와 로직의 결함이 발생되기도 합니다. 결함이 발생되면 루트 CAUSE 를 찾기 위해 다 같이 밤을 지새고, 이러한 모습은 10 년전이나 지금이나 크게 다르지 않습니다
아키텍쳐는 멀티티어 애플리케이션에서 분산-컴포짓 애플리케이션 (Composite Application) 으로 분화되어갑니다.컴포짓 애플리케이션이란 데이터 소스가 서로 다른
Ready-made 컴포넌트들을 조합하여 비즈니스 스위트를 구성하는 사례들이 이에 해당합니다. 불과 수년전만 해도 레이어드 아키텍쳐 도입에 따른 트랜잭션 관리, 워크로드 분산이 IT 이슈였다면 최근에는 내외부의 다양한 시스템들과의 연동, 매쉬업, OpeAPI, SaaS/PaaS 연동 등 IT 운영 주체로서는 완전히 통제-제어하기 어려운 엔티티들과의 통합 요구가 증가하고 있습니다 이에 따라서 개발생산성의 저하, 서비스 품질의 저하 위험이 증가되고 나아가서는 사업환경 변화에 동태적 대응 취약성 우려가 점차 커지고 있습니다.
최근 유행하는 애자일 방법론 도입으로 인해서 IT 운영은 더욱 어려워지고 있습니다.
기존의 CBD, IE, RUP, RAD 와 같은 워터폴 방식에 비해서 애자일 개발은 반복적, 점진적 개발-테스트가 수행된다는 점, 소규모 배포가 여러차례 반복된다는 점을 들 수 있습니다. 애자일 개발을 하다보면 프로젝트 중반 이후로는 이터레이션간의 통합테스트, 도메인 오브젝트 간의 통합테스트가 반복되고 소규모 배포가 반복적으로 진행되서 역동성과 다변성이 일정 내내 상존한다고 볼 수 있습니다. 최근의 IT 동향이 Lean & Agile 로 가고 있어서 많은 사업에서 애자일 도입을 검토하고 있지만 기존 방법론의 성숙도를 따라잡으려면 아직 상당한 시간이 필요할 것으로 예상됩니다
예를들어 계획 수립당시 이터레이션의 규모와 일의 양을 잘못 산정해서 또는 크리티컬 패스의 오류로 인해서 중요 이터레이션에 지연이 발생하면 이를 참조하는 모든 이터레이션의 순연이 불가피하게 되고 계획 수립 단계에서 버퍼를 고려하지 않았다면 프로젝트 종반에는 순연으로 인해 적체된 일의 볼륨이 기하 급수적으로 증가하게 되는 현상을 겪게 됩니다.
전반적인 일정지연과 관리 위험이 증가되고 이에 따라서 관리비용도 함께 늘어납니다. 결과적으로 적시 사업지원이 어렵게 되는 위험을 예상할 수 있습니다
개발 프로세스 중에는 그림에서 보시는 바와 같이 Idle Time 이 많습니다 (Gray Box)
옆자리 개발자 작업이 완료되어야 해서 기다리는 경우도 있고 때로는 연동하는 백엔드 시스템의 장애로 인한 문제도 있고 3RD 파티 솔루션의 설치가 늦어지는 경우, 외부 연계 서비스의 구매가 늦어지는 경우 등 이유는 다양합니다. Idle Time 최소화하고 실제 작업시간을 최대화 하는 것이 Time-to-market 을 가속화 하는 방안이 될텐데요, 여기에는 네가지 도전과제 (4C) 가 있습니다
1. 종속성 제약조건으로서 Constraints
2. 아키텍쳐 복잡성에 따른 문제 Complexity
3. 개발-운영간 소통과 협업의 단절로 인한 문제 Collaboration
4. 개발-운영중 지속적인 모니터링 방안 확보 문제 Complete Visibility
이상의 4C 는 사업으로 부터의 지속적인 피드백과 이에 대응하는 지속적인 딜리버리 체계를 수립하기 위한 선결요건 입니다
예전과는 달리 어느 한두가지 표준과 아키텍쳐를 정의하여 모든 부분에 강제 할 수 없고, 아웃소싱 회사들이 권유하는 다양한 표준과 방법론, 아키텍쳐가 공존 합니다. 패키지 솔루션과 Business-in-a-Box, 서비스로서 완결된 사업 솔루션의 도입과 최근 유행하는 SaaS 기반 솔루션 도입으로 인해서 복잡성은 예측하기 어려운 수준으로 증가하고 있습니다. 표준화를 통해서 생산성을 제고하는 방안은 이제는 진부한 느낌이고 다양성을 IT 운영의 뉴노멀로 인식하여 관리와 품질 수준을 유지,개선 시켜나갈 방안을 모색해야 합니다.
사업혁신과 사업환경 변화에 발맞춰가려면 개발과 운영 조직간의 소통과 협업이 더욱 강조되어야 하지만 기존의 프로세스와 관행으로는 이 또한 쉽지 않습니다
기업의 IT 아키텍쳐는 다양해지고 복잡해지고 있습니다.
과거 메인프레임에서 Client-Server, 웹, 인트라넷에서 2000 년 이후 SOA, SaaS 와 같은 콤포짓 애플리케이션과 국내에서는 차세대 프레임워크의 도입, Web2.0 으로 발전해가고 있고
복잡성은 더욱 심화 되어 갑니다. 복잡도의 증가는 비용, 제약조건의 증가와 조직 측면에서 아웃소싱 비율의 증가, 공정 분리, 비즈니스 요구의 증가를 동반 하는 양상을 보입니다. 그럼에도 불구하고 레거시웹 출현이후로 소프트웨어 딜리버리 주기를 관리하는 역량과 이를 지원하는 관리도구에는 눈에 띄는 변화가 없었다는 점에 주목할 필요가 있습니다
기업에서 운영이관 또는 릴리즈 절차는 과거나 지금이나 여전히 수십명이 철야로 대기하는 작업이고 개발과 운영서버를 가급적 동일하게 맞춘다 해도 완전히 같지는 않아서 예측하기 어려운 오류와 로직의 결함이 발생되기도 합니다. 결함이 발생되면 루트 CAUSE 를 찾기 위해 다 같이 밤을 지새고, 이러한 모습은 10 년전이나 지금이나 크게 다르지 않습니다
아키텍쳐는 멀티티어 애플리케이션에서 분산-컴포짓 애플리케이션 (Composite Application) 으로 분화되어갑니다.컴포짓 애플리케이션이란 데이터 소스가 서로 다른
Ready-made 컴포넌트들을 조합하여 비즈니스 스위트를 구성하는 사례들이 이에 해당합니다. 불과 수년전만 해도 레이어드 아키텍쳐 도입에 따른 트랜잭션 관리, 워크로드 분산이 IT 이슈였다면 최근에는 내외부의 다양한 시스템들과의 연동, 매쉬업, OpeAPI, SaaS/PaaS 연동 등 IT 운영 주체로서는 완전히 통제-제어하기 어려운 엔티티들과의 통합 요구가 증가하고 있습니다 이에 따라서 개발생산성의 저하, 서비스 품질의 저하 위험이 증가되고 나아가서는 사업환경 변화에 동태적 대응 취약성 우려가 점차 커지고 있습니다.
최근 유행하는 애자일 방법론 도입으로 인해서 IT 운영은 더욱 어려워지고 있습니다.
기존의 CBD, IE, RUP, RAD 와 같은 워터폴 방식에 비해서 애자일 개발은 반복적, 점진적 개발-테스트가 수행된다는 점, 소규모 배포가 여러차례 반복된다는 점을 들 수 있습니다. 애자일 개발을 하다보면 프로젝트 중반 이후로는 이터레이션간의 통합테스트, 도메인 오브젝트 간의 통합테스트가 반복되고 소규모 배포가 반복적으로 진행되서 역동성과 다변성이 일정 내내 상존한다고 볼 수 있습니다. 최근의 IT 동향이 Lean & Agile 로 가고 있어서 많은 사업에서 애자일 도입을 검토하고 있지만 기존 방법론의 성숙도를 따라잡으려면 아직 상당한 시간이 필요할 것으로 예상됩니다
예를들어 계획 수립당시 이터레이션의 규모와 일의 양을 잘못 산정해서 또는 크리티컬 패스의 오류로 인해서 중요 이터레이션에 지연이 발생하면 이를 참조하는 모든 이터레이션의 순연이 불가피하게 되고 계획 수립 단계에서 버퍼를 고려하지 않았다면 프로젝트 종반에는 순연으로 인해 적체된 일의 볼륨이 기하 급수적으로 증가하게 되는 현상을 겪게 됩니다.
전반적인 일정지연과 관리 위험이 증가되고 이에 따라서 관리비용도 함께 늘어납니다. 결과적으로 적시 사업지원이 어렵게 되는 위험을 예상할 수 있습니다
개발 프로세스 중에는 그림에서 보시는 바와 같이 Idle Time 이 많습니다 (Gray Box)
옆자리 개발자 작업이 완료되어야 해서 기다리는 경우도 있고 때로는 연동하는 백엔드 시스템의 장애로 인한 문제도 있고 3RD 파티 솔루션의 설치가 늦어지는 경우, 외부 연계 서비스의 구매가 늦어지는 경우 등 이유는 다양합니다. Idle Time 최소화하고 실제 작업시간을 최대화 하는 것이 Time-to-market 을 가속화 하는 방안이 될텐데요, 여기에는 네가지 도전과제 (4C) 가 있습니다
1. 종속성 제약조건으로서 Constraints
2. 아키텍쳐 복잡성에 따른 문제 Complexity
3. 개발-운영간 소통과 협업의 단절로 인한 문제 Collaboration
4. 개발-운영중 지속적인 모니터링 방안 확보 문제 Complete Visibility
이상의 4C 는 사업으로 부터의 지속적인 피드백과 이에 대응하는 지속적인 딜리버리 체계를 수립하기 위한 선결요건 입니다
댓글 없음:
댓글 쓰기