짧은 역사
수년에 걸쳐, 정보를 제시하는 데 도움이 되는 데이터를 표시하는 방식은 보고, 비즈니스 인텔리전스(BI), 데이터 시각화 등 여러 가지 이름을 가지고 있습니다. 2001년부터 BI 플랫폼 소프트웨어 회사에서 일하고 자동화된 보고 도구를 개발하면서 얻은 이전 경험을 바탕으로 데이터 표시를 XNUMX가지 범주로 분류했습니다.
1. 표 형식 보고 – 행 및 열 데이터 추출, 스프레드 시트, 또는 종이 또는 PDF에 페이지가 매겨진 데이터. 데이터는 데이터베이스, 뷰에서 직접 제공되거나 복사, 붙여넣기 및 조작되어 출력 표시 형식으로 제공됩니다.
2. 픽셀 단위의 완벽한 보고 – 재무제표, 송장, 계산서 또는 일반 정보 진술서와 같은 형식화된 보고서는 정적이고 체계적인 방식으로 정보를 전달하기 위해 표 형식 보고서, 차트 및 그래프의 요소를 포함할 수 있습니다.
3. 가이드 분석 – 가이드 분석은 데이터 모델과 대화형 사용자 인터페이스를 구축하는 BI 분석가가 만든 목적에 맞게 구축된 대시보드입니다. 사용자는 차트와 그래프(시각화라고 함), 테이블 및 기타 개체를 통해 데이터를 소비하며, 사용자 지정 레이아웃에 맞습니다.
4. 셀프 서비스 분석 – 셀프 서비스 분석은 가이드 분석 개발 프로세스를 최종 사용자에게 민주화하는 것을 의미합니다. 이러한 도구와 플랫폼을 사용하면 최종 사용자는 여러 소스의 데이터를 추가하고 지능형 데이터 준비 및 지원 차트 생성 기능을 사용하여 사용자 인터페이스에서 시각화를 생성하여 대시보드를 처음부터 만들 수 있습니다.
5. 내장형 분석 – 내장된 분석 기능을 통해 프런트엔드 개발자는 HTML 5와 JavaScript를 사용하여 코드를 통해 강력하고 대화형 시각화를 생성하고 이를 웹 페이지와 애플리케이션에 직접 배치할 수 있습니다.
6. 고급 분석 – 분석의 미래는 그 어느 때보다 밝습니다. 전 세계의 데이터 양이 계속 증가함에 따라 중요한 정보와 통찰력을 얻는 데 더 많은 도움이 필요합니다. 인공 지능, 머신 러닝, 인지 분석, 봇, 대화형 UI 등은 누구나 데이터의 힘을 활용하여 삶을 개선하는 것을 더 쉽게 만드는 기술입니다.
우리가 디스플레이 기술에 대해 바라는 최소한의 것은 그것이 해를 끼치지 않는다는 것입니다. – 에드워드 터프티
도전
데이터 표시(제가 BI라고 부르는 것)가 계속 진화하고 변화함에 따라 문제가 남습니다. 도구와 플랫폼에 대한 요구 사항이 제공하는 기능보다 큽니다. BI 소비자는 이러한 도구에서 "무슨 일이 일어났는가"와 "만약에" 분석 이상을 원합니다. 그들은 과거를 고려하고 미래에 즉각적인 영향을 미칠 수 있는 전체 수명 주기 애플리케이션을 원합니다. 이는 통찰력에서 행동으로의 진정한 약속이지만, 시각적이든 아니든 단일 인터페이스에서 제공됩니다. 이 요구 사항을 충족하기 위해 BI 개발자는 코딩 방법을 배워야 합니다.
BI에서 작업하는 동안 저는 다음을 사용하여 일반 용도 앱을 구축하려는 많은 분석가와 이야기를 나누었습니다. 만 BI 플랫폼 API를 사용했는데, 아무런 의미가 없었습니다.
BI 전용 API를 배우는 것은 어렵습니다.
일반적인 코딩을 배워야 한다는 것과 합치면 궁극적으로 투자와 노력은 반환되는 가치만큼 가치가 없습니다. 그것이 바로 이유입니다. 더 스마트하고 BI 개발자가 BI 및 시각화를 넘어서는 기능을 갖춘 완전한 앱을 제공하는 더 나은 방법입니다. BI API를 사용하여 코드를 작성하거나 BI 도구가 수행하지 않는 작업(예: BI 데이터 세트에 다시 쓰기)을 수행하는 데 필요한 도구를 통합하는 것보다 더 쉽고 강력합니다. 아이러니한 점은 애플리케이션 개발자가 반대 방향으로 같은 작업을 수행하려고 한다는 것입니다.
가입 한 이후 Mendix, 저는 고객과 일주일에 여러 번 로우코드를 사용하여 보고 또는 BI와 유사한 애플리케이션을 개발하는 것에 대해 대화를 나누었습니다. 최종 사용자는 위에서 설명한 범주에서 사용 가능한 여러 기능을 수행할 수 있습니다. 개발 목표는 BI 개발자와 동일합니다. 정보를 의미 있게 전달하는 기능을 제공하는 완전한 앱을 빌드합니다. 데이터의 업데이트 또는 변경을 지원하는 동안 정보를 사용하여 무언가를 수행합니다. 최종 사용자에게 분석적 유연성을 제공합니다.
로우코드 애플리케이션에서 네이티브 차트를 사용하기 위한 고려 사항
보고, BI, 분석 등과 관련하여 애플리케이션 개발자를 위한 기본 전제는 바퀴를 새로 발명하지 않는 것입니다. 기본 사항에 충실하고 최종 사용자가 경험의 다음 단계로 이동하는 데 도움이 되는 데이터를 표시하세요. 차트 및 보고 기능(목록 보기 및 데이터 그리드를 통해)은 사용자가 애플리케이션으로 달성하려는 작업과 관련된 의미 있는 데이터를 표시하는 데 적합합니다. 사용자가 원하는 작업을 수행할 수 있도록 런타임에 모든 데이터를 제공하려는 것은 적합하지 않습니다. 무엇을 할지 결정할 때 다음 세 가지 시작 질문을 고려하세요.
1. 사용자의 어떤 문제를 해결하려고 합니까?
사용 사례와 정보를 사용자에게 전달하는 방법에 대해 생각해 보세요. 고객이 앱 홈페이지나 사용자 경험 전반에 걸쳐 핵심 성과 지표(KPI) 세트를 원하면 플랫폼에 포함된 차트와 그래프를 사용하여 Mendix 아름답고 유용한 비주얼을 빠르고 쉽게 만들 수 있기 때문에 합리적입니다. 고객이 애플리케이션 런타임 중에 모든 종류의 셀프 서비스 기능을 요청하는 경우 요구 사항을 충족하는 통합 플랫폼을 고려할 때입니다.
2. 귀하의 애플리케이션에는 얼마나 많은 데이터가 있습니까?
애플리케이션에 100행의 데이터가 있나요, 아니면 100억 행의 데이터가 있나요? 후자라면 모든 데이터를 자세히 표시해도 애플리케이션에서 렌더링하는 데 걸리는 시간보다 가치가 훨씬 떨어집니다. 상당한 양의 데이터가 포함된 대시보드와 차트가 있는 앱을 디자인할 때는 필터와 조건부 논리를 사용하여 KPI, 차트, 목록 보기에 대한 집계를 규범적이고 제한적으로 적용하세요. 사용자는 표시되는 내용의 가치를 높이는 동시에 통찰력을 얻는 데 걸리는 시간을 단축해 주셔서 감사할 것입니다.
3. 어느 수준의 상호작용 분석이 필요합니까?
가이드 및 셀프 서비스 분석의 상호 작용적 특성으로 인해 최종 사용자는 차트와 그래프를 클릭하고 해당 작업으로 데이터 세트에 필터를 적용하는 데 익숙해졌습니다. 그러나 이러한 도구를 사용하는 방법은 변화하고 있으며 많은 경우 클릭이나 상호 작용에 대한 원하는 응답은 작업을 수행하는 것입니다. 이러한 작업에는 드릴 다운(한 데이터 계층에서 다른 계층으로 이동), 더 자세한 내용을 표시하거나 입력을 요청하기 위해 애플리케이션에서 새 화면을 열거나 알림이나 경고를 트리거하는 워크플로 또는 사람에게 특정 레코드를 할당하는 것이 포함될 수 있습니다. 이러한 모든 활동에는 다음 단계로 넘어가기 위해 시각적 요소와 결합된 논리가 필요하며, 로우코드 플랫폼은 이러한 작업의 구성을 용이하게 하는 직관적인 방법을 제공합니다.
반대로, 로우코드 개발자는 분석 플랫폼에서 수행하기 쉬운 차트에 표시된 데이터를 연결하라는 요구 사항을 받을 수 있습니다. 차트 그룹을 연결하여 상호 작용에 일치하게 응답하는 것은 가능하지만 Mendix, 솔루션의 원하는 이점, 유지 관리 및 규모에 대한 노력을 평가하는 것이 중요합니다. 많은 경우, 이 수준의 복잡성을 처리하도록 의도적으로 구축된 플랫폼을 통합하는 것이 더 합리적입니다.
로우코드 애플리케이션에 내장된 BI 플랫폼 사용을 위한 고려 사항
보고 및 BI 플랫폼을 로우코드 애플리케이션에 통합하는 데에는 여러 가지 이유가 있습니다. 우선, 귀사는 BI에 상당한 투자를 했으며 이를 활용해야 합니다. 애플리케이션의 트랜잭션 기반 시스템은 BI 플랫폼이 자체 데이터 엔진을 사용하여 처리하는 분석 요구 사항을 처리하도록 설계되지 않았으므로 사용자가 데이터를 슬라이스하고 다이싱해야 할 때 BI에 대한 확실한 이점이 있습니다. 또한 BI 플랫폼과 로우코드 애플리케이션 플랫폼은 모두 해당 스택의 다양한 계층에서 통신을 용이하게 하는 API를 노출했습니다. 이를 통해 BI 측에서 후크를 만들고 로우코드 측에서 재사용 가능한 구성 요소를 만들어 두 기술의 힘을 결합하기가 더 쉬워집니다. 비즈니스 인텔리전스와 분석을 애플리케이션에 임베드하려고 할 때 고려해야 할 몇 가지 질문은 다음과 같습니다.
1. 데이터가 여러 소스에서 나오나요?
로우코드 플랫폼과 BI 플랫폼은 모두 강력한 ETL, 데이터 처리 및 변환 기능을 갖추고 있습니다. 고려해야 할 몇 가지 사항은 다음과 같습니다.
- 한 플랫폼에서 데이터 블렌딩을 수행하고 다른 플랫폼에서 필요로 하는 것을 제공할 수 있다면, 다른 시스템에서 이를 재생성하는 데 드는 노력 수준은 그만한 가치가 없을 수 있습니다.
- 데이터 블렌딩에 사용할 플랫폼을 결정해야 하는 경우, 데이터를 가장 잘 이해하는 사람들이 도구를 가장 잘 이해할 수 있는 플랫폼을 선택하세요. 요즘 좋은 점은 로우코드와 BI 플랫폼 모두 서로 통신할 수 있는 API가 있다는 것입니다.
- 사용 사례를 지원하기 위해 두 플랫폼 모두에서 데이터를 처리하지 마십시오. 그렇게 하면 데이터 품질 위험이 발생하고 계산에서 잠재적 오류를 추적하거나 종단 간 데이터 계통을 추적하기가 더 어려워집니다.
2. 최종 사용자는 그리드에서 보려는 데이터 필드를 선택하거나, 기본 데이터를 사용하여 런타임 중에 출력을 생성하거나 시각화를 생성하기 위해 셀프 서비스 기능이 필요합니까?
내가 이전에 한 말이 충분히 명확하지 않다면, 하지 다음 훌륭한 도구를 만드는 것이 목표가 아니라면 어떤 애플리케이션 개발 플랫폼으로든 셀프 서비스 보고 및 분석 도구를 빌드하세요. 제가 설명한 범주 중 하나 이상을 충족할 수 있는 옵션이 시장에 많이 있으며, 많은 솔루션에 화이트 라벨을 적용하여 고객이 자신의 솔루션이라고 생각하도록 하는 옵션이 있습니다. 시간과 비용을 절약하고 개발자의 번아웃을 방지하세요.
3. BI 플랫폼에서 파생된 메트릭은 이벤트를 트리거하고, 애플리케이션 로직을 호출하고, 기본 데이터 소스에 쓰고, BI 시각화를 새로 고쳐야 합니까?
오늘날 BI 세계에서 동일한 플랫폼 내에서 분석을 넘어 실행으로 이동하려면 솔루션으로 가는 길을 코딩해야 합니다. 이는 숙련된 소프트웨어 개발자에게는 시간이 많이 걸릴 수 있으며 문제를 해결하려는 BI 분석가에게는 시작조차 할 수 없는 일입니다. 로우코드 애플리케이션 개발 플랫폼을 사용하면 누구나 시각적 논리(Visio를 생각해보세요. 하지만 흐름은 실행으로 해석됨)를 사용하여 사용자 인터페이스의 상호 작용을 구동하고 백엔드 활동을 처리하는 강력한 애플리케이션을 쉽게 만들 수 있습니다. BI 플랫폼에 연결된 임베디드 분석과 로우코드를 결합하면 두 가지의 장점을 모두 얻을 수 있습니다. 분석 플랫폼이 제공하는 연결성과 상호 작용을 활용하고 로우코드 플랫폼을 사용하여 애플리케이션 수명 주기의 데이터 처리 및 운영 논리를 처리할 수 있습니다.
이 두 기술의 융합에는 의심의 여지가 없습니다. 애플리케이션에 대한 수요가 증가함에 따라 생성된 데이터를 해석하고 제시해야 하는 수요도 더욱 빠르게 증가합니다. 로우코드 플랫폼은 여러 보고 및 차트 사용 사례를 처리할 수 있는 역량을 갖추고 있습니다. 통찰력에서 조치, 검토에 걸리는 시간, 그리고 다시 돌아오는 데 걸리는 시간에 대한 요구 사항이 점점 더 짧아짐에 따라 분석과 로우코드를 활용하는 보다 정교한 솔루션을 고려하여 두 세계의 장점을 모두 제공해야 합니다.