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.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Mark Little on Aug 28, 2008
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?
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.
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.
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.
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?
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.
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.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
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.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
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.
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?
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.
4 comments
Watch Thread Reply