워크 플로우 도구의 가치는 무엇입니까? [닫은]

저는 Workflow 개발에 익숙하지 않으며 실제로 "큰 그림"을 얻는다고 생각하지 않습니다. 또는 다르게 말하면,이 도구는 현재 내 머리에서 "클릭"되지 않습니다.

따라서 회사는 프로세스를 설명하기 위해 비즈니스 도면을 만드는 것을 좋아하는 것으로 보이며 어느 시점에서 누군가는 프로그램과 같은 상태 머신을 사용하여 실제로 다이어그램과 같은 상자와 상자에서 프로세스를 제어 할 수 있다고 결정했습니다. 10 년 후,이 도구는 엄청나고 복잡합니다. (저희 회사는 현재 WebSphere를 가지고 놀았습니다. 저는 일부 교육 과정, 괴물, 심지어 Activiti와 같은 워크 플로 도구의 소위 "미니멀리스트"버전에 참석했습니다. WebSphere affict라는 짐승만큼 복잡하지는 않지만 거대하고 복잡합니다).

이런 식으로 그렇게하면 큰 장점은 무엇입니까? 나는 간단한 선과 상자 다이어그램이 유용하다는 것을 이해할 수 있지만, 내가 알 수있는 한,이 것은 시각적 프로그래밍 언어이며 조건부와 루프로 완성됩니다. 여기의 프로그래머들은 라인과 박스 레이어에서 상당한 양의 작업을 수행하는 것으로 보이며, 이것은 정말 엉뚱하고 기본적인 비주얼 프로그래밍 언어처럼 보입니다.

그렇게 멀리 가려면 왜 일종의 스크립팅 언어를 사용하지 않습니까? 사람들이 이것에 목욕물을 가지고 아기를 버리셨습니까? 선과 상자가 터무니없는 수준으로 취 해졌습니까? 아니면이 모든 것의 가치를 이해하지 못하고 있습니까?

이 기술을 사용해 본 사람들이이 방어를위한 주장을보고 그 이유를 이해하고 싶습니다. 나는 그 가치를 알지 못하지만, 나는 이것에 익숙하지 않으며 아직 얻지 못할 수도 있음을 알고 있습니다.

개발자의 관점에서 볼 때 이러한 "시각적"환경은 실제로 작업하기 어렵다고 말할 수 있습니다. 내가 사용하는 SharePoint 2010 워크 플로는 자동화 된 테스트, 코드 재사용, 읽을 수없는 소프트웨어 등 우수한 엔터프라이즈 소프트웨어를 만드는 데 필요한 모든 모범 사례를 제공합니다. 기본 제공 템플릿보다 복잡한 것은 유지 관리가 어려울 수 있습니다. , 당신이 경험하는 것처럼.

그러나 비즈니스 관점에서 볼 때 워크 플로는 최소한 이론 상으로는 큰 이점이 있습니다. 이 백서 에서 인용 한 것처럼, 자동화 된 워크 플로우의 효율성, 책임, 제어 및 사용 편의성은 생산성을 크게 향상시킵니다. 이 자동화없이 간단한 승인 또는 온 보딩 프로세스가 얼마나 비효율적 일지 상상해보십시오. 또한 워크 플로 정의 작업은 비즈니스 프로세스를 제어하려는 조직에게 가치가 있습니다.

워크 플로우 소프트웨어의 현재 상태는 비즈니스 결함이 아닙니다. 그들은 삶을 더 편하게 만들고 싶어합니다. 나는 대부분 IT 부서를 비난 할 것입니다.

1. 시스템이 실제로 얼마나 복잡하고 취약한 지에 대해 비즈니스에 대해 투명하지 않은 경우. 우리는 모든 복잡성을 숨 깁니다.
2. 직관적이고 간단한 워크 플로 솔루션으로 "가려움증을 긁지"못하게되었습니다. 이것은 아마도 SharePoint 및 SAP와 같은 대기업 패키지에 대한 불만이 많지만 사용자 정의 솔루션보다 낫습니다.

하나의 진정한 이점이 있지만 그 큰 이점 은 우려의 분리입니다 .

따라서 시스템에 프로세스 오케스트레이션 로직이 내장되지 않고 외부 구성이됩니다. 기본적으로 맵입니다. 독립적으로 변경할 수 있으며 여러 프로세스, 여러 버전의 프로세스, 여러 버전의 여러 프로세스를 동시에 실행할 수 있으며 모든 솔루션을 즉시 사용할 수 있습니다.

