시스템 아키텍처란?
시스템 아키텍처는 시스템의 구조와 동작을 설명하는 개념적 모델입니다. 시스템은 일반적으로 여러 구성 요소와 하위 시스템으로 구성됩니다. 그들은 모두 함께 작동하여 전체 시스템을 구현합니다. 시스템 아키텍처 설명은 전체 시스템의 구조와 동작을 설명하는 형식적인 설명입니다. 또한 시스템 아키텍처를 설명하는 데 도움이 되는 것은 아키텍처 설명 언어(ADL)입니다. 다양한 유형의 시스템 아키텍처가 있습니다. 그 중 일부는 다음과 같습니다.
하드웨어 아키텍처 – 시스템의 물리적 구성 요소 및 해당 연결을 설명합니다.
엔터프라이즈 아키텍처 – 엔터프라이즈 수준 애플리케이션의 분석, 설계, 계획 및 구현을 수행하는 방법을 설명합니다. 다양한 전략을 사용하여 성공적으로 지원을 완료하는 데 도움이 됩니다.
협업 시스템 아키텍처 – 시스템 구성 요소 간의 상호 연결을 설명합니다. 몇 가지 예로 인터넷, 합동 방공 시스템, 지능형 그리드 등이 있습니다.
소프트웨어 아키텍처란 무엇인가
소프트웨어 아키텍처는 성능, 보안 및 관리 용이성과 같은 품질 속성을 최적화하면서 기술 및 운영 요구 사항을 충족하는 솔루션을 정의하는 상위 수준 구조입니다.
소프트웨어 아키텍처 설계에 영향을 미치는 많은 품질 속성이 있습니다. 운영 및 기술 수준에서 소프트웨어의 요구 사항과 기대치를 정의합니다. 성능, 내결함성, 확장성 및 안정성과 같은 속성을 고려하는 것이 중요합니다. 결국 소프트웨어 아키텍처를 사용하여 개발된 최종 소프트웨어 제품은 유연하고 사용하기 쉬우며 유지 관리 및 재사용이 가능해야 합니다. 품질 속성은 특성이라고도 합니다.
다양한 소프트웨어 아키텍처 패턴이 있으며 그 중 일부는 다음과 같습니다.
소프트웨어 아키텍처 패턴
서버리스 아키텍처
이벤트 기반 아키텍처
- 이벤트 생산자와 이벤트 소비자를 기준으로
- 시스템을 여러 부분으로 분리하는 데 중점을 둡니다.
- 일부 다른 구성 요소가 이벤트를 트리거할 때 각 부분이 트리거됩니다.
마이크로 서비스 아키텍처
- 소규모의 독립적인 모듈식 서비스 개발에 집중
- 각 서비스는 특정 문제를 해결하거나 어떤 종류의 기능을 수행할 수 있습니다.
- 모든 서비스는 API를 통해 서로 통신합니다.
출처: https://bcho.tistory.com/668 [조대협의 블로그]
Enterprise Architect (EA)
Business Architecture를 포함한 전체 아키텍쳐 설계에 대한 책임을 진다. 비지니스 이해를 바탕으로 전체 아키텍쳐에 대한 큰 설계를 담당하며, 비지니스에 대한 이해를 바탕으로 장기적인 IT 전략 수립을 담당한다. EA의 특징중의 하나는, EA의 경우 단일 프로젝트 뿐만 아니라, 해당 회사의 앞으로의 비지니스 전략에 맞춰서 향후 모든 프로젝트에 대한 아키텍쳐에 대한 책임을 진다. 또한 SA,AA,TA,DA에 대한 통제 권한을 가지고 아키텍트 팀을 운용한다. 가끔 CIO와 혼동하는 경우가 있는데, CIO는 회사 내부의 IT 전략을 수립하고, IT 포트폴리오를 정의하고 수행한다는 관점에서 EA와 유사한 면이 있으나, 기술적인 면에서는 CIO와 EA의 부분이 겹칠 수 있으나 경영적인 측면에서는 다르다. CIO는 결정적으로 예산 집행권과 인사권을 가지고 있으며 설계 보다는 경영과 관리에 목적을 두는 반면, EA는 아키텍쳐 설계를 그 목적으로 한다.
Solution Architect (SA)
특정 솔루션에 대한 아키텍쳐를 설계한다. SA의 경우 프로젝트 내에 개발팀이 있을때, 해당 솔루션을 사용하는 모든 팀에 대한 아키텍쳐 설계를 담당한다.
Technical Architect (TA)
프로젝트 전체팀에 대한 하드웨어 및 네트워크 아키텍쳐를 설계한다.
Application Architect (AA)
애플리케이션에 대한 표준 가이드 및 아키텍쳐 구조를 담당한다. 팀 규모에 따라 대규모 팀인 경우 각 개발팀마다 AA를 배치하고, 소규모팀인 경우에는 프로젝트 전체팀에 대해서 애플리케이션 아키텍쳐 설계를 담당한다.
Data Architect (DA)
프로젝트 전체팀테 대해서 데이타 아키텍쳐 설계를 담당한다.
Global Architect (GA) [Optional]
일반적인 프로젝트 팀 구조에서는 잘 존재하지 않는 역할이다. EA의 경우 사내에서 진행중인 모든 프로젝트에 대해서 관여해야 하고, 비지니스 전략 측면에서 접근을 하다보니 경영진과의 커뮤니케이션이나 의사 결정 과정에 참여가 많아지기 때문에 실제 아키텍쳐 설계 과정에 디테일하게 참여하기가 어렵고, 때로는 기술의 이해수준이 아주 디테일 하지 않은 경우가 있기 때문에, GA라는 역할을 둬서 SA,TA,DA,AA에 대한 통제 권한 부여하고 기술 중심의 System Architecture의 설계 하도록 한다. 프로젝트 팀의 PM/PL의 관계를 EA/GA 관계로 보면 된다. EA는 비지니스를 포함한 외부 대응이나 큰 그림에 신경 쓰고, GA는 기술 위주의 아키텍쳐 설계에 집중한다.
출처: https://bcho.tistory.com/667 [조대협의 블로그]
비지니스 아키텍쳐 이해
아키텍쳐는 앞서 정의하였듯이, 비지니스를 성공적으로 이끌기 위해서, 만들어지는 시스템에 대한 설계다. 목적이 “비지니스의 성공”에 있기 때문에, 그 비지니스 자체가 어떤 목표,전략을 가지고 있는지를 이해해야, 목표에 부합하는 아키텍쳐를 설계할 수 있다.
아키텍쳐 설계 원칙 정의 (Architecture Principals)
비지니스 아키텍쳐가 정의되었으면, 시스템을 설계 하기 위한 테크니컬 아키텍쳐를 설계하기 위한 원칙을 정한다. 품질 속성이나, 기간, 조직 운용론, 기반 기술등 설계의 기본 사상이 되는 원칙을 정의한다.
시스템 아키텍쳐의 (System Architecture) 설계
설계 원칙이 정해졌으면, 비지니스의 요구 사항을 이 설계 원칙에 따라서 설계한다. 시스템 아키텍쳐는 크게 아래와 같이 3가지로 나뉘어 정의된다.
① 애플리케이션 아키텍쳐 (Application Architecture) : 개발해야하는 애플리케이션 소프트웨어에 대한 아키텍쳐를 설계한다. 여기에는 컴포넌트의 정의, 컴포넌트 간의 관계, 특정 기능에 대한 컴포넌트간의 호출 흐름, 그리고 컴포넌트간의 통신을 위한 메세지에 대한 규격 정의를 포함한다.
② 테크니컬 아키텍쳐 (Technical Architecture) : 애플리케이션의 배포 구조를 정의한다. 애플리케이션을 배포할 하드웨어의 구조와, 애플리케이션 개발에 사용하는 미들웨어 (DBMS, 웹서버등)등의 배포 구조를 함께 정의한다.
③ 데이타 아키텍쳐 (Data Architecture) : 마지막으로, 애플리케이션에서 다루는 정보(데이타)의 구조와 관계를 정의한다.
0 Comments