Enterprise Architecture Success Kit: 앱 목록을 업무 역량 지도에 붙여 IT 정리·리스크·ERP 전환을 이끄는 법

회사가 쓰는 앱을 빠짐없이 목록으로 만들고, 각 앱이 어떤 업무 역량을 받치는지 연결해 두면 판단이 한 데이터로 모입니다. 무엇을 남기고 없앨지, 노후 기술 리스크가 어디 있는지, ERP 전환이 무엇을 건드리는지가 모두 여기서 나옵니다. 실제로 돌리려면 정해진 필드, 자동 수집 경로, 앱 오너의 검증 일정이 함께 있어야 합니다.

요약

SAP LeanIX가 낸 30쪽 분량의 백서입니다. EA(enterprise architecture, 회사의 업무·애플리케이션·데이터·기술이 서로 어떻게 엮여 있는지의 전체 구조)를 관리하는 조직을 처음 세우는 방법을 네 장에 걸쳐 설명합니다. 회사는 필요할 때마다 도구를 사서 붙이며 커 왔기 때문에 구조가 저절로 생겼지만 아무도 관리하지 않는 상태가 됩니다. 저자는 이것을 의도적으로 관리하는 순서로 세 가지를 제시합니다. business capability map(업무 역량 지도)을 먼저 그리고, application inventory(앱 인벤토리)를 만들고, 그 데이터의 완결성과 품질을 맞추는 것입니다.

이 기반이 서면 세 가지 활용이 가장 빨리 성과를 낸다고 봅니다. 쓸모가 겹치거나 맞지 않는 앱을 정리하는 application rationalization, 지원이 끊긴 기술을 찾는 obsolescence risk 관리, 그리고 ERP 같은 핵심 시스템의 전환입니다. 근거 수치도 함께 듭니다. 기업이 평균 976개 앱을 쓴다는 MuleSoft·Deloitte 보고서, 앱 포트폴리오를 정기적으로 정리하는 조직이 15%뿐이라는 LeanIX 조사, 보안 사고 수습 비용이 평균 435만 달러라는 수치입니다. 아래에서는 이 흐름을 받치는 개념 일곱 가지, 저자가 통념과 다르게 보는 점, Estée Lauder·CapitaLand·Travis Perkins 사례를 차례로 정리하고 실제로 돌리는 방법을 덧붙입니다.

핵심 메커니즘

Meta model: 앱·역량·기술을 잇는 공통 데이터 구조

무엇인가. 어떤 대상(entity)을 어떤 이름과 필드로 기록하고 서로 어떻게 연결할지 정한 데이터 모델입니다. LeanIX의 meta model은 네 층으로 나뉩니다. 전략·전환 층(Objective, Platform, Initiative), 비즈니스 층(Organization, Business Capability, Business Context), 앱·데이터 층(Application, Interface, Data Object), 기술 층(Provider, IT Component, Tech Category)입니다.

어떻게 작동하나. 입력은 흩어져 있는 앱 목록, 계약, 구성 정보입니다. 이것을 정해진 대상 유형에 나눠 담고, “이 Initiative가 어떤 역량을 바꾸는가”, “이 앱은 어떤 역량을 받치는가”, “이 앱은 어떤 IT Component 위에서 도는가”라는 관계를 겁니다. 출력은 위에서 아래로, 또는 아래에서 위로 따라갈 수 있는 연결망입니다. 서버 OS 하나의 지원 종료가 어떤 업무 역량과 어떤 전략 과제에 닿는지 바로 추적할 수 있습니다.

언제 쓰고 언제 안 쓰나. EA를 처음 시작할 때 씁니다. 저자는 회사의 모든 특수성을 담은 모델을 처음부터 설계하는 것은 시간만 들고 값어치가 없다고 보고, 오래 다듬어진 표준 모델로 시작하라고 권합니다. 이미 잘 돌아가는 CMDB(구성 관리 데이터베이스)를 대체하려는 용도는 아닙니다. CMDB는 운영 자산을, meta model은 업무와 앱의 관계를 다룹니다.

