기업, 시스템 및 응용 프로그램 아키텍처 (모범 사례?)
https://stackoverflow.com/questions/755540
-
09-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
현재 소프트웨어 개발을위한 문서화 된 일관된 아키텍처 안내서를 작성해야합니다. 우리는 많은 똑똑한 사람들이 올바른 일을하고 있지만 일관되고 반복적으로는 아닙니다.
우리는 Microsoft의 응용 프로그램 아키텍처 가이드 2.0을 시작점으로 사용하고 있습니다. 따라서 응용 프로그램 아키텍처를 생각해내는 것은 공정하게 (쉽지 않을 것입니다) 곧바로 말입니다. 아마도 개발자로서 몇 년의 경험이 있기 때문에이 영역을 잘 이해하고 있으며 많은 예와 지침도 있습니다.
우리 조직에는 1 개 이상의 시스템을 형성하는 몇 가지 애플리케이션이 있기 때문에 "클라이언트에"설치하는 "시스템 아키텍처와 엔터프라이즈 아키텍처를 만드는 것이 합리적이라고 생각했습니다. 그리고 이것이 문제가 시작되는 곳입니다.
거기에는 일관된 지침이 없습니다. "시스템 아키텍처 예"를 검색하면 돌아 오는 것들이 너무 다르기 때문에 "표준"방법이 있는지 궁금합니다.
내 (제한된 - 명확한) 모든 것을 이해함으로써 시스템 아키텍처는 시스템을 형성하기 위해 함께 작동하는 방법을 묘사하는 1 개 이상의 응용 프로그램 아키텍처의 추상화입니다. 또한 엔터프라이즈 아키텍처는 시스템이 조직 기업에 어떻게 적합한 지, 비즈니스 프로세스, IT 전략 및 기업의 다른 시스템에 어떻게 통합되는지를 보여주는 추상화입니다.
- 완전히 잘못 되었습니까?
- 거기에 어떤 표준이 있습니까 (그리고 어디에서 찾을 수 있습니까?)?
- 표준이 있거나 "좋은"시스템 아키텍처가 독자에게 명확하고 쉽게 이해할 수 있고 유용한 모든 형식의 문서일까요?
- 노련한 건축가들은 그 접근법에 대해 어떻게 생각할까요?
유용 할 수있는 SOA 관련 패턴 세트를 간단히 나열하고 싶지 않습니다 ... 서비스 지향 아키텍처의 빌드 금융 솔루션 인 우리가하는 일에 조금 더 집중하고 싶습니다.
업데이트 : TOGAF (9). 누구든지 경험이 전혀 있습니까? 자세히 이해하려고 노력할 가치가 있습니다.
해결책
나는 며칠 전에이 질문을 제출했지만 계속 연구와 읽기 후 Littlegeek반응, 나는 매우 유익하고 흥미로운 흥미로운 백서를 발견했다고 생각합니다.
읽다: 상위 4 개의 엔터프라이즈 아키텍처 방법론의 비교작성자 : 로저 세션
스 니펫 ...
-- - - - - - - - - - - 8< - - - - - - - - - - - -
지난 20 년 동안 많은 엔터프라이즈-아키텍처 방법론이왔다 갔다했습니다. 이 시점에서 아마도 필드의 90 % 가이 네 가지 방법 중 하나를 사용합니다.
- 기업 아키텍처를위한 Zachman 프레임 워크-프레임 워크로 자체적으로 설명하면서 실제로 분류법으로 더 정확하게 정의됩니다.
- Open Group Architectural Framework (TOGAF) - 프레임 워크라고 불리는 것은 실제로 프로세스로 더 정확하게 정의됩니다.
- 연방 기업 아키텍처 - 구현 된 엔터프라이즈 아키텍처 또는 엔터프라이즈 아키텍처를 만들기위한 전망 방법론으로 간주 할 수 있습니다.
- 가트너 방법론 - 엔터프라이즈 아키텍처 관행으로 가장 잘 묘사 될 수 있습니다.
이 백서는이 네 가지 접근법에 대해 엔터프라이즈 아키텍처에 대해 논의합니다. 그것은 매우 논픽션 운영 문제에 직면하고있는 가상의 회사의 맥락에서 그렇게합니다. 이러한 문제는 다음과 같습니다.
- IT 시스템은 무의미하게 복잡 해지고 유지하는 데 점점 더 많은 비용이 들었습니다.
- 조직의 현재 및 미래 시장 조건에 적시에 비용 효율적인 방식으로 대응하는 능력을 방해하는 IT 시스템.
- 일관되게 오래되지 않고/또는 단지 잘못된 미션 크리티컬 정보.
- 조직의 비즈니스와 기술 측면 사이의 불신 문화.
-- - - - - - - - - - - 8< - - - - - - - - - - - -
백서는 여러 가지 방법으로 나를 도왔습니다.
- 그것은 나에게 좋은 소개와 건축의 역사를 주었다 (Enterprise Architecture).
- 저자가 제안한 4 가지 주요 엔터프라이즈 아키텍처가 제공되는 것을 소개했습니다.
- 그런 다음 논리적이고 간단한 방식으로 계속 비교할 수있는 좋은 예와 비교합니다.
나는 내 모든 질문에 대한 답변이 응답되었고 이제 죽을 준비가되었다고 말할 수는 없지만 :-), 그러나 많은 것이 명확 해졌으므로 다른 사람이 이것도 유용 할 수 있다고 생각했습니다.
나는 여전히이 주제에 대해 당신이 가질 수있는 추가 의견, 제안 및 질문을 여전히 소중히 여길 것입니다.
다른 팁
당신은 상황과 예술의 영역에 대한 이해를 정말 잘 이해하고있는 것 같습니다.
"시스템"아키텍처는 정의하기가 어렵습니다. "솔루션"또는 "IT"를 찾을 수 있지만 소프트웨어 아키텍처가 물리적 서버 세계와 어떻게 관련되어 있는지, 약간의 네트워킹이 발생하는 것처럼 들립니다.
"우리는 많은 똑똑한 사람들이 올바른 일을하고 있지만 일관되고 반복적으로는 아닙니다."
그런 다음 Togaf 8은 나 자신을 인증했다 - 나는 Togaf가 아키텍처를 정의하는 다양한 측면에 "방법론"을 가져오고 다양한 전문 기술 그룹을 하나로 모으고 비즈니스 목표에 단단히 고정시키는 방법을 가져옵니다. TOGAF는 또한 아키텍처 거버넌스의 필요성을 이해하도록 돕고 모든 부품 기술, 데이터, 시스템, 소프트웨어 및 비즈니스에서 변화에 대한 아이디어를 프로세스로 확고히 제공합니다.
그만큼
- 건축 개발 방법
- 기술 참조 모델
- 표준 정보 기반
- 엔터프라이즈 연속체
모든 도움이되는 데 도움이됩니다. 대주교 노력에 대한 정보를 수집하고 개발 및 EA에 대한 일관된 접근 방식을 제공합니다.
또한 고객이 자신이하고있는 일과 함께 맞는 방법을 보여주는 방법으로 TOAGF를 제시 할 수있는 방법을 이해하는 데 도움이됩니다.
추신 - 나는 Toagf가 당신을 위해 이것을 다룰 것이라고 내가 꺼낸 인용문을 유용하다고 말한다.
다른 건축가 Framworks가 있습니다.
나는 EA에 대한 실습 경험이 없지만 실제로는 탑승하고 있습니다. 상위 4 개의 EA 방법론 중에서, 나는 처음 3 개를 만났다. 나는 Gartner를 알지 못합니다. 어쩌면 문서를 사용할 수 없기 때문일 것입니다. IMHO, 우리가 EA에 대해 이야기 할 때, 우리는 실제로 비즈니스를 기술과 조정하는 것에 대해 이야기하고 있습니다. 따라서 모든 EA 방법론은 비즈니스 지향적이어야합니다. 그렇지 않다면 전혀 EA가 아닙니다.
Togaf는 매우 유용하고 이해할 수 있다고 생각합니다. 예, 현재 기준 아키텍처를 대상 아키텍처로 발전시키는 프로세스입니다. 건축 원칙은 EA 개발의 높은 수준의 지침으로 작용합니다. TOGAF의 핵심 구성 요소는 비즈니스 아키텍처, 정보 아키텍처 및 기술 아키텍처입니다. 그리고 그들 각각은 고유 한 아키텍처 패턴을 가질 수 있습니다. NIH : 국립보건원 Feaf와 함께 EA를 구현했습니다. EA를 구현하는 좋은 예입니다. 적어도 결과물의 관점에서 볼 때 Togaf 접근과 매우 유사하다고 생각합니다.
EA를위한 모델링 프레임 워크를 만들기위한 유일한 합리적인 시도는 지금까지 다음과 같습니다. https://en.wikipedia.org/wiki/archimate
Archimate는 Open Group의 기술 표준이며 IEEE 1471 표준의 개념을 기반으로합니다.
또한 EA 인공물과 그들 사이의 추적성에 대한 다음 링크를 참조하십시오.
