10/23/07 :: [SOA] No clue [permalink]

The reason why I quit working for ISVs is because 95% of the people I worked with: senior executive, product managers, developers and architects had no clue and more importantly did not care to have a clue about what they were doing. Call it bad luck or statistically significant (ok the p-value is kind of high based on my sample), this simply became something I could not no longer stand. I have heard everything in my career from a developer thinking UML activity diagram were the perfect and ultimate business process model, then admitting he was wrong and campaigned for using UML state diagrams instead, to a product manager explaining to me that we did not need any business logic to implement composite applications, we could directly hardwire the user interface to the data model (not even the service interface, directly at the database table level). I don't think there is another engineering discipline where people can get away with stupid thinking: bridges would collapse daily, cars would crash or explode, water would not be drinkable... Product managers expect Product Marketing will brainwash customers and if that doesn't succeed, they  have found the ultimate argument: they often try to hide between the stupidity of users (How many time have I heard "our users are stupid"). Note that nobody is immune to saying something stupid, but every one should be able to figure it out -even with the help of others.

A great example of somebody having no clue at all is Nick Malick. He seems to work hard every day to post gigantic posts about SOA. His blog claims to provide a view “inside architecture”. How misleading ! Please note that I am not saying that everyone at Microsoft has no clue. I am trying to point out a movement that started a few months ago without any ground and is propagating on fallacious arguments. This is the "it makes me look smart to trash something important" syndrome: industry pundits start injecting FUD in SOA initiatives. What if the benefits were not there? What if SOA was to complex? Too expensive? Required too much change? These questions are music to the hears of some Product Managers, since they could not figure out what customers needed, they promptly bag the whole thing and move on. SOA is annoying, it requires that you think.

Jeff said it eloquently in his post today:

Many of these individuals are the ones responsible for silo-oriented thinking in the first place. They proposed small (agile) projects where we captured just enough requirements to begin coding and releasing. Guess what? This style of development doesn't jive with the concept of shared services. It is the cause of the problem, not the solution.

In his post, Nick starts talking about “Semantic Dissonance in the Data”. He nailed it, right there before our eyes: “This makes Enterprise SOA a distant fantasy for many enterprises.“.Taa…Daa… Why didn’t I think of that before? Who knew the hidden relationship between chords and SOA? What’s next? Semantic Relativity? Quantum Data Integration? Connector (String) theory? Nanodocuments? Cold Middleware Fusion?

His scenario is described as follows:

For example, in one business, a purchase order may be created by anyone but is followed by an approval process if it exceeds a threshold.  In another business, the purchase order cannot be created until the approvals have occurred, and perhaps, all purchase orders require approval. 

So, if you look in a database and you see a purchase order... has it been approved or not?  The answer depends on the business unit that created it. 

So let’s try to understand Nick’s argument. There is not much there so my interpretation might fill in some of the blanks. So we have two business units which have two different procurement processes -not unheard of. I see a “state” “Purchase Order Created”. There is one business entity: Purchase Order and therefore a service managing the system of record for purchase orders. Nick is telling us that “Semantic Dissonance in the Data” is preventing us to design a single service that can support these variants of the procurement process. A “Created” state is very innocuous. I would argue that in order to be reviewed, “something” has to be created. The “Submitted” state that follow is a lot more consequential. Nick, it would really help if you got your states right. In the first variant, the service can be implemented with an conditional transition to “Submitted” provided the amount in within a certain range, while in the second case, the transition is always routed to the approval step. So Nick is telling us that the Purchase Order service cannot be implemented to support two variants of its lifecycle based on the requesitioner’s group? I would bet that even Workflow Foundation can do that.

But of course, Nick concludes : “This makes Enterprise SOA a distant fantasy for many enterprises”. Isn’t it clear for everyone? Let’s stop all SOA initiatives, we are wasting our time we reached the point of Semantic Dissonance. I feel sorry to work for such an industry. IT does not matter because software companies charge too much for their product to put in charge people that pontificate all day instead of getting their hands dirty and spending time with the customer. I am sorry to just pick on Nick, he just exemplifies this FUD movement and consistently produces Diracs of Guidance/Rationale ratios (i.e. infinite amounts of guidance from zero rationale). I’ll pick on other people next time. I don’t think I’ll spend much more time reading his blog.