Dan Sholler

Lots of cool stuff about the cloud from all sorts of places.. but one thing strikes me immediately. In the past, the vast majority of our IT investments were either labor, or fixed costs. What cloud is really doing, is injecting a variable cost component into this. I personally believe that this shift is the most significant part of all of the discussion we have had on SOA(subscription required)  and cloud computing (subscription required) , and will create a lot of pressure to change many of the business practices that have been associated with IT, or that are very IT dependent.  There is a lot more research to figure out how this will happen, but it does seem pretty clear that we need to think about how to take not only IT practices, but all types of business practices on a contingent basis. This does not mean that every operation that the company performs will be based on contingencies, but organizations will focus on how to move these practices into that mode.

This also implies that the economics of those activities will come into question. In many cases, companies have been willing to pay to outsource things based on a similar model to what would happen if the organization performed that activity in house. In a contingency model, we are likely to see more pressure, not only to make things variable and contingent, but base the contingency on measured outcomes. This effect will occur not only in IT but in areas where computing and the web model becomes more important. (e.g. Advertising)

If I can acquire things on a variable cost basis, that allows me to take more risks, since if the thing does not work out, I can wind down my relationship. Obviously, this may not happen overnight, but it is a lot less risky than acquiring the things myself, and owning them for the next decade or so.

I have to think that this will change many decision making parameters about IT. I would love to hear your view on what might change, or what is changing in your world.

In a surprising shift, the founder and longtime CEO of Progress software Joe Alsop is leaving the company (see the press release) Rick Reidy, the new CEO has been a longtime employee who started with Progress in 1985. However, this change at the top might signal a change in direction for the company, which historically has focused on being a technology provider and selling through an indirect channel. While this is still a strong business for Progress, the growth is coming in enterprise software that is sold directly to customers. Although Progress has sold products this way for some time, their investments in marketing and customer support have not been as strong as in companies who have focused on a direct sales model. This should require a new approach to the product portfolio, marketing and branding (historically Progress has sold their products with very independent brand identities, such as Sonic and DataDirect). The question of whether this increased investment will have an impact on earnings in what will likely be a down year for everyone is interesting. Under Joe Alsop, Progress has been a very steady performer. It will also be interesting to see whether, in this age of consolidation of software, whether an independent player with a number of extensions to the software platform can continue to thrive.

Gartner customers who would like more info on Progress can find lots of research on the Gartner site, including  the analysis of their recent analyst day , and our recent report on the middleware market that is part of the Market Share: All Enterprise Software Markets, Worldwide, 2007  .

The final analysis of our 2008 survey (which concluded in December) shows us that SOA is clearly delivering value in many organizations.  (See Survey Update: The Value of SOA Gartner subscription required). While the impact of SOA on costs was only moderately positive, SOA made significant contributions to the agility of the IT organization, and the ability of IT support business innovation. Organizations were getting positive ROI from SOA projects within 10 months, on average.

However, there were quite a few warning signs as well. Nearly a quarter of organizations did not measure the value of SOA at all, and 40% did not measure ROI. It seems obvious when you say it, but as all organizations are under pressure to do with less, having no way of demonstrating value is likely to lead to budget cuts and project cancellations.

In the end, it was clear that for most, SOA was a positive step for the organization, and it improved efficiency and agility,and translated into cost savings over the lifecycle of the projects.

Curiously, despite all the talk about recession, the stock market, and healthcare reform, the most popular topic around here is still SOA. Like everything else, we have seen our share of organizations who were planning major initiatives around SOA to put those on hold, and some to question the value of them yet again. At the same time the prevailing mode seems to be that that this architecture is becoming a permanent fixture of the IT landscape, and the question is only about how to apply and and over what scope. The team at Gartner has a solid set of research on this under way, and that research is summarized in the recent Key Issues for SOA, EDA and WOA, 2009. note. (Gartner subscription required)  There is a lot more to come, stay tuned.

It is always amazing how something so obvious can become so confusing. Shared services are shared services. SOA is about creating software as shared services. All of the developments around virtualization, and the infrastructure utility (Gartner subscriptions required) are about changing our infrastructure and operations management to shared services… and guess what? Private clouds (or whatever we end up calling them) are about combining the thing that the infrastructure folks are doing with the things  that the app folks are doing.

So the shocking truth is that similar concepts are being applied across different aspects of the IT industry, and the resulting systems can effectively combine those concepts to increase their leverage and value. This is all to the good. Of course, we all have a lot to learn about exactly how and what to do.. but as with all innovations, the chatter will start to die down as we all get our hands dirty implementing this in practice. It is this effect that has prompted some of the recent "death of SOA" discussions in the blogsphere, and no doubt will spawn the next great buzzword. (This is exactly what is predicted by the Hype Cycle, and documented in our Hype Cycle on Application Architecture)

In the meantime, we all need to focus on the key things that maximize the benefits of adopting those practices, designs and approaches. As I speak to Gartner’s clients about SOA, that is what they are all trying to achieve. I have no doubt that they will combine SOA with virtualization and other changes in the infrastructure to produce better, more flexible, less costly systems. The hype about SOA may be dying away, but the practice is just getting under way, and we have a great deal more to learn there. We have a lot of research about these practices going on right now… and at least for the moment, it will still be called SOA…although who knows..even I and my colleagues may succumb to "private cloud" or the buzzword de jure.. no one is immune, after all…