작은 예시(가상 예시). “온라인 직판 매출 확대”라는 Objective 아래 “고객 앱 구축” Initiative가 있고, 이 Initiative는 Lead Management 역량을 바꿉니다. 그 역량을 받치는 앱은 CRM이고, CRM은 특정 버전의 데이터베이스 위에서 돕니다. 데이터베이스 지원 종료가 다가오면 직판 목표가 영향을 받는다는 사실이 연결망에 바로 드러납니다.

Business Capability Map: ‘무엇’을 고정하고 ‘어떻게’는 바꿀 수 있게

무엇인가. 회사가 돌아가는 데 꼭 필요한 업무 능력(capability)을 계층으로 그린 지도입니다. 원문 예시에는 자산 관리, 고객 서비스, 재무, 인사, 마케팅, R&D 같은 상위 영역 아래 수십 개의 하위 역량이 붙어 있습니다.

어떻게 작동하나. 저자는 capability와 process를 같은 현실의 두 관점으로 구분합니다. capability는 ‘무엇’을 할 수 있는가, process는 그 일을 ‘어떻게’, 누가, 어떤 순서로 하는가입니다. 원문은 available-to-promise(고객 문의에 납품 가능한 수량·장소·시점을 확답하는 능력)를 예로 듭니다. 능력 자체는 사업 모델이 같으면 잘 바뀌지 않지만, 재고와 생산 예측과 우선 주문을 확인하는 절차는 사업이 바뀌면서 계속 달라집니다. 그래서 앱을 process가 아니라 capability에 붙여 두면 지도가 오래 버팁니다. 앱을 역량에 붙이고 나면 역량 하나에 앱이 여럿 몰린 곳(중복), 앱이 하나도 없는 곳(공백), 부실한 앱 하나에 기대는 곳(비효율)이 드러납니다.

언제 쓰고 언제 안 쓰나. 앱 수가 많아 “이게 많은지 적은지”를 판단할 수 없을 때 씁니다. 저자는 평균 976개라는 앱 수 자체로는 아무것도 판단할 수 없고, 그 앱들이 받쳐야 하는 역량을 봐야 한다고 말합니다. 업무 절차를 개선하는 작업에는 process 모델이 따로 필요합니다.

작은 예시(가상 예시). 마케팅의 Audience Segmentation 역량에 CDP, 이메일 도구, BI 대시보드 세 곳이 각자 세그먼트를 만들고 있다면, 이 역량이 정리 후보 1순위가 됩니다.

Application Inventory: 흩어진 목록을 한곳에 모으고 SaaS까지 찾기

무엇인가. meta model이 정한 대상(앱, 인터페이스, 역량 등)을 실제 데이터로 채운 목록입니다. 역량 지도와 함께 EA의 두 기둥입니다.

어떻게 작동하나. 저자는 대부분의 회사가 이미 어딘가에 앱 목록을 갖고 있다고 봅니다. Excel이나 CMDB, 다른 IT 관리 도구에 흩어진 목록을 꺼내 한 저장소로 옮기는 것이 첫 일입니다. 문서, 다이어그램, 이미지에서 아키텍처 요소와 관계를 AI로 뽑아내 옮기는 일도 자동화할 수 있다고 설명합니다. SaaS는 따로 다룹니다. 현업이 IT를 거치지 않고 살 수 있어서 목록에 잘 잡히지 않기 때문입니다. 저자는 설문으로는 전체 그림이 안 나오고, SSO 같은 기업 시스템과 연동해 자동으로 찾아야 한다고 봅니다.

언제 쓰고 언제 안 쓰나. 범위가 정해진 뒤에 씁니다. 목표(비용 절감인지, AI 거버넌스인지)가 어떤 필드를 모을지 정하므로, 목표 없이 모든 것을 모으면 금방 낡습니다.

작은 예시(가상 예시). CMDB에서 앱 310개, SSO에서 앱 420개가 나왔고 둘을 맞춰 보니 SSO에만 있는 앱이 140개였다면, 그 140개가 IT가 모르던 SaaS 후보입니다.

데이터 완결성과 품질: 오너가 확인한 레코드만 믿기

무엇인가. 인벤토리의 각 레코드에 판단에 필요한 필드가 채워져 있고, 그 값이 맞는지 확인된 상태입니다. 어떤 필드가 필요한지는 meta model이 정합니다.

어떻게 작동하나. 기존 기록에서 가져올 수 있는 값은 가져오고, 비어 있는 설명·맥락은 AI로 초안을 만들고 번역합니다. 나머지는 사람만 압니다. 저자는 여기서 설문을 씁니다. 팀 리더와 앱 오너에게 정기적으로 설문을 보내고, 사용자가 레코드를 검토하고 확인하게 합니다. 앞 단계에서 SaaS를 찾는 데는 설문이 부족하다고 했지만, 이미 찾은 앱의 내용을 채우는 데는 설문이 맞는 도구라는 구분입니다.

언제 쓰고 언제 안 쓰나. 수집 직후 한 번으로 끝내지 않고 주기적으로 돌립니다. 수작업 갱신에 기대는 스프레드시트가 금방 믿을 수 없게 되는 것이 저자가 DIY 도구를 반대하는 이유입니다.

Application Rationalization: functional fit과 technical fit으로 TIME 판정

무엇인가. “지금 이 앱들을 갖고 있는 게 맞는가”를 묻고 답하는 일입니다. 저자의 조사에 따르면 이것을 정기적으로 하는 조직은 15%뿐입니다.

어떻게 작동하나. 역량에 연결된 인벤토리에서 평가할 앱과 AI 도구의 범위를 정합니다. 각 앱에 두 점수를 매깁니다. functional fit(업무가 필요로 하는 일을 하는가)과 technical fit(우리 IT 환경에 가장 맞는 도구인가)입니다. 두 점수의 조합을 Gartner TIME 프레임워크에 넣습니다. 그대로 두고 쓸지(Tolerate), 더 투자할지(Invest), 다른 플랫폼으로 옮길지(Migrate), 없앨지(Eliminate)를 정합니다. 저자는 이 틀이 앱 정리의 업계 표준이 됐다고 봅니다.

언제 쓰고 언제 안 쓰나. 인벤토리와 역량 매핑이 끝난 뒤에 씁니다. 점수를 매길 오너가 정해지지 않은 앱은 판정을 미룹니다.

작은 예시(가상 예시). 업무 요구는 잘 맞추지만 지원이 끝나 가는 온프레미스 영업 관리 시스템은 functional fit 높음, technical fit 낮음이라 Migrate로 갑니다.

Technology Obsolescence Risk: 지원 끊긴 기술을 앱과 데이터 흐름까지 추적

무엇인가. 벤더 지원이 끝났거나 끝나 가는 하드웨어·소프트웨어를 찾아, 그 위에서 도는 앱과 업무에 미칠 영향을 관리하는 일입니다. 원문은 미국 CISA(사이버보안·인프라보안청)가 지원 종료 소프트웨어를 핵심 인프라의 첫째 위험으로 꼽는다고 전합니다.

어떻게 작동하나. 각 IT Component의 수명주기 정보를 지속적으로 갱신되는 카탈로그(LeanIX는 Lifecycle Catalog)와 맞춥니다. 기존 데이터의 이름 표기가 제각각이므로 matching 알고리즘으로 정리합니다. 지원 종료가 다가오는 부품을 찾으면 그 위의 앱과, 그 앱이 주고받는 데이터 흐름까지 영향 범위로 표시합니다. 저자는 판단에 쓸 질문 열 가지를 듭니다. 내용은 수명주기와 업그레이드 필요, 응답 시간과 다른 앱 대비 수준, 연간 장애 추이와 사고 빈도, 장애 시 영향받는 사용자와 매출, 규제 준수, 성장 저해 여부로 묶입니다.

언제 쓰고 언제 안 쓰나. 사람이 손으로 버전을 관리해서는 따라갈 수 없다는 것이 저자의 전제입니다. 수명주기 데이터를 자동으로 가져올 수 있을 때 시작합니다.

Application Modernization과 ERP Transformation: 현재 상태에서 로드맵까지

무엇인가. TIME에서 Invest·Migrate로 분류된 앱이 현대화의 1순위 후보입니다. ERP처럼 이해관계자와 연결 시스템이 많은 핵심 시스템의 현대화는 사실상 비즈니스 전환이라고 저자는 봅니다.

