10/25/07 :: [SOA] NoT A clue [permalink]
So Nick responded. Just to be clear, I am fighting this statement: "This makes Enterprise SOA a distant fantasy for many enterprises".
Sadly enough, you do not seem to measure the consequences of what you write. You don't have a single clue of how a statement like this can get parsed and analyzed in an IT organization. How do you go in front of you CIO or you CTO and explain that SOA makes sense when someone in three sentences and a basic use case can call it a distant fantasy. What? SOA does not work for that? Why would I want to invest millions if someone from Microsoft IT comes so easily to these conclusions.
You don't even make a difference between the specification of the use case and its implementation. You are saying in your response that: " The "state of creation" is from a business viewpoint, and I picked an example that even a sophomore in business school would understand."
Not only your problem is not expressed in business terms. Not only you don't realize that "states" are the most intuitive concepts for business analysts. But, the tragic reality is that you are arguing that since you can't articulate the solution, then SOA is a distant fantasy for everyone else on the planet. This is even worse that I had imagined.
How much do you know about me? How much do you think I can talk to the business? Is it one more of your guidance/rationale Diracs? JJ can put UML class diagram together, therefore he can't talk to the business. Now you claim: "I'm talking about semantic dissonance in how BUSINESS talks to BUSINESS.". Hum.. you were talking about Semantic dissonance in the data, indicating that there were ambiguity in identifying purchase orders that were "created". Now you are saying two lines of business can't use the same semantics. Who cares what the business think about states as long as you can implement everyone's solutions? The business is not asking you to think for them. I bet you don't even have a single clue about what a reference data model is and how you use it in a Service Oriented Architecture.
What are you suggesting now? are you saying that the "business" should talk to the "business" to resolve their differences even before they can talk to the delivery teams? What the ... are you talking about? Do you think a LOB is going to swallow that? Each LOB have their own objectives and they not going to align with each other. It is IT which is going to build the Service Oriented Architecture to solve business problems. I don't think any LOB will want to create any kind of dependencies with others unless it makes business sense. Your recommendation: "that businesses align around some common understanding of business events, not just at the end (where all models align... in the money) but in the middle" is simply ludicrous. BTW, an event is the occurrence of a state, so please don't bring events in the mix, states is what the business understands most naturally.
The kinds of things people like you write are outrageous, you are wasting everyone's time by injecting tremendous amounts of FUDs based on bogus rationale that only show your ignorance of the "real world".
I am sorry to say that the whole post is flawed, Nick, every guidance you give only applies to LaLaLand and is the root cause of today's IT inefficacies.
Your other recommendations express "risks" as "facts". I you identify a risk you put a mitigation plan for it. You don't recommend a risk:
a) "there is little business value behind forcing all business units to use the same BPM tool", how smart is that from an EA, cost, operations, skills perspective?
b) "This is important because the businesses themselves are quite likely to affect the amount of governance they want to occur", isn't it the goal of the governance organization to be able to "govern" without impacting the budget and schedule of a project. Why suggest people not even "try" to govern. By making this recommendation you are compromising the most important value of SOA: reuse.
... sorry I don't see any silver lining. I can only express sadness to this post.