애플리케이션 포트폴리오 관리

Application portfolio management

APM(IT Application Portfolio Management)은 1990년대 중반부터 중대형 정보 기술(IT) 조직에서 등장한 관행입니다.[1]Application Portfolio Management는 재무 포트폴리오 관리의 교훈을 활용하여 애플리케이션의 유지 및 운영 비용과 비교하여 각 애플리케이션의 재정적 이점을 정당화하고 측정하려고 시도합니다.

관행의 진화

애플리케이션 포트폴리오에 대해 가장 먼저 언급된 것은 1974년 사이러스 깁슨과 리처드 놀란의 HBR 기사 "EDP 성장의 4단계 관리"에서였을 가능성이 높습니다.[2]

깁슨과 놀란은 예측 가능한 단계에서 IT에 대한 기업의 이해와 성공적인 사용이 "성장"하고 있으며, 전체 IT 지출을 분석하는 맥락에서 애플리케이션 포트폴리오, 사용자 인식, IT 관리 관행 및 IT 리소스를 관찰함으로써 해당 단계를 통한 기업의 발전을 측정할 수 있다고 말했습니다.

Nolan, Norton & Co.는 DuPont, Deere, Union Carbide, IBM 및 Merrill Lynch 등의 연구를 통해 이러한 개념을 실제로 사용할 수 있도록 개척했습니다.이러한 "단계 평가"에서 이들은 각 애플리케이션이 각 비즈니스 기능이나 프로세스를 지원하거나 "적용"하는 정도, 애플리케이션에 대한 지출, 기능적 품질 및 기술적 품질을 측정했습니다.이러한 조치를 통해 비즈니스에 IT가 적용되는 상황, 장단점, 개선 로드맵 등을 종합적으로 파악할 수 있었습니다.

APM은 날짜가 2000년으로 변경되었을 때(2000년 또는 Y2K로 알려지게 된 위협) 조직이 애플리케이션 실패 위협에 대처하기 시작하면서 1980년대 후반과 1990년대에 널리 채택되었습니다.[3]이 기간 동안 전 세계 수만 개의 IT 조직이 각 애플리케이션에 대한 정보를 포함한 포괄적인 애플리케이션 목록을 개발했습니다.

많은 조직에서 Y2K 리스크를 해결하는 데 드는 비용을 우려하는 비즈니스 리더들은 이 리스트를 개발하는 가치에 도전했습니다.일부 조직에서는 애플리케이션 실패의 위험을 관리하는 것 이상으로 업무를 수행하는 데 따른 이점으로 정보 기술 예산을 담당하는 비즈니스 담당자에게 포트폴리오를 관리한다는 개념이 제시되었습니다.

애플리케이션 포트폴리오 관리 솔루션에는 일반적으로 'Top Down' 접근 방식과 'Bottom Up' 접근 방식이라는 두 가지 주요 범주가 있습니다.[4]모든 조직에서 가장 먼저 필요한 것은 어떤 애플리케이션이 존재하는지, 그리고 애플리케이션의 주요 특성(예: 유연성, 유지 관리성, 소유자 등)을 이해하는 것이며, 이를 일반적으로 '인벤토리'라고 합니다.APM에 대한 또 다른 접근 방식은 애플리케이션 소스 코드 및 관련 구성 요소를 저장소 데이터베이스(예: 'Bottom Up')로 구문 분석하여 포트폴리오의 애플리케이션을 상세하게 이해하는 것입니다.현재 APM 도구로 판매되고 있는 애플리케이션 마이닝 도구는 이러한 접근 방식을 지원합니다.

'Top Down' 접근 방식을 지원하는 수백 가지 도구를 사용할 수 있습니다.대부분의 작업은 올바른 정보를 수집하는 것이기 때문에 이는 놀라운 일이 아닙니다. 정보의 실제 유지 보수 및 저장은 비교적 쉽게 구현할 수 있습니다.그러한 이유로 많은 조직들이 상용 도구를 우회하여 재고 데이터를 저장하기 위해 마이크로소프트 엑셀을 사용합니다.하지만 재고가 복잡해지면 엑셀은 유지관리가 번거로워질 수 있습니다.자동으로 데이터를 업데이트하는 것은 엑셀 기반의 솔루션에서는 잘 지원되지 않습니다.마지막으로, 이러한 Inventory 솔루션은 'Bottom Up'의 이해 요구와는 완전히 별개입니다.

