Archive

Posts Tagged ‘process’

What are the Unanticipated consequences of the cloud – part II

October 29, 2009 9 comments

As I was pointing out yesterday, there are many unintended consequences from any emerging technology platform — the cloud will be no exception. So, here are my next three picks for unintended consequences from the evolution of cloud computing:

4. The cloud will disrupt traditional computing sales models. I think that Larry Ellison is right to rant about Cloud Computing. He is clearly aware that if cloud computing becomes the preferred way for customers to purchase software the traditional model of paying maintenance on applications will change dramatically.  Clearly,  vendors can simply roll in the maintenance stream into the per user per month pricing. However, as I pointed out in Part I, prices will inevitably go down as competition for customers expands. There there will come a time when the vast sums of money collected to maintain software versions will seem a bit old fashioned. old fashioned wagonIn fact, that will be one of the most important unintended consequences and will have a very disruptive effect on the economic models of computing. It has the potential to change the power dynamics of the entire hardware and software industries.The winners will be the customers and smart vendors who figure out how to make money without direct maintenance revenue. Like every other unintended consequence there will be new models emerging that will emerge that will make some really cleaver vendors very successful. But don’t ask me what they are. It is just too early to know.

5. The market for managing cloud services will boom. While service management vendors do pretty well today managing data center based systems, the cloud environment will make these vendors king of the hill.  Think about it like this. You are a company that is moving to the cloud. You have seven different software as a service offerings from seven different vendors. You also have a small private cloud that you use to provision critical customer data. You also use a public cloud for some large scale testing. In addition, any new software development is done with a public cloud and then moved into the private cloud when it is completed. Existing workloads like ERP systems and legacy systems of record remain in the data center. All of these components put together are the enterprise computing environment. So, what is the service level of this composite environment? How do you ensure that you are compliant across these environment? Can you ensure security and performance standards? A new generation of products and maybe a new generation of vendors will rake in a lot of cash solving this one. cash-wad

6. What will processes look like in the cloud. Like data, processes will have to be decoupled from the applications that they are an integral part of the applications of record. Now I don’t expect that we will rip processes out of every system of record. In fact, static systems such as ERP, HR, etc. will have tightly integrated processes. However, the dynamic processes that need to change as the business changes will have to be designed without these constraints. They will become trusted processes — sort of like business services that are codified but can be reconfigured when the business model changes.  This will probably happen anyway with the emergence of Service Oriented Architectures. However, with the flexibility of cloud environment, this trend will accelerate. The need to have independent process and process models may have the potential of creating a brand new market.

I am happy to add more unintended consequences to my top six. Send me your comments and we can start a part III reflecting your ideas.

Making sense of REST in context with SOA

January 19, 2009 2 comments

I continue to spend a lot of time thinking and researching REST — REpresentational State Transfer. Yes, REST is a set of architectural guidelines introduced by Roy Fielding in his dissertation where he defined HTTP. While I couldn’t find a link to Fielding’s disseration, I did find a very good blog entry written by Fielding.

Given its origins, REST follows the philosophy of HTTP. In other words, you give everything an ID, you link these services or components together though some standards methods.  These services communicate in a stateless manner.  In addition, these resources can be used in many different contexts.  What is very important about rest is this idea of linking resources based on self-describing interaction where there is no state between requests. Therefore, from a customer perspective it offers the fast, effective model for development that is fundamental to being able to make organizations more fluid and effective.

As part of my research, I had an interesting conversation with Martin Nally,  IBM Rational’s CTO  about REST, its value and its relationship to SOA. From his perspective, REST looks like a data set that is exposed with Internet protocols.  And if you look at the way REST is described in terms of GET, PUT, POST, and DELETE.  In Nally view, REST provides “a simple style of using HTTP if you can look at your problem set as a web of interconnected hyperlinked resources.”  I thought that Nally put it very well, “In the old days we would create a data model with a representation of department, employee, etc. to create the data in a database. Then we would write two styles of applications: one that was basically to conduct simple data based operations (Create, Read, Update, Delete) and a second to type of application that would apply that information to business process — how do you rate a customer’s credit worthiness?”  In other words, it is necessary to intermix web based services that are stateless and can link data together across a distributed computing environment combined with well defined business services that encapsulate business rules and process. In the operational environment based on business services — based on a Service Oriented Architecture — there are many resources provided based on components that require a lot more structuring of process and more overall governance.  For many types of implementations, there needs to be the foundation of technology concepts such as a registry/repository for both management and governance.  There needs to be a transport mechanism for guarenteed transactions.

I think that we need to look at both two world views — REST to support the web, data oriented linkage style with the structured world of  a services and process based approach.  Let’s leave the religious wars to someone else and recognize that there is room in our complicated software world for both.