 |
|
IT 아키텍처란 무엇인가? 아키텍처는 중요하다. 시스템 전문가에게 무엇이 중요한지를 묻는다면, 그들은 아키텍처라고 할 것이다. 시스템의 아키텍처는 시스템을 구현하는 전문가들이 공통으로 이해해야 하는 부분이다. 시스템의 주요 부분들을 이해함으로써, 시스템, 주 컴포넌트들, 이들의 상관 관계를 이해할 수 있다. 아키텍처는 전문 디자이너들이 가장 중요하다고 생각하고 있는 모든 것들을 포함하고 있다. 아키텍처는 중요성으로 상세히 분류되고, 덜 중요한 아키텍처는 낮은 수준의 디자인으로 간주된다.
시스템이 실행되는 한, 아키텍처는 결코 끝나지 않는다. 아키텍처는 시스템이 인식될 때, 첫 번째로 그려지는 부분이다. 시스템의 요구 사항들을 지속적으로 파악하고, 그러한 요구 사항들을 실현하면서 아키텍처는 변하게 된다.
정보 기술(IT) 분야에서, 하나의 소프트웨어 중심 시스템일지라도, 많은 아키텍처가 있다. 전체 시스템이 가장 높은 우선순위에 있는 것으로 간주된다면, 이것은 엔터프라이즈 아키텍처(enterprise architecture)이다. 하드웨어와 시스템을 실행하는 낮은 수준의 소프트웨어는 인프라스트럭처 아키텍처(infrastructure architecture)이다. 네트워크 아키텍처(network architecture)에서 네트워크는 가장 높은 우선 순위가 된다. 또 다른 것으로는 스토리지 아키텍처(storage architecture)가 있다. 연산 아키텍처(Operations architecture) 는 로드 스파이크(load spike) 같은 상황 속에서도 시스템을 무리 없이 실행하는 책임을 맡고 있다.
한 개의 아키텍처는 없지만, 엔터프라이즈 아키텍처는 가장 높은 레벨의 아키텍처이다. 엔터프라이즈는 공통 목표를 가진 조직들의 집합이다. 엔터프라이즈는 기업 또는 정부 기관이 될 수 있고, 같은 조직에서 서로 독립적으로 운영되는 부서가 될 수도 있다. 엔터프라이즈에는 비즈니스 파트너, 공급자, 고객들이 포함된다. 비록, 상충하는 이해관계 때문에 공통 목표를 달성하기가 어렵다. 엔터프라이즈 아키텍처는 소프트웨어 중심 시스템을 생산, 실행, 관리하는데 필요한 엔터프라이즈의 모든 영역과 필요들을 다룬다. |
|
|
모든 시스템은 아키텍처를 갖고 있기 때문에 아키텍처는 중요하다. 가끔, 아키텍처는 시스템의 일부가 구현되기 전에 개발된다. 또 어떤 경우에는, 아키텍처에 대한 정식 정의 없이 소프트웨어 구현이 발생한다. 하지만, 후자와 같은 경우에도, 시스템은 아키텍처를 갖고 있고, 소프트웨어 세계에서도, 시스템 아키텍처는 시스템이 구현된 후에 명확해진다.
구조화 되지 않은(non-architected) 아키텍처에는 세 가지 일반적인 유형이 있고, 각각 경멸하는 듯한 뉘앙스이지만 중요한 이름을 갖고 있다.
- 커다란 진흙 덩이(Big ball of mud) (Shantytown) -- 이러한 유형의 시스템에는 사용되지 않는 많은 세그먼트가 포함된다. 하지만, 사용되지 않는 부분들도 규명하기도 힘들고, 제거하기는 더욱 어려운 것들로 쌓여있다.
- 스파게티(Spaghetti) -- 어떤 논리적 흐름이 없는 시스템이다. 여기에서 어떤 부분은 다른 부분과 연결되어 있을 수 있다. 이 같은 경우, 대부분의 부분들은 다른 많은 부분들에 대해 약간의 의존성을 갖고 있다. 이 같은 의존성이 시스템의 전체 기능에 작은 차이를 만든다.
- 카드로 만든 집(House of cards) -- 이러한 아키텍처에서는, 모든 부분들이 다른 많은 부분들에 의존하여, 한 부분을 변경하면 여러 부분들에 영향을 미치고, 한 가지 문제를 해결하면 더 많은 것들이 해결된다.
한 가지 유형의 속성을 가진 많은 시스템들이 두 개의 다른 유형들을 가질 수도 있다. 아래 그림은 이 세 가지 유형 모두를 가진 아키텍처 예제이다. 
시스템은 플래닝 되지 않기 때문에 이러한 방식으로 구현된다. 장기적 성공에 필요한 자질을 고려하지 않고, 필요 기술과 리소스가 부족한 사람들에 의해서, 순간적인 필요만 맞추기 위해 서둘러 구현된다. 그와 같은 시스템을 구현하는 팀은 너무 적은 인원을 갖고 있거나, 재능 있는 팀 멤버들의 효율성을 희석시키는 사람만 너무 많은 경우가 있다.
앞의 그림을 보면, 팀이 시스템을 구현하기 전에 아키텍처 디자인이 왜 필요한지를 알 수 있다. 시스템을 구현할 때, 단 한 가지라도, 작은 비전만 있어도 디자인 팀을 이런 식으로 혼란에 몰아 넣지 않을 수 있다. 이러한 비전은 세부적일 필요는 없고, 무엇이 필요하고, 어떻게 해야 하는지에 대한 전체적인 개념을 담고 있어야 한다. 누군가가 시스템 구현을 시작하기 전에 아키텍처를 포괄한 비전만 있으면, 주문은 일관성 있고 이해하기에 충분하고, 시스템은 구현될 수 있다. 새로운 필요가 생기면 팀이나 다른 팀이 수정할 수도 있다.
|
아키텍트는 아키텍처를 개발하고 구현된 것을 보장하는 책임을 맡은 사람이다. 개인 아키텍트가 이 모든 일을 할 수 있지만, 개발에는 팀 위주의 접근 방식이 개입된다. 이러한 관점에서 볼 때, 아키텍트는 팀의 코치, 오케스트라의 지휘자, 영화 감독 정도로 간주된다. 구현되고 있는 시스템의 아키텍트 비전은 팀의 구현 플랜이 된다.
IT 아키텍트에게 어떤 기술이 필요한가? IT 아키텍트는 큰 그림을 봐야 하고, 주요 부분들을 이해해야 하며, 이들을 어떻게 조합할 것인가를 알아야 한다. IT 아키텍트는 요구 사항, 예산, 인력, 타임프레임 같은 상충하는 필요들간 균형을 맞춰야 한다. 시스템이 무엇을 수행해야 하는지를 봐야 한다. 또한, 앞으로의 필요와 시스템이 직면할 문제들을 예상할 수 있어야 하고, 이 문제를 해결할 방법도 준비해야 한다. 아키텍트는 비전을 세운 후에, 그 비전에 대해서 팀과 상의하고, 멤버들이 그 비전을 수행할 수 있도록 동기를 부여해야 한다.
아키텍트에게 가장 필요한 것은 경험이다. 초보자가 아키텍트가 될 수는 없다. 아키텍트가 되고자 하는 사람들은 큰 일을 시도하기 전에 개인 분야를 통달해야 한다. 프로젝트를 관리하고, 스테이크홀더들과 작업하고, 팀을 이끈 경험이 필요하다. 좋은 아키텍트가 따로 있는 것이 아니다. 그 역할에 맞게 성장하는 것이다. |
|
|
다음은 IT 아키텍처의 주요 사건들을 연대기별로 요약한 것이다.
- 메인프레임. 최초의 애플리케이션은 중앙 컴퓨터에서 실행되었다. 사용자들은 단순 단말기나 텔레타이프 머신을 통해 연결했다. 아키텍처는 단순했다: 애플리케이션은 운영 체계 이상의 모든 일을 수행했다. IBM DB2® 또는 Oracle--같은 외부 데이터베이스도 없었다. 애플리케이션은 데이터를 자체 파일에 저장했다. 메시징 시스템, GUI, 공유 데이터, 애플리케이션들간 인터랙션이 없었다.
- 워크스테이션. 데스크탑 컴퓨터가 일반화 되면서, 데스크탑 컴퓨터에서 실행되는 애플리케이션도 일반화 되었다. VisiCalc, WordPerfect (현재 Corel Corporation), Microsoft® Office 애플리케이션 같은 개인용 애플리케이션이 생겼다. 이들은 개인용 애플리케이션이었다; 각 사용자들은 로컬로 설치된 카피를 실행했고, 사용한 후에는 중지했다. 어떤 데이터도 공유되지 않았다. 로컬 디스크에 있는 파일에 저장되었으며, sneaker-net에 의해서만 분산되었다.
- 네트워킹. 네트워크는 워크스테이션들을 서로서로 연결하거나, 공유 서버 컴퓨터, 메인프레임 스타일의 중앙 프로세싱 컴퓨터로 연결했다. 이로써 엔터프라이즈 내에서 이메일 기능을 실행할 수 있고, 파일 서버상에서 파일을 공유하게 되었다.
- 클라이언트/서버. 네트워킹이 클라이언트/서버 컴퓨팅을 가능케 하고, 애플리케이션은 더 이상 중앙 컴퓨터나 워크스테이션에서 전적으로 실행되지 않고, 이 둘 사이를 나누었다. 원래 클라이언트/서버 애플리케이션들은 워크스테이션에서 실행되었지만, 데이터베이스 서버에서 중앙 데이터에 액세스 했다. 나중에 아키텍처는 애플리케이션을 두 부분으로 나누었다: 서버에서 실행되는 비즈니스 로직용 공유 컴포넌트와, 사용자 인터페이스를 구현했던 로컬 클라이언트로 나누었다. 중앙 비즈니스 로직을 호스팅 할 필요가 애플리케이션의 서버 부분을 실행 및 관리하는 애플리케이션 서버 개발을 이끌었다.
- N-tier. 클라이언트/서버 아키텍처는 2-티어(two-tier) 아키텍처로 일컬어진다. 데이터베이스 서버는 애플리케이션 서버와는 다른 호스트 컴퓨터에서 실행되고, 이것은 3-티어(three-tier) 아키텍처이다. 네트워크 기반 애플리케이션이 점점 더 복잡해지면서, 디자이너들은 애플리케이션 스택--GUI에서 데이터베이스까지--을 클라이언트와 서버상의 더 많은 프로세스들로 나누었다. 이 같은 멀티-티어(multiple-tier) 디자인을 n-tier 아키텍처라고 한다.
- 인터넷. 인터넷은 글로벌 네트워크이다. 인터넷은 대부분의 기업들의 네트워크 보다 오래되었지만, 인터넷으로 연결될 수 있는 내부 네트워크를 구현하기 전까지는 비즈니스 세계에서는 액세스 하는 것이 불가능 했다. 인터넷은 통신과 정보를 엔터프라이즈의 사용자들뿐만 아니라, 전 세계 사용자들 사이에서도 공유가 가능하도록 했다.
- World Wide Web. 웹(Web)은 인터넷을 그래픽으로 만들었다. 작성자는 단어와 그림--Hypertext Markup Language (HTML)를 사용--을 조합 문서로 공개하고 전 세계 사용자들이 볼 수 있도록 한다. 이러한 HTML 문서들은 다른 문서에 대한 하이퍼링크를 포함하고 있기 때문에, 또 다른 문서에 대한 레퍼런스도 활성화 되었고, 독자들은 참조된 소스로 직접 액세스 할 수 있다. 이것은 노드 만큼 중요한 링크에 대한 정보를 온 디맨드(on demand)로 제공하는 것의 시작이었다.
- Browser GUIs. 웹은 HTML 브라우저를 사용하여 정정 HTML 문서들을 본다. 이 패러다임은 빠르게 채택되어, 원격 애플리케이션들에 액세스 하는 인터랙티브 GUI를 제공했다. 이것은 중앙화된 컴퓨팅 모델로의 회귀였다. HTML 실행과 단순한 스크립팅을 제외하고는 클라이언트에서 실행되는 애플리케이션은 실제로 없었기 때문에, 사실상, 클라이언트/서버 모델이 아니었다. 인풋 값의 밸리데이션 조차도 서버에서 수행되어야 했다.
- 웹 서비스. 인터넷은 애플리케이션들을 연결하기 위해 구현되었지만, 웹은 사람들을 정적 콘텐트와 서버 애플리케이션으로 연결시켜 주었다. 웹 서비스는 웹을 사용하여 애플리케이션들을 연결하여, 하나의 애플리케이션이 웹 연결을 통해 또 다른 애플리케이션을 실행할 수 있다.
- Web 2.0. 웹 서비스를 웹 사이트에 적용한 것이다. 웹 사이트의 사용자는 더 이상 사람이 아니라, 또 다른 애플리케이션이 된다.
- 서비스-지향 아키텍처(SOA). 애플리케이션은 중앙 컴퓨터나 워크스테이션에서 전적으로 실행하려는 경향이 있다. 클라이언트/서버와 n-티어 아키텍처는 애플리케이션 레이어들을 분산했다. 브라우저 GUI들은 애플리케이션을 서버로 옮겼다. n-티어 아키텍처 조차도, 런타임 스택이 독립적이기 때문에 완전히 통일된 구조였다. 애플리케이션들은 피어(peer)들 처럼 인터랙팅 한다. SOA는 애플리케이션을 사용자 기능을 나타내는 서비스 코디네이터(합성 애플리케이션의 소비자)와 그 기능을 구현하는 공급자로 나눈다. 코디네이터가 특정 애플리케이션에 고유하다면, 서비스는 여러 합성 애플리케이션들을 재사용 하고 공유될 수 있다.
- 이벤트-중심 아키텍처(Event-driven architecture). SOA에서, 서비스 코디네이터는 원하는 서비스를 지정 및 호출한다. 이벤트 중심 아키텍처(EDA)에서, 애플리케이션은 이벤트를 탐지하고 공지를 만들어 낸다; 다른 애플리케이션들은 공지를 받고 서비스를 호출할 수 있는 핸들러를 갖고 있다. 이러한 방식으로, 탐지 애플리케이션은 이벤트에 대한 응답으로 호출해야 하는 모든 서비스에 대해 알 필요가 없다; 간단히, 이벤트를 알리고, 다른 애플리케이션들이 어떤 서비스를 호출해야 할지를 결정할 수 있도록 한다.
developerWorks Service-Oriented Architecture (SOA)와 웹서비스에서 자세한 내용을 참조하기 바란다. |
|
|
Information technology (IT) 아키텍처는 소프트웨어 중심(software-intensive) 시스템의 기본적인 구조이다. IT 아키텍처의 가장 주도적인 부분은 애플리케이션이고, 여기에서 사용자들은 비즈니스 태스크를 수행하기 때문에, 시스템은 소프트웨어 중심적이다.
애플리케이션 외에도, IT 아키텍처에는 다른 측면들이 있다. IT 아키텍처에서 애플리케이션들은 실행 토대인 인프라스트럭처가 필요하다. 이 토대는 하드웨어-서버 컴퓨터, 데스크탑 워크스테이션, 스토리지, 네트워킹으로 구성된다. 또한, 미들웨어-애플리케이션 서버, 데이터베이스 서버, 메시징 시스템, 워크플로우 엔진, 규칙 엔진들을 포함한, 서버 소프트웨어로 구성된다. 데이터는 이러한 토대에 저장되고, 자산으로서 관리되며, 여러 애플리케이션들에 액세스 하여 사용할 수 있다. 이 토대는 통합 솔루션의 호스트도 되며, 애플리케이션들은 이 토대 위에서 서로 통신할 수 있다.
IT 아키텍처의 또 다른 측면은 이러한 엘리먼트들을 조합하는 것이다. 이 모든 것은 런타임 시 관리되어 올바른 연산을 수행할 수 있도록 해야 한다. 아키텍트는 이 모든 부분들--인프라스트럭처, 애플리케이션, 데이터, 통합, 연산--이 하나의 완벽한 시스템을 형성하여 사용자의 필요를 채울 수 있도록 해야 한다.
다양한 종류의 IT 아키텍트들이 있다. IBM은 다음과 같이 여섯 개의 아키텍처 원칙을 정의했다.
- 엔터프라이즈 아키텍처. 엔터프라이즈 아키텍트는 IT 기능을 비즈니스 필요에 연결하는데 집중한다. 아키텍트는 다양한 애플리케이션들 간 관계, 애플리케이션들 간 공유된 데이터, 애플리케이션 통합, 애플리케이션 실행 인프라스트럭처 등 엔터프라이즈 전체의 소프트웨어-중심 시스템을 관리한다.
- 애플리케이션 아키텍처. 애플리케이션 아키텍트는 비즈니스 프로세스를 자동화 하고, 사용자가 비즈니스 태스크를 수행할 수 있도록 돕는 기능을 제공하는 애플리케이션 디자인에 집중한다. 성능, 가용성, 확장성, 보안, 무결성을 포함한 기능 및 서비스 품질에 대한 요구 사항에 부합하는 애플리케이션을 설계할 책임을 맡고 있다. 또한, 애플리케이션을 실행하는데 필요한 소프트웨어와 하드웨어를 비롯하여, 애플리케이션을 개발하는 툴과 방법론을 평가 및 선택하는 책임도 있다.
- 정보 아키텍처. 정보 아키텍트는 데이터의 구조, 무결성, 보안, 접근성을 포함하여, 여러 애플리케이션에서 사용되는 데이터에 집중한다. 아키텍트는 데이터 관리용 시스템을 디자인, 구현, 테스트, 설치, 운영, 관리하는 책임이 있다. 이러한 시스템의 디자인은 소스, 위치, 무결성, 가용성, 성능, 수명 등을 설명해야 한다.
- 인프라스트럭처 아키텍처. 인프라스트럭처 아키텍처는 서버 컴퓨터, 스토리지, 워크스테이션, 미들웨어, 비 애플리케이션 소프트웨어, 네트워크, 엔터프라이즈에서 요구하는 애플리케이션과 비즈니스 프로세스를 지원하는 물리적 장치 등, 하드웨어와 서버 소프트웨어의 디자인에 집중한다. 아키텍트는 이러한 컴포넌트들을 평가 및 선택할 책임이 있다. 디자인과 선택된 제품의 유효성 검사를 위한 모델링, 시뮬레이션, 테스트도 담당하고, 결과 인프라스트럭처의 성능, 가용성, 확장성도 관리한다.
- 통합 아키텍처. 통합 아키텍트는 기존 애플리케이션, 소프트웨어 오퍼링, 네트워크, 엔터프라이즈 또는 엔터프라이즈들 간 협업할 수 있는 시스템을 실행하는 솔루션의 디자인에 집중한다. 다양한 기술, 벤더, 플랫폼, 컴퓨팅 스타일을 사용한다.
- 연산 아키텍처. 연산 아키텍트는 엔터프라이즈에서 사용되는 인프라스트럭처와 애플리케이션을 관리하는 솔루션의 디자인에 집중한다. 플래닝, 전략, 그리고, 복잡한 정보 시스템의 설치, 연산, 마이그레이션, 관리용 아키텍처를 담당한다.
이러한 아키텍트들은 영역들이 겹치기 때문에 독립적으로 작업하지 않는다. 인프라스트럭처 아키텍트는 시스템 실행을 위한 토대를 설계한다. 애플리케이션 아키텍트는 사용자용 프로그램을 설계하고, 통합 아키텍트는 프로그램들이 통합될 수 있도록 힘쓰고, 정보 아키텍트는 여기에 데이터가 포함되도록 한다. 연산 아키텍트는 이 모든 것들이 올바르게 실행되도록 하고, 엔터프라이즈 아키텍트는 이 모든 측면들을 감독하고 이들이 모두 협력할 수 있도록 한다. 다음 섹션에서는 IBM에서 규명한 여섯 개의 아키텍처 원리들간 관계를 설명하겠다.  |
|
IBM developerWorks에는 아키텍처를 비롯한 다양한 기술 토픽들을 배울 수 있는 풍부한 자료들이 있다. 다음과 같이 유형 별로 자료를 제공한다.
- 기술자료. IBM의 가장 숙련된 기술 스태프와 객원 기고가들이 집필을 맡고 있다. developerWorks 기술자료는 아키텍처를 비롯하여, 특정-제품 및 벤더-중립적인 애플리케이션 개발에 대한 모든 것을 망라하고 있다.
- 튜토리얼과 교육. IT 기술을 배울 수 있는 단계별 가이드이다. 제품과 기술과 관련하여 시리즈로 구성된다.
- IBM 교육 보조 자료. IBM 제품들을 사용하는데 필수적인 기술 관련 튜토리얼이다.
- 팟캐스트. IBM 내/외부의 기술 리더들로부터, 전문적인 견해와 기술 혁신과 진화에 대해 들어본다.
- 웹캐스트. 무료 기술 프레젠테이션으로서 최신 제품과 기술에 대한 정보를 알 수 있다.
- 블로그. IBM의 유명한 기술 스태프들의 블로그를 소개한다. 주로 아키텍처 문제에 대한 이슈들을 다룬다.
- 샘플 IT 프로젝트. 요구 사항부터 구현에 이르기까지 전체 프로젝트를 샘플링 했다.
다양한 아키텍처 관련 주제들을 찾을 수 있다. 다음은 가장 중요한 아키텍처 주제 및 IBM 제품들이다.
- 서비스-지향 아키텍처
- WebSphere Business Process Management
- 가상화, 그리드, 자율 컴퓨팅
- WebSphere Extended Deployment
|
서비스 지향 아키텍처(Service-Oriented Architecture)
|
SOA는 가장 새롭고, 가장 훌륭한 애플리케이션 아키텍처이며, IT의 미래이다. 다음은 추가 자료이다.
|
WebSphere Business Process Management
|
WebSphere Business Process Management는 SOA 애플리케이션의 구현과 전개와 관련한 IBM 제품을 제공한다. 다음은 WebSphere Business Process Management 관련 자료들이다.
|
가상화, 그리드, 자율 컴퓨팅
|
가상화는 구현 구조를 숨기면서, 논리적 리소스를 만든다. 그리드 컴퓨팅은 리소스들을 모으고, 태스크들을 선택적으로 분산한다. 자율 컴퓨팅은 자가 치료가 가능한 시스템으로 만들며, 요구와 문제에 동적으로 반응할 수 있도록 한다. 기타 자세한 정보:
|
WebSphere Extended Deployment
|
WebSphere Extended Deployment은 WebSphere Application Server 환경으로서 그리드와 자율 기능을 제공한다. 다음은 추가 자료들이다:
|
|
developerWorks 샘플 IT 프로젝트에는 IT 시스템 개발 과정을 이해하는데 도움이 되는 아키텍처, 기술, IBM 제품들이 망라되어 있다. 아키텍처를 다루는 프로젝트는 다음과 같다.
- "온 디맨드 솔루션 설계하기" -- IBM On Demand Operating Environment의 13 가지 기능을 사용하여 애플리케이션을 개발하는 방법 소개.
- "리소스 활용은 최대로, 비용은 최소로" -- WebSphere Portal, WebSphere Extended Deployment, Tivoli, DB2 제품들을 사용하여 비즈니스 중심 애플리케이션들을 모으는 인트라넷 포탈 개발 방법 소개.
- "J2EE용 애플리케이션 플랫폼 구현하기" -- IBM 하드웨어, WebSphere, DB2 소프트웨어를 결합하여 활용도가 높은 솔루션을 개발하는 방법 소개.
|
|
|
IT 아키텍처 관련 추가 자료들도 참조하라.
- "누가 아키텍트를 필요로 하는가?" -- Martin Fowler의 IEEE Computer Society 기술자료(PDF)에서는 소프트웨어 아키텍처의 본질과 이를 수행하는 사람들에 대해 설명한다. 이 글은 Ralph Johnson에게서 받은 이메일 내용으로 구성되었다.
- The Open Group Architecture Framework (TOGAF) -- Open Group은 아키텍처를 생각하면서 많은 시간을 보냈다. 엔터프라이즈의 조직에 대한 정의가 이 글의 주제이다.
- "The Open Group Architecture Framework (TOGAF) 소개" -- In this series on developerWorks Architecture에 실린 시리즈에서, Jeff Egan은 TOGAF를 소개하고, 이것을 사용하여 엔터프라이즈 아키텍처를 개발하는 방법을 설명한다. 시리즈 구성:
- "IT 아키텍처 규칙 연구": Danielle과 Nelson Ruest의 기술자료( developerWorks Architecture에서는 아키텍처의 유형, 이들을 조합하는 방법, 적용하는 방법을 설명한다. 시리즈 구성:
- "엔터프라이즈 IT 아키텍트: 뉴 키즈 온 더 블록," (Danielle과 Nelson Ruest) 새로운 아키텍처 역할과 필요한 기술, 인증 방법을 소개한다.
- "Let's talk: 커뮤니케이션과 올바른 프레임웍을 사용하여 엔터프라이즈 아키텍처 구현하기," (Danielle and Nelson Ruest) 구현과 문서화에 필요한 아키텍트용 툴 정보를 제공한다.
- "관리 불가능 한 것을 관리하기," (Danielle과 Nelson Ruest). IT 라이프 사이클을 관리할 때 아키텍트가 거버넌스를 사용하는 방법을 모색한다.
- "정보 아키텍처 기초: 엔터프라이즈 아키텍트 과정," (Thomas Myer) 정보 아키텍처와 정보 아키텍트의 역할에 대해 설명한다.
- Insight and outlook. IT 아키텍처에 대한 지식을 강화해 보자. Insight and outlook 칼럼의 다양한 기술자료들을 통해서, IBM 아키텍처 전문가들이 공통 주제와 관심사를 나눈다.
| | |
