BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Solving SOA Problems by Merging It with WOA

Solving SOA Problems by Merging It with WOA

This item in japanese

Bookmarks

In his rescent article, Dion Hinchcliffe assesses the direction of Enterprise architecture and SOA in particular. He notes the following trends:

  • Modern software architecture, with SOA as the top-level organizing principle, seems to have more and more trouble keeping up with the rate of change in most organizations... There's a growing sense that the business is "pulling away" and despite enterprise architecture and SOA being intentionally proactive, the default stance is one of short-term reactive response and trying to "clean up afterward"...
  • Consumption of SOA and service-based IT is still too low... The early "field of dreams" approach to services... finally morphed... in many organizations into more mature services landscapes with some actual governance. But now we see that the subsequent complexity, rarefied skills and tools, and additional constraints ended up stamping out a lot of SOA consumption at the edge... Without consumption and uptake, SOA cannot access the "return" in ROI...
  • The focus on SOA still tends to be on the [over]engineering of seams and processes instead of removing constraints on the business and increasing ready access to value... Despite heavy investments in IT for 30 years and the openness and interoperability intents of SOA, the majority of our enterprise data remains submerged and inaccessible to most business users, silos are still prevalent, and there still lacks the human dimension...

In Dion’s opinion, the main reasons for these SOA shortcomings can be attributed to three main problems:

 

  • Project/product oriented focus of SOA implementations.
  • Concentration more on the technology than on the enterprise nature of SOA.
  • The fact that SOA progress is driven more by the standard bodies than by the real implementations.

He suggests that:

...the openness and visibility of today's modern Web seems to provide living examples of what's effective at driving forward business results with SOA. By this I mean when it addresses the key issues around improving the response to opportunities and directly enabling self-service, all while remaining highly scalable and protecting users and data... Web-Oriented Architecture (WOA)... [is] a parallel "track" for SOA that's evolved organically in the wilds of the online world to meet many of the same challenges that we have in our organizations today.

Dion explains that

Key to the story of WOA is that at least one critical feedback loop is present in online businesses that is much less evident in most SOA efforts today: Their business will fundamentally thrive or die based on the adoption of their services. Most new online businesses offer an API (the Web version of SOA) at the very outset these days and it's now common for the services themselves -- instead of the visual Web pages -- to be the dominant point of usage early on... This is a yardstick that would change a lot of what we focus on in SOA.

Despite the fact that there is quite a few differences between SOA and WOA, Dion sees many service-based approaches being emerged naturally in WOA that can be leveraged to improve business performance of SOA:

  • Responding to change faster. Reducing execution chokepoints by making SOA more self-service (running your SOA like a business) by broader audiences in the organization.
  • Increasing consumption. Using new service delivery models that make SOA the easiest, cheapest, and fastest way to solve problems.
  • Actively enabling access to value. Opening up broad access to data and people using models such as deeply linked REST-based data webs and open supply chains. Adopt browser-based approaches to consumption such as enterprise mashups tools and user distributable widgets that project the SOA across the organization.

Dion concludes his article by stating that:

The bottom line: Since many of the very best examples of SOA that works are the models we seeing being proven out in large scale on the Web, we must learn as much as we can from them (and the price is right, even the most compelling lessons here are free.) While enterprise SOA will never be identical to Internet-based WOA, we can borrow the best ideas from the success stories that have emerged on the Global SOA (which is what I call the service-enabled side of the Internet)...

Dion seems to be spot on in defining current issues (and their origin) of SOA implementations. Whether his solution - merging WOA with SOA - will solve them remains to be seen.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Why would these issues be different with WOA?

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Why would the issues that Dion presents be different with WOA? When Google changes its API, people must adapt and Google never really sees this cost show up on its income statement. When you change a service internally, everybody screams because they don't have the budget to get adapt to this new service.

    None of the issues presented by Dion are technology dependent. Suboptimal programming models certainly don't help resolving them. Versioning does, but WOA/REST has no versioning strategy in sight because there is nothing to version. You change something and most likely, everything breaks. The fact that REST coupls access and identity will actually make Dion's issues quite worse in a WOA world.

    We were within reach of delivering a decent programming model, that could have resolved all this, but no, the industry had to go all the way back to CRUD their way up.

    Until people will show precisely how they build entire information systems in a RESTful way and how they resolve these issues, this will only remain some pump and dump analyst talk.

  • Good, but not quite right

    by William Martinez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hello.
    Ok, things I do agree with:
    1. Totally agree with

    The focus on SOA still tends to be on the [over]engineering of seams and processes instead of removing constraints on the business and increasing ready access to value

    2. Also, in the two first causes pointed out, namely the product/project orientation and concentration in technology.

    Now, what I disagree with.
    1. Third cause: I feel it is not the standards driving SOA, but actually implementations! All the way around. Actual implementations are wrong, too RPC driven, IT domain modeled. No wonder business cannot make it there!

    2. WOA as an example of improved response, self-service and high scalability, business side. That is not correct, simply because the web oriented apps tend to be wrongly modeled too! Internal domain model exposed, CRUD through HTTP, Database transactions over HTTP, all those are examples of proposals for web enterprise applications. Tell me if those are not IT oriented instead of business oriented. Problem is always the same: IT people think naming the variables with some business domain concept names will make that business usable, well not.

    Now, WOA success examples are mashups. The composability concept I do defend as a business driver. To make that, we should allow IT to support services transparently, with no IT concept surfacing. Now, we have mashups, but no business people can do them! They will need experts in Javascript, embedding, Ajax, RIAs, etc to make them work. So, we are not there yet.

    3. Examples of SOA I see working are not in the web. They lack the IT invisibility, technology independency that is key for composability and business use.

    What it is valuable in Dion's research and proposal is the business driven idea. But sadly, actual WOA implementation, as Jean-Jacques mentions in his post, is not different from SOA, so it is not of help for improvement to check implementation.

    BTW, for Jean-Jacques: it is not Suboptimal programming the problem, but Suboptimal understanding of the goal, leading to Suboptimal modeling.

    Regards.

    William Martinez Pomares

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT