애플리케이션 아키텍처

Applications architecture

정보 시스템에서 애플리케이션 아키텍처 또는 애플리케이션 아키텍처는 엔터프라이즈 아키텍처(EA)의 기둥을 이루는 여러 아키텍처 도메인 중 하나이다.[1][2]

애플리케이션 아키텍처는 비즈니스에서 사용되는 애플리케이션들이 상호 및 사용자와 상호작용하는 방법에 초점을 맞춘 동작을 설명한다. 그것은 내부 구조보다는 애플리케이션에 의해 소비되고 생산되는 데이터에 초점을 맞추고 있다. 애플리케이션 포트폴리오 관리에서 애플리케이션은 제공되는 가치를 평가하기 위해 비용, 기능 품질 및 기술 품질뿐만 아니라 비즈니스 기능 및 프로세스에 매핑된다.

애플리케이션 아키텍처는 비즈니스 및 기능 요구사항에 기초하여 지정된다. 여기에는 기능적 적용범위 측면에서 애플리케이션 패키지, 데이터베이스 및 미들웨어 시스템 간의 상호작용을 정의하는 것이 포함된다. 이는 통합 문제 또는 기능 적용 범위의 격차를 식별하는 데 도움이 된다. 그런 다음 소프트웨어 수명주기가 끝나거나 기술적 실패의 결과로 사업을 중단시킬 수 있는 잠재적인 기술적 위험이 내재된 시스템에 대해 마이그레이션 계획을 작성할 수 있다.

애플리케이션 아키텍처는 조직에서 복합 아키텍처를 생성하기 위해 사용하고 있는 애플리케이션 제품군이 확장 가능하고, 안정적이며, 가용하며, 관리가 가능하도록 보장하기 위해 노력한다.

애플리케이션 아키텍처는 여러 애플리케이션이 어떻게 함께 작동하는지 정의한다. 시스템 구축 방식의 기술 설계를 다루는 소프트웨어 아키텍처와는 다르다.[citation needed]

복합 아키텍처가 구현하고 있는 기능성의 역학을 이해하고 관리할 뿐만 아니라, 배치 전략을 수립하고 조직의 성장 및/또는 운영을 위태롭게 할 수 있는 기술적 위험을 계속 주시할 필요가 있다.[citation needed]

전략

애플리케이션 아키텍처 전략은 애플리케이션과 통합이 조직의 성장 전략과 일치하도록 보장하는 것을 포함한다. 어떤 조직이 인수를 통한 빠른 성장 계획을 가진 제조 조직이라면, 애플리케이션 아키텍처는 다른 대규모 경쟁 시스템뿐만 아니라 상속된 레거시 시스템도 포괄할 정도로 민첩해야 한다.

패턴

주요 기사: 건축 패턴
추가 정보: 소프트웨어 설계 패턴

애플리케이션은 그들이 따르는 애플리케이션 아키텍처 패턴에 따라 다양한 유형으로 분류될 수 있다.

"패턴"은 "한 가지 실제적인 맥락에서 유용했고 아마도 다른 사람들에게 유용할 것"으로 정의되었다.

패턴을 만들려면 블록을 쌓아야 한다. 빌딩 블록은 소프트웨어의 구성요소로서, 대부분 재사용할 수 있으며, 특정 기능을 만드는 데 활용할 수 있다. 패턴은 건물 블록을 문맥에 넣고 하나 또는 여러 개의 아키텍처 문제를 해결하기 위해 건물 블록을 사용하는 방법을 설명하는 방법이다.

애플리케이션은 일반적으로 동일한 패턴을 따르는 다양한 기능의 모음입니다. 이 패턴은 응용 프로그램의 패턴을 정의한다.

애플리케이션 패턴은 구조(배포/배포 관련) 또는 행동(프로세스 흐름 또는 상호작용/통합 관련) 특성을 설명할 수 있으며 애플리케이션 아키텍처는 하나의 패턴 또는 혼합된 패턴을 활용할 수 있다. 패턴에 대한 생각은 컴퓨터 과학이 시작된 이래 거의 존재해 왔지만, 패턴의 상당 부분이 '응용프로그램 아키텍처' 패턴이 아닌 '소프트웨어 아키텍처' 패턴임에도 불구하고 '4강(Gang of Four)'에 의해 가장 대중화된 것으로 알려져 있다. 토머스 얼은 GoF 외에도 다양한 형태의 패턴을 잘 쓴 저자로 마이크로소프트와 같은 대형 소프트웨어 도구 판매상 대부분이 광범위한 패턴 라이브러리를 출판했다.

