SOA Governance: An Enterprise View
Michael Poulin explains the necessity for SOA governance to ensure an Enterprise SOA's success, relying on concepts from the OASIS SOA Reference Model and Reference Architecture.
- SOA,
Tracking change and innovation in the enterprise software development community
Posted by Deborah Hartmann on Jun 01, 2006 02:03 PM
We human beings, so often capable of complex thought, paradoxically also long for something often called "simplicity". A well known example of deep reflection on the subject is Thoreau's "Walden", published in 1854, a social critique of the Western World examining aspects of humanity that needed to be either renounced or praised. But this tension is surely as old as man."Simplicity - the art of maximizing the amount of work not done - is essential"But the term is somehow deceptive - surely simplicity should be, well, simple?
"Technical skill is mastery of complexity, while creativity is mastery of simplicity."The Agile approach invites us to consider which of these is necessary at every moment: technical skill or creativity. Each is valuable in its own right, and when well balanced against one another and focused on customer goals, both can contribute to the creation of extraordinary business value.
Agile Metrics Tracking and Mingle Podcast + Transcript
The Agile Business Analyst: Skills and Techniques needed for Agile
Scaling Agile on large teams & Being Agile every day Tracks @ QCon SF Nov 19-21
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
This is true in so many human endeavours, from writing a short story, to making an email concise, to making a software system 'simple'. It's often worth the effort, but it certainly isn't easy.
Take the famous Blaise Pascal quote:
I have made this letter longer, because I have not had the time to make it shorter.
It takes EFFORT to keep things simple. It's easy to cut-n-paste your way to code-hell, it takes effort to identify opportunities for reuse and refactor out common code. At work a lot of what I do is to encapsulate the complexity of something we're trying to do so that the other team members can use what I've done to very simply solve similar problems over and over again.
Take for example XFire. There's a lot going on under the covers, and even understanding it and configuring it is too complex to have to do more than once. But now that it's configured, people on my team can just annotate their classes with an @WebService annotation and the bean will be automatically registered as a web service.
Don't let the term "simplicity" fool you. Simple != Easy.
Take the famous Blaise Pascal quote:
I can definitely sympathize with that. Take InfoQ.com for example, the UI was designed to be as simple as possible, but we had to jump through many hoops to get it that way... Even editorially, I spend a long time trying to write news items in as concise a way as possible, to make them as clear and easy to understand as I can. That takes a LOT of effort.
I have made this letter longer, because I have not had the time to make it shorter.
It takes EFFORT to keep things simple. Don't let the term "simplicity" fool you. Simple != Easy.
Michael Poulin explains the necessity for SOA governance to ensure an Enterprise SOA's success, relying on concepts from the OASIS SOA Reference Model and Reference Architecture.
This article covers setting up a RichFaces portlet using JBoss Portlet Container and JBoss Portlet Bridge, deploying a RichFaces portlet, and RichFaces capabilities.
This article discusses scalability worst pratices including The Golden Hammer, Resource Abuse, Big Ball of Mud, Dependency Management, Timeouts, Hero Pattern, Not Automating, and Monitoring.
Obie Fernandez shares his experience selling consulting services for both Thoughtworks and Hashrocket and give tips how Ruby developers can work with clients.
Jeffries and Hendrickson derive Agile practices from the natural laws of software development. They don't just say "Be Agile!", but they explain why Agile practices make perfect sense.
Jinesh Varia talks about the architecture of one of Amazon's web services called Alexa. Jinesh explains how Amazon has reached scalability, performance and reduced costs for the Alexa service.
David Douglas and Robin Dymond discuss about companies adopting Agile, but don't go all the way, resulting in failure and rejection of it, and predictably having a negative impact on Agile's future.
Kenji Hiranabe talks about Toyota's development process of a new car. Kenji shares his experience meeting Nobuaki Katayama, former Chief Engineer at Toyota, and the lessons he learned from him.
3 comments
Reply