APM을 위한 비즈니스 케이스

Forrester Research에 따르면, "IT 운영 예산의 경우 기업은 지속적인 운영 및 유지보수에 3분의 2 이상을 지출합니다."[5]

동일한 기능을 수행하는 여러 시스템을 보유한 조직을 찾는 것이 일반적입니다.이러한 중복에는 부서 컴퓨팅의 중요성, 1970년대와 1980년대의 애플리케이션 사일로, 기업 인수합병의 확산, 새로운 도구를 채택하려는 실패한 시도 등 많은 이유가 있을 수 있습니다.중복 여부와 관계없이 각 애플리케이션은 별도로 유지 관리되고 주기적으로 업그레이드되며 이중화로 인해 복잡성과 비용이 증가합니다.

대부분의 비용이 기존 IT 애플리케이션을 관리하는 데 사용되므로 애플리케이션의 현재 인벤토리와 리소스 소비의 투명성이 애플리케이션 포트폴리오 관리의 주요 목표가 됩니다.[6][7]이를 통해 기업은 다음과 같이 할 수 있습니다: 1) 부분적으로 그리고 완전히 중복된 애플리케이션을 식별 및 제거하고, 2) 안정성, 품질 및 유지관리 측면에서 애플리케이션의 상태를 정량화하고, 3) 애플리케이션의 비즈니스 가치/영향 및 각 애플리케이션이 비즈니스에 미치는 상대적 중요성을 정량화하고,4) 비즈니스 우선 순위의 맥락에서 애플리케이션의 상태와 중요도에 따라 리소스를 할당합니다.

또한 투명성은 전략적 계획을 수립하는 데 도움이 되며 비즈니스/IT 갈등을 확산시킵니다. 왜냐하면 비즈니스 리더들이 애플리케이션이 주요 비즈니스 기능을 어떻게 지원하는지, 운영 중단 및 품질 저하의 영향을 이해할 때,대화는 과도한 비용에 대해 IT를 탓하는 것에서 벗어나 기업의 우선순위를 지원하기 위해 귀중한 리소스를 가장 잘 사용하는 방법으로 전환됩니다.

포트폴리오

APM 실무자는 투자 포트폴리오 관리에서 아이디어를 얻어 애플리케이션을 구축하고 유지하는 비용, 생산된 비즈니스 가치, 애플리케이션의 품질 및 예상 수명을 포함하여 비즈니스 또는 조직에서 사용 중인 각 애플리케이션에 대한 정보를 수집합니다.[8]포트폴리오 관리자는 이 정보를 사용하여 소유 비용 및 제공되는 비즈니스 가치와 관련하여 IT 인프라의 성능에 대한 자세한 보고서를 제공할 수 있습니다.

응용프로그램의 정의

애플리케이션 포트폴리오 관리에서 애플리케이션의 정의는 매우 중요한 구성 요소입니다.많은 서비스 공급자는 이러한 정의에서 종종 논란이 되는 결과로 인해 조직에서 자체 정의를 만들 수 있도록 지원합니다.

[9]

  • 응용 소프트웨어 - 실행 가능한 소프트웨어 구성 요소 또는 하나 이상의 실행 가능한 소프트웨어 구성 요소(하나 이상)가 함께 배치되어 특정 비즈니스 목적을 위해 정보를 생성, 업데이트, 관리, 계산 또는 표시하는 데 필요한 일련의 단계의 일부 또는 전부를 제공하는 실행 가능한 소프트웨어 구성 요소입니다.카운트하려면 각 구성 요소가 다른 응용 프로그램의 구성 요소가 아니어야 합니다.
  • 소프트웨어 구성 요소 - 더 이상 분리할 수 없는 방식으로 하나의 배포 컨테이너에 포함된 실행 가능한 컴퓨터 명령 집합입니다.예를 들어 동적 링크 라이브러리, ASP 웹 페이지, 명령줄 "EXE" 응용 프로그램이 있습니다.ZIP 파일은 (ZIP 아카이브를 풀면) 소프트웨어 구성 요소를 더 쉽게 분해할 수 있기 때문에 0개 이상의 소프트웨어 구성 요소를 포함할 수 있습니다.