어떻게 작동하나. 저자가 꼽는 성공 조건은 다섯 가지입니다. IT·현업·프로젝트 팀의 정렬을 끝까지 유지하는 것, 중요한 결정에 경영진의 지원을 얻는 것, IT 구성 요소 사이의 연결과 의존을 모두 파악하는 것입니다. 나머지 둘은 목표 아키텍처 설계와 실행 가능한 로드맵입니다. 이 모든 것의 전제는 IT 전체를 보는 가시성입니다. 현재 상태를 지도에 올리고, 목표 상태를 설계하고, 로드맵을 만든 뒤, 전환 중에도 현재 상태가 바뀌는 대로 로드맵을 고칩니다. 끝난 뒤에도 효과를 추적하고 다음 최적화 기회를 찾습니다.

언제 쓰고 언제 안 쓰나. ERP 전환 프로젝트를 시작하기 전에 씁니다. 연결을 모르고 시작한 현대화가 끝없이 지연되는 것이 1장에서 저자가 든 대표 문제입니다.

통념과 다른 주장

저자가 든 사례

Estée Lauder: 브랜드·지역이 흩어진 200개 넘는 앱을 정기적으로 정리

• 상황: 직원 6만 명 이상, 여러 브랜드와 지역에 걸쳐 앱 200개 넘게 운영하는 화장품 회사. 브랜드·지역·팀마다 흩어진 포트폴리오라 정리 자체가 큰 과제입니다.
• 한 일: LeanIX로 앱 포트폴리오 최적화를 위한 8단계 방법론을 만들었습니다. 비용 최적화, 핵심 앱의 글로벌 표준 수립, 이해관계자 동의 확보가 들어 있고, 이사회부터 내려오는 전략 목표를 LeanIX에 넣어 구체적 프로젝트에 연결합니다.
• 결과: 정기적인 앱 정리를 지속하는 체계를 갖췄습니다. 절감액 같은 수치는 원문에서 밝히지 않음.
• 연결: Application Rationalization과 Meta model의 Objective → Initiative 연결이 실제로 쓰인 예입니다.

CapitaLand: AI 도입 전에 앱 사이의 연결과 의존을 먼저 보기

• 상황: 40개 넘는 나라, 260개 넘는 도시에서 사업하는 아시아 최대급 부동산 그룹. 넓은 앱 환경 전반에 AI 기능을 늘리고 있습니다.
• 한 일: LeanIX를 AI 도입과 거버넌스, 앱 정리, 재사용 가능한 EA 프레임워크에 씁니다. 아키텍트가 앱과 구성 요소 사이의 모든 연결과 의존을 보고 AI를 붙입니다.
• 결과: AI를 매끄럽게 구현하는 기반이 됐다고 설명합니다. 정량 수치는 원문에서 밝히지 않음.
• 연결: 1장의 “AI가 어디서 어떻게 쓰이는지 모르는 문제”에 대한 답으로, Meta model과 Application Inventory를 AI 거버넌스에 쓴 예입니다.

Travis Perkins: 프로세스 데이터와 EA 데이터를 합쳐 ERP 전환

• 상황: 직원 2만 5천 명 이상인 영국 주택 자재 유통사. ERP 전환을 포함한 큰 IT 현대화를 앞두고 있었고, 예전 다이어그램 도구는 분석에 쓸 데이터를 남기지 못했습니다.
• 한 일: LeanIX와 SAP Signavio(프로세스 관리 도구)를 함께 써서 IT 지도와 프로세스 지도를 한 화면에 합치고, 프로세스 데이터에 EA 데이터를 덧붙였습니다.
• 결과: 어떤 앱이 어떤 프로세스에 쓰이고 누가 소유하고 쓰는지 모두가 빨리 알게 됐고, 이후 전환도 같은 표준 방식으로 실행할 수 있게 됐다고 설명합니다. 기간·비용 수치는 원문에서 밝히지 않음.
• 연결: Business Capability Map과 process의 구분, ERP Transformation의 “연결과 의존 파악” 조건이 실제로 쓰인 예입니다. 담당 임원은 다이어그램을 두고 “it’s just a picture”라고 말합니다.

기술 디테일: 인벤토리를 데이터로 돌리는 방법

아래는 원문에 없는 실행 방법을 AX Partners가 덧붙인 것입니다. 필드 이름과 수치는 가상 예시입니다.

