Discussions

News: Neward on where SOA ends

  1. Neward on where SOA ends (11 messages)

    SOA has taken a few twists and turns since it emerged out of Web services and SOA early in this decade. Among the baggage picked up along the way was SOA Governance. Ted Neward discusses SOA governance and the SOA frenzy in a post on SearchSOA.com's SOATalk Blog. He says things have gotten to the point that CTOs and CEOs are talking about SOA as a general strategy for running their entire IT department.
    In the rush to embrace new technologies and demonstrate "cutting-edge awareness", companies (and individuals) sometimes create mountains out of molehills. Such was the case with XML a few years ago, relational databases before that, object- orientation, Java, graphical user interfaces.... in fact, it's hard to name a recent technology trend that hasn't spawned this kind of "rush to embrace" that leads to nonsensical claims, bizarre architectural suggestions, or blatant bald-faced attempts at capturing clueless consumer dollars. One of those more recent trends has been the SOA bandwagon. Originally, though it's hard to remember in the frenzy around SOA, the whole point of services, at least in their original form, was about designing distributed systems to be loosely-coupled and thus easier to interoperate with.
    http://itknowledgeexchange.techtarget.com/soa-talk/where-soa-ends/

    Threaded Messages (11)

  2. Re: Neward on where SOA ends[ Go to top ]

    Number of responses to this thread reflects the level of interest on this topic. All the vendors and marketing cum sales people killed this topic by over selling and confusing the top management you talk about in your post. Fortunately this time around the development community was smart enough to not waste time / money / energy in buying "soa" :). Instead all developers are more of less aware of what SOA means and have done stuff on their own in a custom way. ( may not be optimal but anytime better than any product out on market) Whatever works is fine.
  3. Re: Neward on where SOA ends[ Go to top ]

    Number of responses to this thread reflects the level of interest on this topic.

    All the vendors and marketing cum sales people killed this topic by over selling and confusing the top management you talk about in your post.

    Fortunately this time around the development community was smart enough to not waste time / money / energy in buying "soa" :).

    Instead all developers are more of less aware of what SOA means and have done stuff on their own in a custom way. ( may not be optimal but anytime better than any product out on market)
    Whatever works is fine.
    SOA can never be a product that you can buy and no one can do it for you. It's something a company has to do for itself. I think that Ted Neward is right on and that there's not really much more to say. Developers already know what he says is true. It's management that needs to get this. The problem is that a lot of IT management take the word of salespeople over their own people. It's one of the biggest problems in IT and was a problem before SOA and will be a problem after SOA.
  4. Re: Neward on where SOA ends[ Go to top ]

    Number of responses to this thread reflects the level of interest on this topic.

    All the vendors and marketing cum sales people killed this topic by over selling and confusing the top management you talk about in your post.

    Fortunately this time around the development community was smart enough to not waste time / money / energy in buying "soa" :).

    Instead all developers are more of less aware of what SOA means and have done stuff on their own in a custom way. ( may not be optimal but anytime better than any product out on market)
    Whatever works is fine.


    SOA can never be a product that you can buy and no one can do it for you. It's something a company has to do for itself.

    I think that Ted Neward is right on and that there's not really much more to say. Developers already know what he says is true. It's management that needs to get this. The problem is that a lot of IT management take the word of salespeople over their own people. It's one of the biggest problems in IT and was a problem before SOA and will be a problem after SOA.
    it was a sarcastic comment when i said - SOA is not sold. There were sales guys whom i met personally who were trying to do so. i m not kidding. they will sell anything if someone is there to buy it. BTW - Everyone here has posted really valid comments.
  5. Re: Neward on where SOA ends[ Go to top ]

    it was a sarcastic comment when i said - SOA is not sold.
    There were sales guys whom i met personally who were trying to do so. i m not kidding. they will sell anything if someone is there to buy it.
    BTW - Everyone here has posted really valid comments.
    I wasn't arguing with you. I apologize if it came off that way. I more responding to the level of interest point you made. When I first saw this, I had an inclination to comment but I'm so tired of arguing about what is SOA and what isn't. On a side note, when I said Ted Neward was right, I mean in general about how the hype around SOA has gone off the rails such that it's meaningless. He actually seems to be under the impression that SOA is another word for web services which is 100% incorrect. But like I said above, I'm tired of arguing about this and I don't think matters anymore. The feel like hype has metastasized around SOA. All we can do now make prognoses about when it will finally succumb to the next big thing. It's frustrating because there are some really solid principles at the core of SOA. They'll probably just get a new name and the cycle will start all over.
  6. SOA Maturity[ Go to top ]

    SOA is all about defining loose coupled services and interfaces to support enterprise business requirements so that IT an non IT communities can address their views and concerns using implementation independent metadata defined in common language such as XML. Governance and management of enterprise services is important to build maturity and trust in enterprise services from service consumers and providers perspective so that an organization can achieve business agility, high ROI, low TCO and dynamic response to business challenges. Successful adoption of SOA depends upon number of factors including, Understanding of SOA as an enterprise architecture practice.Established SOA domain model to address all parties’ views and concerns. Established maturity model to understand and assess capabilities of an enterprise as services. Proper service taxonomies to provide visibilities to IT and business consumers and providers of services. Integration of SOA governance and management views with all other views of normal IT practices. However AS OF TODAY what we have is a very low level governance and management approach to support WEB SERVICES. Web service is just one technology which support SOA principles; however web service is not SOA.
  7. Re: Neward on where SOA ends[ Go to top ]

    SOA ends (and fails) the moment you believe the vendor. We made a big mistake by buying the suite from the 'leading' SOA vendor. They continued to push technologies , products and consultants which we didn't really need under the pretex of doing SOA 'properly'. Naturally the adoption failed and now we are saddled with loads of products and service contractors, and to top it all the yearly cost for all this baggage is MORE than what we were expecting to save annually!
  8. Re: Neward on where SOA ends[ Go to top ]

    SOA ends (and fails) the moment you believe the vendor.
    We made a big mistake by buying the suite from the 'leading' SOA vendor. They continued to push technologies , products and consultants which we didn't really need under the pretex of doing SOA 'properly'. Naturally the adoption failed and now we are saddled with loads of products and service contractors, and to top it all the yearly cost for all this baggage is MORE than what we were expecting to save annually!
    We've got consultants that basically came in and said SOA is WSDL + SOAP. Architecturally, nothings changed. We call it 'Spaghetti and Meatballs' because that's what it looks like when you draw all the systems and their dependencies. The above is probably the biggest problem with SOA. People think it's technologies and/or protocols. SOA is really a strategy. What most people are doing that they call SOA is purely tactical.
  9. Re: Neward on where SOA ends[ Go to top ]

    'Spaghetti and Meatballs'
    Nice anti-pattern although I don't know what the fix is. What has probably changed the definition of SOA, at least in the last 6 months, is the fact that IT project budgets are getting slashed. Part of early adopter SOA was picking a vendor story (marketing, technologies, tooling, process, and consultants) and having the CIO close the deal on the golf course. Now that the technology end of the problem has become more defacto and less vendor-driven, the real problem of exposing business functions as services can get underway. Here enters POA (politics-oriented architecture) a.k.a. governance, where business functions and business units hash out integration. Revenue generator win and cost centers lose.
  10. disagree[ Go to top ]

    This is where I have to disagree. One of the biggest points of SOA is to bridge the gap between business and IT, so that business capabilities can be defined as re-useable IT assets. Not just live as a bunch of class definitions that only developers understand. A service oriented architecture should be able to cross the IT boundaries and reach the executive business boundaries. SOA should definitley not just be a way to describe an approach by which we can create distributed systems. If you have a situation where the CTO and CEO communicate based on the SOA business capabilities then mission accomplished.
  11. Re: disagree[ Go to top ]

    Definitely, +1. Basically, an architecture that is based on Services is that one that does not rely on actual technologies or XML formats, but on the business definition. See, as I understand, a service is not a techy thing, but a business one. Service is a set of business functionality exposed over a common interface. The main task in SOA is defining that functionality is a business way that makes sense. The problem is then when you leave Services to be defined by developers!
    William Martinez Pomares.
    Architect's Thoughts
  12. SOA is not a technology[ Go to top ]

    Is the author implying that relational databases were over hyped? That technology goes back to the 1970's and is central to most enterprise infrastructures. Looks like we really fell for that one :-) The article displays a programmer centric viewpoint as opposed to an enterprise (business) oriented viewpoint in claiming that SOA is a "a way of structuring the way programmers think". This causes the article to conflate how SOA works (loosely coupled, etc.), versus what problems SOA is intended to solve (interfacing heterogeneous enterprise and/or legacy stovepipe systems with a coherent architecture). Web services are only a particular implementation of SOA. SOA is an architecture, not a technology (and by extension not a product). Now let's have the same discussion about "cloud computing"!