여기에 업데이트 일정에 대해 알아보십시오.

의도적인 솔루션은 즉시 시간에 따라 비즈니스 가치를 제공합니다. 의도적인 아키텍처는 전략적으로 계획 및 전달되며, 효과적으로 유지 관리할 수 있으며, 사람이 쉽게 읽고 이해할 수 있습니다.

기능 및 수정 사항은 비즈니스 및 기술 이해당사자 모두에게 투명한 방식으로 우선 순위가 지정되고 전달됩니다. 엔지니어링 선택 항목은 추가 기능이나 복잡성 없이 배달 및 서비스 점검 팀이 쉽게 작업할 수 있는 구현을 만듭니다. 명확하고 일관된 구현 패턴을 따르므로 비즈니스에서 의도된 아키텍처를 더욱 쉽게 소유, 유지, 발전할 수 있습니다. 빌더는 새 기능에 대한 설계를 해석하고 구현할 수 있으며, 서비스 점검 팀은 구현된 내용의 문서를 이해할 수 있습니다.

전략, 유지 관리, 가독성과 같은 세 가지 핵심 영역에 집중하여 더 의도적인 시스템을 만들 수 있습니다.

아키텍처의 전략은 시스템이 신중하게 계획되고 전달되었음을 의미합니다. 즉, 배달 및 서비스 점검 팀이 오늘과 향후 수행할 작업을 명확하게 파악하고 모든 사람이 수행할 작업의 "왜"에 부합한다는 의미입니다. 즉, 긴급한 요청을 효율적이고 효율적으로 분류할 수 있으며 이해당사자가 요청의 영향 및 제약을 명확하게 이해할 수 있습니다.

우선 순위, 로드맵, 거버넌스에 집중하여 아키텍처에 명확한 전략을 구축할 수 있습니다.

우선 순위 지정은 배달할 작업의 순서 및 범위를 계획하는 것을 의미합니다. 우선 순위 지정에는 비즈니스에 대한 배달의 실제 영향을 이해하고 다른 작업 요청 및 제품 또는 프로그램에 대한 전체 로드맵에 대한 영향을 평가하는 작업이 수반됩니다.

지정된 작업 항목의 영향을 평가하는 한 가지 방법은 비즈니스에 대한 실제 비용 또는 이점을 살펴보는 것입니다. 자동화에 대한 KPI를 파악한 후에는 비즈니스 영향 계산 워크시트를 사용하여 구현의 전체 비용 또는 이점을 평가할 수 있습니다. 해당 계산을 통해 구축할 자동화와 순서에 대한 이해당사자의 조정을 얻고 구매를 요청할 수 있습니다. 또한 자동화를 식별하여 연기하거나 피할 수 있습니다. 자동화는 효과적인 작업 식별에 대한 자세한 내용은 프로세스 설계을 참조하십시오.

또한 배달에 대한 우선 순위 지정 프레임워크를 설정하면 사용자 및 서비스 점검 팀이 사용자 기대치를 관리하고 로드맵을 유지하는 데 도움이 됩니다.

우선 순위 지정에 사용할 수 있는 몇 가지 고려 사항은 다음과 같습니다.

• 배달의 비즈니스 영향(비용/익률)
• 배달에 필요한 새 작업의 양
• 배달 서비스 점검에 필요한 작업량

아래의 패턴 및 안티패턴 목록은 Salesforce 작업에 대한 올바른(그리고 부적절한) 우선 순위 지정을 보여줍니다. 이를 사용하여 구현 계획을 확인하거나 구축하기 전에 우선 순위를 더 잘 식별해야 하는 위치를 식별할 수 있습니다.

Salesforce에서 사용할 수 있는 도구에 대해 자세히 알아보려면 우선 순위 지정에 대한 도움말을 받으려면 도구의 의도적 관련을 참조하십시오.

로드맵은 수행할 작업에 대한 우선 순위가 지정되고 확인되었으며 명확하게 정의된 보기입니다. 효과적인 로드맵은 향후 작업의 비즈니스 영향 및 기술 영향을 명확하게 파악합니다. 로드맵의 핵심 부분은 비즈니스 및 기술 이해당사자를 참여시키는 것입니다. 로드맵을 사용하면 작업을 시작하기 전에 접근 방식 및 결과에 대한 사용자 의견을 얻고 구매할 수 있습니다. 최종적으로 로드맵은 모든 이해당사자에게 앞으로 수행할 작업의 " 이유"에 대한 조율을 제공합니다.

