로우코드 원칙 #8, 거버넌스 및 제어: 좋은 가드레일은 좋은 애플리케이션을 만듭니다.

메인 컨텐츠로 가기

로우코드 원칙 #8, 거버넌스 및 제어: 좋은 가드레일은 좋은 애플리케이션을 만듭니다.

거버넌스 및 제어

“당신은 할거야 누구 do ? "

이는 많은 전문 개발자와 IT 리더가 개발 프로세스를 민주화한다는 개념에 대해 보이는 반응입니다. 더 스마트하고 그리고 비전문적인 '시민' 개발자(비즈니스 분석가, 엔지니어, 도메인 전문가 등)가 애플리케이션을 만들도록 합니다. 그들의 다음 반응은 종종 다음과 같습니다. 코드를 볼 수 없다면 어떻게 확신할 수 있습니까? 애플리케이션은 기업의 기존 표준, 모범 사례 및 아키텍처 고려 사항을 준수합니다.?

IT가 기술 환경에 대해 취하는 보호적 태도는 컴퓨터가 처음으로 "일반" 사용자의 손끝에 도달했을 때 생겨났습니다. 그들의 우려는 당시에 정당했고, 오늘날에도 여전히 상당 부분 그렇습니다. 어떤 사람들은 기술이 끊임없이 숨가쁘게 진화함에 따라 아키텍처, 도구 및 인간 구성 요소를 통제해야 할 필요성이 그 어느 때보다 크다고 주장할 것입니다. 따라서 Low-Code Manifesto의 원칙 #8이 다음과 같다는 것은 놀라운 일이 아닙니다.

거버넌스 및 통제:
강력한 거버넌스, 통제 프로세스 및 프로토콜이 필수적입니다.

여기서 정의는 중요합니다. 최소한 세 가지 다른 맛이 있기 때문입니다. 로우코드 거버넌스. 하나는 사람들이 물건을 깨지 않도록 내부 규칙(모범 사례, 표준, 문화적 규범)을 준수하는 것입니다. 이것이 여기서 우리의 주요 주제입니다. 또 다른 하나는 외부 규칙과 규정(예: 재무 애플리케이션에 대한 특정 규제 요구 사항)을 준수하는 것입니다. 세 번째는 CIO 수준의 정의로, IT 전략이 비즈니스 전략을 지원하고 정량화 가능한 결과를 제공하도록 하는 것을 의미합니다. 여기서 우리의 초점은 첫 번째 정의이지만, 로우코드가 두 번째와 세 번째 정의를 지원하는 데도 훌륭한 역할을 한다는 것도 분명해질 것입니다.

반면 제어는 단순히 제어를 의미하는데, IT가 전체 기술 생태계에서 일어나는 일, 즉 누가 액세스할 수 있는지, 어디에서 액세스할 수 있는지, 그곳에서 무엇을 할 수 있는지, 어떤 도구를 사용할 수 있는지를 제어한다는 의미입니다. IT는 전체 기술 스택의 무결성에 대한 책임이 있으므로 책임을 져야 합니다.

거버넌스와 컨트롤의 경계는 약간 모호할 수 있습니다. 둘은 서로 밀접하게 관련되어 있습니다. 그래서 우리는 둘을 하나의 로우코드 원칙으로 함께 고려합니다.

자유가 많을수록 더 많은 거버넌스와 통제가 필요합니다.

로우코드의 가장 큰 이점 중 하나는 개발에 대한 교육을 받지 않은 비기술적인 유형을 포함하여 애플리케이션 생성에 참여할 훨씬 더 광범위한 인재 풀을 초대한다는 것입니다. 비즈니스 사용자는 앱을 빌드하거나 기술 팀을 위해 아이디어를 계획할 수 있습니다. 초보 개발자는 상상할 수 있는 모든 것을 빌드하여 기술을 연마할 수 있습니다. 물론 노련한 개발자는 모든 흥미로운 신기술을 사용하여 혁신을 한계까지 끌어올릴 수 있습니다. 로우코드는 모든 기술 수준의 제작자에게 모든 종류의 애플리케이션을 만들 수 있는 도구를 제공합니다. 창작의 자유를 제공합니다.

하지만 그들은 문제를 일으킬 자유를 가질 수 없습니다. 전통적인 개발 플랫폼보다 로우코드에 대한 강력한 통제를 갖추는 것이 더욱 중요합니다. 경험이 부족하거나 지나치게 야심 찬 애플리케이션 제작자가 실수로 중요한 엔터프라이즈 시스템에 혼란을 일으키지 않도록 하기 위해서입니다.

혁신 문화가 있다면 강력한 보호 장치가 있어야 합니다. 빠르게 움직일 때, 팀이 프로세스에 다양한 기술 세트를 가져올 때, 팀에 탁월함을 위한 자율성이 주어질 때 - 이때 통제가 가장 중요합니다.

