BPM 또는 단지 일반 프로그래밍?

Question

비즈니스 프로세스를 구현할 때 개발자의 관점에서 무엇을 선호합니까?

BPMS (Business Process Management System) 또는 필요한 도구 및 프레임 워크 (예 :보고 도구)가있는 좋아하는 IDE?

귀하의 관점에서 귀하의 개인 도구 및 프레임 워크와의 IDE에 비해 BPM의 가장 큰 이점은 무엇입니까?

확인. 어쩌면 나는 더 구체적이어야 할 것입니다 ... 규칙을 구성하여 비즈니스 프로세스를 쉽게 구현할 수 있어야하는 특정 BPM을 알아야합니다. 그러나 개발자로서 저는 시스템과 함께 일하기가 어렵습니다. 리팩터를 리팩터 할 수있는 텍스트 파일로 작업하고 싶습니다.해야 할 작업에 적합한 기술이나 프레임 워크를 선택할 수 있기를 바랍니다. 대신 시스템은 나를 구성하도록 강요합니다.

Java를 사용할 수있는 규칙이 있지만, 심지어 Intellisense 등이없는 시스템 편집기를 고수해야합니다.

그래서 이것은 내 자신의 질문에 대한 답으로 이어집니다 - 나는 BPMS (적어도 내가 아는 것)와 함께 일하는 방법을 배우지 않고 익숙한 도구를 사용하고 싶습니다. . 내가 아는 BPM은 탈출하기 어려운 프레임 워크입니다! 현재 나는 내가 아는 BPM보다 Grail과 같은 프레임 워크를 선호합니다.

아마도 더 구체적인 질문은 다음과 같습니다. 당신은 같은 느낌이 들거나 개발자를 꿀벌을 지원하고 개발자처럼 생각하거나 대부분의 일을하도록 강요하는 BPMSE가 있습니까?

Answer 1

정확히 무엇을 요구하는지 확실하지 않지만 선택 BPM 대 일반 프로그래밍은 요구 사항에 따라 다릅니다. "비즈니스 프로세스"는 소프트웨어 엔지니어링에서 비교적 모호한 용어입니다.

다음은 귀하의 요구를 평가하기위한 몇 가지 기준입니다.

• 규칙의 복잡성 - 프로세스에서 결정/규칙이 간단하고 복잡하며 구성 가능하며 하드 코딩 된 것입니까?
• 프로세스의 변동성 - 프로세스가 얼마나 자주 변경됩니까? 누가 변화를 할 수 있어야합니까?
• 통합 필요 - 여러 이종 서비스를 사용하여 프로세스가 실현됩니까? 아니면 모두 같은 언어로 구현됩니까?
• 동기/비동기 - 당신의 프로세스는 비동기 동작을 처리 할 필요가있는 "장기적"입니까?
• 인간의 과제 - 귀하의 프로세스는 인적 상호 작용과 관련이 있으며, 역할/책임에 따라 업무를 사람들에게 할당/라우팅 하는가?
• 프로세스 모니터링 - 실행중인 기존 프로세스 인스턴스에서 원하는 제어 수준은 얼마입니까? 조치 등을 감사해야합니까?
• 오류 처리 - 이전 요점에 따라 오류를 어떻게 처리하거나, 결함이있는 프로세스 실행을 재 시도 할 계획입니까?

이 질문에 대한 답변에 따라 프로세스가 간단한 상태 차트 순서로 실행할 수있는 몇 가지 조치와 결정이 포함되어 있거나, 더 정교한 무언가가 필요하고 자신이 그 모든 것을 재 구현하고 싶지 않다는 것을 알 수 있습니다.

사이 일반 프로그래밍 그리고 a 풀 플러드 BPM 솔루션 (예 : 오라클 BPM 스위트 포함하는 BPEL, 규칙 엔진, 등), 거기 있습니다 중간 솔루션 ~와 같은 JBPM 또는 Windows Workflow Foundation 그리고 아마도 다른 많은 사람들. 이 중간 솔루션은 종종 상충됩니다.

Answer 2

내 경험에 따르면 BPMS 시스템이 제공하는 개발 환경은 세 번째 속도, 비생산적이며 실제로 제한이 제한되지 않기 때문에 유지하기 어려운 코드 (제한 사항으로 인해)를 작성해야합니다. 내가 익숙한 BPMS 시스템에서 제공하는 거의 모든 "기능"(UI, 통합 등)은 (데이터베이스를 위해 이름을 딴 회사가 판매 한 회사) 우리가 지불 한 돈의 가치가 없었습니다.