팀에서 백로그를 사용하는 경우 로드맵이 백로그의 요약 또는 항목 목록이 아닌지 이해해야 합니다. 관계는 반대입니다. 항목은 로드맵의 배달에 명확하고 신뢰할 수 있는 방식으로 연결할 수 있는 경우에만 백로그에 입력할 수 있습니다. 이해당사자의 참여로 생성된 고품질 로드맵은 배달 및 서비스 점검 팀이 집중해야 하는 사항 및 요청 우선 순위를 지정해야 하는 방법을 명확하게 파악하여 충돌하는 요청을 쉽게 정렬하고 이해당사자 기대치를 관리할 수 있도록 합니다.

로드맵이 없거나 없으면 다음이 발생합니다.

• 새 기능 및 기능을 사용할 수 있는 시점에 대한 명확성 부족
• 이해당사자 간 우선 순위 충돌
• 제공되는 솔루션과 전체 조직 비전 간의 연결 끊김
• 진행 중인 작업을 이해하기 어려움
• 팀 간의 불규칙한 작업 부하
• 작업 항목 간 관계 및 종속성에 대한 가시성 부족
• 잘못 관리되는 종속성으로 인해 구현이 중단됨

이해당사자는 결정하기 위해 역할에 부합하는 정보를 필요로 하는 경우가 많습니다. 효과적인 로드맵을 만들려면 대상 그룹 및 대상 그룹이 필요한 정보 유형을 명확하게 이해해야 합니다. 로드맵은 비즈니스 및 기술 대상 그룹을 지원하기 위해 두 가지 스타일로 분류됩니다. 각 스타일에는 서로 다른 유형의 정보를 지원하는 두 가지 세분화 수준이 포함되어 있습니다.

비즈니스 로드맵은 이해당사자가 조직 변경을 계획하고, 성장 기회를 활용하고, 기업 목표를 유지하는 데 도움이 됩니다. 비즈니스 로드맵은 전체 비즈니스 비전에 맞춰 IT 지출을 보장하는 방법도 제공합니다.

• 비즈니스 성능 로드맵을 만들어 경영진 이해당사자에게 활성화할 성능을 표시합니다. 이 유형의 로드맵에는 기능 자체와 운영 효율성 향상 또는 새 제품 라인 출시와 같은 비즈니스 목표에 부합하는 방법에 대한 상위 수준의 세부 사항이 포함되어 있습니다.
• 비즈니스 기능 로드맵을 만들어 특정 기능을 자세히 살펴보고 비즈니스 이해당사자에게 자원 계획, 예산, 변경 관리에 도움이 필요한 경우 지원 기능 및 기능을 표시합니다.

기술 로드맵은 기술 이해당사자가 예산 및 자원 할당 계획에 도움이 됩니다. 또한 구현 팀이 더 큰 전체적인 이미지의 일부로 프로젝트가 부합하는 지점을 이해하고 팀 간 종속성을 식별할 수 있습니다.

• 기술 시스템 로드맵을 만들어 구현할 특정 시스템과 시스템 수준 종속성을 표시합니다. 이 유형의 로드맵은 상위 수준 시스템 정보와 시스템과 비즈니스 기능 간의 정렬을 보여줍니다.
• 기술 구성 요소 로드맵을 만들어 리소스 계획 및 활성화 요구 사항에 도움이 되도록 배포할 시스템의 특정 구성 요소를 자세히 살펴봅니다. 이 유형의 로드맵에는 구성 요소 수준 정보 및 구현 요구 사항(예: 선언적 개발, 프로 코드 등)이 표시됩니다.

로드맵에 실질적인 타임라인이 포함되어 있는지 확인합니다. 일반적인 실수는 관련 활동을 완료하는 데 걸리는 시간도 고려하지 않고 시스템 구현에 소요되는 시간만 포함하는 것입니다. 이를 통해 구현 팀 구성원이 과도하게 할당되고 예상보다 더 오래 지연될 수 있습니다. 로드맵을 만들 때 다음을 완료하는 데 걸리는 시간을 고려하십시오.