역사적으로 SoC의 개념은 유닉스 원칙에서 시작하여 "한 가지 일을하지만 좋은 일을한다"고 ESB, 다른 지속성 시스템, 캐싱,로드 밸런싱과 같은 전용 서버 구성 요소를 갖는 것과 같이 여러 번 적용되었습니다. , CSS를 HTML에서 나누는 것과 같은 모니터링 등

비즈니스 프로세스 및 흐름 규칙은 종종 데이터, UI "화면"또는 사용자 "계층 구조"와 직교합니다. 따라서 시스템의 다른 측면과 별도로 개발하고 변경하는 것이 완벽합니다. 이것이 BPM 이 1990 년대 초에 등장한 전제 였습니다.

그 이후로이 개념을 지원하기 위해 많은 도구와 언어가 만들어졌으며, 가장 잘 알려진 BPMN 은 프로세스에 직접 매핑되는 "순서도"를 만드는 그래픽 언어입니다. 사람들은 크고 다루기 힘들며 (어휘에 100 개가 넘는 기호가 있으며) S-BPM (5 개의 기본 기호 만 있음) 과 같은 현대적인 접근 방식을 옹호한다고 주장하지만 , 현재 업계 관행은 BPMN 또는 그 파생어, 하위 집합 또는 형제 자매를 고수하는 것입니다.

BPMN에 만족하지 않는 것 같습니다.

여기의 프로그래머들은 라인과 박스 레이어에서 상당한 양의 작업을 수행하는 것으로 보이며, 이것은 정말 엉뚱하고 기본적인 비주얼 프로그래밍 언어처럼 보입니다.

그러나 그것은 나쁘지 않다) 그 뒤에 이론이있다. 그리고 버전 2.0은 1.0 단점에서 좋은 통찰력을 얻었습니다.

그렇게 멀리 가려면 왜 일종의 스크립팅 언어를 사용하지 않습니까?

명령형 패러다임과 스크립팅 언어가 항상 최고의 대답은 아닙니다. HTML, CSS, SQL, Drools 또는 Nginx, Graddle 및 Maven, Puppet 등의 내부 언어와 같은 선언적 언어에서 볼 수 있듯이 결과 코드는 " 괜찮은 언어로 작성된 버전보다 훨씬 작고 깨끗할 수 있습니다 . Java 또는 C ++ " 와 같은

다른 점은 다음과 같습니다.

내가 알 수있는 한,이 시점에서 시각적 프로그래밍 언어는 조건부와 루프로 완성됩니다.

이벤트 및 트리거 를 살펴 보셨습니까 ? BPMN은 언어 이므로 사용하기 전에 배우거나 최소한 익숙해 져야합니다.

후드 아래에서 BPMN은 XML이므로 직접 편집하거나 생성 할 수 있습니다. XML은 텍스트 기반이기 때문에 버전을 제어 할 수 있습니다. 그러나 플로우 차트로 변환 할 수있는 XML을 가지고있는 것만으로도 goona가 도움이되는 것처럼 들리지 않으며, 자신 만의 파서 나 편집기를 작성하는 것은 의심 할만한 이점이있는 힘들고 값 비싼 작업입니다.

운 좋게도 시장에는 이미 그 도구를 사용하고 있습니다.

Activiti 는 초기 가격 ( 0 ), 정보 가용성 및 겸손 성으로 인해 무료이며 개발자와 비즈니스 소유자 모두에게 매우 인기가 있습니다 . 마지막 요점은 Activi가 전체 패키지 솔루션을 사용하지 않고 비즈니스 프로세스 관리에만 초점을 맞추기 때문에 매우 독창적입니다. 또한 개방형이므로 Java 및 REST를 알아야만 작동시킬 수 있습니다. 단점은 클라이언트 측, 통합 및 응용 프로그램 / 비즈니스 로직 및 전체 아키텍처가 개발자에게 맡겨져 있으므로 개발 팀이 약한 경우 실패에 대비하십시오. 무료 툴의 경우 총 소유 비용이 놀라 울 정도로 높아질 수 있습니다 .)

