Discussions

News: Web services to offload integration from professional services

  1. A new research report from ZapThink claims that as service oriented architectures using Web services become dominant, consulting firms will be doing less system integration and more architectural consulting and business process automation. Integration revenue for consultants will drop over 70% by 2010, while Service-Oriented Business Process consulting will increase 20-fold in the same time period.

    Web services will enable software to integrate out of the box, leaving consultants to add value elsewhere, ZapThink said.

    Checkout the Service-Oriented Consulting: Facilitating the Service-Oriented Enterprise study summary.

    Read Web services to offload integration from professional services.

    This all sounds kind of utopian to me. :).


    Key Findings of the study:

     - Today’s professional services firms are struggling to find their long-term value proposition in environments that are in constant change. There is a significant opportunity for PSOs in the short-term for helping companies implement and adopt SOAs, and in the long-term for providing critical business process expertise.

     - As Service-oriented process tools mature, system integration will no longer be a separate activity, but will be subsumed into the process orchestration and choreography activities within the Service-oriented process tools.

     - The business process design, optimization, and execution consulting market will come to displace the system integration market.

     - System integrators will find the low-level integration work diminishing as their customers adopt SOAs, and therefore will need to transition their skills to the Service-oriented process arena to avoid having their market erode substantially.

     - There is a significant opportunity for consulting firms in the next five years for helping companies implement and adopt SOAs, and in the long-term for providing critical business process expertise.

     - Total SOA architectural and process consulting revenues will surpass those from system integration by 2006.

     - System integration revenue by professional services organizations will decrease by over 70% by 2010, while Service-Oriented Business Process consulting will increase 20-fold in the same time period.

    Threaded Messages (16)

  2. This all sounds kind of utopian to me. :).


    No kiddng. I think I heard the same hoopla when Client/Server, DCOM, NetPC, ThinClient, CORBA, EJBs, and WebServices came out.

    Expert high-end systems with ultimate flexibility will always require experts that know how to use and eploit those flexible features.

    I wonder which one of ZapThink's buddies is selling pre-packaged applications. :)
  3. Utopian - FIght the good fight[ Go to top ]

    This all sounds kind of utopian to me. :).

    >
    > No kiddng. I think I heard the same hoopla when Client/Server, DCOM, NetPC, ThinClient, CORBA, EJBs, and WebServices came out.
    >
    > Expert high-end systems with ultimate flexibility will always require experts that know how to use and eploit those flexible features.
    >
    > I wonder which one of ZapThink's buddies is selling pre-packaged applications. :)

    ChannelWave is. The founder of ZapThink was also a founder of ChannelWave, which, incidentally, sells prepackaged CRM-lite app. Go figure ;)
  4. <quote>
    Today’s professional services firms are struggling to find their long-term value proposition in environments that are in constant change. There is a significant opportunity for PSOs in the short-term for helping companies implement and adopt SOAs, and in the long-term for providing critical business process expertise.
    </quote>

    I see a big opportunity for technically savvy consulting firms in the short term in applying Web services standards, such as BPEL, to solve integration problems without resorting to use of proprietary point-to-point EAI technologies.

    In the longer term, consultants can capture their vertical industry process knowledge directly using the BPEL standard and package it for deployment on a customer's readily-available Web services infrastructure.

    Doron\
  5. Why not support them all[ Go to top ]

    I don't believe in BPEL as a standard. I think BPEL is one of the specifications in the BPM-area like XPDL (WfMC), ebXML (UN/CEFACT,OASIS), WSCI (Intalio,Sun,SAP,BEA), BPML (bpmi.org) , Rosettanet, petrinets, ...

    I believe the approach should be to build a BPM-runtime system that is able to support all these specification. This approach is taken by JSR207 : "Process Definition for Java" and the open source project java Business process management (jBpm) If I were a "savvy consultancy firm" I'ld certainly look at those two :-)

    Regards,
    Tom Baeyens
    Founder of jBpm
  6. Tom, I agree with you, I don't believe in BPEL as a standard too.
    Moreover, I don't believe in XML based flow languages :-)
    We already have an excellent flow language called Java.
    XML is good for process interface definitions but not as programming language. The problem is that we cannot use Java as it is to implement workflow patterns.
    We in Velare have developed framework called ATCT that makes possible asynchronous method invocations in Java. It allows you to stop, serialize and resume deserialized Java execution process.
    Using ATCT developers can implement any kind of workflow patter in pure Java using OOP.
    You can read this article to get idea how ATCT can be used for asynchronous process development.

    Serguei Mouarchov
    www.velare.com
  7. dissing BPEL?[ Go to top ]

    Serguei: Tom, I agree with you, I don't believe in BPEL as a standard too.

    "Collaxa Jill" won't like to hear that.

    Have you used BPEL?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  8. dissing BPEL?[ Go to top ]

    Cameron, do you mean Collaxa's product or WSBPEL aka BPEL4WS created by Microsoft, IBM and BEA? :-)
    I played with Collaxa server and I really didn't like their way of processing Java source. It completely removes power of Java for flow definition. Even simple process definition creates huge jar files.
    It uses proprietary tags for to define flow instead of standard Java syntax. I can understand using this technique in JSPs to simplify HTML output but it's absolutely no sense in case of flow definition when we have all richness of Java that was created exactly for this.

    To be honest I don't believe in magic of visual programming (except GUI) and I don't believe in programming in XML dialects such as WSBPEL.
    I think all we need for real B2B integration is a simple XML based language for message exchange pattern between partners. I would call it Dialog Definition Language.
    It really doesn't matter how each partner processes its messages. As process developer I'm interested in conversation rules only. If I have such rules I can create my process using any language and any programming environment.
    I think that it's possible to create simple processes using WSBPEL but it will fail in case of complex distributed conversations involving hundreds or even tens of partners when process should be active for months and years.

    Serguei Mourachov
    www.velare.com
  9. dissing BPEL?[ Go to top ]

    Serguei: do you mean Collaxa's product or WSBPEL aka BPEL4WS created by Microsoft, IBM and BEA? :-)

    I haven't yet had a chance to look at any of the BPEL4WS products or specifications. (I think you can safely say that falling behind on keeping up with specifications is a full-time job now. ;-) I haven't had a chance to look at any of Velare's offerings either.

    [Collaxa server] completely removes power of Java for flow definition.

    Obviously though there is nothing you can do in XML that is converted to Java that you can't do in Java itself. And since it's a "standardized" way of doing things, one would expect BPEL4WS to address a common set of approaches, not all approaches. In cases that BPEL4WS isn't sufficient, is there an elegant way to drop down to Java code?

    Even simple process definition creates huge jar files.

    Depending on what "huge" is, this one doesn't scare me too much. The real question is always going to be "can it get the job done?"

    To be honest I don't believe in magic of visual programming (except GUI) and I don't believe in programming in XML dialects such as WSBPEL.

    Programming directly in XML is a definitely no-go, that's for certain.

    Visual tools do have their benefits, so don't knock them too much. Their overuse for problems that have simpler solutions may lead to huge problems, but likewise the overuse of "coding" when there are tools available can lead to just as many failures. I strongly believe that on a large project, everything you have to maintain (including code) becomes a liability. Visual tools can decrease that liability immensely for certain parts of the application.

    It really doesn't matter how each partner processes its messages. As process developer I'm interested in conversation rules only. If I have such rules I can create my process using any language and any programming environment.

    I agree with that. Isn't BPEL4WS designed to address the "implementation" side? Or is it supposed to also address the conversation side itself?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  10. dissing BPEL?[ Go to top ]

    Cameron: I think you can safely say that falling behind on keeping up with specifications is a full-time job now. ;-)

    Right, and in many cases we have premature standardization based on marketing, not technical decisions, and BPEL4WS falls in this category, IMHO.
     
    Cameron: In cases that BPEL4WS isn't sufficient, is there an elegant way to drop down to Java code?

    Well, you always can call webservice written in Java :-), I couldn't find description of possibility of direct calls in the spec, but I'm sure BPEL vendors will provide such functionality. But you will no not be allowed to use full power of Java or any other language for flow definition!!!

    Cameron: Depending on what "huge" is, this one doesn't scare me too much. The real question is always going to be "can it get the job done?"

    To be honest, my impressions about Collaxa's product can be more accurately expressed the other way: I don't think that approach they use combining Java and BPEL is elegant enough, size of jar file is just one of consequences of this approach.

    Cameron: Visual tools do have their benefits, so don't knock them too much.

    In case of BPEL4WS we don't have an alternative for process development: or you have to use visual tools or you work directly with raw XML. There is no human friendly textual representation of your process flow at all. Can you imagine if you want to use CVS (or any other version control system) to handle such files, analyze diffs etc. Obviously, it's possible to create new type of tools, training programs, write hundreds of books, convince companies that this is standard solution and they have to pay for it. Using Java or other languages for flow programming in existing IDEs and modeling tools can help to reuse development skills and save lots of money.

    Cameron: Isn't BPEL4WS designed to address the "implementation" side?
    That's right, it's called executable processes.

    Cameron: Or is it supposed to also address the conversation side itself?
    BPEL4WS introduces something called abstract process that is pretending to handle conversation rules. But I don't see how it can be used to build partner processes, and even people from BEA (that is one of BPEL4WS creators) understand these limitations.

    My point is that BPEL4WS pretend to be standard execution language using ugly XML syntax and at the same time as we have excellent standard (C# ;-) or widely used languages (Java, VB) that were created for the same purpose: program execution flow. We have tons of tools including visual that help us in the development process.
    IMHO BPEL4WS is just another case of unnecessary standard and product created exclusively to make more money for its proponents.

    Serguei Mourachov
    www.velare.com
  11. Integration Products are becoming J2EE compliant (See Beyond Ver5 for example). They can be installed in standard J2EE app servers. They also support web services (SOA in turn). EAI deals with reliable messaging, transactions etc. Reliability and Transactions are yet to take off in Web Services. To my knowledge, it is not going be easy as well. For example, HTTPR from IBM is yet to become popular. Legacy applications are not going to die soon. It is hard to make them service orentied and is easier to do integration.
  12. dissing BPEL?[ Go to top ]

    <quote>
    I think that it's possible to create simple processes using WSBPEL but it will fail in case of complex distributed conversations involving hundreds or even tens of partners when process should be active for months and years.
    </quote>

    I believe BPEL is warranted somewhat deeper exploration before such far-reaching conclusions about its potential and applicability are made. There are currently more than a few serious prototyping efforts under way with BPEL in both EAI and B2B domains. We have put together a BPEL Boot Camp National Tour in order to educate developers and share information about some of these BPEL projects. At any rate, a good way to start and get a feel for what's possible with BPEL is checking out these BPEL samples.

    Doron.

    CTO, Collaxa.
  13. Serguei,

    If you do not like the JBPEL abstraction, you should instead implement your flows in raw XML.

    There are 2 important points here that are lost in your message:
    - But implementing their business processes in BPEL, customer have the choice to select Collaxa, MSFT, IBM or any other vendor supporting the spec. You are not locked in!

    - BPEL is not competing with Java. BPEL is a language optimized for the orchestration of asynchronous interactions into long-running business flows: asynchronous receive, correlation, XML data manipulation, parallel flows, compensation/undo, visualization, scope serialization are examples of features optimized in BPEL.

    If you want to bash BPEL for its lack of flexibility, please come up with an example...We are in a technical community here and "complex distributed conversations" is not enough to win an argument!

    Finally, it is OK if you do not like our product because you are a competitor, but I would expect you to find a better argument than the size of the jars are large :-)

    Edwin
    Collaxa Inc.
  14. SOA it is not...[ Go to top ]

    I think the term SOA (Service Oriented Architecture) is used to describe something different than what it actually means. Most people still seem to believe, that SOA is about web services or web services orchestration. It is not. It is about *Services* and *Architecture*. This means it is about granularity and (flexible, extensible) contract definition. It is about scope and transaction types (or no transactions at all). It is about passing rather complicated data structures (e.g. XML documents). But SOA is not tied to any particular technology. It can be done using MQSeries, Java RMI, SOAP, Corba or SUN RPC. And as long as it is not used "B2B" it really doesn't matter. And processes as well can be orchestrated with Java, Tcl, Python or any vendors (or standard bodies) tools and languages. The Service is what's the heart of the matter, not its integration. In an ideal SOA, integration and orchestration are, in fact, "for free".
  15. Service Oriented Architecture[ Go to top ]

    Karl,

    Are there any good articles or books on the topic of SOA? The ones that I have found so far are vendor-oriented and do not explain the concepts in a vendor/technology-agnostic manner. Thanks in advance.

    - arafiq
  16. As far as I know[ Go to top ]

    there are none that I know of. However, there were one or two books anounce that claim to do the job (Something like the "Managers Guide to service architecture"), but I did not have a chance to look at them until now. There are a number of books on software components and web services that are useful, but they are not really to the point.
  17. Service Oriented Architecture[ Go to top ]

    There’s quite a good high-level overview on SOA article here:
    http://eaijournal.com/article.asp?ArticleID=474&DepartmentID=9