--- In [email protected], Todd Biske <[EMAIL PROTECTED]> wrote: > > There are a couple nuggets I want to call out. Regarding > governance, I don't think governance, per se, is the problem, but > rather the process by which we govern.
Governance per se is not the problem. My point was the seeming over emphasis on governance is contributing to SOA woes. > [snip] > > Just because it is difficult to do doesn't mean that we're trying > to do the wrong thing. I don't think SOA is all that difficult of a notion to embrace and do. The problem I was mentioning was that we have a bunch of folks telling us that we're doing it wrong. "Don't listen to the vendors-- you might end up with a 'sub-optimal' solution." "JBOWS isn't SOA." "Without governance you're doomed to fail." Certainly these have a basis in truth but there is also a bit FUD spreading within them. Following and trusting a vendor doesn't necessarily lead to doom-- vendors have a vested interest in client success. Governance doesn't assure success, and depending upon the size of the company, formal governance could actually be hurtful. That JBOWS doesn't make an SOA could be argued the other way--I ask, why not? > Personally, I think there are two factors to consider. First, to > Rob's point, if the organization is struggling to get working > solutions out the door today, the deck is already stacked against > them to be successful on anything of a strategic nature, whether > SOA or anything else. Agreed. So why do we muddle the discussions about SOA with non-SOA issues? > Second, we IT practitioners are prone to > putting the solution before the problem. I disagree. Virtually every time I've ever tried to get beyond the solution to further understand the business and the issues, I get shut down. "We don't have time to analyze this to death." "We just need this done, we're on an agressive timeline." IT does contribute its share to the confusion when chasing shiny new concepts and solution, but it's been my experience that the business is by far the primary contributor to the hodge-podge of IT systems. The "solution" gets tossed over the wall for IT to manage, and then IT gets the blame for the inflexibility, and "holding the business hostage with spiraling IT costs." But I'm not bitter. :) > Generalities like "we > need to improve IT and business alignment" can be meaningless > without concrete examples of where the "misalignment" caused > problems. Organizations adopting SOA without clear definitions of > the deficiencies that need to be addressed and criteria for knowing > when they've been successful are at greater risk for viewing the > whole effort (if you could even call it a formal effort) as > unsuccessful. Swap out "SOA" for "any architectural style" in the last sentence and we're in violent agreement! -Rob