Meta model을 실제 레코드 스키마로 옮기려면 (Meta model, 데이터 품질 연결) 판단에 쓸 필드만 먼저 정합니다. 처음부터 필드가 많으면 채움률이 떨어지고 오너가 설문을 포기합니다. 아래는 앱 레코드 하나의 최소 형태입니다. sources와 verified_at이 있어야 이 값이 어디서 왔고 언제 누가 확인했는지 추적할 수 있습니다.

{
  "id": "APP-0142",
  "name": "Salesforce Sales Cloud",
  "aliases": ["SFDC", "세일즈포스"],
  "owner": {"business": "영업기획팀장", "technical": "CRM 운영 담당"},
  "capabilities": ["CAP-MKT-Lead Management"],
  "interfaces": [{"to": "APP-0007", "type": "API", "data_objects": ["Customer"]}],
  "it_components": [{"id": "ITC-311", "name": "PostgreSQL", "version": "12"}],
  "functional_fit": 3,
  "technical_fit": 2,
  "time": "Migrate",
  "lifecycle": {"phase": "active", "eol_date": null, "source": "vendor", "checked_at": "2026-11-13"},
  "users_monthly": 420,
  "annual_cost": 180000000,
  "ai_usage": {"uses_ai": true, "provider": "외부 LLM API", "data_objects": ["Customer"]},
  "sources": [{"type": "sso", "ref": "entra:app/…"}, {"type": "cmdb", "ref": "CI-88812"}],
  "verified_by": "owner",
  "verified_at": "2026-11-20"
}

문서와 다이어그램에서 AI로 인벤토리를 뽑으려면 (Application Inventory 연결) 아키텍처 문서는 페이지 단위로, 다이어그램 이미지는 장 단위로 끊어 비전 지원 LLM에 넣습니다. 출력은 {entity_type, name, relation: {from, to, type}, evidence: {file, page}, confidence} 목록으로 고정하고, entity_type은 meta model의 대상 유형 중에서만 고르게 합니다. temperature는 0으로 두고 같은 입력을 3회 돌려 2회 이상 나온 항목만 남깁니다. 실패하는 경우는 셋입니다. 같은 앱이 다른 이름으로 나오면(SFDC와 Salesforce) aliases 표로 합칩니다. 다이어그램이 오래돼 지금은 없는 연결이 나오면 문서 날짜를 evidence에 남겨 오래된 근거를 걸러냅니다. 근거 페이지 없이 나온 인터페이스는 버립니다. confidence가 0.7 미만인 항목은 자동 반영하지 않고 오너 검토 대기열로 보냅니다.

SaaS를 빠짐없이 찾으려면 (Application Inventory 연결) SSO(Okta, Microsoft Entra ID 등)의 연동 앱 목록과 사용 로그를 주 1회 가져오고, 법인카드·구매 데이터의 거래처 이름과 맞춥니다. 이름은 소문자화, 법인 표기 제거, aliases 대조 순서로 정규화합니다. 비용 데이터에만 있고 SSO에는 없는 앱은 SSO를 거치지 않는 SaaS 후보이므로 결제 부서장에게 확인 설문을 보냅니다. 90일 동안 로그인이 없는 SSO 앱은 Eliminate 검토 후보로 표시합니다.

역량 매핑과 TIME 판정을 반복 가능하게 하려면 (Business Capability Map, Application Rationalization 연결) LLM에는 앱 설명과 역량 지도(L1·L2 이름과 정의)를 함께 주고 맞는 L2 역량 상위 3개와 이유를 JSON으로 받습니다. 서로 다른 모델 두 개로 돌려 1순위가 같으면 자동 제안하고, 다르면 오너에게 묻습니다. fit 점수는 LLM이 정하지 않습니다. 오너 설문과 운영 데이터(장애 건수, 응답 시간)로 매기고, LLM은 근거 요약만 만듭니다. 판정 규칙은 단순하게 둡니다. 4점 척도에서 3점 이상을 ‘높음’으로 보고 아래 표처럼 TIME에 대응시킵니다.

점수	functional fit (업무 적합)	technical fit (기술 적합)
1	핵심 기능이 빠져 현업이 우회 작업을 함	지원 종료 또는 보안 기준 미달
2	기능은 있으나 불만이 잦음	운영은 되나 장애·수작업 패치가 잦음
3	업무 요구를 대부분 충족	표준 기술, 지원 기간 2년 이상
4	업무 요구를 충족하고 확장 계획에도 맞음	회사 표준 플랫폼, SSO·감사 로그 지원

노후화 리스크를 자동으로 잡으려면 (Technology Obsolescence Risk 연결) IT Component의 이름과 버전을 정규화한 뒤 벤더 수명주기 정보나 공개 카탈로그(예: endoflife.date)와 맞추고, 출처와 확인 날짜를 lifecycle.source, lifecycle.checked_at에 남깁니다. 규칙 예시는 이렇습니다. 지원 종료까지 12개월 이하이고 받치는 역량이 핵심이면 빨강, 24개월 이하면 주황입니다. 버전을 모르는 부품은 초록이 아니라 주황으로 둡니다. 판정된 부품에서 interfaces를 따라가 영향받는 앱과 데이터 흐름을 함께 표시합니다. 저자의 열 가지 질문은 필드로 바꿔 두면 매번 다시 조사하지 않아도 됩니다. 수명주기는 lifecycle, 성능은 응답 시간과 동종 앱 대비 백분위, 장애는 연간 장애 건수와 전년 대비, 영향은 users_monthly와 연결 매출, 규제는 관련 규정 목록으로 받습니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할. 아래 역할은 원문의 단계에 맞춰 AX Partners가 정리한 예시입니다.

역할	하는 일	결정
경영 스폰서(CIO 또는 CFO)	프로그램 목표 승인, TIME 결과 의사결정 회의 주재	무엇을 없애고 무엇에 투자할지
EA 리드	범위와 meta model 필드 확정, 일정 운영	필드·판정 규칙
애플리케이션 오너	레코드 검증, fit 점수 입력	자기 앱의 사실 값
비즈니스 역량 오너(현업 리더)	역량 지도 검토, functional fit 확인	역량 정의
IT 운영·SSO 관리자	SSO 앱 목록, 장애·응답 시간 데이터 제공	없음(데이터 제공)
재무·구매	계약, 비용, 거래처 데이터 제공	계약 해지 시점
보안	지원 종료 정책, AI 사용 승인 기준	리스크 등급 기준

시작 전 준비물. 목표 한 줄(예: 연 IT 비용 절감, AI 사용 현황 파악, ERP 전환 준비 중 하나), 기존 앱 목록(Excel·CMDB), SSO 관리자 권한, 최근 12개월 소프트웨어 비용 내역, 표준 역량 지도 템플릿, 범위로 삼을 사업부 하나가 필요합니다.

12주 일정(예시).

기간	할 일	산출물
1~2주	목표·범위·필드 확정, 스폰서 승인	목표 1장, 필드 정의서
2~4주	역량 지도 L1·L2 초안, 현업 워크숍 2회	역량 지도 v1
3~6주	Excel·CMDB·SSO·비용 데이터 수집, 문서 AI 추출	인벤토리 초안
7~8주	오너 설문과 검증, 역량 매핑 확정	검증된 인벤토리
9~10주	fit 점수, TIME 판정, 노후화 리스크 판정	TIME 표, 리스크 목록
11~12주	의사결정 회의, 첫 정리 대상과 로드맵 확정	결정 기록, 로드맵 v1

오너에게 물을 질문. 이 앱이 받치는 업무 역량은 무엇입니까? 같은 일을 하는 다른 앱이 있습니까? 월간 실사용자는 몇 명입니까? 지난 1년 장애는 몇 번이었습니까? 계약 만료일과 연 비용은 얼마입니까? AI 기능을 쓰고 있다면 어떤 데이터가 들어갑니까? 이 앱이 내일 없어지면 누가 가장 곤란합니까?

진행 판정 기준(예시). 범위 안 앱의 90% 이상에 오너가 지정되고, 핵심 필드(owner, capabilities, functional_fit, technical_fit, lifecycle)의 채움률이 80% 이상이며, 오너 검증을 마친 레코드가 70% 이상이면 9주 차 TIME 판정으로 넘어갑니다. 미달이면 2주를 늘리거나 범위를 한 사업부 안의 한 업무 영역으로 줄입니다.

AX 적용 제언. 엔터프라이즈 AX에서 이 백서가 가장 쓸모 있는 지점은 AI 거버넌스입니다. 앱 레코드에 ai_usage 필드 하나를 붙이면 1장에서 저자가 말한 “AI가 어디서 어떻게 쓰이는지 모르는 문제”를 인벤토리로 답할 수 있습니다. 에이전트를 배포할 때도 어떤 앱, 인터페이스, Data Object를 건드리는지 같은 지도에서 확인할 수 있습니다. 순서는 한 사업부와 한 목표로 12주를 돌려 TIME 결과로 절감 근거를 만들고, ERP 전환이나 전사 AI 도입 계획이 잡히면 그때 전사로 넓히는 것을 권합니다. 프로세스 마이닝이나 PI(프로세스 혁신) 과제가 이미 있다면 Travis Perkins처럼 프로세스 데이터에 앱 데이터를 붙이는 것이 가장 빠른 출발점입니다. 바꿔야 할 관행은 하나입니다. 목표 아키텍처 보고서부터 쓰던 순서를 현재 상태 데이터부터 채우는 순서로 바꾸는 것입니다.

원문 사례

항목	내용
발행	SAP LeanIX, 30쪽 백서(© 2026 SAP SE)
구성	1장 EA가 필요한 이유 / 2장 시작 원칙 / 3장 기반 3단계 / 4장 활용 사례
시작 원칙	상아탑에서 나오기, 표준 데이터 모델 쓰기, 목표 정하기, 현재 상태부터, 맞는 도구 고르기
도구 체크리스트	표준 데이터 모델, 빠른 성과, 폭넓은 연동, 전략적 AI 기능
기반 3단계	역량 지도 → 앱 인벤토리 → 데이터 완결성·품질
활용 3가지	앱 정리(TIME), 노후 기술 리스크, 앱 현대화·ERP 전환
인용 수치	기업 평균 앱 976개(MuleSoft·Deloitte), 정기적으로 앱을 정리하는 조직 15%(LeanIX), 보안 사고 수습 평균 435만 달러, 핵심 업무에 레거시 앱을 쓰는 조직 66% 이상·고객 접점 60% 이상(Tata Consultancy·AWS, 2021년 C레벨 211명 조사)
사례	Estée Lauder(제조·유통, 앱 200개 이상, 8단계 방법론), CapitaLand(부동산, AI 거버넌스), Travis Perkins(유통, ERP 전환, Signavio 연계)

핵심 개념

Enterprise Architecture (EA)

회사의 전략, 업무 역량, 앱·데이터, 기술 기반이 어떻게 연결돼 있는지의 전체 구조와 그것을 관리하는 일.

CMDB

서버·소프트웨어 같은 IT 운영 자산과 구성을 기록하는 데이터베이스. EA 인벤토리의 입력 중 하나.

Gartner TIME

Tolerate·Invest·Migrate·Eliminate의 머리글자. 앱마다 유지, 투자, 이전, 폐기 중 하나를 고르는 틀.

Lifecycle Catalog

하드웨어·소프트웨어의 출시, 지원, 지원 종료 시점을 계속 갱신해 모아 둔 LeanIX의 참조 데이터.

Single source of truth

여러 팀이 같은 질문에 같은 답을 얻도록 한곳에 모은 기준 데이터.

Business-led IT

현업이 IT 부서를 거치지 않고 직접 SaaS를 사서 쓰는 방식. 민첩하지만 인벤토리에서 빠지기 쉬움.

SAP Signavio

업무 프로세스를 모델링·분석하는 SAP 도구. Travis Perkins는 LeanIX와 함께 써서 프로세스와 앱을 한 지도에 합침.

내 메모

TODO: 내 생각 추가

원문: SAP LeanIX, “Enterprise architecture success kit: Everything you need to drive impact with EA” (백서, 30쪽). 요약, 핵심 메커니즘, 통념과 다른 주장, 사례는 원문이 언급한 내용을 AX Partners가 다시 정리한 것이고, 기술·현업 실행 디테일, 표, 인포그래픽은 새로 작성했습니다. 필드 이름과 수치가 붙은 디테일은 가상 예시입니다. 전체 내용과 원문 도표는 SAP LeanIX 다운로드 페이지(leanix.net/en/download/enterprise-architecture-success-kit)에서 확인할 수 있습니다.