Just when the dust seems to have settled from the whole "SOA is Dead" kerfuffle, our own Dave Linthicum throws more cold water on the SOA/cloud party -- with a proclamation that "Design-time Governance is Dead." (Well, not dead yet, but getting there...)
We've been preaching both sides of governance as the vital core of any SOA effort -- and with good reason. Ultimately, as SOA proliferates as a methodology for leveraging business technology, and by extension, services are delivered through the cloud platform, people and organizations will play the roles of both creators and consumers of services. The line between the two are blurring more every day, and both design-time and runtime governance discipline, policies, and tools will be required.
In a post that raised plenty of eyebrows (not to mention eyelids), Dave Linthicum says the rise of the cloud paradigm may eventually kill off the design-time aspect of governance, the lynchpin of SOA-based efforts. As Dave explains it, with cloud computing, it's essential to have runtime service governance in place, in order to enforce service policies during execution. This is becoming a huge need as more organizations tap into cloud formations. "Today SOA is a huge reality as companies ramp up to leverage cloud computing or have an SOA that uses cloud-based services," he says. "Thus, the focus on runtime service execution provides much more value."
Many of the existing runtime SOA governance players support enough design and implementation capabilities that separate design-time tools are not required, Dave adds.
Todd Biske, enterprise architect extraordinaire and author of SOA Governance: The Key to Successful SOA Adoption in Your Organization, recently weighed in on Dave Linthicum's remarks that cloud computing will soon kill design-time governance. Todd says there is an important role for design-time governance in the cloud, but he says his definitions differ from Dave's.
While runtime governance is very important to cloud computing, it's critical to be able to manage services across their entire lifecycles, from the earliest phases of the service contract, Todd says. The issue may be Dave's definition of design-time governance, which is one many in the industry apply -- the "notion that design-time governance is only concerned with service design and development." Todd notes that governance should actually be thought of in three timeframes; "pre-project, project, and runtime." As he explains it:
"There's a lot more that goes on before runtime than design, and these activities still need to be governed. It is true that if you're leveraging an external provider, you don't have any need to govern the development practices. You do, however, still need to govern the processes that led to the decision of what provider to use; The processes that define the service contract between you and the provider, both the functional interface and the non-functional aspects; and the processes executed when you add additional consumers at your organization of externally provided services."
WebLayers' Jeff Papows disagrees with Dave, stating that "nothing could be further from the truth" in terms of the role of design-time governance in the cloud. In fact, if anything, the rise of the cloud computing paradigm calls for greater attention to design-time governance. As Jeff puts it:
"If we cut corners at the beginning of the development process, we will almost always create gaps in the cloud resulting in the proliferation of bad code and applications. If in fact more services are accessed, sometimes anonymously, from God knows where, in fact the quality of those services now destined to be used and reused must in fact of an even higher quality. Sounds like design time governance to me."
The growing utilization of cloud resources brings forward new design governance challenges, Jeff argues." For example, when and how should cloud resources be used, do they support the proper technologies, functionality and performance we expect?"
"I think Dave Linthicum's point was subtler than this. He was saying that, if you don't know where, how or by whom your services are going to be consumed until you've deployed them, then you can't possibly design the governance you'll need in advance. It's only once the service starts running that your monitoring and governance becomes meaningful, as an iterative process that responds to actual, changing usage.
And Layer 7's Scott Morrison points out that Dave's statement is a logical extension of the "SOA is Dead" turn-of-events since January 2009, which calls for a new way of looking at service orientation and service delivery:
"The incendiary nature of is-dead statements often conceal the subtle but important ideas behind them. Dave's declaration is no different. What he's really suggesting is that cloud will rapidly shift the traditional priorities with respect to services governance. In the big SOA era (before Jan 1, 2009), design-time governance was king. It fit nicely into the plan-manage-control discipline underpinning a large enterprise-scale SOA effort. And to support this, tool vendors rushed in and offered up applications to facilitate the process. Run time services governance, in contrast, was often perceived as something you could ignore until later-after all, on-premise IT has reasonably good security and monitoring in place. The technology might be old and the process a little byzantine, but it could tide you over. And if any internal staff were caught accessing services they shouldn't be you could just fire them.
The cloud inverts this priority. If you deploy even one service into the public cloud, you must have runtime service governance in place. That one service needs to be hardened and protected as you would a DMZ-based application. You must have continuous visibility into its operation from the moment you turn it on. Run time governance simply cannot be put off."