BPMS를 개발자로 사용해야한다면 Java 또는 .NET와 같은 기존 개발 환경에서 BPMS 환경 자체에서 가능한 한 적은 구축을하고 통합하는 것이 좋습니다. 둘. BPMS에 들어가야 할 유일한 것은 비즈니스 프로세스를 수행하는 최소값입니다.

Answer 3

나는 과거에 Biztalk와 함께, 최근에는 JBPM과 함께 일했습니다. 내 의견은 다음과 같은 이유로 BPM에 대해 편향되어 있습니다.

1. 가파른 학습 곡선 : 프로세스 작업을 수행하려면 시스템과 편집자의 작동 방식을 이해해야합니다. 개발자가 비즈니스 사용자는 물론 시스템을 이해하기에 충분히 어렵습니다. 드래그 앤 드롭 및 시각적 표현은 훌륭한 데모 도구입니다. 그것은 확실히 관리자 (궁극적으로 지불하는 사람)에게 깊은 인상을 주지만 개발자의 생산성은 단지 떨어집니다.

2. 워크 플로를 변경하는 비 개발자 : 하나의 BPM 솔루션이 완벽하게 보지 못했습니다. 코드처럼 보이지는 않지만 상자를 마우스 오른쪽 버튼으로 클릭하면 코드를 넣어야합니다. 그렇지 않으면 작동하지 않습니다. 따라서 개발자가 필요합니다. 가장 좋은 점은 개발자 친화적이거나 비즈니스 사용자 친화적이지 않고 데모 사용자 친화적이라는 것입니다.

3. TestAblity 및 Refactoring : BPM을 드라이브하는 것은 사실상 불가능합니다. 당신은 '단위 테스트 프레임 워크'가 광고되었지만 대부분은 해킹과 사용하기 어렵습니다. 최근에 나는 JBPM을 시도했다. 나는 많은 접착제 코드와 가짜 워크 플로 처리기를 작성하여 작동하게했습니다. 저를위한 거래 차단기는 리팩토링입니다. 비즈니스가 근본적으로 변경되면 비즈니스 프로세스가 어떻게 보이는지에 대한 마음이 마음에 들고, 상자를 다시 조절하는 것이 작동하지 않기 때문에, 상자에 바인딩 된 모든 변수도 다시 정렬되어야합니다. 나는 IDE의 힘을 선호하고 비즈니스 프로세스를 리팩터링하기위한 테스트를 선호합니다.

응용 프로그램에 워크 플로가있는 경우 워크 플로 라이브러리 (영구 상태가 있거나없는)를 시도 할 수 있습니다. BPM과 함께 제공되는 모든 부풀지 않고도 여전히 워크 플로를 관리합니다. 비즈니스 사용자가 코드를 이해해야하는 경우 비즈니스가 우수한 프로세스 흐름도를 준비하고 양호한 도메인 구동 코드로 변환하도록합니다. 오이 스타일 수락 테스트를 사용하여 개발자와 비즈니스를한데 모으십시오. BPM은 너무 많은 일을하려고 시도하고 모든 일을 심하게하는 것입니다.

Answer 4

BPMS- 많은 일반적인 비즈니스 사례, 사용 사례가 이미 구현되었습니다. 그래서 당신은 그것을 사용하는 방법을 알아야합니다. 일반적인 워크 플로우의 경우 한 줄의 코드를 작성할 필요조차 없지만 대부분 구현되지 않은 것들을 다루기 위해 일부 스크립트를 작성해야합니다.

일반 프로그래밍- IDE를 사용하여 코드를 해킹하십시오. 긍정적 인면 : 더 많은 통제. 부정? 보일러 플레이트 코드를 다시 쓰는 데 많은 시간이 소요됩니다. 그리고 당신은 그들을 유지해야합니다.

간단히 말해서 비즈니스 프로세스 관리 시스템을 선호합니다. 내가 추천 할 것입니다 프로세스 메이커. 직관적 인 프로세스 디자이너가있어 드래그 앤 드롭으로 워크 플로를 설계 할 수 있습니다. 그리고 항상 쓸 수 있습니다 방아쇠 프로세스 기능을 확장합니다. 오픈 소스도 있습니다.