Design-time governance killed in the cloud?

Design-time governance killed in the cloud?

Summary: An emerging debate over the value of design-time governance of services in the cloud computing era

SHARE:

Will the cloud computing paradigm kill off design-time service governance as a separate practice?

How badly do we need design-time governance in the cloud era?

Dave Linthicum recently posted his predictions on technology areas cloud computing may eventually kill off, and one of them is design-time service governance, a lynchpin of many 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.

However, some others beg to differ with Dave's assessment. Jeff Papows, for one, believes "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?"

In the SOA world, 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.

Readers, let's hear your views on the subject. How badly do we need design-time governance in the cloud era?

Topics: Enterprise Software, Browser, Cloud, Hardware, Software, Software Development, Virtualization

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

8 comments
Log in or register to join the discussion
  • Design-what?

    Umm - a bit too much business language, it seems.
    Not too familiar with "Design-time governance."

    It does, however, sound a bit too much like things
    are going the way of too much overhead?
    CobraA1
  • Jeff Papows doesn't make sense

    The quote you show from Jeff Papows appears to contradict itself. He says:

    "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."

    If you don't even know by whom and where those services have been designed, then how on earth are you going to do design-time governance?!! Sounds like run-time governance to me!

    I hope that what he is trying to say is that building in governance and instrumentation at design time is something those who provide services should take very seriously, which is fair enough.

    However 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.

    Meanwhile, those who consume services have no choice but to concentrate on run-time governance, since they cannot rely on being able to specify their governance needs at design-time if they'll be consuming services over which they have no ownership.
    phil wainewright
  • Design-Time is not Build-Time and Governance is Just Nannying

    Joe,

    Your post reflects everything that's wrong with business-as-usual IT. 'Design-Time' is not coding - that's 'Build-Time'. 'Governance' is something that a nanny does - e.g. nannying your babies, your children and, oh yes, your employees. The cloud is no different to on-premise computing, if IT continues to confuse 'Design-Time' with 'Build-Time' and, of course, Runtime' is all about SLAs, uptime, etc.

    By confusing 'Build-Time' for 'Design-Time', left-brained IT people forget that it's User Experience Design and Interaction Design by right-brained people that should be the beginning and end of successful IT app deployment - cloud or not.
    XceliantBear
  • RE: Design-time governance killed in the cloud?

    Phil gets it.

    I was indeed talking about the fact that in the lifecycle of a service, you indeed don't know where, how or by whom your services are going to be consumed until you've deployed them. Thus, how do you design the governance ahead of time? The logic is flawed.

    Good discussion, but it appears as if my assertions remain sound.

    Dave Linthicum
    DavidLinthicum
  • Cloud does not change the fundamental need for design & run time governance

    I don't follow Dave?s analysis.

    Design-time governance applies to both service
    providers and service consumers. On the provider end,
    it is about building the right services, building
    services the right way and managing change. This does
    not change simply because you are delivering services
    via cloud-based infrastructure. These issues are
    critical even for a SaaS provider who does not know
    where its next customer is going to come from.

    On the consumer end, Design-time governance it is
    about finding the right services and using them
    correctly. Again, these considerations are important
    even when services consumed are delivered via cloud.
    If the services consumed are provided by a SaaS
    vendor, enterprises often have to adapt them before
    use ? example adapting data formats. So in fact,
    design-time governance takes on new dimensions when
    consuming such services.

    Net-net: Cloud does not change the primary reason
    design-time and run-time governance are needed ?
    autonomous parties providing and consuming shared
    services.
    jshah0209
  • Design-time, Run-time - Yeah, you're going to need both!

    My initial reaction to Dave's article was similar to Jeff's -- but when I settled down a little, I saw Dave's argument that the cloud is going to drive run-time governance to the forefront.

    But, to say that the cloud is going to kill design-time governance is a little over the top, too.

    Granted I can't know everything until I get it running, but I do know something about my target consumer's requirements & needs. The cloud's not going to make me throw away all my design-time patterns and practices - surely not.
    Mike Marshall
  • Maybe not killed, but definitely obscured

    I wrote about this on my blog last week: http://kscottmorrison.com/2010/01/07/on-the-death-of-design-time-service-governance/

    In a nutshell: I think what we are seeing is a change in priorities around governance as the clouds roll in.
    KScottMorrison
  • Cloud or not, runtime governance won't make up for a bably designed service

    Badly designed services is a potential source of many types of runtime problems like logic gaps, spreading or redundancy (low reuse), excessive transformation needs (performance), consumer to implementation coupling (broken contract), wrong granularity (communication and processing load) and so on.

    And no runtime policy can fix design flaws.
    jcq@...