스펙트럼의 다른 측면에는 BPM 시스템의 왕인 가트너와 포레스터에 따라 페가 (Pega PRPC)가 있는데, 이는 나이에 비해 놀랍게도 좋아 보인다. 이 주방 싱크 형 베헤모스는 CRM, OCR 및 음성 인식 기능, 예측 분석, 비즈니스 규칙 관리 및 WYSIWYG UI 편집기도 가능합니다. 그러나 가격표는 심각하다. 그것은 막대한 비용뿐만 아니라 모든 개발이 웹 응용 프로그램 내에서 이루어지고 있습니다. 즉, IE8 인 브라우저 (데이터 테이블 편집을 위해 Excel을 사용하는 것과 같은 일부 플러그인, 추한 해킹)와 같은 브라우저를 사용해야합니다. 또한 Java, Javascript 또는 HTML / CSS 편집도 웹 브라우저를 사용하여 수행됩니다. 단위 테스트, IDE 코드 강조 표시, 리팩토링 및 좋아하는 모든 프로그래밍 장난감에 작별 인사를하십시오.

그것의 좋은면? WEEKS 내에 복잡한 시스템을 구현할 수 있습니다 [ PDF , 22 페이지 참조]. 그리고 네, 결과는 보장되지 않습니다.

IBM은 다소 최근 (엔터프라이즈 시간 속도에 accoring에) 한 롬바르디을 구입, 지금은 매우 경쟁력있는 솔루션을 제공하고있다 (그러나 다음 구입해야합니다 모든 IBM , you'know을). Appian 은 흥미로운 통찰력과 긍정적 인 피드백을 가지고있는 젊은 벤더이지만, 그들이 작성하는 방식 (비주얼 언어 외에 두 가지 추가 DSL 언어)은 저에게 호소력이 없습니다.

다른 플레이어와 솔루션이 있습니다. 그들 대부분은 끔찍합니다. 당신이 단순히 그들을 볼 때, 눈, 뇌 및 심장이 문자 그대로 피를 흘릴 것입니다. 그러므로, 당신의 용기를 믿고 개발자와 사용자가 당신을 미워하게하지 마십시오.

결산 메모 :

BPM 시스템은 프로세스와 Photoshop의 이미지와 동일합니다. 시각적 인 것을 두려워하지 마십시오. 적합하지 않은 작업을 수행하지 마십시오 (Photoshop에서 완전히 제작 된 웹 사이트는 편집 할 수 없었습니다). 간단하게 유지하고 버그를 만들지 마십시오.)

몇 년 전, 대부분의 사람들이 태어나 기 전에 소프트웨어 개발자는 데이터를 저장하기 위해 자체 코드를 작성해야했습니다. 프로그램 상태를 저장해야하는 경우 코드 기능의 일부로 간주되어 많은 소프트웨어 개발자가 데이터를 구성하고 저장하고 읽는 등의 코드를 작성하게되었습니다.

그리고 누군가 이것은 이것이 많이 일어난 일이라는 것을 깨달았습니다. 즉, 데이터를 저장, 구성, 읽기 및 검색하는 논리는 실제로 너무 자주 사용되어 자체 구성 요소 여야하는 구성 요소였습니다. 그리고 우리는 데이터베이스를 얻었습니다.

지난 10 ~ 15 년 동안 IT 부서는 비즈니스 프로세스를 구성 및 / 또는 조정하는 논리가 너무 일반적이기 때문에 자체 구성 요소 여야하므로 모든 종류의 다양한 워크 플로 도구로 이어졌습니다.

워크 플로우 도구의 3 가지 주요 이점이 있습니다.

1. 변경 및 배포에 필요한 시간 : 코드 변경과 동일한 기술적 위험없이 워크 플로의 논리를 개발하고 변경할 수 있습니다.
2. 투명성 : BPM 기반 시스템의 비즈니스 로직은 비즈니스 분석가가 즉시 사용할 수 있으며 읽을 수있는 반면, 개발자는 "코드 기반"시스템에서 비즈니스 로직을 읽을 수 있습니다.
3. 기술 구성 요소 재사용 : BPM 도구는 종종 서비스 지향 아키텍처가있는 시스템과 함께 사용됩니다. 비즈니스 구성 요소와 비즈니스 구성 요소를 분리하면 (특히 수백 또는 수천 개의 서로 다른 비즈니스 프로세스를 구현해야하는 엔터프라이즈 시스템의 경우) 비즈니스 논리 개발에 비교적 적은 시간을 소비하면서 (워크 플로 사용) 기술 구성 요소를 재사용 할 수 있습니다 수단).

그러나 워크 플로 및 BPM 도구 사용과 관련된 가장 일반적인 문제 중 하나는 개발자가 여전히 비 투명 코드로 비즈니스 로직을 "매립"하려고한다는 것입니다.

