[Source: "ALL I REALLY NEED TO KNOW I LEARNED IN KINDERGARTEN" by Robert Fulghum. See his web site at http://www.robertfulghum.com/ ]
Metaphors are magic. IMO, they help people grok (wikipedia: http://en.wikipedia.org/wiki/Grok) complex subjects and make them understandable. This year, I’m experiencing a right-of-passage as my youngest has entered Kindergarten. That being top of mind, it brought back to me the well-known prose from Robert Fulghum’s “All I Really Need to Know I Learned in Kindergarten”. He made the statement about the message in his book:, “Take any one of those items, (from his list of everything I really need to know I learned in Kindergarten) and extrapolate it into sophisticated adult terms and apply it to your family life or your work or government or your world and it holds true and clear and firm”.
I thought to myself how would this concept apply to the domain of SOA Best Practices? Here’s my attempt to apply the metaphor -- “All I’ll need to know about how to successfully implement SOA is there to be learned in kindergarten. SOA Success is not at the top of the Enterprise Architecture Mountain, but there in the sand pile at school”.
These are the things I learned:
- Share everything – I’ll take a slight derivative of this, “learn to share”. This statement doesn’t mean re-use everything but it does imply that you need to ensure the infrastructure, processes and corporate culture is built to encourage sharing, not penalize those for it. This maps to adopting SOA processes and technologies that deliver visibility, trust, a culture of shared benefit and shared costs and favorable cost models (avoiding “not in my budget”)
- Play fair—Allocate costs accordingly, put in measures to encourage good SOA practices (reporting and dashboards help) and understand the implications of change and how people and culture must change as well to accommodate SOA.
- Don't hit people—Corollary to the above, do not penalize the first SOA project for being over budget. SOA will initially cost more but then the rewards come with subsequent projects when the benefits of agility, trust and potentially re-use kick in. This first project should not be penalized for investing in “good, clean SOA”
- Put things back where you found them – This is a biggie. SOA governance is critical here. We need to avoid rogue services. Services and their associated artifacts should be effectively catalogued and changes should be managed and reflected as such. If you “move” a service (such as redeploy it to a more scalable platform), update the catalog so consumers can find the change. This simple rule will avoid SOA chaos and web sprawl.
- Clean up your own mess—Key to SOA success is measurement, reporting and accountability through a service lifecycle. A successful SOA includes having the capabilities to visualize the SOA in action, proactively monitor and measure service interactions and performance and feed that information back into the SOA catalog or system of record so that changes can be made to “clean up any messes” and ensure SOA health, stability and availability on an on-going basis.
- Don't take things that aren't yours—This comment may first seem to contradict the concept of re-use but I looked at it a different way. A successful SOA is a Governed SOA. Governance allows services to go through a process of understanding how they should be re-used, and who has authorization to re-use services. A successful SOA supports this concept and enables policies to ensure that services are accessed and used in ways that support the business objectives and not endangered by rogue consumption.
- Say you're sorry when you hurt somebody—I interpret this one from a SOA perspective as building into the SOA process the ability to apply governance at all stages of the SOA lifecycle and to be able to proactively manage when services fall out of compliance. You cannot determine whether a SOA action is helpful or harmful without comprehensive governance across the lifecycle. .
- When you go out in the world, watch out for traffic, hold hands and stick together—And when you go out into the SOA world, set yourself up for success. Ensure that core to your SOA effort is management and visibility (watch for traffic), Ensure that your processes and organization are designed to “hold SOA hands”, in other words, encourage the creation of shared services and all the implications of that (shared costs, upfront complexity for downstream benefit, participation in the governance process). And finally, align business and IT across the SOA goals (stick together) and this is worth another blog…. .
Successful SOA is more than just creating and integrating standards-based services. It requires organizational and process changes to support sharing of code, costs, and information. It requires effective governance to ensure that services are compliant to corporate and IT objectives, services are visible for re-use and services can be trusted. It requires management to ensure that the in-production SOA results map to customer SLA and SLO expectations regardless of how the landscape changes, and it requires alignment of the business and IT towards common goals and expectations so that the SOA effort pays off in business terms now and in the future to become “not just another IT experiment” but truly an element of strategic business transformation. More on that in another “Emo’s SOA World”.
Information disclosed in this community becomes public.
Exercise caution when deciding to disclose your personal information.
HP reserves the right, but is not obligated to, edit or remove your comment if it contains personally identifiable information or other content HP deems unacceptable.
Opinions expressed are your personal opinions or those of the original authors, and not of HP.
Please see HP's web Terms of Use for more details.