• 모든 신규 및 업데이트된 기능 문서
• 새 기능을 지원하는 데 필요한 기존 기능의 서비스 점검
• 통합을 지원하기 위해 필요한 관련 시스템 업데이트
• 적용 직후 프로젝트 팀의 지원 강화
• 테스트, 교육, 변경 관리

올바르게 조율된 비즈니스 및 기술 로드맵은 기능이 적용되는 시기 및 이후의 기술에 대한 전체적인 관점을 전달합니다. 아래의 패턴 및 반패턴 목록은 Salesforce 조직의 올바른(또는 나쁜) 로드맵을 보여줍니다. 이를 사용하여 로드맵 전략을 확인하거나 개선할 수 있습니다.

로드맵을 작성하는 데 도움이 되는 Salesforce 도구에 대해 자세히 알아보려면 도구와 관련된 의도을 참조하십시오.

거버넌스는 이해당사자와 우선 순위 지정, 의사 결정, 변경 관리를 처리하는 데 사용하는 구조입니다. 거버넌스는 결정을 내리고 커뮤니케이션하는 방식을 명확하게 보여줍니다. 이는 의사 결정 프로세스에 참여할 사용자 의견과 요청을 일관되게 제공하고 모든 이해당사자가 서비스 점검 및 개발 작업 상태를 이해할 수 있는 방법을 제공합니다. 거버넌스는 릴리스 관리 프로세스를 명확하고 일관되게 만들고 모든 팀 구성원이 역할 및 책임을 이해하는 데 도움이 됩니다.

적절한 거버넌스가 없으면 팀은 다음을 포함하여 다양한 문제를 겪게 됩니다.

• 겹치는 기능 및 기능에 대한 요청이 임시로 도착합니다.
• 구현 팀은 비즈니스 가치, 혜택 또는 전체 조직 목표를 적절하게 고려하지 않고 더 영향력 있는 이해당사자의 "쉬운" 노력 또는 요청에 우선 순위를 지정합니다.
• 일관적인 승인 및 검토 프로세스가 없음
• 불일치하는 릴리스 케이던스 및 품질
• 개발 노력에서 고유율, 덮어쓰기, 충돌, 중복 작업

시스템에 효과적인 거버넌스가 없다는 가장 명확한 증거는 느리고 번거로운 릴리스일 수 있습니다. 거버넌스 시스템의 크기가 효율성을 측정하는 것은 아닙니다. 실제로, 많은 대기업에서 발견되는 것과 같은 정교한 거버넌스 시스템은 릴리스 속도와 빈도를 줄일 수 있습니다.

올바른 관리는 나쁜 사용자 정의가 개발 초기 단계를 지나가기 어렵게 만들고 좋은 사용자 정의를 예측 가능하고 일관적으로 프로덕션으로 가져오는 것입니다.

너무 자주, 거버넌스 노력이 반응적입니다. 과도한 기술 부채와 같은 문제가 비즈니스 문제가 되기 시작하거나 중복됩니다. 많은 경우 불행하게도 비즈니스는 효과적인 설계 표준과 빌딩 자동화를 만들어 개발자 도구 체인 및 소스 제어 시스템 내에서 해당 표준을 적용하는 대신 개발 노력과 릴리즈를 "차단"하는 것입니다.

Salesforce 거버넌스 시스템에 대한 프레임워크를 구축할 때 다음 요소를 포함하고 다음의 주요 질문에 대한 답변을 고려하십시오.

• 작업 요청. 사용자가 기능 또는 기능을 어떻게 요청할 수 있습니까? 버그를 어떻게 보고합니까?
• 우선 순위 지정 및 작업 계획. 어떤 작업 요청이 중요한지 누가 결정합니까? 작업 범위 지정, 우선 순위 지정, 수락 또는 사인오프
• 환경 및 출시 계획. 개발, 테스트, 릴리스를 위한 환경 파이프라인은 무엇입니까? 누가 프로비저닝, 새로 고침, 액세스 권한을 제공해야 합니까? 배포 및 유효성 검사를 처리하는 사람은 누구입니까? 변경 사항이 릴리스되는 방법 및 시기 Salesforce 릴리스 주기 동안 배포 또는 환경을 처리하는 방법은 무엇입니까? (자세한 내용은 응용 프로그램 수명 주기 관리를 참조하십시오.)
• 서비스 소유권 및 생산 지원. 누가 무엇을 지원합니까? "핫픽스" 프로덕션 문제를 처리하는 사람은 누구입니까? 이러한 항목이 테스트 및 해제되는 방법은 무엇입니까? 조직의 전체 보안 표준을 담당하는 사람은 누구입니까?