내가 보는 것은 항상 개발자가 가능한 가장 투명한 방법 대신 가능한 가장 기술적 인 방법으로 비즈니스 로직을 추가하려고하는 것입니다. 개발자는 본질적으로 워크 플로 도구보다 코드에 훨씬 더 익숙하기 때문에 이는 자연스러운 일입니다. 또한 기술적 인 방식으로 유지하는 논리가 많을수록 개발자로서 더 많이 필요합니다. 불행하게도, 개발자가 BPM 시스템의 주요 이점을 과소 평가하기 때문에 BPM 시스템에서 할 수있는 최악의 상황입니다.

마지막으로, 대부분의 BPM 도구로는 비즈니스 분석가가 워크 플로 자체를 개발할 수있을만큼 충분하지는 않습니다. 그러나 이것이 목표입니다. 이상적으로 비즈니스 분석가는 워크 플로 / 비즈니스 프로세스 다이어그램을 개발하고 개발자는 워크 플로 엔진에서 호출하는 기술 구성 요소에 대해서만 작업합니다.

아래 내용은 워크 플로 도구, 특히 Oracle BPM Suite (10.3G & 11G)를 사용한 개인적인 경험입니다. 먼저, 실행 가능한 프로세스 모델을 모델링 할 수있는 워크 플로우 도구에 중점을두고 있으며, 이러한 도구는 BPM (Business Process Management Systems)의 일부입니다. 이 특정 프로세스 모델링은 확실히 개발 중이며이를 시각적 프로그래밍 언어로 참조 할 수 있습니다.

주요 이점은 프로세스 로직을 이해하고 변경 하는 민첩성입니다.

비즈니스 프로세스 모델을 사용하면 프로세스 논리에 대한 시각적 설명과 동시에 실행 가능한 통합 구성 요소를 다룹니다. 이는 개발 과정 이후 전환, 조건부 (게이트웨이 또는 비즈니스 규칙) 및 프로세스 흐름에 대한 문서화가 적어지기 때문에 프로그래머의 온보드 및 오프 보딩 속도가 더 빠릅니다.

또한 대부분의 BPMS에서 다루는 각 응용 프로그램마다 개별적으로 개발해야하는보고 / 모니터링 기능을 첨부했습니다.

또한 대부분의 BPM 개발 환경에서 서비스 어댑터 (예 : JMS, 웹 서비스, JDBC 등)가 사전 구축 되어 단계별 대화식 통합으로 미들웨어 솔루션을보다 빠르게 개발 하여 코딩의 인적 오류를 줄일 수 있습니다.

다음 워크 플로 플랫폼은 위에서 언급 한 많은 이점을 얻습니다. 워크 플로 자동화를위한 플랫폼 기반 접근 방식

가치

가치 제안은 변화하는 비즈니스 특성에 맞게 워크 플로를 빠르고 쉽게 만들거나 변경할 수 있다는 것입니다. 이 가치 제안을 실현하는 데있어 중요한 부분은 비즈니스 프로세스 자체가 시스템의 자원 단위라는 것입니다.

자원 단위로서의 워크 플로우는 비즈니스 프로세스가 단일 '단위'로 정의됨을 의미합니다. 이것이 의미하는 바를 이해하려면 비즈니스 용으로 작성된 컴퓨터 프로그램을 고려하십시오. 확실히 비즈니스 프로세스를 구현하지만 해당 프로세스의 논리가 소스 코드를 어느 정도 퍼지게됩니다. 워크 플로우 도구를 사용하면 프로세스를 잘 포함 된 한 곳에 정의 할 수 있습니다. 하나의 단일 구성 파일에 있거나 하나의 시각적 다이어그램에서 추출되거나 워크 플로가 플러그 인, 즉석에서 스왑 또는 구성 될 수있는 단일 코드 모듈에 있음을 의미 할 수 있습니다.

가치가 실현되지 않는 이유

이러한 가치 제안은 바닐라 이외의 사례를 다루고, UI 기술과 매우 빠르게 변화하는 워크 플로 도구를 래퍼로만 사용하고 실제 논리를 코드에 넣는 등의 나쁜 관행으로 인해 어려움을 겪을 수 있습니다.

도구 자체의 열악한 디자인은 제한 요소 일 수 있습니다. 예를 들어 프로세스간에 전달 된 모든 매개 변수를 Java Map에 포함시켜야하는 도구가 있습니다 (일반적인 메소드 매개 변수 대신 실제로 맵에 넣을 수있는 값에 대한 제한 사항이 있습니다). 특히 인기있는 도구).

