The Problem: Current State of Enterprise Development
The Traditional Development Lifecycle
A typical cycle for developing a new enterprise system comprises several milestones, each with significant overhead:
┌─────────────────────────────────────────────────────────────────────┐
│ TRADITIONAL DEVELOPMENT LIFECYCLE │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ PHASE 1: REQUIREMENTS GATHERING (4-8 weeks) │
│ ─────────────────────────────── │
│ • Business analysts conduct interviews, workshops │
│ • Output: Software Requirements Specification (SRS) │
│ • Written in natural language - ambiguous, interpretable │
│ • Requires domain expert sign-off │
│ • Changes require formal change control process │
│ │
│ ▼ │
│ │
│ PHASE 2: SYSTEM DESIGN (2-4 weeks) │
│ ────────────────────── │
│ • Architects interpret SRS document │
│ • Constant clarification meetings with analysts │
│ • Output: Architecture and design documents │
│ • Translation losses begin here │
│ │
│ ▼ │
│ │
│ PHASE 3: IMPLEMENTATION (8-16 weeks) │
│ ─────────────────────── │
│ • Developers write code based on design docs │
│ • Must understand business context (they often don't) │
│ • Traceability requires manual effort │
│ • DevOps engineers set up CI/CD (additional overhead) │
│ • Code diverges from original requirements │
│ │
│ ▼ │
│ │
│ PHASE 4: TESTING (4-8 weeks) │
│ ──────────────── │
│ • Testers write automation tests (more code!) │
│ • Manual testing for complex scenarios │
│ • Test cases may not cover actual requirements │
│ • Bugs found → back to implementation │
│ │
│ ▼ │
│ │
│ PHASE 5: RELEASE (1-2 weeks) │
│ ─────────────── │
│ • Release manager assesses readiness │
│ • Manual deployment procedures │
│ • Hope nothing breaks in production │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ TOTAL TIME: 19-38 weeks │
│ ROLES INVOLVED: 6+ (BA, Architect, Developer, Tester, DevOps, RM) │
│ OVERHEAD: 40-60% of effort doesn't directly add features │
│ ═══════════════════════════════════════════════════════════════ │
│ │
└─────────────────────────────────────────────────────────────────────┘
The Hidden Costs
1. Communication Overhead
Every handoff between roles introduces translation losses:
Domain Expert's Intent
│
│ -10% (writing SRS)
▼
Business Analyst's Understanding
│
│ -15% (design translation)
▼
Architect's Interpretation
│
│ -20% (implementation)
▼
Developer's Code
│
│ -10% (testing gaps)
▼
Final System: ~55% of Original Intent
2. Change Management Burden
When requirements change (and they always do):
| Activity | Traditional Approach |
|---|---|
| Update SRS | 2-4 hours |
| Update design docs | 2-4 hours |
| Developer implements | 4-40 hours |
| Tester updates tests | 2-8 hours |
| DevOps updates pipelines | 1-4 hours |
| Total for one change | 11-60 hours |
3. Knowledge Silos
- Business logic lives in developer's heads
- "Ask John, he wrote that plugin"
- When John leaves, knowledge leaves
4. Technical Debt
- Separate documentation becomes fiction
- Tests don't match reality
- No one knows what the system actually does
The Dynamics 365 CE Challenge
Microsoft Dynamics 365 Customer Engagement (CE) promises to be a low-code solution for building business applications. This promise is only partially fulfilled.
The Reality of Dynamics 365 CE
┌─────────────────────────────────────────────────────────────────────┐
│ DYNAMICS 365 CE: PROMISE VS REALITY │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ THE PROMISE THE REALITY │
│ ─────────── ────────── │
│ │
│ "Empower citizen developers" Developers write plugins │
│ "No-code business rules" C# code for complex rules │
│ "Visual workflow designer" Code activities required │
│ "Rapid application development" Months of development │
│ "Business users in control" IT bottleneck for changes │
│ │
│ WHAT FUNCTIONAL CONSULTANTS CAN DO (without developers): │
│ ───────────────────────────────────────────────────────── │
│ ✓ Create entities and fields │
│ ✓ Design forms and views │
│ ✓ Configure simple workflows │
│ ✓ Set up basic business rules │
│ ✗ Complex calculations ← Needs developer │
│ ✗ Multi-entity validations ← Needs developer │
│ ✗ Advanced process automation ← Needs developer │
│ ✗ External integrations ← Needs developer │
│ ✗ Custom APIs ← Needs developer │
│ ✗ Sophisticated branching logic ← Needs developer │
│ │
│ THE RESULT: │
│ ─────────── │
│ • 60-70% of customizations require developer involvement │
│ • Functional consultants depend on and must trust developers │
│ • Business logic is hidden in compiled .NET assemblies │
│ • Traceability from requirements to implementation is lost │
│ • Changes require developer availability (bottleneck) │
│ │
└─────────────────────────────────────────────────────────────────────┘
Specific Dynamics 365 CE Limitations
| Limitation | Impact |
|---|---|
| Plugin Development | Complex logic requires C# plugins, needs Visual Studio, deployment complexity |
| Workflow Activities | Custom activities need .NET development |
| Business Rules | Limited to simple field-level logic |
| Process Flows | Native BPF has severe limitations (linear, no complex branching) |
| API Development | Building REST APIs requires significant backend development |
| Deployment | Manual, error-prone solution management |
| Testing | No built-in test generation from requirements |
The Cost Summary
| Problem | Business Impact |
|---|---|
| Long Development Cycles | Delayed time-to-market, missed opportunities |
| High Development Costs | Developer salaries, external consultants |
| Developer Bottleneck | Changes blocked waiting for developer availability |
| Knowledge Loss | Turnover leads to lost institutional knowledge |
| Compliance Risk | Documentation doesn't match implementation |
| Technical Debt | Accumulated complexity slows future development |
Next Steps
- The Solution - How FlowOn addresses these challenges
- Product Suite - Overview of FlowOn products