아래의 패턴 및 반패턴 목록은 Salesforce 조직의 올바른(그리고 나쁜) 거버넌스를 보여줍니다. 이를 사용하여 거버넌스 전략을 확인하거나 개선할 수 있습니다.

거버넌스에 사용할 수 있는 Salesforce 도구에 대해 자세히 알아보려면 도구의 의도적 관련을 참조하십시오.

다음 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다.

✨ Pattern & Anti-Pattern Explorer에서 전략에 대한 더 많은 패턴을 알아보십시오.

유지 보수성은 새로운 기능이 적용되고 기술 부채가 예측 가능한 기준으로 시스템에서 정기적으로 이동하는 상태로 시스템을 유지할 수 있음을 의미합니다. 서비스 점검 가능한 시스템을 사용하면 팀이 예측 가능한 속도와 품질으로 비즈니스에 가치를 전달할 수 있습니다. 시스템의 서비스 점검 가능성은 얼마나 가독성이 뛰어난지, 얼마나 느슨하게 연결되어 있는지, 테스트 전략의 철저성 등 여러 요소에 따라 다릅니다.

무엇보다 시스템의 서비스 점검 가능성은 설계의 간단성에 따라 다릅니다. 이 섹션에서는 보다 간단한 솔루션 설계를 만들고 유지 관리 기능을 향상하는 방법을 설명합니다.

사용자 정의 기능을 기준으로 표준을 사용하고 기술 부채를 처리하는 두 가지 키에 집중하여 유지 관리하기 쉬운 솔루션을 구축할 수 있습니다.

Salesforce는 Sales Cloud, Service Cloud 및 많은 Salesforce 산업 솔루션과 같은 사전 구축된 솔루션의 범위를 제공하며 자체 사용자 정의 솔루션을 만들 수 있는 유연성을 제공합니다. Salesforce의 자체 클라우드 솔루션을 구동하는 기본 서비스는 Salesforce Customer 360 플랫폼에 구축된 사용자 정의 솔루션에서도 사용할 수 있습니다. Salesforce의 사전 구축 서비스 및 솔루션을 최대한 많은 솔루션에 대한 신뢰할 수 있는 기반으로 사용합니다.

사전 구축 플랫폼 서비스를 사용하면 두 가지 고유한 이점이 있습니다. 먼저, 앱은 릴리스마다 최신 Salesforce 혁신을 자연스럽게 활용할 수 있습니다. 두 번째로, 개발 팀은 기본 아키텍처의 어려운 작업을 처리하는 대신 Salesforce 솔루션에서 제공하는 비즈니스 역량 확장 및 강화에 집중할 수 있습니다.

표준 기능을 사용할 시기와 사용자 정의 기능을 구축할 시기를 올바르게 선택하는 것은 아키텍처 측면에서 까다로운 것은 아닙니다. 키:

• 플랫폼을 사용자 지정하는 것은 복제가 아니라 수정 및 확장을 의미합니다. 아키텍처를 설계하거나 평가할 때 다음을 물어야 합니다. Salesforce Platform에 이미 이러한 항목이 있습니까? 답변이 “*예, 하지만...[비즈니스 이해당사자가 여기에서 변경 사항을 삽입하려면...]”*인 경우 플랫폼에서 미리 작성된 기능을 사용합니다. 수행할 아키텍처 작업은 비즈니스 기대치를 충족하도록 사전 구축된 Salesforce 기능을 구성하는 가장 유용한 방법을 식별하는 것입니다.
• 사용자 정의는 소소하지 않습니다. 시간이 지남에 따라 모든 변경에 결과가 있습니다. 사용자 지정 솔루션을 구축해야 하는 경우 시스템이 발생하는 불가피한 기술적 부채를 완화할 수 있습니다. 가능한 경우 낮은 코드 기술을 사용하고 구축에 합성 유닛을 생성합니다.
• 구축-구매 스펙트럼을 고려하십시오. Salesforce AppExchange는 Salesforce를 확장할 수 있는 앱과 솔루션의 마켓플레이스입니다. AppExchange 앱은 맞춤형 솔루션 구축 및 유지 관리와 관련된 오버헤드 없이 기능을 제공할 수 있습니다. AppExchange 솔루션을 평가할 때 다음 사항을 고려하십시오.
  • 솔루션 기능 및 공백을 식별합니다. 모든 비즈니스 요구 사항을 충족하는 앱을 찾을 수 있습니다. 실제로는 완벽한 맞춤을 찾을 수 없습니다. 솔루션을 평가할 때 잠재적인 솔루션의 기능을 우선 순위가 지정된 비즈니스 요구 사항 목록에 매핑합니다. 이렇게 하면 가장 중요한 요구 사항을 가장 잘 충족하는 솔루션을 찾을 수 있습니다.
  • Sandbox 및 무료 평가판을 사용합니다. 무료 평가판을 사용하여 Sandbox 환경에서 앱을 평가하고 가장 적합한 앱을 식별합니다. 앱에서 기존 구성과 충돌하는 구성을 변경해야 하는지 확인합니다.
  • 단기 및 장기 비용을 고려합니다. 구독 기반 앱의 반복 비용과 비교하여 장기 앱 서비스 점검 할인을 평가합니다. 비즈니스 이해당사자가 사용하지 못하는 많은 기능에 대해 반복 비용을 지불해야 하는 시나리오를 피하십시오.
• Salesforce에서 미리 작성된 데이터 모델을 사용합니다. Salesforce는 세일즈, 서비스, 다양한 산업 분야에 사전 구축된 데이터 모델을 제공합니다. Salesforce에서 제공하는 데이터 모델을 사용하면 시스템의 기능이 한 번만 정의되도록 합니다(중복 및 사일로 제거), 전체 시스템에 대한 신뢰할 수 있는 단일 소스를 설정하고, 분석을 통해 애플리케이션 데이터를 더 쉽게 이해하고, Salesforce의 사전 구축된 인공 지능 서비스를 더 쉽게 사용할 수 있도록 하고, 지원해야 하는 사용자 정의를 줄여 유지 관리 비용을 절감하며, 기술 부채를 줄일 수 있습니다.

매우 간단합니다. 아래의 모형 및 안티모형에서 볼 수 있듯이, 안티모형은 사용자 정의 솔루션에서 표준 기능을 복제하거나 더 복잡한 기술을 사용하여 사용자 정의 작업을 수행합니다.

실제로 비즈니스 이해당사자가 사용자 정의 기능 안티 패턴을 최선 또는 유일하게 실행 가능한 방법으로 보는 시나리오가 발생할 수 있습니다. 이러한 경우 이해당사자에게 이 경로를 선택하는 데 관련된 제약 사항을 설명한 다음, 결정, 그 근거, 구현을 철저하게 문서화해야 합니다. 이 영역은 조기에 핵심 가치를 제공하고 시간에 따라 적절하게 조정하면 이해당사자가 앞으로 나아갈 수 있는 최상의 방법을 더 잘 이해하는 데 도움이 됩니다.

서비스 점검 가능성을 높이는 데 도움이 되는 Salesforce 도구에 대해 자세히 알아보려면 도구와 관련된 의도을 참조하십시오.

기술 부채는 모든 시스템의 자연적 부분입니다. 기술 또는 비즈니스 요구가 변경되면 어제의 사운드 디자인이 안티 패턴이 될 수 있습니다. 새로운 Salesforce 릴리스 또는 제품 출시로 Salesforce Platform 기능의 격차를 채우기 위해 구축된 기능이 갑자기 중복되었을 수 있습니다. 보다 성능이 뛰어난 또는 유연한 기술이 이미 구현한 기술을 대체할 수 있습니다. 기술 부채는 여러 가지 방법으로 생성할 수 있습니다.

Salesforce Customer 360 플랫폼을 사용하여 애플리케이션을 구축하는 주요 장점은 플랫폼에 내장된 뒤로 호환성입니다. 다시 말해 새로운 플랫폼 혁신을 통해 솔루션이 진행되기 위해 사용해야 하는 패턴을 변경할 수 있지만 이전 Salesforce 기술을 기반으로 구축한 솔루션의 일상적인 기능은 계속 작동합니다. 시간이 지남에 따라 오래된 기술을 기반으로 하는 솔루션은 앱에 새로운 기능을 추가할 때 위험 또는 지체 지점을 야기하고 전반적인 솔루션 상태가 저하됩니다.