하지만 모든 것을 통제할 수는 없고, 통제하고 싶어서도 안 됩니다. 창의성의 손을 묶는 것은 목적을 무너뜨립니다. 그것은 섬세한 균형 잡기 행위, 자유 대 통제, 혁신 대 위험 관리입니다. 플랫폼 자체가 적절한 균형을 촉진하고 시행해야 합니다.

예방, 감지, 수정

위험을 통제하는 데는 세 가지 주요 측면이 있습니다. 명백히 말해서 예방은 문제가 처음부터 시작되지 않도록 하는 데 중점을 둡니다. 탐지는 잠재적 또는 실제 문제를 찾는 데 중점을 둡니다. 그리고 수정은 다시 명백하게도 망가진 것을 고치는 데 중점을 둡니다.

전형적인 사고방식은 문제가 표면화된 후에 문제를 해결하는 것보다 문제를 예방하는 것이 낫다는 것입니다. 이 접근 방식의 단점은 심각한데, 너무 많은 제어가 내장되면 창의성이 억제되고 전체 프로세스가 느려진다는 것입니다. 둘 다 로우코드 접근 방식에는 저주입니다. 예방의 실제 비용이나 혁신이 방해를 받을 때의 기회 비용은 수리를 위한 시간과 비용보다 높을 수 있습니다.

로우코드 방식은 탐지 및 수정에 더 중점을 두고, 큰 피해를 입힐 수 있는 것에만 예방을 저장합니다. 아이디어는 실수나 실수의 영향을 최소화(또는 "폭발 반경 제한")하는 것입니다. 로우코드의 마이크로서비스 및 클라우드 기반 아키텍처 실수가 발생했을 때 본질적으로 낙진을 고립시킵니다. 또한 문제를 식별하고 수리하는 것을 더 쉽고 훨씬 빠르게 만듭니다.

그럼에도 불구하고, 로우코드는 상당한 예방적 안전 메커니즘을 내장하고 있습니다. 특히, 사용자가 어떤 도구에 접근할 수 있는지 제어하고 물건을 부수지 못하게 하는 빌딩 블록을 제공합니다. [속담에 "어린아이에게 전동 공구를 주지 마세요"라고 합니다.]

거버넌스 및 제어, 로우코드 스타일

적절하게 설계된 로우코드는 모든 시간적으로 검증된 거버넌스 및 제어 도구와 기존 개발의 관습을 통합하고 이를 업데이트하며 최신 기술, 특히 인공 지능 및 자동화의 힘으로 이를 보강합니다. 일반적으로 로우코드는 세 가지 중요한 방식으로 사용자가 옳은 일을 하기 쉽게 하고 틀린 일을 하기 어렵게 만들기 위해 설계되었습니다.

우선, 로우코드는 애플리케이션을 구성하기 위한 많은 기술적 선택을 하므로 개발자는 그렇게 할 필요가 없습니다. 일반적이고 일상적인 작업은 자동화되므로 결정해야 할 사항이 적고 따라서 오류가 적습니다.

그런 다음, 전체 프로세스 동안 인공 지능은 개발자에게 가장 좋은 다음 단계를 안내하고 작업을 지속적으로 확인합니다.

마지막으로, 로우코드를 사용하면 전체 애플리케이션 라이프사이클에 자동화된 품질 관리가 주입됩니다. 자동화되다 요구 품질과 규정 준수를 보장하기 위해 자동화해야 함: 모든 항목의 일관성 검사, 리팩토링, ID 제어, 지속적인 테스트 및 모니터링, 백업 모두.

가시성, 통찰력, 제어

효과적인 거버넌스와 통제를 행사하려면 가시성이 필요합니다. 사람들이 무엇을 하는지 볼 수 없다면 그들이 옳은 일을 하고 있는지 확인할 수 없습니다. 로우코드의 풍부한 메타데이터를 사용하면 측정할 수 없는 것이 사실상 없습니다. 모든 것이 추적 가능하고 감사 가능합니다. 모든 것을 확인할 수 있습니다. 모든 것을 모니터링할 수 있습니다. 얻은 통찰력은 IT 리더가 통제를 유지하는 데 도움이 될 뿐만 아니라 모든 사람이 비즈니스 영향을 달성하기 위해 올바른 방향으로 나아가고 있는지 확인하는 데 도움이 될 수 있습니다. 이는 CIO에게 매우 소중한 거버넌스의 세 번째 정의를 충족합니다.

로우코드에 대한 새로운 정보 때때로 사용하기 쉽고 빠르기 때문에 거버넌스와 제어가 가벼울 것이라는 잘못된 가정을 합니다. 사실, 그 반대입니다. 기존 플랫폼의 모든 거버넌스와 제어가 있고 그 이상도 있습니다(이는 또한 빠르고 사용하기 쉽게 만들어 순환적 사고를 완성하는 데 기여합니다).

인기 있는 표현을 바꿔 말하면: 빨리 움직이고 물건을 부수지 마세요. 로우코드가 당신을 지지합니다.

언어를 선택하세요