[This guest post by Andrew Paier, Vice President of BP Labs, does a great job capturing our culture around participating in the wider BPM community and forums.? This blog, our participation in DeveloperWorks, and our participation in conferences and other discussion forums is all part of it. ]
Anyone who watches the DeveloperWorks BPM forum for any length of time may notice that I spend significant energy attempting to answer questions. Several people have asked me why I do this and why BP3 allows me to help out those who may be competing with us. ?I think the answer will help you understand BP3 better.
BP3 is BPM
Our company focuses on BPM. ?And delivering good customer value in BPM. ?We are not the only company that makes that claim, but I do think we are one of the only ones willing to walk away from projects that aren't process-oriented or BPM. ?We also are one of the only ones making significant investments to make the ecosystem better. ?Posting to Developer Works is one of those investments.
We make investments in the BPM community because bad BPM projects affect all of us.? Many times the result of a bad project is the customer thinking that the problem is BPM- that it isn't their company, the team delivering the project, or the expertise of the team. ?If it is one of their first projects their reaction is likely to be "Well, we tried BPM and it failed. ?I guess BPM isn't for us. ?We shouldn't do that any more." ?When that happens, all BPM practitioners are poorer. We've all seen this same reaction to companies that have tried one Agile project, and then stopped - "we tried and it didn't work."
If we can remove road blocks that prevent user adoption by helping everyone have a better user experience, that is awesome! ?If I can save a BPM Developer 10 hours by telling them they are going down a wrong path and pointing in the right direction, everyone wins. ?Every successful BPM deployment means a customer who is going to be looking to do more BPM.? Looking towards more sophisticated solutions. ?Looking for more help.
That is good for everyone in the ecosystem.
Certainly some of the people I help on developer works may be on a team that we were bidding against. ?That is okay, perhaps they even won the BPM engagement. ?Now I want BPM to succeed. ?If they fail we are both poorer for that. ?And remember BP3 is BPM. ?Many of the people asking questions about BPM now likely work for companies that will be asking them next month or next quarter to write Java applications, or an iOS app, or whatever else they think is hot and they can sell. ?And we will still be here delivering high quality BPM solutions.? Focused.? Because BP3 is BPM.
I've known many IT professionals who have "coded themselves a priesthood". ?They have created something so complex and poorly understood that they will never be without a job. ?I've never wanted to be that guy. ?Ever. ?(Probably still guilty of it, but I've never done it on purpose). ?I've always striven to take hard technical problems and create tools that make the problem easier for the next person. ?Take a hard problem, create code to make it easier to solve, and hand it to someone else and let them solve it the next time.
I want new problems. ?I have no interest in solving the same problem over and over.
Look at our Brazos UI Toolkit. ?Yes BP3 could have kept it to ourselves, and only used it for our customers, it it would have been differentiating for us. ?But that would be tantamount to saying "We all do BPM, but BP3 is a bit better at the UI part." ?If we are going to win a BPM engagement I don't want it to simply be we have the best toys. ?I want it to be because we are hands down the best at what we do. ?That even when we give other consultants our tools, even when we help explain implementation details to them on developer works, we are still able to deliver a higher quality experience for our customers.? And we are still able to be a critical part of the BPM ecosystem.? We believe in the rising tide for BPM.? We believe BPM isn't a zero sum game.