나는 큰 기술 에코 시스템을 가진 큰 기업으로서 IBM이 다른 것보다 더 나은 박람회라고 말하는 것이 공평하다고 생각한다. 또한 워크 플로 도구와 함께 사용되는 UI 기술과 데이터베이스 및 SOA 기술을 제어하는 ​​경우 에코 시스템을 잘 통합하고 실제로 활용할 수있는 기회를 창출 할 수 있습니다. 이 아이디어.

워크 플로 도구와 시스템의 다른 부분 사이의 인터페이스를 작성하는 노력이 전체 가치 제안을 완전히 무효화 할 수 있다는 것은 사실입니다. 더 좋은 방법이 있는지 항상 고려해 볼 가치가 있습니다.

프로그래밍은 워크 플로우

진실은 프로그래밍이 (적어도 명령형 언어로) 이미 해결되었다는 것입니다. 시스템 기술 처리와 관련된 워크 플로를 구현하는 코드가있을 수 있습니다. 파일 액세스 및 SQL 쿼리 실행 등 비즈니스 워크 플로를 구현하는 코드가있을 수 있습니다. 예를 들어 문서의 상태를 설정하고이를 검토 자에게 전달합니다.

이를 인식하고 이러한 개별적인 문제를 완전히 분리하도록 코드를 설계하는 것은 완전히 어려울 수 없지만, 그렇게하는 것만으로도 먼 길을 갈 수 있습니다.

나는 당신에게 동의합니다. 때로는 누군가가 좋은 아이디어라고 판단하고 도구가 너무 복잡하여 우리의 일을 더 어렵게 만들기 때문에이 도구를 사용하게됩니다. 나는 항상 그런 경우가 아니라고 생각합니다. 가치가 있는지 아닌지를 결정하기 위해서는 신중한 고려가 필요합니다.

어떤 도구를 사용하고 있는지 명확하지 않습니다. 비즈니스 프로세스 모델링 도구라는 일반적인 도구 세트를 참조하고있을 것입니다. 그러한 도구를 사용하는 데는 합당한 이유가 있습니다. 모든 품질의 비즈니스는 프로세스 및 분석가 측면에서 기능을 정의하고 비즈니스 전문가는 이러한 프로세스를 편안하게 그릴 수 있습니다 (표준과 묶을 때까지). 웹 프로그래밍에 대한 지식이 없어도 개념 수준에서 이러한 프로세스를 만들 수 있으며 올바른 도구가있는 경우 프로세스를 작동중인 응용 프로그램으로 변환 할 수도 있습니다 (경험이있는 사람이이 마술을 제작하려면 보드에 올라와야합니다) 당연하지). 아이디어가 좋습니다.

시각적 도구의 목적은 프로세스를 문서화하는 것이 아닙니다. 이 도구를 사용하면 전문적인 리엔지니어링 프로세스를 지원하고 때로는 시뮬레이션을 실행하여 프로세스가 원하는 것보다 덜 효율적인 지점을 찾아 병목 현상을 제거 할 계획을 세울 수 있습니다.

오늘날 많은 회사에서 BPMN 2.0 (Business Process Modeling Notation)이라고하는 표준 방식이 있습니다. 도구에서 사용하는 경우이 표기법을 이해하는 것이 좋습니다.

지식 의 비즈니스 프로세스 관리기구는 여러분이 고려해야 할 유명한 자료입니다.

위의 비즈니스 측면을 다룹니다. 기술적 인 측면에는 SOA와 BPEL이 필요하지만 지금 여기에 대한 조언을 해줄 수 있을지 모르겠습니다.

역사에 의한 간단한 예.

석기 시대

처음에는 사람들이 어디에서 무엇을해야하는지 알려주는 소규모 선배 회사가있었습니다. 때때로 상황이 잘못되어 Person X 또는 Y가 비난을 받았습니다.

다음 인터넷과 이메일이 발명되었습니다.

사람들은 이제 다른 사람들에게해야 할 일을 썼습니다. 사람들은 종종 이메일에 문제가 있거나 잘못 읽거나 단순히 읽지 않고 단순히 이메일을 삭제했습니다. 종종 나쁜 이메일을 비난하지 않는 것들

워크 플로는 관리에서 발전했습니다 . 작업을 표준화함으로써 사람들은 프로세스를 중단 한 단계를 확인하면서 동시에 실제로 수행 된 작업에 대한 디지털 개요를 얻을 수있었습니다. 이것은 사람들이 표준 프로세스를 변경하고 싶거나 알 수없는 XY 사람이 부적절한 데이터베이스 요청을 일으켜 데이터베이스가 손상되어 생산을 석기 시대로 되돌릴 때까지 잘 작동했습니다.