소프트웨어 애플리케이션 및 소프트웨어 구성요소는 IT 포트폴리오 관리를 목적으로 하는 애플리케이션 소프트웨어 클래스의 특정 인스턴스를 설명하는 데 사용되는 전문 용어입니다.IT 관리 또는 엔터프라이즈 아키텍처의 비전문가를 위한 정의는 애플리케이션 소프트웨어를 참조하십시오.

소프트웨어 애플리케이션 포트폴리오 관리의 기술과 실무는 조직에 설치된 애플리케이션 카탈로그를 작성하기 위해 애플리케이션에 대한 상당히 상세하고 구체적인 정의를 요구합니다.

응용프로그램에 대한 정의의 요구사항

애플리케이션의 정의는 애플리케이션 포트폴리오 관리의 맥락에서 다음과 같은 요구사항을 갖습니다.

  • 비즈니스 팀원들이 설명하고 이해하고 지원하는 것은 간단해야 합니다.
  • IT 그룹의 개발, 운영 및 프로젝트 관리가 합리적이어야 합니다.
  • 출력이 포트폴리오의 전체 비용인 복잡한 함수의 입력으로 유용해야 합니다.즉, IT 포트폴리오의 전체적인 비용을 초래하는 요인이 많습니다.애플리케이션의 수가 너무 많다는 것도 그러한 요인 중 하나입니다.따라서 애플리케이션의 정의는 해당 계산에서 유용해야 합니다.
  • 이것은 포트폴리오 최적화 및 단순화를 위해 목표와 관련하여 프로젝트를 판단하려는 엔터프라이즈 아키텍처 팀의 구성원들에게 유용해야 합니다.
  • 측정 가능한 '포트폴리오 단순화' 활동을 수행하는 사람이 기존의 두 응용프로그램의 경계를 단일 응용프로그램이라고 부를 수 있는 방식으로 단순하게 재정의할 수 없도록 응용프로그램의 경계를 명확하게 정의해야 합니다.

많은 조직이 IT 포트폴리오 관리 및 거버넌스 관행의 맥락에서 애플리케이션의 정의를 읽을 것입니다.그러한 이유로 이 정의는 작업 시작으로 간주되어야 합니다.

예

응용 프로그램의 정의는 명확하게 전달하기 어려울 수 있습니다.IT 조직에서는 팀 간, 심지어 한 IT 팀 내에서도 미묘한 정의 차이가 있을 수 있습니다.예를 제공하여 정의를 설명하는 데 도움이 됩니다.아래 섹션에서는 응용 프로그램, 응용 프로그램이 아닌 것 및 둘 이상의 응용 프로그램으로 구성된 것의 몇 가지 예를 제공합니다.

포함

이 정의에 따르면 다음과 같은 응용프로그램이 있습니다.

  • 세 가지 웹 서비스를 제공하는 웹 서비스 끝점:송장 작성, 송장 검색 및 송장 세부 정보 가져오기
  • 인보이스 작성을 위한 사용자 인터페이스를 제공하고 인보이스 작성 서비스를 호출하는 SOBA(서비스 지향 비즈니스 애플리케이션)입니다.(서비스 자체가 다른 애플리케이션이라는 점에 유의하십시오.)
  • 기업용 애플리케이션 스토어에 게시되어 직원 소유 또는 운영되는 휴대용 장치에 배포되어 데이터 및 서비스에 대한 인증된 액세스를 가능하게 하는 모바일 애플리케이션입니다.
  • 리치 클라이언트, 서버 기반 미들 계층 및 데이터베이스로 구성된 레거시 시스템.(예: 한 변경 사항이 다른 변경 사항을 트리거할 가능성이 매우 높습니다.)
  • 데이터베이스에서 데이터를 끌어와 공개 URL의 하위 사이트로 HTML 형식으로 게시하는 웹 사이트 게시 시스템.
  • 레이아웃 및 계산을 위해 정보를 쿼리하는 Microsoft Excel 워크북에 데이터를 제공하는 데이터베이스입니다.데이터베이스가 다른 응용프로그램(예: 레거시 시스템)에 이미 포함되어 있지 않은 경우 데이터베이스 자체가 응용프로그램이라는 점에서 흥미롭습니다.
  • 비즈니스 가치를 제공하는 일관된 재사용 가능 매크로 집합이 포함된 Excel 스프레드시트입니다.스프레드시트 자체가 응용프로그램의 배포 컨테이너(예: TAR 또는 CAB 파일)를 구성합니다.
  • 웹 응용 프로그램의 경험과 논리를 전달하기 위해 서로 함께 작동하는 ASP 또는 PHP 웹 페이지 세트입니다.커플링이 느슨할 경우 하위 사이트가 이 정의에 따라 별도의 애플리케이션으로 적합할 가능성이 완전히 있습니다.
  • (인간 상호 작용을 위한 것이 아니라) 기계 간 통신을 위해 설정된 웹 서비스 엔드포인트이지만 비즈니스 프로세스에서 하나 이상의 유용한 단계를 나타내는 것으로 합리적으로 이해될 수 있습니다.

