Sign In

Has the Cloud Killed Design-Time Governance?

Phil Wainewright: Picking up on a prediction from Dave Linthicum, this blog post by Joe McKendrick debates whether design-time governance has any relevance in a cloud computing environment, where services are often consumed from anonymous, third-party sources. Dave's view is that "focus on runtime service execution provides much more value." Joe takes the line that "as SOA proliferates as a methodology for leveraging business technology, and by extension, services are delivered through the cloud platform...both design-time and runtime governance discipline, policies, and tools will be required."

13 Replies

Design-time governance was already dead. As one of the commenters to the original post by Joe McKendrick points out, the term 'design-time' has generally been used to mean 'build-time', which is a lousy time to try and predict governance needs.

A later comment by Dave Linthicum succinctly sums up the stance that we both agree on:

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

It's not the cloud that kills design-time governance, it's the untidiness, instability and unpredictability of the real world. The cloud is merely the catalyst that shows up pre-deterministic software design for the sham that it is, by bringing it into contact with reality.

Design Time is a very vague and misused term when it comes to SOA -I think we should focus more on the life cycle management of an SOA asset to make sense out of it - whether it’s cloud or not. These may be managing policies associated with a service (Security, deprecation, routing, message enrichment), managing its EOL, subscription management, managing its attribution et al.
The concept of Design Time though becomes meaningful in the context of a SOA blue print being rolled out for an enterprise by EA’s or Consultants where you require certain guidelines (consumption and provider patterns) to design services and how to go about defining them.

I recently blogged about why SOA is simply not possible without governance. http://bit.ly/6c9WnI. Cloud does not change the fundamental need for design & run time governance

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. For example - adapting data formats. So in fact, design-time governance takes on new dimensions when consuming such services.

What I believe we are seeing with cloud is a change in our priorities around governance. In classic, on-premise SOA, design-time service governance was nearly always a top priority for architects. Run time service governance was often something that could be delegated to existing process and technology.

In the cloud, these priorities invert. Even a single service needs run time service governance to be in place on the day it's turned on. The cloud brings an urgency to run time governance that can't be ignored.

Will design-time governance actually die because of cloud? Of course not--it has too much of value to offer to be ignored.

If design time means the modeling of services, than it's governance cannot die. Even in cloud environment I would need to model and control my services. From the other hand, services that I consume from others are not subject to my governance anyway. So, I see cloud as a technology issue that does not influence the business modeling.

You know what, maybe one of these days people will build the roof of their houses before they have walls, but I doubt building walls first will be "dead" soon.

So if anyone here feels comfortable not to do design-time governance and move to production without it ... that's your call, just don't be surprised when the roof falls on your head (and by the way, saying Joe told me won't help you either ;)).

If you design you also need to govern what you design. Therefore the question asked could be changed to the following question: Has the Cloud Killed Design-Time? The answer is no. You are designing If you are using the Cloud as Infrastructure as a Service (IaaS) or Platform as a Service (PaaS). Do you need to design if you are using SaaS? yes, you need to. For example, a process could be used as a Service included in a more complex process. Is it possible that a process Service will contain SaaS service as well as in house Data Center service? yes it is.
The location of the service (Cloud or in house) has nothing to do with the need to govern its design.
The fact that Design time Governance tools for the Cloud are not mature does not make Design Time Governance obsolete.

I replied to K. Scott Morrison's post on this, and as I usually state, there's some truth in both sides.

First, there's no doubt that the run-time governance space is important to cloud computing. Clearly, a service provider needs to have some form of gateway (logical or physical) that requests are channeled through to provide centralized capabilities like security, billing, metering, traffic shaping, etc.

Second, the notion of the cloud "killing" design time governance is simply an attention grabbing headline and nothing more. One issue, however, is the use of the term "design time." Design time isn't the opposite of run-time. There are many activities that occur outside of run-time, design is a subset of them. Governance of the activities that occur outside of run-time is still needed. How is the company deciding what service provider to use? How is the company making sure decisions by multiple groups for similar capabilities are in line with company principles? How is the company making sure that interoperability and security needs are properly addressed, rather than being left at the whim of what the provider dictates? These are all governance issues that do not go away when you switch to IaaS, SaaS, or PaaS. The only thing that goes away is the need to govern development policies of the service implementation, since you're not doing that anymore.

I believe there is a danger in getting fixated on a pre-concieved label. When an Applications organization makes a move to consuming services from the cloud instead of designing them or building them in-house, certainly tasks naturally drop off the plate, whether they are governance tasks or development tasks or documentation tasks, or other. As Todd Biske mentions above "The only thing that goes away is the need to govern development policies of the service implementation, since you're not doing that anymore."

In following that line of reasoning, from a governance perspective, there will be certain governance activities that the Apps organization will no longer be concerned with (and we can argue whether those activities should be labeled "design time" or not but that is probably a waste of energy that could be focused on what we need to do to meet business needs via cloud sourced services)

I also concur with the general theme coming out of the comments above (which I will paraphrase) that chosing to meet application portfolio demand via sourcing and consuming services delivered via the cloud will increase the importance of other activities that can be considered governance. Examples include governance of the business relationship between the cloud service provider and the consuming organization -- broken out into key governance focus areas such as managing and validating delivered quality of service (and what happens if QoS commitments are not met), levels of security and assurance of data privacy, managing process, protocols and time commitments pertaining to change response, and governance of measuring usage and subsequent billing. There are also key governance decisions needed up front in the Applications portfolio planning process around determining what demand requests should qualify as being able tobe fulfilled via a cloud sourced service, what happens if additional demand comes forth for a cloud sourced service from a different business unit or applications group, and how one manages request for changes to the cloud sourced service from the consumer's side, who do they work through to determine if this change means a change in service level from the cloud provider?

All this is to say, application lifecycle governance represents an important set of activities for any application portfolio whether the application functionality is built, composed, or sourced from external or Cloud service providers. It's time to move away from debating what is "design time" or "run time" governance and focus on what we need to govern and how best to do it.

design-time, run-time, build-time, etc... after 20 years working on IT and it's hard to see a consensus/standarization on simple concepts. From a service provider perspective , dt governance is a must regartheless cloud. And what if a service consumer is also consuming third-party services to build composite apps ? bingo! you also need dt governance ...btw when we started to create a wall between dt and rt? I can not remeber it ;-) I always thought that it is about the value of the overall governance processes to your services and apps.