출판된 패턴이 넘쳐나지만 '산업 표준'이라고 생각할 수 있는 패턴은 상대적으로 적다. 이들 중 가장 잘 알려진 것은 다음과 같다.

  • 단일 계층/단일 클라이언트/단일 애플리케이션(프로토콜 패턴): 단일 컴퓨터, 일반적으로 데스크톱에만 존재하는 애플리케이션. 물론 많은 컴퓨터에서 동일한 데스크톱 애플리케이션을 사용할 수는 있지만 서로 상호 작용하지는 않는다(희귀한 예외를 가지고 있음).
  • client-server/2-tier (property pattern): 비즈니스 논리, 워크플로우, 통합 및 데이터 서비스를 제공하는 백엔드(서버)와 통신하는 리치 클라이언트로 실행되는 프런트엔드(사용자 대면) 계층으로 구성된 애플리케이션. 데스크톱 애플리케이션(단일 사용자)과 대조적으로 클라이언트-서버 애플리케이션은 거의 항상 다중 사용자 애플리케이션이다.
  • n-계층(구조 패턴): 서버 기능이 여러 계층으로 분할되어 LAN(local-area network)을 통해 서로 다른 컴퓨터에 분산되는 클라이언트-서버 패턴의 확장.
  • 분산(구조 패턴): 서버 기능이 광역 네트워크(WAN) 또는 클라우드에 분산되는 n-계층 패턴의 확장. WAN 및 클라우드 구축 시나리오에서 발생할 수 있는 잠재적으로 유의한 대기 시간을 처리하기 위해 서버 기능이 다른 기능과의 비동기 대화 상자에서 더 자율적이고 기능하도록 설계되어야 하기 때문에 이 패턴에는 일부 행동 패턴 속성도 포함된다.
  • 수평 확장성(수평 패턴): 더 크고 더 강력한 컴퓨터에 기능을 재전개할 필요 없이 처리 부하를 증가시키는 방식으로 여러 대의 컴퓨터에서 서버 기능의 복사본을 실행하기 위한 패턴. 클라우드 네이티브 애플리케이션은 기본적으로 수평적 확장성을 기반으로 한다.
  • 이벤트 중심 아키텍처(이벤트 패턴): 데이터 이벤트(처음에는 장치, 애플리케이션, 사용자, 데이터 저장소 또는 시계에서 시작되었을 수 있음) 및 이벤트를 조건부로 폐기하거나, 이벤트 관련 프로세스를 시작하거나, 사용자 또는 장치 관리자에게 경고하거나, 데이터 저장소를 업데이트할 수 있는 이벤트 탐지 논리. 이벤트 중심 패턴은 분산 아키텍처 패턴이 요구하는 비동기 처리의 기본이다.
  • ETL(행동 패턴): 원본에서 데이터를 추출하여 일부 비즈니스 규칙에 따라 데이터를 변환한 다음 해당 데이터를 대상에 로드하는 애플리케이션 프로세스 패턴. ETL 패턴의 변화에는 ELT와 ETLT가 포함된다.
  • 요청-응답(행동 패턴): 응용 프로그램이 다른 응용 프로그램의 데이터를 요청하고 요청된 데이터를 포함하는 응답을 기다리는 데이터 교환을 위한 응용 프로그램 통합 패턴. 이것은 이전의 패턴 설명에서 언급된 비동기 처리와는 대조적으로 동기 패턴의 가장 두드러진 예다.

올바른 애플리케이션 패턴은 조직의 산업과 구성요소 애플리케이션의 사용에 따라 달라진다. 조직은 조직적으로 그리고 인수를 통해 모두 성장했다면 여러 가지 패턴이 혼합될 수 있다.

애플리케이션 설계자

TOGAF는 애플리케이션 설계자의 기술과 역할 기대치를 모두 설명한다. 이러한 기술에는 애플리케이션 모듈화/유통, 통합, 고가용성, 확장성 패턴, 기술 및 동향에 대한 이해가 포함된다. 애플리케이션 컨테이너, 서버 없는 컴퓨팅, 스토리지, 데이터 및 분석, 기타 클라우드 관련 기술 및 서비스에 대한 이해는 점점 더 애플리케이션 설계 기술이 요구되고 있다. 소프트웨어 배경은 애플리케이션 설계자에게 훌륭한 기반이지만, 프로그래밍과 소프트웨어 설계는 애플리케이션 설계자에게 요구되는 기술이 아니다(컴퓨터 프로그래밍 팀의 리더인 소프트웨어 설계자에게 실제로 필요한 기술이다).

지식 도메인

애플리케이션 모델링
새 애플리케이션 또는 향상된 애플리케이션의 배포 및 통합을 위한 프레임워크로 모델링 사용, 문제 발견, 위험 감소, 예측 가능성 향상, 비용 및 출시 시간 단축, 다양한 제품 시나리오 테스트, 고객의 비기능적 요구/요건 통합, 개발 프로세스에 테스트 설계 결정 추가제품 설계 문제를 평가한다.
경쟁력 있는 인텔리전스, 비즈니스 모델링, 전략적 분석
글로벌 시장, 소비자, 산업 및 경쟁과 글로벌 비즈니스 모델, 전략, 재무, 운영 및 구조가 어떻게 상호 연관되어 있는지 이해. 시장, 산업, 경쟁 및 규제 환경의 현재 추세를 포함한 경쟁 환경에 대한 이해와 비즈니스 모델의 구성요소(즉, 전략, 재정, 운영)가 어떻게 상호 연관되어 조직이 시장에서 경쟁력을 갖도록 하는가에 대한 이해. 조직의 비즈니스 프로세스, 시스템, 도구, 규정 및 구조에 대한 이해와 이들이 고객, 소비자 및 주요 이해당사자들에게 가치를 창출하는 제품과 서비스를 제공하기 위해 상호 연관되는 방법. 고객, 소비자 및 주요 이해당사자를 위한 가치가 조직의 비전, 비즈니스, 문화, 가치 제안, 브랜드 약속 및 전략적 의무와 어떻게 일치하는지 이해. 경쟁 환경과 관련하여 강점과 약점, 기회 및 리스크를 평가하기 위한 조직의 과거와 현재의 성과와 단점에 대한 이해.
기술
IT 전략, 개발 라이프사이클 및 애플리케이션/인프라 유지 보수, IT 서비스 및 지원 프로세스를 이해하여 경쟁 우위 촉진, 효율성 창출 및 비즈니스 가치 증대
기술표준
기존 및 미래의 비즈니스 요구사항을 효과적으로 지원하는 데 필요한 인프라를 형성하고, 모든 하드웨어 및 소프트웨어가 비즈니스 환경에 통합되어 기술을 이해하고 개발할 수 있는 기본 요구사항 및 표준을 준수하도록 보장하는 핵심 기술에 대한 철저한 이해도를 입증ical 표준과 절차를 통해 신기술의 사용을 촉진하고, 신기술의 사용과 적용을 위한 유용한 지침을 개발한다.

임무들

애플리케이션 설계자는 조직에서 애플리케이션별 모든 것을 마스터한다. 애플리케이션 설계자는 다음과 같은 관점에서 모든 애플리케이션을 이해함으로써 애플리케이션 유지관리 팀에 전략적 지침을 제공한다.

위의 분석은 단편화된 애플리케이션에 대한 배치 전략의 변화에서 기술 또는 기능 라이프사이클이 끝날 때 애플리케이션의 완전한 대체에 이르기까지 다양한 변화가 필요한 애플리케이션을 지적할 것이다.

기능 설치 공간

주요 비즈니스 프로세스의 시스템 프로세스 흐름 이해 그것은 다양한 애플리케이션의 기능 맵과 애플리케이션 설치 공간을 맵 전체에 걸쳐 명확하게 보여준다.

많은 조직은 문서화 규율이 없기 때문에 세부적인 비즈니스 프로세스 흐름과 시스템 프로세스 흐름이 부족하다. 사람들은 우선 그것들을 배치하기 위한 이니셔티브를 시작해야 할지도 모른다.

솔루션 아키텍처 지침 작성

모든 조직에는 여러 부서에서 하나의 인스턴스 또는 각 부서마다 다른 인스턴스로 사용되는 핵심 애플리케이션 집합이 있다. 모든 프로젝트가 구현 설계를 위한 공통의 시작 기반을 갖출 수 있도록 모든 핵심 애플리케이션을 위한 솔루션 아키텍처 템플릿을 만드십시오.

아키텍처 세계의 표준은 TOGAF에 정의되어 있으며, 오픈 그룹 아키텍처 프레임워크는 EA의 네 가지 요소를 BDAT(비즈니스 아키텍처, 데이터 아키텍처, 애플리케이션 아키텍처 및 기술 아키텍처)로 설명한다.

조직의 복잡성 수준에 따라 고려해야 할 다른 기준도 있다.


참고 항목

참조

  1. ^ Steven Spewak; S. C. Hill (1992). Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. Boston, QED Pub. Group. ISBN 978-0-471-59985-2.
  2. ^ "Reference Model for ISEB Certificates in Enterprise and Solution Architecture Version 3.0" (PDF). bcs. 2010.
  3. ^ "Application Architecture". Gartner IT Glossary. 2012-02-09. Retrieved 2017-07-26.