엔터프라이즈 아키텍처 및 전략과 같은 상위 수준의 주제에 대한 작업을 맡은 사람들은 단순한 질문 인”당신은 무엇을합니까?”결과물이 명료성과 명확성이 부족할 때,이 질문에 대한 응답은 질문자를 혼란스럽게 만들고 응답자에게 거의 유감스럽게 생각합니다. 불확실성과 불완전성에 대한 자리 표시 자로서 응답에 던져진 일반적인 용어는 참조 아키텍처입니다.
이 용어는 다른 사람들에게 많은 것을 의미 할 수 있습니다. 정의되지 않은 경우,그것은 좌절과 낭비를 낳는 솜털과 흐릿함의 인상을줍니다. 구현 임무 사람들은 현실과 구체성에 개념과 생각을 접지 할 수있는 능력에 의문을 제기 할 수있다. 따라서 정의가 유용합니다. 다음은 참조 아키텍처에 대한 나의 정의입니다:
대상 고객에게 친숙한 언어 및 시각적 형식으로 설문 조사,경험 및 실험의 관찰을 기반으로 제품,솔루션 또는 시스템의 설계를 안내하는 고려 사항,옵션 및 알려진 표준의 표현입니다.
진실은 일단 특정 청중에게 사용의 의도,가치 및 맥락이 명확 해지면 공식적인 정의를 갖는 것은 중요하지 않다는 것입니다.
진짜 질문은—
“우리가 하고 싶은 것은 무엇입니까?”
둘째—
“우리는 사람들이(그들이 누구이든간에)무엇을 원합니까?”
이러한 질문에 대한 명확한 답변을 갖는 것은 참조 아키텍처의 의미와 전달을 제거하는 시작입니다. 의도,내용,청중 및 가치는 명확해야합니다. “참조”라는 단어는 산출물이 무엇을 구축해야하는지에 대한 정의와 반대로 관찰,경험 및 실험에서 지침과 표준을 제공한다고 제안합니다. “아키텍처”는 구조화되고 일관되며 검증 가능하다는 것을 암시합니다.
인터넷에서 발견되는 참조 아키텍처에 대한 다양한 정의가 있지만 위의 명확성 규칙(의도,내용,잠재 고객,가치)은 각각 찾을 수 있습니다. 구글 검색에서 최고 결과로 나오는 광산에 대한 대안 정의를 고려:
(1) 전달 될 내용(예:”문서”)의 매체 및 형식을 명확히하십시오. 이것은 필요한 도구,수행 할 작업의 성격 및 참여자의 기술 세트를 알려줍니다. 대체 전달 방법은 프레젠테이션 또는 쿼리 가능한 지식 기반 일 수 있습니다.
(2)”문서 세트”와 같이 전달 될 내용의 구조와 규모에 동의합니다. 하나의 결과물이 부족할 수 있지만 문제가 있는 시스템 도메인의 규모에 따라 결과물을 여러 문서로 분해해야 할 수 있습니다.
(3)”프로젝트 관리자”와 같은 주요 청중과 이해 관계자를 식별합니다. 그들이 정기적으로 소비하는 정보의 유형 및 형식을 이해하십시오. 현 상태 또한 여기에서 역할을 할 수 있습니다. 어떤 경우에는 참조 아키텍처가 정책으로보고 라인을”통과”하는 반면,다른 경우에는 고려해야 할 가장 좋은 방법과 대안을 설명한다는 기대와 함께”좋은”것으로 취급됩니다.
(4)참조 아키텍처를 사용해야 할 다른 이해 당사자를 식별합니다. 다른 뷰 또는 레이어를 만들 필요가 있습니까? 참조 아키텍처를 해석하고 적용하는 방법에 대해 다른 사람을 교육 할 필요와 공간이 있습니까?
(5)청중/독자가 문서로 무엇을해야하는지 분명히하십시오. “모범 사례를 참조하십시오.”출력은 그들이 표지에 말을 제공해야합니다,검증을위한 소스에 대한 증거와 링크를 포함. 참조 아키텍처는 또한 일관되고 실행 가능한 방식으로 실험에서”학습”을 제공 할 수 있습니다.
(6)관련성의 영역을 명확히 한다. 특정 도메인이 없는 참조 아키텍처는 아키텍처가 아닌 상위 수준의 지침 원칙을 구현하는 철학입니다. 아키텍처,심지어 참조 아키텍처도 도메인 바인딩되어야 합니다. 이 도메인이 작을수록 참조 아키텍처의 관련성이 높고 실행 가능합니다.
(7)레퍼런스 아키텍처의 의도된 가치를 전달해야 하는데,이는 시청자가 그 목적과 한계를 판단하는 데 도움이 되기 때문이다.”그런 다음 구현 팀은 이 결정을 내려야 할 때 어디로 가야 하는지 알고 있습니다.
(8)도메인의 예를 가지고 관련 기술을 진술하면 참조 아키텍처의 컨텍스트를 명확히하는 데 도움이됩니다.
(9)구현할 때 고려해야 할 구성 요소 및 기능의 대안과 출처는 잘 문서화되고 연결되어야합니다.
기술 프로젝트가 시작되기 전에 참조 아키텍처가 반드시 차단제는 아닙니다. 그것은 병렬로 또는 배달 후 개발 될 수 있으며,사후 및 교훈의 문서 역할을합니다. 프로젝트가 시작되기 전에 생성 된 경우 좋은 관행을 알리기 위해 설문 조사,시험 및 실험이 필요합니다. 다음은 잠재 고객,솔루션 및 조직 또는 프로젝트 팀 내의 현재 지식 격차에 따라 가능한 참조 아키텍처 클래스에 대한 제안 된 분류법입니다.
레퍼런스 아키텍처의 다섯 가지 측면에 대한 약어는 이해의 조직 수준 또는 도메인에서 대화에서 기억에 남는 것으로 입증되었습니다 음악이다:
- 엠버십:도메인과 관련된 것으로 간주되는 아키텍처 요소의 목록 및 분류.
- 세이지: 사용자 스토리,비즈니스 사례,프로세스,워크 플로우 및 도메인의 활동을 설명하는 수단.
- 구조:도메인의 다양한 요소가 사용을 지원하기 위해 상호 연결되는 방법.
- (또는 통합):사용 중에 아키텍처 요소간에 교환되는 인터페이스와 메시지.
- 제어:상호 작용을 제어하는 데 사용되는 제약 조건 및 정책.
이제 모든 참조 아키텍처가 식별 된 각 영역을 다루는 25 개의 문서 또는 하위 섹션을 제공해야한다는 것을 암시하지는 않습니다. 이것은 고려 사항,옵션 및 책임이 조직이나 프로젝트에서 분명히 표현되어야하는 25 가지 영역이 있음을 보여줍니다. 이것은 너의 경청자의지하고 있는 변화할 것이다. 참조 아키텍처에는 흐릿함 또는 솜털이 없습니다. 그들은 탐색 노력의 결과이며 단기 응용 연구의 유형 출력입니다.