--- In service-orientated- [EMAIL PROTECTED], "jeffrschneider" <[EMAIL PROTECTED]> wrote: > > > Here's an interesting article. discuss: > > > http://cio.com/article/438413/Top_Reasons_Why_People_are_Making_SOA_Fa > il?page=1 > > > Miko - what a thought provoking article! Thanks for the softball. > > If these are the 10 obstacles to implementing SOA... we have to ask > the very simple question: Can we remove them? > > Here are the 10 reasons, followed up with the 'obvious question'... > (you may want to read the article first to get the context). > > "Top Reasons Why People are Making SOA Fail" > 1. They fail to explain SOA's business value > - What if... SOA didn't require an explanation to the business?
It really shouldn't require an explanation, should it. SO applied to business architecture may require a bit of an adjustment in thinking but by many accounts, SO applied to BA is a natural fit that is easily grasped. Focusing on "the business value of SOA" is incorrect, IMO. The value is in defining the BA, SO or otherwise--the focus should be on the value of the BA. One may need to justify applying SO to BA, but the focus of business value is the BA. > 2. They underestimate the impact of organizational change > - What if... SOA didn't require organizational change? The article states: "SOA brings massive amounts of change to an organization, especially if the organization does not have a well established enterprise architecture in place." Introducing architectural discipline, in any form, is disruptive. But why assume that applying an SO style to EA (I'm assuming a particular level here) requires "massive" change? I agree with the comment by Bert Hooyman in the reader feedback section of that article" "...somehow we take it for granted that successful introduction of SOA requires organisational change." Why do we make such an assumption? The definition of the BA/EA may or may not identify necessary organizational change. The discussion will be in the context of the BA/EA, not simply because SOA is being pursued. > 3. They fail to secure strong executive sponsorship > - What if... SOA didn't require executive sponsorship? IMO, SOA per se doesn't require any sponsorship because SOA does not presume any particular level of abstraction. SO applied at the BA level will have the most bang for the buck--but the sponsorship is for defining the BA (or EA), not for "SOA." > 4. They attempt to do SOA on the cheap > - What if... SOA wasn't expensive? The article says "SOA isn't something you buy, it is something you do." And then goes on to list all the things you have to buy. Following SO principles isn't necessarily an expensive proposition. It is highly likely that an enterprise already has sufficient tools (and multiples to choose from) with which to proceed. > 5. They lack the required skills to do SOA > - What if... SOA didn't require major skills retooling/ The article seems to present SO as though it's a completely brand new thing with completely new concepts and approaches--for which we must all be completely retrained and consulted, etc. Thinking in terms of services isn't the huge conceptual leap that this point seems to indicate. > 6. They have poor project management > - What if... SOA didn't affect project management? SO doesn't affect project management, IMO. This could be on any "Top 10 Reasons Why People are Making [pick your favorite topic] Fail." > 7. They think of SOA as a project instead of an architecture > - What if... SOA was clear in everyones head? SOA is not a discrete architecture. It is an architectural style. The author listed "...user interface designers, business process models, data services experts, business rules specialists, ESB experts, etc." none of which have anything to do with SO. All these items are the domain of a robust, cohesive EA. The EA will have service producers and consumers as components, and also address the other non-SO items. The phrase "SOA implementation" conjures up images of a project, so it might be a good idea to stop using it. "Our SOA implementation will be done Q4 of this year." No it won't. First, you're implementing a BA/EA, not an SOA (you've got more to deal with than just services). Second, implementation of a BA/EA will never be done because those items are in constant flux--which is why an SO approach can be valuable because it (ostensibly) embraces and enables that constant flux. > 8. They underestimate the complexity of SOA > - What if... SOA wasn't complex? SO isn't complex. BAs and EAs are. "It is not a hard concept to understand, but it is hard to implement correctly." Oh if only we had agreement on "correctly." > 9. They fail to implement and adhere to SOA Governance > - What if... SOA didn't require governance? (AKA, synthetic trust) SOA governance is too narrowly focused. Not everything is SO related, correct? Or does access to the SAP data tables not need to be "governed?" ;-) The focus should be on insuring, through "normal" processes and procedures, that the BA/EA/AA principles are adhered to throughout the lifecycle. "...the team must adhere to the architectural guidelines that the company adopts." That says it perfectly. No need for the "SOA" modifier. > 10. They let the vendors drive the architecture > - What if... SOA didn't need much vendor infrastructure? Like list item #6, VDA is a universal issue. The focus really needs to shift to BA/EA and off of SOA. SOA as a term must die. It's a source of endless confusion. As always, just my opinion. I could be way off base! -Rob
