Loading ...
Sorry, an error occurred while loading the content.

RE: [service-orientated-architecture] Re: Yefim Natis is sure that "SOA is integration"

Expand Messages
  • Nibeck, Mike
    Zapthink has a very specific take on SOA and integration. They state the following: - One goal of SOA - Integration as a byproduct of Service composition -
    Message 1 of 117 , Dec 22, 2008
    View Source
    • 0 Attachment
      Zapthink has a very specific take on SOA and integration.  They state the following:

      - One goal of SOA -  Integration as a byproduct of Service composition

      - One Goal of legacy integration: building Services to support this goal, NOT connecting systems to address a particular business need

      Their primary point being that in a SO architecture, integration is simply one of the steps or parts of a 
      composition, and it no longer gets seen as a distinct and separate set of processes or technologies.  In most cases, 
      integration efforts are designed to somehow "join" two or more disparate systems.  If however the point of interaction 
      is a higher level business service contract, the individual integration points become less relevant. 
       
      You will always have the need to interact with remote systems, and the lower level details will still be very similar to traditional integration efforts, but these efforts will exist in a larger context, the service model, that will hopefully not be directly impacted by the individual integration efforts.
       
      _mike


      From: service-orientated-architecture@yahoogroups.com [mailto:service-orientated-architecture@yahoogroups.com] On Behalf Of htshozawa
      Sent: Sunday, December 21, 2008 6:43 AM
      To: service-orientated-architecture@yahoogroups.com
      Subject: [service-orientated-architecture] Re: Yefim Natis is sure that "SOA is integration"

      IMHO, isn't integration just one objective of SOA. Isn't SOA an
      architecture which will make integration easier.

      I'm afraid that the best way to just eliminate redundency may result
      to just using products all from one vendor. I think there is a need
      to distinguish between migration to a single vendor and SOA.

      I personally favor, create an architecture and a "suggested"
      implementation plan, but to start the actual implementation with a
      single project.

      H.Ozawa

      --- In service-orientated- architecture@ yahoogroups. com, "Gervas
      Douglas" <gervas.douglas@ ...> wrote:
      >
      > Here is what Anne's blog has to say on this:
      >
      > <<According to this report by Jack Vaughn at SearchSOA | TechTarget,
      > Yefim Natis asserted "SOA is integration" at last week's Gartner
      AADI
      > Summit. The assertion produced the usual firestorm of commentary on
      > the Yahoo! SOA discussion list. Michael Poulin started the
      discussion
      > with this comment:
      >
      > "What can we do to slow down spreading such Integration SOA
      madness?"
      >
      > My response followed suit:
      >
      > "While I agree with the last line ["SOA is less a technology
      than
      > a way to dependably extract business value from technology." ], I
      > disagree with the leading one: "SOA is integration" . Many
      > organizations mistakenly perceive SOA as an integration strategy.
      But
      > it is not. SOA is about architecture. To achieve SOA, you must
      > rearchitect your systems. You must remove the deadwood. Every
      > organization has too much stuff -- too many redundant applications
      and
      > data sources. SOA is about cleaning house. You will not simplify
      your
      > environment, reduce costs, and gain agility until you reduce that
      > redundancy."
      >
      > We have 17 messages in the thread so far, and our debate was picked
      up
      > yesterday by Loraine Lawson at ITBusinessEdge. Loraine admonished us
      > for our "boil the ocean" perspective of SOA. As many SOA case
      studies
      > indicate, "SOA" works well for integration. I put "SOA" into quotes,
      > though, because I assert that these integration case studies are not
      > examples of service oriented architecture (SOA). The are examples of
      > service oriented integration (SOI). i.e., they are examples of
      > projects that used service oriented protocols (e.g., WS-*) and
      > middleware (e.g., ESB) to integrate two or more application systems.
      > But from an architectural perspective, you still have monolithic
      > systems bridged by integration middleware.
      >
      > Maybe I'm just being pedantic, but I think it's important to
      > distinguish between integration and architectural activities. It's
      > fine to use service oriented middleware to implement integration
      > projects, but then you need to readjust your expectations. Most
      > organizations that I speak with say that the goals of their SOA
      > initiative are to reduce costs and increase agility. Unfortunately,
      > these organizations aren't likely to achieve these goals if their
      > projects only focus on integration. (Also see Chris Haddad's
      > perspective on these success stories.)
      >
      > In the research that Chris and I conducted last year, we found only
      > four companies that had achieved real success in their SOA
      initiatives
      > -- i.e., they met their goals to reduce costs and increase agility.
      > Their successes were astounding, and they delivered positive returns
      > on investment in less than 12 months. In all cases these companies
      > focused on architecture -- not integration.
      >
      > Service oriented architecture is hard work. It's disruptive. It's a
      > political minefield. It involves going through the application
      > portfolio and identifying redundant applications that can be
      > decommissioned and replaced by a single service. But no one ever
      wants
      > to open that can of worms. Many folks live by the adage, "If it
      ain't
      > broke, don't fix it." There's way too much other stuff to do. But
      each
      > additional application increases the annual maintenance and
      operations
      > budget. And for many of those applications, the cost of maintaining
      > the application exceeds the value it brings to the business. It's
      just
      > good business sense to eliminant some of that redundancy. And by the
      > way, the CFO is going to be looking to reduce the IT M&O budget this
      > year. There is no better time to start an application
      rationalization
      > effort.>>
      >
      > You can find it at:
      >
      > http://apsblog. burtongroup. com/
      >
      > together with a photo of Anne looking very canny!!
      >
      > Gervas
      >
      > --- In service-orientated- architecture@ yahoogroups. com, "Steve
      Jones"
      > <jones.steveg@ > wrote:
      > >
      > > Not really, the argument appears to be more about what is
      integration,
      > > for instance whether process and choreography count as
      integration
      > > and whether more dynamic interaction models count as integration.
      > >
      > > I think that most people on this list agree that SOA is
      > > _predominately_ a governance/organisa tional/business/ thinking
      thing,
      > > but that there are SOA _technologies_ which are related directly
      to
      > > implementation. One of the on going challenges in this group is
      the
      > > two different worlds of SOA.
      > >
      > > Far from being vacuous that is in fact the biggest and oldest
      > > challenge of IT and the point of SOA is that it can have the
      > > discussion on both sides but its failing is that it still hasn't
      made
      > > the difference clear.
      > >
      > > Define integration in a tight and specific way.
      > >
      > > Steve
      > >
      > >
      > >
      > > 2008/12/20 Nick Gall <nick.gall@> :
      > > > Doesn't the suspicion that SOA is vacuous grow stronger when
      you see
      > > > that we can't even agree about the relationship of SOA and
      > > > integration?
      > > >
      > > >
      > >
      >

    • Michael Poulin
      So information about governance is more important than information about service design and development? Hmmm. Not exactly, Rob, more accurately - not
      Message 117 of 117 , Jan 3, 2009
      View Source
      • 0 Attachment
        "So information about governance is more important than information about service design and development? Hmmm." Not exactly, Rob, more accurately - not 'about' governance but about 'how' the governance regulates development process and enforces the good practices of the development. For example, if someone uses SOAUI for SOA service testing and declares that services have been tested, the SOA Governance has to have a policy saying - no, pal, you have not tested SOA service but only SOAP communication; your job is not done yet!.. Now, the manager has to enforce such policy and follow up with the developers (based on the policy) till proper testing complete.

        ""Governance" is the latest fad word that was previously covered in large part by "management. " " - covered in the sense of enforcement, yes. However (IMO), it was up to individual manager what to enforce. As a result, the quality and architectural integrity was usually sacrificed for the sake of 'simplify', resource 'problems', 'minimal' risks and other managerial excuses for keeping the development under not technically qualified (in many cases) directions.

        As you see, when talking about SOA governance, I want to give Architects more power to influence proper solution implementations, I want Architects to allow producing the 'law' while keeping management in its regular role of managing/enforcing the laws.

        - Michael



        From: Rob Eamon <reamon@...>
        To: service-orientated-architecture@yahoogroups.com
        Sent: Wednesday, December 31, 2008 12:43:58 AM
        Subject: [service-orientated-architecture] Re: Yefim Natis is sure that "SOA is integration"

        --- In service-orientated- architecture@ yahoogroups. com, Michael
        Poulin <m3poulin@.. .> wrote:

        >
        > Yes, we have to stop bullsh!t ourselves hoping that "presentations
        > on services" can ever work instead of Governance.

        So information about governance is more important than information
        about service design and development? Hmmm.

        >
        > Governance is the thing which defines "what constitutes a good
        > service, how many interfaces are too many, managing the
        > relationship between interface definition and service
        > implementation, etc"

        I'm with Jeff, that's design or architecture. "Governance" is the
        latest fad word that was previously covered in large part
        by "management. "

        -Rob


      Your message has been successfully submitted and would be delivered to recipients shortly.