On Oct 2, 2007, at 12:16 PM, "Rob Eamon" <[EMAIL PROTECTED]> wrote: > >> > > Governance per se is not the problem. My point was the seeming over > emphasis on governance is contributing to SOA woes.
Emphasis by the vendor community and hijack of the term for what was previously known as Service Management, yes. Architectural governance (I.e. Someone making sure that projects are building the right things, services or not) is needed. As we've all said, though, that's not specific to SOA. > > >> [snip] >> >> Just because it is difficult to do doesn't mean that we're trying >> to do the wrong thing. > > [snip] > > 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? > The only argument that could be made against this is that a service- oriented solution for a project could unnecessarily create more moving parts, potentially making mgmt tougher. Given a choice of JBOWS and no services, I too would take JBOWS. > >> 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? This is a bit thought provoking. In some ways, SOA has become the vehicle that allows discussions of what really needs to be fixed, even though those things aren't specific to SOA. The key thing is that problems get fixed and improvements made. If attaching them to an SOA moniker makes that more likely, do it. If removing them from the SOA discussion helps, do that. Success in corporate IT is certainly a political game. > > >> 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." > I never said the business wasn't prone to the same behavior. :) I violently agree that agressive timelines and assumptions in place of analysis have contributed to the current state of corporate IT systems. Fault lies on both sides, as is usually the case. It's good that you've tried to dig into the business, but my experience has been that is the exception rather than the norm. > >> 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 Yup. Good discussion! -tb Todd Biske http://www.biske.com/blog Sent from my iPhone!