기술 부채를 해결하기 위해 정기적인 작업을 계획하고 수행하는 것은 Salesforce 솔루션에서 원활하고 간단한 디자인을 유지하기 위해 필요합니다. 기술 부채를 계획, 감사 및 조정하지 못하면 잘못된 구조의 시스템을 만들 수 있습니다.

기술 부채를 최소화하는 방법 중 하나는 바로 가기를 피하고 사용자 지정 기능보다 표준 기능을 선호하는 방식으로 기술 부채를 가능한 한 많이 도입하지 않는 것입니다. 하드 코딩 값과 같은 바로 가기는 시간을 절약하는 유혹이 될 수 있지만 장기적으로는 환불해야 하는 부채를 야기합니다.

아키텍처 관점에서 기술 부채를 해결하기 위한 핵심은 다음과 같습니다.

• 행동과 비행의 실제 비용 또는 이점을 파악
• 적절한 로드맵
• 구축 가능한 솔루션

이해당사자를 조치에 부합시키는 것은 어려울 수 있습니다. 일부 이해당사자는 진행 중인 서비스 점검을 "내일의 실수"를 해결하거나 예산에서 지원하려는 기능을 제거하는 것으로 간주할 수 있습니다.

작업과 비작업이 미치는 실제 비즈니스 영향을 명확하게 정의된 납품 및 타임라인과 함께 표시하면 이해당사자가 기술 부채 해결의 가치와 상대적 우선 순위를 이해하는 데 도움이 됩니다. 기술 부채를 비즈니스 영향에 연결하는 작업을 일관되게 수행하면 이해당사자가 수행할 작업을 더 잘 이해하는 데 도움이 됩니다. 또한 기술 부채를 식별하고 사용자에게 도움이 되는 방식으로 해결할 수 있습니다.

아래의 모형 및 비모형 목록은 Salesforce 조직의 적절한(그리고 부족한) 기술 부채 관리를 보여줍니다.

기술적 부채를 해결하는 데 도움이 되는 Salesforce 도구에 대해 자세히 알아보려면 의도적 관련 도구를 참조하십시오.

다음 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다.

✨ Pattern & Anti-Pattern Explorer에서 유지 관리 기능을 위한 더 많은 패턴을 알아보십시오.

읽기의 핵심은 일관성을 창출하는 것입니다. 이를 통해 사람들이 어떻게 작동하는지 쉽게 이해할 수 있습니다. 읽을 수 있는 시스템을 구축하면 배달 및 서비스 점검 팀이 조율되며 시스템에 익숙하지 않은 사람들은 부품이 함께 어울리는 방식을 빠르게 이해할 수 있습니다. 즉, 팀은 기관 또는 과거 Knowledge 있는 개인에 의존하지 않아 공급업체 또는 새 팀 구성원을 효율적으로 온보딩할 수 있습니다. 이는 시스템의 구성과 코드를 쉽게 읽고 이해할 수 있으므로 팀의 숙련된 개인이 선택한 품질 및 제약에 집중할 수 있음을 의미합니다. 가독성을 통해 거버넌스 및 품질 보증 프로세스의 속도를 높이고 팀이 중복 사용자 정의를 만들 때를 더 잘 식별할 수 있습니다. 또한 재사용 가능하고 테스트 가능한 방식으로 동작하는 시스템의 가능성을 높일 수 있습니다.

효과적인 설계 표준 및 문서를 통해 가독성을 향상할 수 있습니다.

설계 표준은 개발 초기 단계에서도 모든 맞춤 설정을 일관되게 유지하기 위한 지침을 제공합니다. 설계 표준은 가드 레일처럼 작동하므로 시스템에서 작업하는 모든 배달 팀 및 서비스 점검 팀이 사용자 정의 접근 및 구현 방법에 부합합니다. 설계 표준을 정의하면 배달 및 유지 보수 팀의 생산성을 높이고, 코드 및 아키텍처 검토를 쉽게 수행하고, 더 나은 문서 작성을 위한 기반을 제공할 수 있습니다.

