More Nonsense

I know I need to let this go, but I can't stop thinking about the nonsense of this BPMN -> JCAPS -> .Net web service architecture proposed by management at the client I'm working with.
  • The main reason for the base web services to be implemented in .Net rather than directly in JCAPS is that this organization has 10x as many .Net developers as it has Java/JCAPS developers. The thinking is that this ratio will make it easier to find available bodies to maintain and enhance these services. While this makes sense, any guess on how many people know BPMN? A small handful... all of them contractors. There's not even a BPMN modeling tool in place at the company. Yet they're convinced this is the way to go.
  • Is it reasonable to expect business users to create BPMN models? While I realize the GUI interface makes it less like "coding", I think that it'd be helpful to have a basic understanding of boolean logic, parallelism, and exception processing in creating the business models. While I've seen some amazing Excel applications created by business users, the assumption that these people will be able to create high availability, high throughput applications is a bit of a reach for me.
  • All the excitement over BPM reminds me of the EJB "revolution" - when the mantra at many companies was "EJB everywhere" and EJBs were the architectural style du jour. EJBs were (poorly) implemented in many places where they weren't a good fit. Many of these applications had scalability and performance problems. I'm wondering if this BPM "revolution" will produce similar results. (Is there a reason it's called Business Model Notation rather than Business Application Notation?)
  • In a system like this, it's important to think about how service enhancements are rolled out. No one is talking about how these services will be maintained, released, or tested. Will there be a period of backward compatibility for service clients? How will that be handled? This lack of foresight is another reason I feel this company is not ready for SOA.

On numerous occasions I've approached the client to discuss these things with little success. I can't get them to recognize that many of their problems result from their (lack of) process rather than problems with their technology. I wish I knew of a better way to get through to them.

Comments

Popular posts from this blog

I Believe...

More stuff to get excited about

A few quick notes