InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

WOA Governance Is Different To SOA Governance

Posted by Mark Little on Aug 28, 2008

Sections
Architecture & Design,
Enterprise Architecture
Topics
Governance ,
SOA Platforms ,
SOA ,
REST ,
SOA Appliance
Ignoring the fact that it talks about WOA and not REST, in a recent article Dan Foody talks about governance for Web-based architectures.
Some  would argue that it's the complexity of SOA itself (driven by the enterprise top-down focus) that creates the need for a formalized SOA governance initiative.  Without formal SOA governance you can't hope to succeed with SOA because it's too easy to get it wrong.

In his view WOA manages to avoid many of the complexities of SOA, not needing complex tools or the WS-* architecture. (We should assume that Dan knows that many people dislike the assuming that SOA equates to WS-*.) Of course there are those who would argue that REST (aka WOA) is not simple at all when you have to implement complex applications and WS-* is needed, but we should ignore that argument in case it deflects us from Dan's core question: "So do you still need governance for [WOA]?"

The answer is probably yes (if you're an enterprise architect, you can stop holding your breath now).  But, I think the approach to "WOA governance" is going to be fundamentally different than that of SOA governance (OK, time for the EA's to hold their breath again).

And the reason for this? In a traditional SOA you typically have enterprise architects setting the rules that govern the interactions between providers and consumers.

This works fine in an enterprise where everyone ends up reporting to one common person when you look far enough up the chain.

However, in a Web-based architecture in order to get parties to interact you would first have appoint an "Enterprise Architect for the Internet" who would set all of the policies in the same way as before.

Simple really.  Except the part about "appointing an EA for the Internet".  That might be a bit tricky. So, you can see, the top-down approach of SOA governance totally falls down when you look at WOA.

But what will work then? As Dan points out, there are fundamental aspects of governance that any infrastructure needs to solve, whether it is Web-based or SOAP-based. For example:

How can a provider make it easier to on-board customers and keep them happy (all while changing the service frequently)?
How can a consumer establish and build trust in their service provider (that's trust as in "trust but verify")?

Therefore in order to truly be a success WOA needs to achieve many of the same goals that SOA governance hopes to achieve. But as Dan things "... in a fundamentally different way." So does this indicate a missing piece in the REST architecture? Can the right kind of governance be added to WOA without affecting adversely its perceived simplicity?

  • This article is part of a featured topic series on SOA
Governance != Centralization by Stefan Tilkov Posted
Re: Governance != Centralization by Julian Browne Posted
Re: Governance != Centralization by Dan Diephouse Posted
A dark view on " fundamentally different way..." by Michael Poulin Posted
  1. Back to top

    Governance != Centralization

    by Stefan Tilkov

    To me, governance is about defining and enforcing rules in the interest of a better overall result. This seems a good idea regardless of any particular architectural or technical approach.

    What's somewhat contrarian to WOA (hate that term) goals is the idea of having a central authority. But why is this a necessity? I think governance can be de-centralized, and if it is, it works perfectly with a more web-like style.

  2. Back to top

    Re: Governance != Centralization

    by Julian Browne

    That's exactly what I was thinking when I read this. I can see that there are differences in what's needed and in what's done, but not in how it's done.



    Amazon are a good example of this, with their decentralised two-pizza service delivery teams, as described here.

  3. Back to top

    Re: Governance != Centralization

    by Dan Diephouse

    Heartily agree with Stefan here - especially on WOA sucking as a term. :-) Also, started to post some more thoughts, but they turned a little product oriented so I put them up as a blog entry instead.

  4. Back to top

    A dark view on " fundamentally different way..."

    by Michael Poulin

    I do agree with Stefan. However, here are 2 fundamentally different ways possible: 1) having a non-centralised (distributed) Governance; 2) having an anarchy - no Governance at all.

    I suspect that WOA assumes that everything in the Web is like a social or community sites, or it has to be. Let me welcome such believers to deal with, for example, government, financial, pharmaceutical, and healthcare sites AFTER they would be governed like a social/community sites. Interesting, how long they would manage to stay free, healthy, without bankruptcy, and even alive?

Educational Content

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.

Max Protect: Scalability and Caching at ESPN.com

Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.

The Seven Deadly Sins of Enterprise Agile Adoption

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?

Wrap Your SQL Head Around Riak MapReduce

Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.