설계 표준이 없으면 팀이 사일로에서 작업할 가능성이 높습니다. 설계 표준이 제공하는 일관성이 없으면 기업은 다음과 같은 어려움을 겪게 됩니다.

• 공급업체 및 개발 팀은 솔루션 간에 특정 패턴 및 접근 방식을 사용하여 잠재적으로 안티 패턴을 도입하고 재사용 가능성을 줄일 수 있습니다(관심 분리 참조).
• 프로덕션 문제를 해결할 시간을 늘리고 지원 팀이 새 팀 구성원을 온보딩하고 서로 다른 패턴 및 접근 방식을 이해할 수 있도록 지원합니다.
• 부적절한 팀 간 공동 작업, 팀 간의 작업 중복, 충돌 해결에 소요된 시간, 통합 테스트 중 발견된 버그
• 불만족도 증가하고 매출률이 증가했습니다.

설계 표준의 주요 혜택은 이해당사자가 표준을 만드는 데 필요한 대화 및 결정을 통해 얻을 수 있습니다. 특히 프로세스를 통해 비즈니스 및 기술 리드가 비즈니스에 최적의 디자인을 조율할 수 있습니다.

설계 기준에 다음을 포함하십시오.

• Salesforce 메타데이터의 명명 규칙 시스템의 모든 사용자 정의 이름을 지정하는 방법에 대한 일련의 규칙을 정의합니다. 우수한 명명 규칙은 개체, 필드, 코드, 플로 및 시스템의 기타 요소 이름에 일관성을 적용하는 것뿐만 아니라 또한 좋은 명명 규칙을 통해 개발 팀이 구축 중인 내용의 목적 및 기능에 대한 정보를 전달하는 이름을 사용할 수 있습니다. 따라서 다른 이해당사자는 이름을 보면 특정 사용자 정의를 더 잘 이해할 수 있습니다.
• 승인된 디자인 패턴 및 사용 사례 Pattern & Anti-Pattern Explorer 라이브러리를 구축하고 각 패턴을 사용할 시기(및 사용하지 않을 시기)에 대한 주요 정보를 제공합니다. 라이브러리에 필요한 Apex 트리거 패턴 또는 시스템에서 원하는 구성 가능성을 기반으로 하는 플로 오케스트레이션 패턴이 포함될 수 있습니다.
• 개발 환경 및 도구 지침 개발 팀이 작업에 사용할 도구의 명확한 목록을 유지합니다. 여기에는 코드를 작성하는 모든 사람의 승인된 도구 체인 및 언어 또는 하위 코드 개발에 승인되었거나 승인되지 않은 선언적 기능이 포함될 수 있습니다. 표준에는 사용자 정의 및 문서화용 소스 제어 시스템 목록, 필수 체크인/체크아웃 단계가 포함될 수 있습니다. 다양한 유형의 개발 작업에 사용할 환경 목록도 포함할 수 있습니다.

해당 표준을 정의하는 것과 함께 해당 표준을 유지 관리하고 저장할 방법과 위치를 결정해야 합니다. 회사 전체의 팀이 설계 표준을 찾을 수 없거나 존재를 인식하지 못할 경우에는 효과가 없습니다. 이상적으로 설계 표준은 문서와 동일한 시스템 내에 적용됩니다(자세한 내용은 다음 섹션을 참조하십시오).

아래의 모형 및 비모형 목록은 Salesforce 조직의 올바르고 나쁜 디자인 표준을 보여줍니다. 이를 사용하여 설계 표준을 확인하거나 개선할 수 있습니다.

설계 표준을 정의하는 데 도움이 되는 Salesforce 도구에 대해 자세히 알아보려면 도구의 의도적 관련을 참조하십시오.

문서에서 시스템의 내용, 방법 및 이유를 설명합니다. 의미 있고 일관된 문서가 없으면 팀이 시스템을 그대로 이해하고 잠재적으로 기능 및 사용자 정의를 잘못 이해하는 데 많은 시간을 낭비합니다.

적절한 문서를 작성하는 데 시간이 걸립니다. 대부분의 팀은 문서가 대규모 프로젝트에 중요하다는 점에 동의하지만 구성 업데이트 또는 자동화에 대한 사소한 조정과 같은 빠른 변경 사항을 수행할 때 건너뛰기 어려운 단계일 수 있습니다. 시스템에 대한 변경 사항을 문서화하지 않는 것은 항상 반 패턴입니다. 문서를 건너뛰면 미리 약간의 시간을 절약할 수 있지만, 문서화되지 않은 조직의 문제를 해결하는 데 필요한 시간은 이러한 시간 절약을 취소하는 것 이상입니다. 항상 계획하는 업데이트에 필요한 노력 수준에 관계없이 모든 예상에 문서를 작성할 충분한 시간을 포함하십시오.

명확한 문서가 없으면 다음을 포함하여 다양한 문제를 야기할 수 있습니다.

• 기존 구현 재작업에 사용된 개발 주기
• 이전 결정에 대해 재개하거나 혼동하는 반복 토론
• 신규 팀 구성원 또는 공급업체에 대한 긴 온보딩
• 조직 또는 과거 Knowledge 있는 개인에 대한 과도한 의존성
• 중복 아키텍처 - 비즈니스 전반에서 동일하거나 유사한 성능을 지원합니다.
• 주요 이해당사자에게 솔루션의 목적 및 가치를 전달하는 어려움

Salesforce 솔루션의 경우 다음에 대한 문서를 유지합니다.

• 솔루션 개요. 다이어그램을 사용하면 귀하와 귀하의 이해당사자가 다양한 수준의 세부 사항으로 솔루션을 시각화할 수 있습니다. Salesforce 다이어그램 프레임워크를 사용하면 솔루션의 비즈니스 기능과 기술 구현 세부 사항을 보여주는 다이어그램을 만들 수 있습니다.
• 결정 기록 모든 팀 구성원이 향후 참조를 위해 액세스할 수 있는 중앙 위치에 고려된 옵션, 협상, 최종 결정, 추론 레코드를 유지합니다.
• 코드 코드 형식 자체는 문서의 핵심 요소이며, 이는 귀하의 설계 기준에 부합할 수 있습니다. 또한 키 정보 로그를 가지고 코드 조각의 모든 수정 사항으로 업데이트할 수 있습니다. 모든 클래스, 트리거 및 구성 요소의 경우 다음을 문서화합니다.
  • 코드를 작성한 사람
  • 코드가 작성된 시점
  • 코드가 수행할 작업
  • 주요 종속성
  • 모든 변경 사항
• 선언적 사용자 정의. 조직의 메타데이터에 대해 수행할 수 있는 모든 사용자 정의에 대해 Salesforce는 팀에 메타데이터의 목적과 의도에 대한 유용한 정보를 제공하는 내장된 속성을 제공합니다. 설계 표준의 일부로 팀이 이러한 내장형 기능을 사용하는 방법 및 선언적 사용자 정의의 이름을 지정하는 방법을 포함합니다. 또한 코드에 사용하는 정보와 동일한 키 정보 로그를 유지합니다.

현재 및 미래의 모든 팀원이 동일한 방식으로 문서를 해석할 수 있도록 문서화 표준을 개발합니다. (설계 표준이 도움이 될 수 있습니다.) 또한 사용자가 문서를 검색하여 관련 섹션 또는 용어를 찾을 수 있는 방법을 고려해야 합니다. 시스템이 구식화되고 복잡해질수록 문서도 성장합니다. 문서의 정보의 유용성은 사용자가 관련 항목을 검색하고 찾을 수 있는 빈도, 속도 및 용이성과 직접적으로 관련이 있습니다.

아래의 모형 및 비모형 목록은 Salesforce 조직에 적합한(또는 나쁜) 문서를 보여줍니다. 이를 사용하여 문서화 전략을 확인하거나 개선할 수 있습니다.

문서용 Salesforce 도구에 대한 자세한 내용은 의도에 대한 도구를 참조하십시오.

다음 표는 조직에서 조회하거나 구축할 패턴을 선택하고 방지하거나 조치를 위한 안티 패턴을 보여줍니다.

✨ Pattern & Anti-Pattern Explorer에서 더 많은 패턴을 검색하여 읽을 수 있습니다.

Salesforce Well-Architected의 관련성을 유지할 수 있도록 도와주십시오. 이 콘텐츠에 대한 사용자 의견을 제공하려면 설문 조사을 작성하고 다음에 원하는 내용을 알려주십시오.