I have recently been inundated with questions about the design of message formats. While these questions vary from techniques for XML extensibility to issues about how to create common elements for messaging standards. Underlying all of these questions is a basic challenge: Creating a common set of shared services requires a common information model.  We all have been challenged to create common information for many years, but because SOA is a centralizing concept (consolidating application specific functions into shared services) it creates more demand for sorting out the information model. The process of deciding how to structure common messages is very complicated, and tied up with all sorts of other design decisions about how services are structured, etc.

If anyone has good or bad experiences with this process of creating common message formats for SOA, please let me know, I would love to hear from you.

Also, if anyone is using industry standards as part of their message formats, I would love to talk to you as well.

For you Gartner subscribers who are interested in WOA services, I suggest you take a look at the Reference Architecture for WOA. This is a description of the moving parts that are needed to implement a WOA-style service. The good thing about it is that there is not much there that is new; the architecture is completely consistent with that of the Web, and most of the content is derived from Roy Fieldings original thesis. Hopefully, it will be helpful to put that architecture into the service context.  We are seeing a growing number of WOA-style services that are being deployed in organizations. In fact, our survey numbers indicate that while these services represent a very small percentage of those in production, 87% of the respondents had at least one WOA service in their portfolio. From the conversations I have had, it seems that many of these services were built in a Web Oriented way because the providers and consumers were intended to be web sites. I look forward to doing more research into how these services are built and used in the coming year.

A very happy holiday to all, and I look forward to speaking with you in the new year.

OK, so I have finally dug out from the backlog after attending our AADI conference in Las Vegas last week. It was nice to see some of you in person. One thing that always bothers me is that I never have enough time to answer all the questions that people ask during our presentations. In this case, we also had a fire alarm go off during the Q&A portion of one of my presentations (it was a false alarm). So I figured that I would try to answer  them here.

The link to my presentations is here.

One of the major points of discussion was that as you plan how to adopt and make use of the ideas inherent in SOA, you have to remain cognizant of the benefits that you are trying to achieve. One of the main benefits is "agility" which roughly translates into the ability to change our IT systems at a rate that is sufficient to match the needs and expectations of the business environment. One question that we received was about how to quantify agility. There is some Gartner research on this topic (Gartner subscription required) that goes into great detail on how to do it. One other heuristic that I have seen used in a few cases has been just to measure the cost of change, and the time to make changes. People who are doing this usually divide the changes up into small, medium and large buckets based on some arbitrary criteria, and then figure out how much money and how many person-days have been applied to making those changes. While this will probably not mean much for small numbers, in a large organization this can give very good directional indications of whether SOA (or any other initiative) is having an impact on your agility.

The other question that was asked was whether WSDL was required for SOA. This is easy, in that the answer is a resounding NO. However, WSDL is most often used to implement the particular style of SOA that we refer to as RPC style SOA. In this style, services are essentially methods, and the messaging network is assumed (from the point of view of the endpoints) to be a WS-* and SOAP based network. In this situation, there is a lot of tooling that people use to simplify the programming of the interactions, and in most cases that tooling relies on WSDL files. (even in this case, they are not required, but given the tooling and how easy it makes things, it is pretty unlikely that anyone would choose to do without. )  In other styles of SOA, such as the WOA style,(Gartner subscription required)  WSDL is not only not required, but usually does not play a role. (Note that WSDL 2.0 was designed to be used even with WOA style services, and there are other efforts, such as WADL, to create a description language for this style of SOA. However, most practitioners at this point do not believe such a construct is necessary. )

Most of the other questions were from the presentation on the current state of SOA, which highlighted some of our findings from our SOA surveys. (Gartner subscription required).  The first one was about whether SOA adoption was consistent across industries.  The answer is that it is not, but that in some cases the number of responses in a particular industry was small, so it was hard to be sure the proportions were correct. In general, we see the most SOA adoption in high tech sector with 100% of the survey responses saying they were pursuing SOA, to a low of 37% in retail. However please be aware that the margin of error in this is too big to use these percentages directly.

The final question was about why, while most of the people using SOA saw positive outcomes for their agility and for other factors, there were some people who had negative or even strong negative outcomes. Most of the reason for this is just human nature.. if enough people do it, the outcomes will be all over the map. Anecdotally, a lot of the cases where people have had failures in their SOA initiatives have been the result of inattention to governance. As part of the conference, my colleague Paolo Malinverno did a presentation on the major mistakes to avoid, that is a compendium of the learnings we have had from talking to these organizations.

Hope you all enjoyed the conference. If you did not get a chance to attend, you can do so at the next one this summer in Orlando.

I will be heading out to Gartner’s Application Architecture, Development and Integration conference next week at Caesar’s in Las Vegas. I am presenting on how to get started with SOA, how to use SOA effectively for integration,  and the results of our surveys about SOA implementation and effectiveness. In addition, I will be hosting a panel on using standards with SOA, with an impressive group of industry luminaries who are involved in the standardization processes around SOA.

I hope to see you there!

We all know that building the business case for many IT and infrastructure related projects is quite difficult. I and my colleagues Anthony Bradley, Roy Schulte, and Paolo Malinverno have summarized the best practices we have observed in a research note that was just published today .  This technique represents a pragmatic approach to creating a business case for SOA, and probably could be applied to many other types of activities as well.  Even if you are well on your way to establishing SOA as normal means of designing IT systems, it will be helpful to take a look at this approach and apply it to upcoming projects, as it enables you to identify those aspects of SOA that directly contribute to business performance. Once this type of technique is in place.. all sorts of things, from budget requisitions to measurement schemes, become much easier. It also helps in the never-ending task of justifying the value of the IT organization.  I encourage you all to take a look.