Поделиться через

Why SOA?

  • Статья

As the product manager of Shadowfax I am often asked about how Shadowfax relates to service oriented architecture (SOA). I have had many lengthy discussions with others here at Microsoft as we consider how best to help our customers with this new architectural style.

I am convinced that SOA is an architectural style, not a product. You can't go down to the store and buy SOA. You can however build a system according to the principles of SOA. Most people recognize that building a system to SOA principles is in the short run more difficult, costly and time consuming. Especially the first one. Likewise, many people also recognize that this is one of the many cases in life where investing in something difficult up front pays big dividends later. I just spent 90 minutes with my trainer at the gym and worked very hard doing a number of things that have no direct relationship to helping me to get my work done, but I recognize that over time, this is a worthwhile investment in my physical body which will really pay off in the future...no pain, no gain right?

Given that it is more difficult, costly and time consuming, why would people then choose to build a system according to SOA principles? I have spoken with a number of very large organizations and the reasons I hear are usually something like this.

  • We have 1500 applications, 400 frameworks running on 10 different platforms and the TCO is killing us
  • Our application has business logic that would be useful to other divisions within the company but because it was built as a tightly coupled silo, nobody else can access this functionality.
  • We want to build our systems to be highly adaptable, to build with the future in mind

Almost every large organization I have spoken to in the last year is making some move toward SOA and the bottom line for most of them is cost savings. They believe that by making this investment up-front, in the long term they will reap benefits of increased reuse, increased managability and lower costs.

What about you? What is your experience? Have you taken the SOA plunge yet? Do you believe that we will realize these benefits as an industry?

Comments

  • Anonymous
    April 26, 2004
    The comment has been removed
  • Anonymous
    April 27, 2004
    I don't accept your "given" (i.e. it is more difficult, costly and time consuming to build a system to SOA principles) and I think by approaching it that way, you're asking your customers to make a leap of faith which, if we judge by our industry's past performance, strains their credulity. Most large organizations have every reason to be wary of this year's technology fad. If SOA is to be more than a fad, we (the geeks, for lack of a better term) have to deliver real value now, not promises of a better life hereafter.

    What are we comparing SOA to, anyway? Client-server? N-tier? The Big Ball of Mud [1]? If you think SOA is something you add to whatever it is you're currently doing, then, by definition, it's more difficult, costly, and time consuming that what you're doing now. If, on the other hand, SOA is a different way of doing what you're already doing, it could be easier, cheaper, and quicker than what you're doing now. Here's my recipe for easier, cheaper, and quicker software development with SOA:

    1. The right people - If you don't have experience with SOA, get help from folks who've been there and done that. The term may be new, but some of us have been doing this stuff for years.
    2. The right project - SOA isn't appropriate for every project. Pick a project that requires distributed systems, supports a crucial business process, and integrates with existing systems. You'll get an excellent ROI on this project and you'll get all those future benefits.
    3. The right tools - Favor the technologies on your chosen platform that support document-centric, message-oriented development over those that foster RPC style development. For the Microsoft platform, that means MSMQ, InfoPath, BizTalk, XML, and HTTP.
    4. The right attitude - Your whole team needs to understand and buy in to the service oriented approach. Successful software development requires a shared sense of mission.

    Get this stuff right and SOA has immediate benefits.


    [1]http://www.devcentre.org/mud/mudmain.htm
  • Anonymous
    April 27, 2004
    Silly Mr. Parsons. There's a requirement that each new tech wave add a tier!