We’re a distributed organization. Multiple teams are working on different parts of the migration to open source BPM. Each team is essentially solving similar problems independently—integration points, data mapping, workflow patterns. It’s clear that we’re duplicating effort.
The idea of a shared marketplace where teams post the patterns they’ve figured out as reusable templates is appealing. But I keep wondering whether it actually happens in practice. Does everyone really share their work? Or do most people just keep their solutions internal and rebuild things that another team already solved?
I’m also curious about the economics of it. If someone spends time generalizing their workflow into a shareable template, what actually gets them to do that versus just shipping their solution and moving on? Is there some incentive structure that makes this work?
And from a quality perspective, how do you prevent teams from using migration patterns that work in one context but are actually problematic in another?
Has anyone worked in an organization that actually makes the marketplace model function? Does it cut migration time and cost, or is it mainly overhead that slows things down?
We tried this kind of pattern sharing across our organization and it had mixed results. The places where it worked: teams that were already collaborating closely would naturally share what they figured out. When we made sharing easier through a central location, they kept doing it.
Where it didn’t work: teams that operated independently didn’t spend time documenting and sharing patterns. The incentive wasn’t there. They prioritized shipping their solution over building something reusable for other teams.
What actually changed the dynamic was making it part of the evaluation criteria for project completion. If you shipped a solution but hadn’t documented it for reuse, your project wasn’t considered done. Sounds bureaucratic, but it worked. Teams started thinking about reusability earlier.
Quality issues did show up. A workflow pattern that worked for one team’s specific context would get reused by another team that had slightly different requirements, and then it broke in production. We ended up needing people who could review patterns and flag assumptions that wouldn’t transfer to other teams.
The economic piece: external incentive like recognition or time reduction didn’t really work. What worked was making it part of normal process. If your team’s definition of done includes shareable documentation, you do it. If it’s optional, you don’t.
Pattern sharing works best with governance. Document which patterns are suitable for which contexts, require code review before adding patterns to shared library, and maintain ownership by initial team for support questions. Without structure, you get chaos—teams using patterns in inappropriate contexts, out-of-date documentation, unsupported variations. With structure, you eliminate duplicate work and speed up similar migrations elsewhere.
Organizational patterns get shared when it’s mandatory, not optional. Make it part of delivery requirements and teams will document reusable solutions. Success also requires investment in pattern governance—someone has to validate quality and applicability before patterns go into the shared library. Marketplace model works when there’s curation and accountability.
Pattern sharing through a marketplace absolutely works when teams have a platform that makes it easy. What I’ve seen is that teams naturally document patterns they’ve built, and when other teams can easily access and customize those patterns, adoption accelerates.
The economics work because you avoid rebuilding solutions that already exist. Team A solves an integration problem, documents it, publishes it. Teams B, C, and D save weeks by using that pattern instead of rediscovering the solution themselves.
Quality issues are real but manageable. The patterns that work best are the ones with clear documentation about what they do and what assumptions they make. When you pull a pattern from the marketplace, you know what you’re getting.
For a distributed migration, this is huge. Each team still owns their part of the migration, but they’re building on patterns that other teams have validated. That’s how you speed migration across a large organization.