All:
Found content: http://www.computerworld.com/managementtopics/management/story/0,10801,110436,00.html?source=NLT_APP&nid=110436
My take:
Hard to tell whether we’re twisting the concept of “governance” beyond its natural breaking point…but here I’m testing the tensile strength of the concept in yet another context.
Governance is control, implemented by hook or crook, proactively and/or reactively. The referenced article--“Why achieving SOA quality can be so difficult” by Shridhar Mittal--is an excellent discussion of software QA challenges in the “composite…distributed…heterogeneous….dynamic” SOA world. Here’s the graf that jumped out at me: “Application quality is fast becoming the primary governor for achieving companywide SOA success and deployment. With so many interconnected parts making up applications that can be delivered virtually anywhere, testing no longer becomes a mere matter of finding bugs within the developer's code or problems that occur on a given user interface. Software quality processes must evolve with the architecture to genuinely test a business process and maintain context across the entire workflow.”
Governor…governance….hmmmm. In the previous post, I implicitly defined governance as “different control structures on human interactions, some of which emerge from the confusion of decentralized self-interested interactions … and some of which are imposed by very visible iron hands.” Perhaps I should generalize this discussion to refer to “control structures on human and automated interactions, some of which emerge from the blur of decentralized, autonomous decision agents, and some of which are imposed by centralized authorities.” Yeah…that’s the ticket.
Governance is often event-driven: you see an exception condition (such as a software glitch or DDoS) in development or operations, and you implement a remediation and/or enforcement action to address it. In my discussions with the industry, everybody keeps bringing up the following lifecycle of SOA governance activities: design-time, deploy-time, run-time, change-time (or optimize-time, which is essentially a return to design-time, but incorporating SOA operational metrics from run-time into tweaking the production SOA).
Ideally, QA should be an activity that transcends all of these “times.” You should look for glitches and bugs continually—in development, when the software is being deployed, and in normal operations—and address it continually, sometimes fixing it on the fly, sometimes decommissioning a software component so that it can be fixed “out-of-band” while you implement a workaround. Your SOA governance toolset (i.e., Web services management in operations + visual design and policy administration tools in development shop) should provide you with the ability to test for, detect, and fix these issues at any “time.”
SOA governance involves continuous interaction testing that permeates the entire environment at all “times.” As the article states: “Comprehensive regression testing and runtime monitoring across this distributed environment is critical to maintain the integrity of the application….When teams truly collaborate and continuously automate tests against every layer of the SOA, companies can more reliably wrest value from today's complex, service-oriented business software.”
QA-driven SOA governance, then, is both an automated background activity and a very human collaboration operation that never sleeps.
Jim