제외

다음은 응용 프로그램이 아닙니다.

  • HTML 웹사이트.
  • 데이터를 포함하지만 해당 데이터를 사용하여 비즈니스 가치를 제공하는 일련의 단계에는 속하지 않는 데이터베이스입니다.
  • 구조적으로 가치를 제공하는 일련의 단계의 일부가 될 수 없는 웹 서비스입니다.예를 들어, 공유 스키마를 깨는 수신 데이터가 필요한 웹 서비스입니다.
  • 독립 실행형 배치 스크립트로, 각 데이터베이스에 전화를 걸어 두 데이터베이스의 내용을 비교한 다음 데이터 이상이 발견될 경우 모니터링 별칭으로 전자 메일을 보냅니다.이 경우 배치 스크립트는 두 데이터베이스 중 적어도 하나와 밀접하게 연결될 가능성이 매우 크므로 가장 밀접하게 연결된 데이터베이스를 포함하는 응용프로그램 경계에 포함되어야 합니다.

합성물

다음은 많은 응용 프로그램입니다.

  • 재사용 가능한 서비스 세트와 이러한 서비스를 활용하는 사용자 인터페이스로 구성된 복합 SOA 애플리케이션입니다.여기에는 적어도 두 개의 애플리케이션(사용자 인터페이스 및 하나 이상의 서비스 구성 요소)이 있습니다.각 서비스는 애플리케이션으로 계산되지 않습니다.
  • 데이터를 저장하기 위해 데이터베이스에 기록하는 레거시 클라이언트-서버 앱과 매크로를 사용하여 데이터베이스에서 데이터를 읽어 보고서를 표시하는 Excel 스프레드시트입니다.이 예에는 두 개의 앱이 있습니다.데이터베이스는 기존 앱과 함께 개발되고 제공되며 데이터베이스와 긴밀하게 연결되어 있기 때문에 분명히 레거시 앱에 속합니다.레거시 시스템이 Excel 스프레드시트와 동일한 저장 프로시저를 사용하는 경우에도 마찬가지입니다.

응용프로그램의 평가방법 및 조치방법

애플리케이션이나 정보 시스템을 평가하는 데 사용되는 다양한 유형(비재무적이거나 복잡한)의 다양한 측정 지표가 많이 있습니다.

투자수익률(ROI)

투자 수익률은 비즈니스 분석에 사용되는 가장 일반적인 성과 측정 및 평가 지표 중 하나입니다.ROI 분석(정확하게 적용될 경우)은 기존 정보 시스템을 평가하고 소프트웨어 인수 및 기타 프로젝트에 대한 정보에 입각한 의사결정을 내리는 강력한 도구입니다.그러나 ROI는 수익성 또는 재무 효율성을 평가하기 위한 특정 목적을 위해 설계된 메트릭입니다.정보 솔루션의 전반적인 경제적 그림을 제공하는 데 있어 다른 많은 재무 지표를 안정적으로 대체할 수 없습니다.ROI를 정보 시스템과 관련된 의사 결정을 위한 유일한 또는 주요 메트릭으로 사용하려는 시도는 생산적일 수 없습니다.매우 제한된 수의 사례/프로젝트에서 적절할 수 있습니다.ROI는 재정적인 척도이며 정보 시스템의 효율성이나 효과에 대한 정보를 제공하지 않습니다.[10]

경제적 부가가치(EVA)

영업이익에서 자본비용을 차감하여 산정한 잔여재산에 의한 기업의 재무적 성과의 측정치(현금기준으로 세금을 조정).('경제적 이익'이라고도 함)

식 = 세후순이익(NOPAT) - (자본 * 자본비용)

총소유비용(TCO)

Total Cost of Ownership(총 소유 비용)은 정의된 기간 동안 애플리케이션에 드는 비용을 계산하는 방법입니다.TCO 모델에서는 하드웨어, 소프트웨어 및 인건비가 캡처되어 다양한 애플리케이션 수명 주기 단계로 구성됩니다.TCO 모델은 구축, 실행/지원 및 간접 비용을 측정하려고 시도할 때 관리자가 애플리케이션의 실제 비용을 이해하는 데 도움이 됩니다.많은 대형 컨설팅 회사들이 완전한 TCO 모델을 구축하기 위한 전략을 정의했습니다.

총경제효과(TEI)

TEI는 Forrester Research Inc.에 의해 개발되었습니다.Forrester는 TEI가 IT에 미치는 비용, 이점, 비즈니스에 미치는 영향, 유연성, 투자를 통해 창출된 미래 옵션, 리스크, 불확실성 등 네 가지 차원에서 기술 투자의 잠재적 영향을 체계적으로 조사하고 있다고 주장합니다.

IT의 비즈니스 가치(ITBV)

ITBV 프로그램은 2002년 Intel Corporation에 의해 개발되었습니다.[11]이 프로그램은 비즈니스 가치 측정(Business Value Dials, 지표)이라고 불리는 일련의 비즈니스 가치 재무 측정을 사용합니다.비즈니스 구성 요소를 포함한 다차원 프로그램으로 구현이 비교적 용이합니다.

응용정보경제학(AIE)

AIE는 Hubbard Decision Research에서 개발한 의사결정 분석 방법입니다.AIE는 몬테카를로 방법의 사용을 포함한 의사결정 이론 및 위험 분석의 여러 방법을 기반으로 하는 "진정으로 과학적이고 이론적으로 건전한 최초의 방법"이라고 주장합니다.AIE는 복잡하기 때문에 자주 사용되지 않습니다.

참고문헌

  1. ^ Daniel Simon; Kai Fischbach; Detlef Schoder (2010). "Application Portfolio Management—An Integrated Framework and a Software Tool Evaluation Approach". Communications of the Association for Information Systems. 26. doi:10.17705/1CAIS.02603.
  2. ^ HBR Prod.#: 7104-PDF-ENG
  3. ^ Spratt, Tyrone (2007). "Information technology portfolio management: Search for business value". Futurics. 32: 42.
  4. ^ Gliedman, Chip (September 29, 2004). "Defining IT Portfolio Management" (PDF). Forrester: 10.
  5. ^ "글로벌 엔터프라이즈 IT 예산 현황: 2009년부터 2010년까지", Forrester Research, [1]
  6. ^ Keller, W. (2007). IT-Unternehmensarchitektur: Von der Geschäftsstrategie zur ptimalen IT-Unterstützung [IT enterprise architecture: From business strategy to ultimate IT support] (in German). dpunkt. ISBN 978-3-86490-406-6.
  7. ^ Maizlish and Handler (2005). IT Portfolio Management Step-by-Step. Wiley. ISBN 978-0-471-64984-7.
  8. ^ Daniel Simon; Kai Fischbach; Detlef Schoder (2010). "Application Portfolio Management—An Integrated Framework and a Software Tool Evaluation Approach". Communications of the Association for Information Systems. 26. doi:10.17705/1CAIS.02603.
  9. ^ 애플리케이션의 정의, 인사이드 아키텍처 블로그, Nick Malik
  10. ^ Alexei Botchkarev, Peter Andru "정보 시스템 평가 지표로서의 투자 수익률:분류 및 응용" 학제간 정보, 지식 및 관리 저널, 2011, V. 6, pp. 245-269.
  11. ^ Sward, D. (2006).정보 기술의 비즈니스 가치 측정.IT 및 비즈니스 관리자를 위한 실용적인 전략(IT Best Practice).인텔 프레스.