The Latest Summit Information and Insight
Get a different view of what’s hot, what’s not, and what’s next at the Application Integration and Web Services Summit. The Summit blog delivers the latest event information and analyst insight you need to get the most from this Gartner Event. Explore thinking and future trends with those who coin the terms, shape the concepts and advise thousands of clients on their implementations every year. Be sure to check the blog regularly and submit comments and questions!
Get a different view of what’s hot, what’s not, and what’s next at the Application Integration and Web Services Summit. The Summit blog delivers the latest event information and analyst insight you need to get the most from this Gartner Event. Explore thinking and future trends with those who coin the terms, shape the concepts and advise thousands of clients on their implementations every year. Be sure to check the blog regularly and submit comments and questions!
08 December, 2005 02:41 PM EST
Q&A for "At Play in the Fields of the Web: lower case web services"
Posted By: Nick Gall, Vice President, Gartner Research
Q: You show "taxonomy" as Web 1.0 and "tagging" as Web 2.0. Aren't tags conceptually/logically based on a taxonomy to be valuable?
A: A good way to understand the relationship between tags and taxonomies is to think of the former as "bottom-up," statistical, decentralized creation of categories and the latter as "top-down," deterministic, centralized creation of categories. For some interesting resources discussing these differences see this Gartner research note, Update on Emerging Technologies, and my Semantic Web bookmarks, especially Clay Shirky's Ontology is Overrated: Categories, Links, and Tags.
Q: Can you talk about security on REST (e.g., if I want to provide access for someone with valid username/password)?
A: Since REST is HTTP based, most implementations use a combination of SSL and HTTP-based identity management (e.g., Web SSO).
Q: How do you do scalable services discovery with POX-based web services?
A: There is no "standard" for POX service discovery, but one example of how it can be done informally is RSS feed discovery. RSS feeds (e.g., http://blog.gartner.com/blog/xml-rss2.php) are discovered by bots or spiders as they scan web pages. Also, for human discovery of all forms of web services, sites like Strike Iron are available.
Q: What happens to open and free love? [This was an actual question!]
A: Our research indicates that the use of lower case web services is strongly correlated with increased levels of open and free love.
08 December, 2005 02:13 PM EST
Notes from Tim O’Reilly’s Keynote
Posted By: Whit Andrews, Vice President, Gartner Research
Tim’s argument, in essence, is that open source models essentially do not eliminate profit – instead, they effectively squeeze the profit from where the open source is applied to somewhere else in the value chain. Thus, commoditizing PC design, architecture and assembly squeezed profit into the OS and the office and down into the supplier environment (for Intel, because it is a dominant supplier). So, value moves up the stack now that Web infrastructure software is commoditized, so that new-generation functionality (software and information businesses) companies such as eBay, Google and Amazon.com can exploit that squeezed-out profit.
What is distinct now about these new companies is that they are information businesses, Tim argues, who deliver their software and information as a service. Now famously, Tim calls this Web 2.0.
When Tim says, “the key to competitive applications is the extent to which users add their own value to that which you provide,” he points to things like the buyer/seller mass on eBay. In other words, he says, “the users are the application.” Or, he says, look at Google. Every time we add a link, we add to Google, because it is Google’s use of PageRank that makes it extraordinary. It’s Amazon’s user lists, databases of user behavior, and user reviews that make it extraordinarily successful.
This idea of user empowerment has spread from software development into this new kind of business.
Getting your users to add value is a source of lock-in and added value, Tim says. This is what companies like Amazon and Google have taken – not just their code – from the open-source movement.
But he said this: Only a small number of users will add this explicitly. You have to be able to architect your software or business so it has these network effects.
Mashups are a huge challenge to the whole idea of open source. Mashup authors do not have any access to source code, but they are exploiting open source models.
Tim says, “I believe that data may be the new ‘Intel Inside.’ ” Look at Navteq and Digital Globe, as the proprietary hearts of Google Maps.
Q: What are hackers doing now?
A: They’re hacking on hardware. Hardware is becoming more malleable. I’ve been watching a a bunch of alpha geeks hacking on chips. Disposable hardware, like old cellphones, are becoming something to work with.
Q: What would you recommend to Gartner to have their users add value?
A: Create some sort of aggregate feedback loop. I would imagine you have a lot of insights through info suppliers. Could you make it more transparent, more explicit, so you could get info from people you don’t know. How to find the most prolific inventors, for example – a reporter went to the USPTO and couldn’t figure it out. I recommended to him that he try IBM’s Web Fountain – of course he had already published his story. If there were some way to ask one’s users, or instrument with data sources things like: What are your users using? What is it the most common software users are using?
Miscellany:
Based on book sales, Tim said, Ruby has passed Python as the third most popular development language.
08 December, 2005 02:12 PM EST
"Is There an XML Appliance in Your Future?" Q&A
Dan Sholler, Vice President, Gartner Research
Q: Are there any aspects of an XML appliance that would result in a “non-adaptive” enterprise? In other words, an enterprise that is resistant to change?
A: No, I do not think so. Certainly, it is always possible to create configurations that are difficult to change, and the notion of changing infrastructure at this level is difficult. However, the things that usually change on a regular basis are those things that are associated with the application logic (the data transformations, the business processes, the routing). The basic infrastructure configuration does not change nearly as often. Also, the issue is the cost of change. If the appliance is easy to implement, and relatively low cost, then swapping out one for another (of the same type, of course) should be no more difficult, and in some cases less difficult than upgrading your software.
There is an issue with packaging things as appliances, in that they have not been accepted in areas where the value of the customization or custom configuration of the software is much greater than the value of the infrastructure.. in other words, where I expect to do a lot of configuration of the software, and then have that configuration survive many generations of hardware.
We also need to remember that this market is still in its early stages. Almost every function that is packaged in an appliance is also available in a software format. Currently there is a difference between how appliances are sold and maintained vs. software, but that distinction is somewhat artificial. Many appliances can have their software upgraded on a regular basis when the customer pay a maintenance fee. This is identical to the maintenance value proposition in software. The main difference is that the customer cannot arbitrarily change the underlying hardware and infrastructure configuration. However, it would certainly be possible to have a company deliver a new hardware platform as part of that maintenance agreement (for the right price, of course). It remains to be seen whether these pricing models that support flexibility will develop, and what customers will require from these vendors. However, I do not believe that there is a fundamental brittleness to appliances that makes them less flexible than software from a functional perspective
Q: Hardware seems harder to replace/upgrade/change than software, is this perception accurate?
A: As I pointed out above, some of that distinction is artificial. Hardware is priced by the unit, whereas software pricing has a significant subscription component. There is nothing to say that one cannot price the appliance by subscription, although the upgrading of physical infrastructure is sometimes more challenging (because it requires someone to do it from a particular location) the cost in terms of effort may not be any different (and could be much less).
Also, the perception that one’s infrastructure changes less than one’s software is accurate at the micro level, but not at the macro level. Most organizations have applications that are running that have been sequentially deployed on several different generations of hardware. Those applications have had other changes to them, but they clearly outlive the infrastructure. Hmm, I wonder if we have stats on this.. I will have to check our research and see if this is something that has ever been accurately quantified..
But to answer your question, I do not believe the perception to be accurate.
Q: In what category do you find guaranteed delivery and state?
A: I am assuming that this question is referring to the value categories I was discussing about he segmentation of the market.
Guaranteed delivery is an aspect of messaging capabilities, and to the extent that the device supports messaging systems, it can offer guaranteed delivery. Of course, the level of “guarantee” can vary between implementations. For example, if the device is doing a protocol translation between two messaging systems, it is possible to have guaranteed delivery turned on in each system and still have a failure window in the device. Similarly, it is possible to run a guaranteed delivery protocol over a non-reliable transport (this is how WS-ReliableMessaging works). Also, even those systems that have “guaranteed delivery” sometimes do have some failure conditions, although they are statistically quite rare. My expectation is that most devices will do just what the software will do – they will have a mode where the failure window is larger, but performance is improved by removing the requirement to persist messages as they go through the protocol translation. They will also offer a persisted model with automated restart on recovery, and most will support standard SOAP functions, which will include WS-ReliableMessaging in the not too distant future.
As far as state management is concerned, this is a somewhat separate issue. Today, when an integration/middleware person starts talking about BPM, what they are really referring to is a engine whose primary purpose is to track the state of interactions on the network Those interactions are analogues of the business process, but they are not complete business process definitions, nor do they capture some of the business semantic that is associated with business processes by business management folks. This interaction state manager is necessary, because the challenge of maintaining state in a distributed environment is significant, and can get expensive if additional messages are required for state coordination. So for an appliance to offer state management, it would have to offer a BPM engine similar to many of those offered by integration vendors. (I am making a generalization here. Different vendors capture different amounts of business semantics and are able to express abstractions at a business-relevant level. I am just pointing out that the use of a tool like this to manage interaction state is different than “business process management” in the large. Today, few appliances offer this capability, but since it is a standard part of the middleware bundle, I expect that most appliances that are designed as middleware implementations will offer this capability, either in the bundle, or as a separate appliance (since the state may be tracked over network segments that are not implemented by a particular appliance).
Q: What functions provided by an integration suite (e.g., Tibco) today will be provided by application-level networks in the future? What is the timing of this? Will one dominate (hw/sw)? Or will we have a mix?
A: The application-level network is the term we are using in this context to refer to the complete end-to-end function that delivers messages and invokes services and transmits events across an extended enterprise. Because of its pervasiveness and reach, it is unlikely that implementations of this network will be homogenous (although they could be.) One of the opportunities presented by the standardization of messaging, XML, etc. is the ability to treat this network in a consistent way, but have varying implementations. In reality, many large organizations do this already, in that they have multiple implementations of the network (middleware stacks) that connect with each other, and that provide function to different subnets in the overall network. I expect that this model will continue, although the reason for having multiple subsets in the past was often local buying decisions, and I do not expect that to continue. My expectation is that the heterogeneous implementations will be because those implementations differ in function capability and cost. The transition to making this decision on a cost/value basis is happening now, but is unlikely to be a mainstream phenomenon before 2009.
As for whether more of those implementations will be appliance based or purely software based, the current expectation is that this will be a mix. Obviously, if something changes the value equation of either the appliances or the software, it will shift the balance toward one or the other. Today, the value opportunity is such that we believe 40% of G2000-sized organizations will have an appliance that supports this network by 2008.
Q: How much will rich client technologies (e.g., Ajax) help the network latency issue?
A: Just to be clear, the latency issue that the devices help with is the latency of the end-to-end interaction over the network. The “network latency,” which usually refers to latency that exists in the functionality at the IP layer and below, is not changed by these appliances. The part of that latency that appliances help with is that which is caused by the marshaling and unmarshaling of XML into memory structures (and the access of those structures), and some of the specialized complex processing that is required (cryptography support, etc.). Ajax as a technique has the ability to help perceived latency by pre-fetching related information, but can also compound a requirement to minimize latency by increasing the number of round trips (e.g., Google Suggest) so the answer is that it can help in some cases and make the problem significantly worse in others.
Stepping back, the issue here is that we are asking our networks to take on a new workload as we move to service-oriented architectures. These networks will need to add technologies and capabilities to meet the expectations of those workloads.
I would also refer you to Ray Valdes’ work on Ajax.
Q: What are your thoughts on search appliances?
A: They are non-existent..
Because the value proposition for search technology is radically different than that for middleware, these types of appliances are not included in our research around “application-fluent network appliances” (boy, I hope we come up with a better name for these things than that). These devices are competitive/complimentary to search software technologies, and while I do not have any information to share on this, my colleague, Whit Andrews (aka “Mr. Search” and “The guy who was carrying the blogging sign around at the conference”) should be able to weigh in on this topic.
Q: Are there any aspects of an XML appliance that would result in a “non-adaptive” enterprise? In other words, an enterprise that is resistant to change?
A: No, I do not think so. Certainly, it is always possible to create configurations that are difficult to change, and the notion of changing infrastructure at this level is difficult. However, the things that usually change on a regular basis are those things that are associated with the application logic (the data transformations, the business processes, the routing). The basic infrastructure configuration does not change nearly as often. Also, the issue is the cost of change. If the appliance is easy to implement, and relatively low cost, then swapping out one for another (of the same type, of course) should be no more difficult, and in some cases less difficult than upgrading your software.
There is an issue with packaging things as appliances, in that they have not been accepted in areas where the value of the customization or custom configuration of the software is much greater than the value of the infrastructure.. in other words, where I expect to do a lot of configuration of the software, and then have that configuration survive many generations of hardware.
We also need to remember that this market is still in its early stages. Almost every function that is packaged in an appliance is also available in a software format. Currently there is a difference between how appliances are sold and maintained vs. software, but that distinction is somewhat artificial. Many appliances can have their software upgraded on a regular basis when the customer pay a maintenance fee. This is identical to the maintenance value proposition in software. The main difference is that the customer cannot arbitrarily change the underlying hardware and infrastructure configuration. However, it would certainly be possible to have a company deliver a new hardware platform as part of that maintenance agreement (for the right price, of course). It remains to be seen whether these pricing models that support flexibility will develop, and what customers will require from these vendors. However, I do not believe that there is a fundamental brittleness to appliances that makes them less flexible than software from a functional perspective
Q: Hardware seems harder to replace/upgrade/change than software, is this perception accurate?
A: As I pointed out above, some of that distinction is artificial. Hardware is priced by the unit, whereas software pricing has a significant subscription component. There is nothing to say that one cannot price the appliance by subscription, although the upgrading of physical infrastructure is sometimes more challenging (because it requires someone to do it from a particular location) the cost in terms of effort may not be any different (and could be much less).
Also, the perception that one’s infrastructure changes less than one’s software is accurate at the micro level, but not at the macro level. Most organizations have applications that are running that have been sequentially deployed on several different generations of hardware. Those applications have had other changes to them, but they clearly outlive the infrastructure. Hmm, I wonder if we have stats on this.. I will have to check our research and see if this is something that has ever been accurately quantified..
But to answer your question, I do not believe the perception to be accurate.
Q: In what category do you find guaranteed delivery and state?
A: I am assuming that this question is referring to the value categories I was discussing about he segmentation of the market.
Guaranteed delivery is an aspect of messaging capabilities, and to the extent that the device supports messaging systems, it can offer guaranteed delivery. Of course, the level of “guarantee” can vary between implementations. For example, if the device is doing a protocol translation between two messaging systems, it is possible to have guaranteed delivery turned on in each system and still have a failure window in the device. Similarly, it is possible to run a guaranteed delivery protocol over a non-reliable transport (this is how WS-ReliableMessaging works). Also, even those systems that have “guaranteed delivery” sometimes do have some failure conditions, although they are statistically quite rare. My expectation is that most devices will do just what the software will do – they will have a mode where the failure window is larger, but performance is improved by removing the requirement to persist messages as they go through the protocol translation. They will also offer a persisted model with automated restart on recovery, and most will support standard SOAP functions, which will include WS-ReliableMessaging in the not too distant future.
As far as state management is concerned, this is a somewhat separate issue. Today, when an integration/middleware person starts talking about BPM, what they are really referring to is a engine whose primary purpose is to track the state of interactions on the network Those interactions are analogues of the business process, but they are not complete business process definitions, nor do they capture some of the business semantic that is associated with business processes by business management folks. This interaction state manager is necessary, because the challenge of maintaining state in a distributed environment is significant, and can get expensive if additional messages are required for state coordination. So for an appliance to offer state management, it would have to offer a BPM engine similar to many of those offered by integration vendors. (I am making a generalization here. Different vendors capture different amounts of business semantics and are able to express abstractions at a business-relevant level. I am just pointing out that the use of a tool like this to manage interaction state is different than “business process management” in the large. Today, few appliances offer this capability, but since it is a standard part of the middleware bundle, I expect that most appliances that are designed as middleware implementations will offer this capability, either in the bundle, or as a separate appliance (since the state may be tracked over network segments that are not implemented by a particular appliance).
Q: What functions provided by an integration suite (e.g., Tibco) today will be provided by application-level networks in the future? What is the timing of this? Will one dominate (hw/sw)? Or will we have a mix?
A: The application-level network is the term we are using in this context to refer to the complete end-to-end function that delivers messages and invokes services and transmits events across an extended enterprise. Because of its pervasiveness and reach, it is unlikely that implementations of this network will be homogenous (although they could be.) One of the opportunities presented by the standardization of messaging, XML, etc. is the ability to treat this network in a consistent way, but have varying implementations. In reality, many large organizations do this already, in that they have multiple implementations of the network (middleware stacks) that connect with each other, and that provide function to different subnets in the overall network. I expect that this model will continue, although the reason for having multiple subsets in the past was often local buying decisions, and I do not expect that to continue. My expectation is that the heterogeneous implementations will be because those implementations differ in function capability and cost. The transition to making this decision on a cost/value basis is happening now, but is unlikely to be a mainstream phenomenon before 2009.
As for whether more of those implementations will be appliance based or purely software based, the current expectation is that this will be a mix. Obviously, if something changes the value equation of either the appliances or the software, it will shift the balance toward one or the other. Today, the value opportunity is such that we believe 40% of G2000-sized organizations will have an appliance that supports this network by 2008.
Q: How much will rich client technologies (e.g., Ajax) help the network latency issue?
A: Just to be clear, the latency issue that the devices help with is the latency of the end-to-end interaction over the network. The “network latency,” which usually refers to latency that exists in the functionality at the IP layer and below, is not changed by these appliances. The part of that latency that appliances help with is that which is caused by the marshaling and unmarshaling of XML into memory structures (and the access of those structures), and some of the specialized complex processing that is required (cryptography support, etc.). Ajax as a technique has the ability to help perceived latency by pre-fetching related information, but can also compound a requirement to minimize latency by increasing the number of round trips (e.g., Google Suggest) so the answer is that it can help in some cases and make the problem significantly worse in others.
Stepping back, the issue here is that we are asking our networks to take on a new workload as we move to service-oriented architectures. These networks will need to add technologies and capabilities to meet the expectations of those workloads.
I would also refer you to Ray Valdes’ work on Ajax.
Q: What are your thoughts on search appliances?
A: They are non-existent.
Because the value proposition for search technology is radically different than that for middleware, these types of appliances are not included in our research around “application-fluent network appliances” (boy, I hope we come up with a better name for these things than that). These devices are competitive/complimentary to search software technologies, and while I do not have any information to share on this, my colleague, Whit Andrews (aka “Mr. Search” and “The guy who was carrying the blogging sign around at the conference”) should be able to weigh in on this topic.
07 December, 2005 11:34 AM EST
Q&A from The State of Web Services Standards 2005-2006
Dan Sholler, Vice President, Gartner Research
Dialogue from this presentation.
Q: What makes something a "standard"?
A: It seems that 2 or more companies can create a specification and publish a "standard". How do we as end user companies discourage the creation of competitive "standards?"
I confess to being a terminology abuser, and often use the word "standard" when what I really mean is a "specification" or "proposed standard". In reality, the only thing that makes something a standard is that it pervasive, i.e. that everyone or everything (in the relevant domain) uses it or does it that way.
There are a set of organizations whose role is to codify standards. The assumption is that the members of those organizations all agree to support the standards that the organization ratifies. In practice, what happens these days is that specifications are often proposed and vetted amongst a private community of interest, and only when there is general agreement within that community is the specification submitted as a proposal to one of the standards organizations. The most important standards organizations for Web Services are OASIS and W3C, although work relevant to web services is going on in other places, such as OMG. There is also WS-I which has a role in codifying the usage of standards when taken together.
These organizations are a valuable mechanism for screening the proposals and gaining agreement among vendors and users of the proposed standard that it actually can create the desired commonality. However, from a practical standpoint with regard to Web Services standards, the question is whether the standard can be used to enable different things to interoperate in a service-oriented model.
I do believe that most of the IT industry today understands that standardization of certain things, and the ability to promote interoperability amongst different technologies is critical to your success as an IT organization, and they are not opposed to the idea of standards. However, it is certainly also true that where there is a perceived differentiation between vendors, the impetus to create a standard (and therefore bound the interoperable function) can cause vendors to deemphasize standardization efforts.
User organizations should be very clear with their vendors, and state that having a standard (or adhering to a standard) is a necessary precondition for doing business with their vendors. Obviously, for this statement to be taken seriously it has to be true (in other words, you have to be willing to walk away from a vendor who refuses to participate in a standardization effort). But in the end, money talks, and the impact on business will drive vendors toward standardization.
Q: Do you see OWL and OWL-S move toward solutions for the self-discovery of web services?
A: I believe that there will be some mechanisms to describe taxonomic and semantic characteristics of searches that will be used to identify services and promote the automated discovery of them. However, there are two reasons why I think there is a pretty good likelihood that the current crop of tools will probably not be the model for this. The first reason is that this stuff is pretty esoteric and difficult today. The second is that the approach toward defining attributes embedded in these tools is a prescriptive approach (i.e. I create the taxonomy and fit the service into it). I believe that in all areas (not just web services discovery) search metadata (which is largely implemented in this prescriptive model today) will shift such that much more of it is self-organizing, folksonomy style of metadata development. The combination of these two models will ultimately lead us toward a very dynamic mechanism, that can be highly accurate and also responsive to change. The third problem is that the business value of representing service metadata in this way would only come when the set of services to be searched is very large, and no organization is at that stage, and it is entirely possible that the only way that would come about is in an aggregated directory of services from multiple organizations.
Q: Which standards bodies are recognized as having jurisdiction over web services standards? Does the answer change for a global enterprise?
A: The core web services standards (meaning the technology standards that enable network level interoperability) are mostly going through W3C and OASIS. The standards that are attempting to codify business semantics are all over the place, although there are some organizations that are doing broad-based work (such as OAGIS). The core technology standards are not function or geography specific, and therefore would not change for a global enterprise. Obviously content standards relevant to particular business activities, where those activities or their context (regulatory, etc. ) changes based on geography would have to have local incarnations...
Q: What do you make of the recent SCA/SDO announcement by IBM. Sybase BEA et al? Competition for JBI? Potential for continued standards wars? What do you think of the "SCA" announcement from IBM BEA et al? How does this fit into the big picture? How about existing standards such as JBI? Is this going to be another standards war? Is SCA a proposed standard that will compete with UDDI? how do the standards differ?
A: I'll start with the last SCA question first. SCA and UDDI are essentially independent of each other. UDDI is a standard for registry function, and certain types of registry metadata. The current content in UDDI does not overlap with the content that one could express as SCA. If SCA information needed to be part of the package that was kept about a service, it could be added to the UDDI model fairly easily. The only slight area of conflict is that UDDI assumes that all services are Web Services (in caps), whereas SCA has a more generalized notion of service that could be implemented using a different communication model, or one that is internal to the SCA container.
Overall, the SCA standard is a good idea. Today there are far too many models for how to bind services together. The challenge is that the industry has been saying for the past few years, that the way to solve this problem is to make all of the services SOAP-based Web Services. This is true at a wire interop level, and in fact my expectation is that most services described by SCA will be Web Services, but the programming models for how to utilize web services have been very inconsistent. SCA allows a service to publish enough information about itself in a generalized form, that the composition infrastructure in which it is running can bind that service to its callers, without the developer having to worry about what kind of service, or any of the additional infrastructure details. Having said this, it is my expectation that it will take quite a while before SCA metadata becomes visible to users, (except for the emacs crowd, of course who want to do everything themselves) SDO on the other hand is likely to have a nearer term impact, as its utility is more obvious to most customers. There is a First Take on this subject.
Dialogue from this presentation.
Q: What makes something a "standard"?
A: It seems that 2 or more companies can create a specification and publish a "standard". How do we as end user companies discourage the creation of competitive "standards?"
I confess to being a terminology abuser, and often use the word "standard" when what I really mean is a "specification" or "proposed standard". In reality, the only thing that makes something a standard is that it pervasive, i.e. that everyone or everything (in the relevant domain) uses it or does it that way.
There are a set of organizations whose role is to codify standards. The assumption is that the members of those organizations all agree to support the standards that the organization ratifies. In practice, what happens these days is that specifications are often proposed and vetted amongst a private community of interest, and only when there is general agreement within that community is the specification submitted as a proposal to one of the standards organizations. The most important standards organizations for Web Services are OASIS and W3C, although work relevant to web services is going on in other places, such as OMG. There is also WS-I which has a role in codifying the usage of standards when taken together.
These organizations are a valuable mechanism for screening the proposals and gaining agreement among vendors and users of the proposed standard that it actually can create the desired commonality. However, from a practical standpoint with regard to Web Services standards, the question is whether the standard can be used to enable different things to interoperate in a service-oriented model.
I do believe that most of the IT industry today understands that standardization of certain things, and the ability to promote interoperability amongst different technologies is critical to your success as an IT organization, and they are not opposed to the idea of standards. However, it is certainly also true that where there is a perceived differentiation between vendors, the impetus to create a standard (and therefore bound the interoperable function) can cause vendors to deemphasize standardization efforts.
User organizations should be very clear with their vendors, and state that having a standard (or adhering to a standard) is a necessary precondition for doing business with their vendors. Obviously, for this statement to be taken seriously it has to be true (in other words, you have to be willing to walk away from a vendor who refuses to participate in a standardization effort). But in the end, money talks, and the impact on business will drive vendors toward standardization.
Q: Do you see OWL and OWL-S move toward solutions for the self-discovery of web services?
A: I believe that there will be some mechanisms to describe taxonomic and semantic characteristics of searches that will be used to identify services and promote the automated discovery of them. However, there are two reasons why I think there is a pretty good likelihood that the current crop of tools will probably not be the model for this. The first reason is that this stuff is pretty esoteric and difficult today. The second is that the approach toward defining attributes embedded in these tools is a prescriptive approach (i.e. I create the taxonomy and fit the service into it). I believe that in all areas (not just web services discovery) search metadata (which is largely implemented in this prescriptive model today) will shift such that much more of it is self-organizing, folksonomy style of metadata development. The combination of these two models will ultimately lead us toward a very dynamic mechanism, that can be highly accurate and also responsive to change. The third problem is that the business value of representing service metadata in this way would only come when the set of services to be searched is very large, and no organization is at that stage, and it is entirely possible that the only way that would come about is in an aggregated directory of services from multiple organizations.
Q: Which standards bodies are recognized as having jurisdiction over web services standards? Does the answer change for a global enterprise?
A: The core web services standards (meaning the technology standards that enable network level interoperability) are mostly going through W3C and OASIS. The standards that are attempting to codify business semantics are all over the place, although there are some organizations that are doing broad-based work (such as OAGIS). The core technology standards are not function or geography specific, and therefore would not change for a global enterprise. Obviously content standards relevant to particular business activities, where those activities or their context (regulatory, etc. ) changes based on geography would have to have local incarnations...
Q: What do you make of the recent SCA/SDO announcement by IBM. Sybase BEA et al? Competition for JBI? Potential for continued standards wars? What do you think of the "SCA" announcement from IBM BEA et al? How does this fit into the big picture? How about existing standards such as JBI? Is this going to be another standards war? Is SCA a proposed standard that will compete with UDDI? how do the standards differ?
A: I'll start with the last SCA question first. SCA and UDDI are essentially independent of each other. UDDI is a standard for registry function, and certain types of registry metadata. The current content in UDDI does not overlap with the content that one could express as SCA. If SCA information needed to be part of the package that was kept about a service, it could be added to the UDDI model fairly easily. The only slight area of conflict is that UDDI assumes that all services are Web Services (in caps), whereas SCA has a more generalized notion of service that could be implemented using a different communication model, or one that is internal to the SCA container.
Overall, the SCA standard is a good idea. Today there are far too many models for how to bind services together. The challenge is that the industry has been saying for the past few years, that the way to solve this problem is to make all of the services SOAP-based Web Services. This is true at a wire interop level, and in fact my expectation is that most services described by SCA will be Web Services, but the programming models for how to utilize web services have been very inconsistent. SCA allows a service to publish enough information about itself in a generalized form, that the composition infrastructure in which it is running can bind that service to its callers, without the developer having to worry about what kind of service, or any of the additional infrastructure details. Having said this, it is my expectation that it will take quite a while before SCA metadata becomes visible to users, (except for the emacs crowd, of course who want to do everything themselves) SDO on the other hand is likely to have a nearer term impact, as its utility is more obvious to most customers. There is a First Take on this subject.
07 December, 2005 11:32 AM EST
Tremors
Whit Andrews, Vice President, Gartner Research
Maybe you had a chance to see Nick Gall's "maverick" presentation today. He's a big fan of thinking about the impact of Web technologies from another perspective. I've spent three years managing the agenda around what enterprises have been begging for, which is a more sophisticated, more fully realized set of standards that will let them get from Web services what they get today from proprietary middleware. Nick says, let's look instead at what developers want to do. In other words, it's not that Web services are too simple - it's that they are too hard.
I have my own blog, and I think I'm using some of these new specifications that Nick is talking about – things like REST. I know I'm using RSS. I suspect I might end up using Atom. I guess I use AJAX, because I used Google Maps. (I told my mother I know there's a path near my house that leads through the woods because I found it on a satellite image, but I haven't walked it yet, and she practically rolled her eyes 180 degrees to the back of her head.) I can't really tell, and I don't really care.
So Nick's got a point. Web services were so hard I couldn't use them. Now I can use these great new Web technologies. I get it. The Web services movement, the phenomenon, is spreading up into sophistication and down into simplicity. Works for me, so far. Not waffle, not syrup – this is wake-up coffee.
Maybe you had a chance to see Nick Gall's "maverick" presentation today. He's a big fan of thinking about the impact of Web technologies from another perspective. I've spent three years managing the agenda around what enterprises have been begging for, which is a more sophisticated, more fully realized set of standards that will let them get from Web services what they get today from proprietary middleware. Nick says, let's look instead at what developers want to do. In other words, it's not that Web services are too simple - it's that they are too hard.
I have my own blog, and I think I'm using some of these new specifications that Nick is talking about – things like REST. I know I'm using RSS. I suspect I might end up using Atom. I guess I use AJAX, because I used Google Maps. (I told my mother I know there's a path near my house that leads through the woods because I found it on a satellite image, but I haven't walked it yet, and she practically rolled her eyes 180 degrees to the back of her head.) I can't really tell, and I don't really care.
So Nick's got a point. Web services were so hard I couldn't use them. Now I can use these great new Web technologies. I get it. The Web services movement, the phenomenon, is spreading up into sophistication and down into simplicity. Works for me, so far. Not waffle, not syrup – this is wake-up coffee.
07 December, 2005 10:07 AM EST
Platforms for SOA Follow Up Q&A
Yefim V. Natis, VP & Distinguished Analyst, Gartner
Q: Since you talked about suites, is ESB a product as vendors are promoting?
A: A minimal ESB is simply an extensible transport for services and events. However, vendors, in their desire to compete and differentiate are adding extra features and capabilities, extending the base to a suite of technologies. A well-implemented ESB will have at least an internal extensibility model, so users will have an option of deploying only the extensions they intend to use.
Q: What exactly is a definition of a standard? Is SCA a standard?
A: No, SCA is certainly not a standard. It is a specification that is intended to be proposed as a standard in the future. However, if all vendors that have endorsed SCA in fact implement it in a compatible manner – it may emerge as a “de facto standard” even without being adopted by an officially recognized standards body.
Q: You said a portal is sufficient for SOA with small number of services. Please define “portal.”
A: A portal product may be sufficient for some smaller SOA-style applications as their core platform. This is because most leading portal products (WebSphere Portal, WebLogic Portal, BEA User Interaction (formerly PlumTree), Sun ONE Portal, Oracle Fusion Portal, etc.) support service invocations. Using these products alone you can build a less demanding fan-style pattern of SOA. In the next two years all leading portal products are likely to adopt ESB and some registry/repository support, further enhancing their SOA capabilities.
Q: How does or will SOA affect the development of commercial of the shelf purchases/development?
A: Commercial (packaged) applications are affected by SOA as much as the custom applications developed in-house by IT departments of enterprises or by system integrators on their behalf. All applications, no matter how developed, are and will be under pressure to be modular, incremental, programmatically accessible for integration and loosely coupled.
Q: Why do you not mention DBMS as an option for enabling technology for SOA?
A: In written research on the subject we in fact do list DBMS stored procedures engine as a type of platform middleware. Indeed, services in SOA may be implemented as the stored procedures. The degree of the openness of these stored procedures to external loosely-coupled programmatic access is not standard and thus varies by the vendor. Typically, the stored procedures are used for direct access and manipulation of relational data – more like tightly-coupled components than like cross-application services.
Q: How do you differentiate between APS and Integration Suites?
A: The APS and Integration Suites (IS) have different objectives and different (though overlapping) content. The objective of an APS is to support the end-to-end implementation of a modern on-line transaction. APS therefore includes an application server, a portal product, an integration suite (and business process manager), the development tools and systems management tools. Theoretically, if you deployed an APS you do not need to buy any more platform or middleware technology to complete a software project. An IS is offered to address all integration problems an enterprise might have: data reconciliation, multi-step process and composite transactions. This objective is a subset of the APS objective, in that IS do not support new green-field software projects, and a superset of APS, in that IS offers deeper and broader support for integration patterns than a typical APS buyer requires.
Q: What WS standards exist today that event-driven and asynchronous services?
A: There is not a sufficient set of WS-* standards (even in a proposal form) for all aspects of event driven applications. WS-Reliability and WS-Reliable messaging deal with guaranteed delivery of asynchronous messages. JMS component of J2EE offers APIs for Java messaging and pub/sub. JBI and the newly proposed SCA – both also have provisions for event processing.
Q: Earlier I attended David Smith’s presentation of where he talked about the Web Services Platforms (WSP) and the importance of SCA. You are talking about APS and the importance of SCA to SOA. Do you see these are competing solutions?
A: APS is a product category defined by its content (application server, integration suite and portal product combined constitute a basic APS). WSP is a product category defined by its objective: to support web services. imilarly, users planning a SOA-based project look for technology that can act as a platform for SOA (sometimes referred to as a SOA suite). An APS (i.e., WebLogic Platform, NetWeaver, Fusion Middleware, Java ES, exteNd) is one of the potential product categories to fulfill either Web services or SOA objective. Other product categories may be considered for this purpose as well (i.e., portal products, BPM tools, application servers, integration suites)
Q: On the micro-kernel aspect – JBI proposal is for componentizing the building blocks of ESB. Correct? It does not apply to other aspects of E-APS. How do you see this concept applied to BPM, EII/MDM?
A: No, JBI specification can be used equally well by any extensible systems software that needs to be built of multiple interchangeable component-parts. Sun has talked of ESB as the first product they implement using JBI. BPM tools, EII tools and any other systems software can adopt JBI as well.
Q: In your slide entitled “Platforms for SOA-based applications” the outer circle does not include a data services platform. How does canonical (“master”) data and schema get fed into this picture?
A: Certainly, there is no SOA-based (or any other) application without access to a data store. However SOA is about access and assembly of software encapsulated behind the interfaces (services). The services then in turn access the data stores. For this reason the data store is not part of the picture – it belongs to a further outer layer. However, DBMS do offer stored procedures. These can be used for service implementations. In that case the DBMS stored procedures engine acts as an application server and is reflected in the diagram as such.
Q: Since you talked about suites, is ESB a product as vendors are promoting?
A: A minimal ESB is simply an extensible transport for services and events. However, vendors, in their desire to compete and differentiate are adding extra features and capabilities, extending the base to a suite of technologies. A well-implemented ESB will have at least an internal extensibility model, so users will have an option of deploying only the extensions they intend to use.
Q: What exactly is a definition of a standard? Is SCA a standard?
A: No, SCA is certainly not a standard. It is a specification that is intended to be proposed as a standard in the future. However, if all vendors that have endorsed SCA in fact implement it in a compatible manner – it may emerge as a “de facto standard” even without being adopted by an officially recognized standards body.
Q: You said a portal is sufficient for SOA with small number of services. Please define “portal.”
A: A portal product may be sufficient for some smaller SOA-style applications as their core platform. This is because most leading portal products (WebSphere Portal, WebLogic Portal, BEA User Interaction (formerly PlumTree), Sun ONE Portal, Oracle Fusion Portal, etc.) support service invocations. Using these products alone you can build a less demanding fan-style pattern of SOA. In the next two years all leading portal products are likely to adopt ESB and some registry/repository support, further enhancing their SOA capabilities.
Q: How does or will SOA affect the development of commercial of the shelf purchases/development?
A: Commercial (packaged) applications are affected by SOA as much as the custom applications developed in-house by IT departments of enterprises or by system integrators on their behalf. All applications, no matter how developed, are and will be under pressure to be modular, incremental, programmatically accessible for integration and loosely coupled.
Q: Why do you not mention DBMS as an option for enabling technology for SOA?
A: In written research on the subject we in fact do list DBMS stored procedures engine as a type of platform middleware. Indeed, services in SOA may be implemented as the stored procedures. The degree of the openness of these stored procedures to external loosely-coupled programmatic access is not standard and thus varies by the vendor. Typically, the stored procedures are used for direct access and manipulation of relational data – more like tightly-coupled components than like cross-application services.
Q: How do you differentiate between APS and Integration Suites?
A: The APS and Integration Suites (IS) have different objectives and different (though overlapping) content. The objective of an APS is to support the end-to-end implementation of a modern on-line transaction. APS therefore includes an application server, a portal product, an integration suite (and business process manager), the development tools and systems management tools. Theoretically, if you deployed an APS you do not need to buy any more platform or middleware technology to complete a software project. An IS is offered to address all integration problems an enterprise might have: data reconciliation, multi-step process and composite transactions. This objective is a subset of the APS objective, in that IS do not support new green-field software projects, and a superset of APS, in that IS offers deeper and broader support for integration patterns than a typical APS buyer requires.
Q: What WS standards exist today that event-driven and asynchronous services?
A: There is not a sufficient set of WS-* standards (even in a proposal form) for all aspects of event driven applications. WS-Reliability and WS-Reliable messaging deal with guaranteed delivery of asynchronous messages. JMS component of J2EE offers APIs for Java messaging and pub/sub. JBI and the newly proposed SCA – both also have provisions for event processing.
Q: Earlier I attended David Smith’s presentation of where he talked about the Web Services Platforms (WSP) and the importance of SCA. You are talking about APS and the importance of SCA to SOA. Do you see these are competing solutions?
A: APS is a product category defined by its content (application server, integration suite and portal product combined constitute a basic APS). WSP is a product category defined by its objective: to support web services. imilarly, users planning a SOA-based project look for technology that can act as a platform for SOA (sometimes referred to as a SOA suite). An APS (i.e., WebLogic Platform, NetWeaver, Fusion Middleware, Java ES, exteNd) is one of the potential product categories to fulfill either Web services or SOA objective. Other product categories may be considered for this purpose as well (i.e., portal products, BPM tools, application servers, integration suites)
Q: On the micro-kernel aspect – JBI proposal is for componentizing the building blocks of ESB. Correct? It does not apply to other aspects of E-APS. How do you see this concept applied to BPM, EII/MDM?
A: No, JBI specification can be used equally well by any extensible systems software that needs to be built of multiple interchangeable component-parts. Sun has talked of ESB as the first product they implement using JBI. BPM tools, EII tools and any other systems software can adopt JBI as well.
Q: In your slide entitled “Platforms for SOA-based applications” the outer circle does not include a data services platform. How does canonical (“master”) data and schema get fed into this picture?
A: Certainly, there is no SOA-based (or any other) application without access to a data store. However SOA is about access and assembly of software encapsulated behind the interfaces (services). The services then in turn access the data stores. For this reason the data store is not part of the picture – it belongs to a further outer layer. However, DBMS do offer stored procedures. These can be used for service implementations. In that case the DBMS stored procedures engine acts as an application server and is reflected in the diagram as such.
07 December, 2005 09:22 AM EST
More Q&A from the Architecture and Platforms for Extreme OLTP session
Massimo Pezzini VP & Distingushed Analyst, Gartner
Q: In your presentation you mentioned a couple of examples of successful extreme OLTP applications and failure. What key concepts in the implementation of these projects differentiated between success and failure?
A:Many aspects proved relevant in these experiences, including proper capacity planning and disaster recovery, but one crucial issue differentiated the Comic Relief success from the Robbie Williams failure (at least from a technical perspective, though certainly not from a business perspective): the ability to insure continuous availability of the service even in the case of lack of resources. In both cases the bottleneck was the credit card payment process that was carried out by the same service provider. However, whereas Comic Relief was capable of accepting donations even at the time when the payment system couldn’t process the volume of incoming requests fast enough, in the Robbie Williams case this option wasn’t anticipated. Therefore requests for ticket purchases were refused as the system couldn’t complete the transactions due to the clogged payment system. Comic Relief instead was able to queue the payment requests and provided donors an email confirmation later, when their donation had been actually processed, as the volume of donation actions cooled down.
Q:You advocate “Enterprise Grid” as an option to scale. At the same time Gartner tells major companies that TCO and number of boxes is higher with horizontal scaling, i.e., it is “bad”. Please explain this dichotomy!
A:“Enterprise Gird” is exactly about reducing TCO for large scale deployments vs. traditional clustering. In a traditional cluster a certain amount of computing resources is statically allocated to each application, thus leading to over-provisioning to be able to support peak loads. The idea behind enterprise grid is that through a virtualization layer computing resources can be optimally and dynamically allocated to multiple OLTP applications on the basis of certain criteria (also called “policies”). Resources allocated to a one application to support a peak load can be dynamically allocated to another application when the peak terminates. This way it should be possible to minimize over provisioning and keep the total amount of computing resources down. However given the immaturity of enterprise grid technology it is still hard to say how much the saving vs. traditional “scale out” clustering could be.
Q:Where does IBM’s TXSeries fit in the “extreme OLTP” technology scenario?
A:Although essentially a “CICS clone” supporting the CICS programming model on distributed platforms (Linux, Unix, Windows) the product has been rarely used to support large scale OLTP apps. Its typical usage pattern is as gateway between distributed applications and CICS TS on zSeries mainframes. The next major version of the product will simplify the architecture by eliminating dependency from OSF DCE and the Encina technology, but overall we believe its positioning it is not going to change. We see it continuing in to play its traditional “gateway” role as well as a “downsizing” opportunity for CICS applications. We don’t expect many new developments on TXSeries.
Q:You mentioned that 95 percent of the future “extreme OLTP” will be on .NET or J2EE. What size of environment will be needed and what cost analysis has been done about support cost?
A:First of all let me clarify my point. I didn’t say that 95 percent of extreme OLTP will be on .NET or J2EE, but that by 2010 .NET and J2EE will be technically capable of supporting 95 percent of the OLTP requirements. Simply put both platforms will be almost as good as TPM in terms of scalability, performance, availability, manageability etc. Many new OLTP applications will continue to be implemented on TPMs, for various reasons (e.g., skills), even though they could technically be developed and deployed on J2EE or .NET as well. Sizing the environment is always a complex exercise as it depends from the application requirements etc. As an example Comic Relief has been able to manage about 1,000 transactions per second on the peak hour by deploying approximately 140-150 (Solaris) CPUs for the app server, another 8 CPUs for the database server and 8 additional CPUs for the payment gateway. Undoubtedly today mainframe based TPMs are cheaper to support than distributed application servers on Linux or Windows, but our expectation is that in five years from now, J2EE and .NET platforms will have caught up in terms of manageability.
Q:What are the characteristics that differentiate distributed caching products with one another? What should I look for in these products?
A:Distributed caching products allow you to upload in memory large amount of data, typically from a relational database, so that applications have fast access to critical data without the latency of reading data from disk. A simple way of figuring out what a distributed cache does it to think at it as an “in memory database”, although not all the features of a DBMS can be found in these products. When evaluating these products you may want to look at the set of APIs available for you to manipulate data in the cache. As example some products support multiple APIs (SQL, JDBC, XML etc.) others only one. Ability to support multiple data sources (various DBMS, MOM, XML etc.) is another important feature. Utilities to fast loading the cache, to asynchronously persist the cache content, to manage cache overflow are also relevant features you may want to look at. Cache partitioning and distribution, failover management and load balancing, transaction and locking support and security should also be taken into account when evaluating these products. Management is probably the biggest issue in distributed caching products. Understanding what’s going on in the cache in terms of which pieces of data are in the cache, what their state is etc. is usually pretty difficult. Therefore particular attention should be paid to management capabilities offered by the products.
Q: In your presentation you mentioned a couple of examples of successful extreme OLTP applications and failure. What key concepts in the implementation of these projects differentiated between success and failure?
A:Many aspects proved relevant in these experiences, including proper capacity planning and disaster recovery, but one crucial issue differentiated the Comic Relief success from the Robbie Williams failure (at least from a technical perspective, though certainly not from a business perspective): the ability to insure continuous availability of the service even in the case of lack of resources. In both cases the bottleneck was the credit card payment process that was carried out by the same service provider. However, whereas Comic Relief was capable of accepting donations even at the time when the payment system couldn’t process the volume of incoming requests fast enough, in the Robbie Williams case this option wasn’t anticipated. Therefore requests for ticket purchases were refused as the system couldn’t complete the transactions due to the clogged payment system. Comic Relief instead was able to queue the payment requests and provided donors an email confirmation later, when their donation had been actually processed, as the volume of donation actions cooled down.
Q:You advocate “Enterprise Grid” as an option to scale. At the same time Gartner tells major companies that TCO and number of boxes is higher with horizontal scaling, i.e., it is “bad”. Please explain this dichotomy!
A:“Enterprise Gird” is exactly about reducing TCO for large scale deployments vs. traditional clustering. In a traditional cluster a certain amount of computing resources is statically allocated to each application, thus leading to over-provisioning to be able to support peak loads. The idea behind enterprise grid is that through a virtualization layer computing resources can be optimally and dynamically allocated to multiple OLTP applications on the basis of certain criteria (also called “policies”). Resources allocated to a one application to support a peak load can be dynamically allocated to another application when the peak terminates. This way it should be possible to minimize over provisioning and keep the total amount of computing resources down. However given the immaturity of enterprise grid technology it is still hard to say how much the saving vs. traditional “scale out” clustering could be.
Q:Where does IBM’s TXSeries fit in the “extreme OLTP” technology scenario?
A:Although essentially a “CICS clone” supporting the CICS programming model on distributed platforms (Linux, Unix, Windows) the product has been rarely used to support large scale OLTP apps. Its typical usage pattern is as gateway between distributed applications and CICS TS on zSeries mainframes. The next major version of the product will simplify the architecture by eliminating dependency from OSF DCE and the Encina technology, but overall we believe its positioning it is not going to change. We see it continuing in to play its traditional “gateway” role as well as a “downsizing” opportunity for CICS applications. We don’t expect many new developments on TXSeries.
Q:You mentioned that 95 percent of the future “extreme OLTP” will be on .NET or J2EE. What size of environment will be needed and what cost analysis has been done about support cost?
A:First of all let me clarify my point. I didn’t say that 95 percent of extreme OLTP will be on .NET or J2EE, but that by 2010 .NET and J2EE will be technically capable of supporting 95 percent of the OLTP requirements. Simply put both platforms will be almost as good as TPM in terms of scalability, performance, availability, manageability etc. Many new OLTP applications will continue to be implemented on TPMs, for various reasons (e.g., skills), even though they could technically be developed and deployed on J2EE or .NET as well. Sizing the environment is always a complex exercise as it depends from the application requirements etc. As an example Comic Relief has been able to manage about 1,000 transactions per second on the peak hour by deploying approximately 140-150 (Solaris) CPUs for the app server, another 8 CPUs for the database server and 8 additional CPUs for the payment gateway. Undoubtedly today mainframe based TPMs are cheaper to support than distributed application servers on Linux or Windows, but our expectation is that in five years from now, J2EE and .NET platforms will have caught up in terms of manageability.
Q:What are the characteristics that differentiate distributed caching products with one another? What should I look for in these products?
A:Distributed caching products allow you to upload in memory large amount of data, typically from a relational database, so that applications have fast access to critical data without the latency of reading data from disk. A simple way of figuring out what a distributed cache does it to think at it as an “in memory database”, although not all the features of a DBMS can be found in these products. When evaluating these products you may want to look at the set of APIs available for you to manipulate data in the cache. As example some products support multiple APIs (SQL, JDBC, XML etc.) others only one. Ability to support multiple data sources (various DBMS, MOM, XML etc.) is another important feature. Utilities to fast loading the cache, to asynchronously persist the cache content, to manage cache overflow are also relevant features you may want to look at. Cache partitioning and distribution, failover management and load balancing, transaction and locking support and security should also be taken into account when evaluating these products. Management is probably the biggest issue in distributed caching products. Understanding what’s going on in the cache in terms of which pieces of data are in the cache, what their state is etc. is usually pretty difficult. Therefore particular attention should be paid to management capabilities offered by the products.
07 December, 2005 06:00 AM EST
Five Things You Need to Know Wednesday
1. Registration for analyst One-on-Ones will be available until 4:30PM. The One-on-One registration table is located outside of the Del Lago 3&4 meeting rooms.
2. The Keynote Presentation, "Open Source and Web 2.0," by Tim O'Reilly, Founder and CEO of O'Reilly Media, begins at 2:00PM.
3. Vendor Case Study Panels will take place at 9:45AM.
4. Shuttles between the JW Marriott and the Sheraton World Resort will depart every 15 minutes between 7:00 AM - 9:00 PM.
5. The Open Source Summit begins today, with a luncheon at noon, followed by the keynote presentation.
2. The Keynote Presentation, "Open Source and Web 2.0," by Tim O'Reilly, Founder and CEO of O'Reilly Media, begins at 2:00PM.
3. Vendor Case Study Panels will take place at 9:45AM.
4. Shuttles between the JW Marriott and the Sheraton World Resort will depart every 15 minutes between 7:00 AM - 9:00 PM.
5. The Open Source Summit begins today, with a luncheon at noon, followed by the keynote presentation.
06 December, 2005 06:01 PM EST
A Strong Finish
As the conference heads into its final day, take some time to ask questions and engage Gartner analysts during three breakfast sessions:
Vertical Networking Breakfast (Coquina Ballroom)
User Survey - How Are Your Peers Planning for and Implementing Web Services?
During this special session, Gartner will reveal and discuss the results of an exclusive global user survey undertaken in the spring. Presented for the first time at the conference, the results will provide an in-depth view of the real-world use of Web services products and external service providers.
Overview of the New Gartner Enterprise Architecture Framework
The Gartner acquisition of META Group and its thriving Enterprise Architecture (EA) practice provided the opportunity to unify the research and approaches of both companies in the EA arena. At the same time, changes in the business and IT climate have made the practice of EA even more challenging for our clients. The fusion of our EA research is an opportunity to leverage the significant assets of both companies to develop an approach which helps clients work through the new challenges of EA. This session will introduce the new Gartner framework and show examples of its application.
Get some brain food along with the most important meeting of the day.
Vertical Networking Breakfast (Coquina Ballroom)
User Survey - How Are Your Peers Planning for and Implementing Web Services?
During this special session, Gartner will reveal and discuss the results of an exclusive global user survey undertaken in the spring. Presented for the first time at the conference, the results will provide an in-depth view of the real-world use of Web services products and external service providers.
Overview of the New Gartner Enterprise Architecture Framework
The Gartner acquisition of META Group and its thriving Enterprise Architecture (EA) practice provided the opportunity to unify the research and approaches of both companies in the EA arena. At the same time, changes in the business and IT climate have made the practice of EA even more challenging for our clients. The fusion of our EA research is an opportunity to leverage the significant assets of both companies to develop an approach which helps clients work through the new challenges of EA. This session will introduce the new Gartner framework and show examples of its application.
Get some brain food along with the most important meeting of the day.
06 December, 2005 04:33 PM EST
Q&A From ICC and SOA Governance Presentation
Q&A from Paolo Malinverno's presentation earlier today.
Q: does the Integration Competency Center (ICC) have responsibilities for integration development and operational support? If so, how are these responsibilities differentiated from the existing application development groups and the operational support group?
A: Initially ICCs tend to centralize all integration development efforts; when they mature, they tend to offload development, under the ICC standards (naming conventions, business logic, tools usage, documentation) either to internal development groups, or outsourcing. Operations typically sits in the ICC on a part time basis, when a new integrated solution is about to be put into production. Think of the ICC as a dynamic group, where most people sit on a part time basis, having another job too (e.g. operations), and being measured on both.
Q: for an enterprise that already has an established ICC with all the typical ICC components, what would be the first step towards SOA governance?
A: the first step is always to assess the current governance mechanisms, and see how they play towards disciplining the 5 major decisions (slide 12 of my presentation). Normally changes are needed in the way the company takes those decisions, and that’s the first thing to work on (as it will take a long time to change).
Q: if public services are contracts, how best to specify and enforce the contract? Are SLAs appropriate?
A: Absolutely, SLAs are one of the most important governance mechanisms. Classical examples are guaranteed response times, and general quality of service metrics
Q: If there is no governance for private services, and public services are the primary users of them, how do you prevent private services proliferation?
A: Private services are much more tied to single IT infrastructure areas (e.g. a specific ERP system); typically, the group of people maintaining skills on that area is small, and some sort of ‘natural reuse’ takes place, as they are involved in all the service implementations for that area, and they obviously will not recreate something they already have
Q: How would the breakdown between public and private services apply to local government, where some customers are citizens, but most of the customers are agencies within the local government?
A: It is important not to get any confusion on the word "public" and on the word "services": for the sake of this discussion, public services are reusable components in the IT infrastructure, not specific (and possibly government defined) things that local government has to provide citizens and agencies with. Both for citizens and agencies (possibly through B2B connectors) you will have a set of reusable, high level reusable components (sometimes mapped onto the specific government defined things. Those are the public services.
Q: Are there sample governance mechanisms published on the Gartner site?
A: Not yet. In the next two months I am going to publish a series of notes on the matter; the last of them is going to contain descriptions of sample governance mechanisms
Q: does the Integration Competency Center (ICC) have responsibilities for integration development and operational support? If so, how are these responsibilities differentiated from the existing application development groups and the operational support group?
A: Initially ICCs tend to centralize all integration development efforts; when they mature, they tend to offload development, under the ICC standards (naming conventions, business logic, tools usage, documentation) either to internal development groups, or outsourcing. Operations typically sits in the ICC on a part time basis, when a new integrated solution is about to be put into production. Think of the ICC as a dynamic group, where most people sit on a part time basis, having another job too (e.g. operations), and being measured on both.
Q: for an enterprise that already has an established ICC with all the typical ICC components, what would be the first step towards SOA governance?
A: the first step is always to assess the current governance mechanisms, and see how they play towards disciplining the 5 major decisions (slide 12 of my presentation). Normally changes are needed in the way the company takes those decisions, and that’s the first thing to work on (as it will take a long time to change).
Q: if public services are contracts, how best to specify and enforce the contract? Are SLAs appropriate?
A: Absolutely, SLAs are one of the most important governance mechanisms. Classical examples are guaranteed response times, and general quality of service metrics
Q: If there is no governance for private services, and public services are the primary users of them, how do you prevent private services proliferation?
A: Private services are much more tied to single IT infrastructure areas (e.g. a specific ERP system); typically, the group of people maintaining skills on that area is small, and some sort of ‘natural reuse’ takes place, as they are involved in all the service implementations for that area, and they obviously will not recreate something they already have
Q: How would the breakdown between public and private services apply to local government, where some customers are citizens, but most of the customers are agencies within the local government?
A: It is important not to get any confusion on the word "public" and on the word "services": for the sake of this discussion, public services are reusable components in the IT infrastructure, not specific (and possibly government defined) things that local government has to provide citizens and agencies with. Both for citizens and agencies (possibly through B2B connectors) you will have a set of reusable, high level reusable components (sometimes mapped onto the specific government defined things. Those are the public services.
Q: Are there sample governance mechanisms published on the Gartner site?
A: Not yet. In the next two months I am going to publish a series of notes on the matter; the last of them is going to contain descriptions of sample governance mechanisms
06 December, 2005 04:21 PM EST
Roundtable Notes & Comments
Comments by Dan Sholler and others from an earlier roundtable discussion:
DAN SHOLLER: If I treat the network as a SOAP network, I can overlay the network on top of most of the leading middleware. You still have to configure the middleware, but you can configure the middleware topology without getting into the middleware programming model.
CLIENT:If I am writing business code, and I need to interact with something else, I can interact with the SOAP abstraction? I can use it and reliability and security is behind it?
DAN SHOLLER: SOAP is actually at a pretty high level. It’s not necessary at a business network level. But I am at least writing this generic SOAP interface, not a proprietary middleware interface.
------
We Are All Software Vendors Now
CLIENT: If you’re the designer of shared service in an organization, you are essentially the vendor. You have to think about your two customers. This is not a worry just for software vendors any more.
------
DAN SHOLLER: If you were to look at your business processes, and you looked at the processes of your competitors, at the semantic level they are pretty much the same. All these things happen in roughly the same way. What’s different about your company is how your company is designed to do the work. And the app portfolio is developed to match. So the place where you need what is unique to your overall organization is the boundaries where things cross your application.
------
DAN SHOLLER: To share anything, you need to have agreement about four things:
Technology. What Web services are doing is trying to make that as easy as possible.
Syntax. I have to know that purchase orders have line items and headers and footers.
Semantics. Even if I have identical syntax. In one, tax might be included in a given line, and in another, the same line might not include tax.
Usage patterns. So, what an invoice can be used for must be known.
For us to share things, you have to do those things the same way. In a perfect world, you could so that simply if you knew what the other guy did that is different. The shareability of that thing gets eroded the more difference that you tolerate, because then you are forcefitting a veneer on different implementations of the process.
DAN SHOLLER: If I treat the network as a SOAP network, I can overlay the network on top of most of the leading middleware. You still have to configure the middleware, but you can configure the middleware topology without getting into the middleware programming model.
CLIENT:If I am writing business code, and I need to interact with something else, I can interact with the SOAP abstraction? I can use it and reliability and security is behind it?
DAN SHOLLER: SOAP is actually at a pretty high level. It’s not necessary at a business network level. But I am at least writing this generic SOAP interface, not a proprietary middleware interface.
------
We Are All Software Vendors Now
CLIENT: If you’re the designer of shared service in an organization, you are essentially the vendor. You have to think about your two customers. This is not a worry just for software vendors any more.
------
DAN SHOLLER: If you were to look at your business processes, and you looked at the processes of your competitors, at the semantic level they are pretty much the same. All these things happen in roughly the same way. What’s different about your company is how your company is designed to do the work. And the app portfolio is developed to match. So the place where you need what is unique to your overall organization is the boundaries where things cross your application.
------
DAN SHOLLER: To share anything, you need to have agreement about four things:
Technology. What Web services are doing is trying to make that as easy as possible.
Syntax. I have to know that purchase orders have line items and headers and footers.
Semantics. Even if I have identical syntax. In one, tax might be included in a given line, and in another, the same line might not include tax.
Usage patterns. So, what an invoice can be used for must be known.
For us to share things, you have to do those things the same way. In a perfect world, you could so that simply if you knew what the other guy did that is different. The shareability of that thing gets eroded the more difference that you tolerate, because then you are forcefitting a veneer on different implementations of the process.
06 December, 2005 03:00 PM EST
At This Point is Application Integration Just Part of Daily Life?
Posted By: Whit Andrews, Vice President, Gartner Research
Waffle or syrup, waffle or syrup. I’ve been on the lookout for syrup, and I’m finding some pretty sugary stuff. A lot of that is from the vendors, but I’m not saying which bottles are the least satisfying. On the other hand, one of the critical questions I’m trying to find my way toward is whether application integration really is just daily life at this point. I think it is, for plenty of people. But there are some aspects of application integration that seem to be relentlessly new, and still enormous in their potential impact.
So, for example, I have talked to some folks who are asking very detailed (even granular!) questions about integration. They’re looking for advice about what specific products to consider in terms of establishing gateways for the Web services in their enterprise, for example. Or they’re seeking advice about compensation plans, or methods for adopting service registries. But for some people the real necessity of hyper-integration (that’s not a new Gartner term; I intend it only descriptively) is a daunting circumstance that requires some scary strategic steps.
For example, I met a software vendor today facing the challenge for absolute re-architecture of its product. It allows for business processes to be performed in fearsomely heterogeneous environments. Right now, they’re trying to decide what their new shape will be. Will the product look like the Death Star, with an impossible number of inputs and outputs with differing degrees of security but a single platform? Will it be a space shuttle, a discrete unit built to be widely versatile with modules that are swapped onboard and off as necessary? Or will it be a fleet of lesser vessels acting as a swarm?
Decidedly NOT daily life for that vendor. (Actually, I’ve just this instant met another – so think “those vendors,” instead.) EAT YOUR BREAKFAST.
06 December, 2005 12:45 PM EST
How many XML standards are there?
Rita E. Knox, Ph.D. Vice President & Research Director
I’ll distinguish between the “foundational” XML-related standards (what we once called the “family of standards) and the specifications developed using XML.
There are thousands of specifications (at least) written using XML covering many topics and domains – investment, banking health care, human resources, manufacturing, insurance, cave survey data – just about any topic that can be imagined. It only takes an interested party to create a model conforming to the XML specification (the syntax) and the “document” specification --schema or document type definition ---DTD. As long as the model is syntactically correct, it can serve as a specification for whatever domain users agree to employ it. There is no requirement for general agreement on metadata or for tag names dictated by the domain application in what the World Wide Web Consortium (W3C) has published.
If a group wants interoperability there has to be some method of assuring that vocabularies are understood by different applications. By this, we mean that an application can pick up an XML message, understand the entity tags (“company” is a tag they have defined) and have a model they can parse to extract the data the tags identify. This is beyond what the foundational standards groups address.
There are a few of these domain specific standards that have broader adoption than others due to regulatory agency adoption or broad industry consensus. Examples are Extensible Business Reporting Language (XBRL – www.xbrl.org) used by the FDIC and SEC for financial information reporting, modernized e-filing (the standards developed by the IRS) and ACORD in the insurance industry.
Progress for modernized e-filing is discussed in the June 2005 report(PDF) from the Electronic Tax Administration Advisory Committee. Schemas and style sheets published by the IRS to date are now online.
I’ll distinguish between the “foundational” XML-related standards (what we once called the “family of standards) and the specifications developed using XML.
There are thousands of specifications (at least) written using XML covering many topics and domains – investment, banking health care, human resources, manufacturing, insurance, cave survey data – just about any topic that can be imagined. It only takes an interested party to create a model conforming to the XML specification (the syntax) and the “document” specification --schema or document type definition ---DTD. As long as the model is syntactically correct, it can serve as a specification for whatever domain users agree to employ it. There is no requirement for general agreement on metadata or for tag names dictated by the domain application in what the World Wide Web Consortium (W3C) has published.
If a group wants interoperability there has to be some method of assuring that vocabularies are understood by different applications. By this, we mean that an application can pick up an XML message, understand the entity tags (“company” is a tag they have defined) and have a model they can parse to extract the data the tags identify. This is beyond what the foundational standards groups address.
There are a few of these domain specific standards that have broader adoption than others due to regulatory agency adoption or broad industry consensus. Examples are Extensible Business Reporting Language (XBRL – www.xbrl.org) used by the FDIC and SEC for financial information reporting, modernized e-filing (the standards developed by the IRS) and ACORD in the insurance industry.
Progress for modernized e-filing is discussed in the June 2005 report(PDF) from the Electronic Tax Administration Advisory Committee. Schemas and style sheets published by the IRS to date are now online.
06 December, 2005 12:09 PM EST
More Q & A from Ray Wagner's Web Services Security session
Q: How do I carry my identity infra into my WS infra?
A: Well, if it’s just for a simple interaction with a WS, that’s very simple, because a WS can be treated like any other application – does this user have access? Yes? OK. The user can simply be authenticated. But what if I hook into a WS and I interact with that, and then that service needs to interact with others? See Daryl Plummer's “three laws” (This is a related issue to the admonition that services should not be stateful, as possible, because the authentication of a user is something commonly managed in conventional systems through state.) The front end WS needs to have a token service, where it can call and get a token, and that token can then travel with subsequent invocations of services. EAMs don’t create tokens; you generally have to buy an add-on to get that token creation. You can buy it from a major vendor, or you can buy a WS gateway that has it built in.
A: Well, if it’s just for a simple interaction with a WS, that’s very simple, because a WS can be treated like any other application – does this user have access? Yes? OK. The user can simply be authenticated. But what if I hook into a WS and I interact with that, and then that service needs to interact with others? See Daryl Plummer's “three laws” (This is a related issue to the admonition that services should not be stateful, as possible, because the authentication of a user is something commonly managed in conventional systems through state.) The front end WS needs to have a token service, where it can call and get a token, and that token can then travel with subsequent invocations of services. EAMs don’t create tokens; you generally have to buy an add-on to get that token creation. You can buy it from a major vendor, or you can buy a WS gateway that has it built in.
06 December, 2005 11:53 AM EST
Which XML standards must we immediately learn and use?
Rita E. Knox, Ph.D. Vice President & Research Director
For the XML standards – those necessary to make data driven web representations work – there are a number of standards that should be understood
These are not standards to be understood by everyone in the organization but by those doing development work. Applications can provide interfaces that obscure the standards details underlying any particular application.
For industry- specific development, organizations should begin to understand the approaches based using “grammars” with reusable vocabularies. These are
The linguistic approach to developing standards is controversial. Some advocate adopting industry-specific standards because the more general approach has not been fully developed.
Here's some relevant research ...
ASC X12 Proposes CICA for XML Specification Definition - 01/02/03
Here's What's Wrong With XML-Defined Standards - 12/30/02
Can Language Help Build XML-Defined Standards? - 04/10/02
For the XML standards – those necessary to make data driven web representations work – there are a number of standards that should be understood
- XML
- XSL – extensible stylesheet language for presentation (XML has no inherent presentation characteristics)
- XPointer and XLink for referencing and navigating XML entities and structures
- XML Schema
- The security standards published by OASIS (SAML, XACML and others)
- The Web services standards written in XML – SOAP, WSDL, UDDI
These are not standards to be understood by everyone in the organization but by those doing development work. Applications can provide interfaces that obscure the standards details underlying any particular application.
For industry- specific development, organizations should begin to understand the approaches based using “grammars” with reusable vocabularies. These are
- Context Inspire Content Applications (CICA) – work by the ANSI Accredited Standards Committee X12 (ASC)
- The Open Applications Group OAGIS work
The linguistic approach to developing standards is controversial. Some advocate adopting industry-specific standards because the more general approach has not been fully developed.
Here's some relevant research ...
ASC X12 Proposes CICA for XML Specification Definition - 01/02/03
Here's What's Wrong With XML-Defined Standards - 12/30/02
Can Language Help Build XML-Defined Standards? - 04/10/02
06 December, 2005 11:11 AM EST
Comments From User Roundtable Discussion
The following are anecdotes from Daryl Plummer’s user roundtable.
Daryl: Developers develop services and someone else puts them into production. The documentation is somewhat limited. It’s kind of haphazard. It’s not a problem right now, because people don’t have that many services -- but it will be.
------
You have to have someone in your organization who comes from the business side to aid you in determining the proper granularity for a service.
------
Client: We have 60 services, and people are asking for more. The app dev people want all the services developed to be in the registry. I want re-use. But people are telling me if it’s a system service, it shouldn’t be in the registry – that only business services should be in the registry. App dev says you need to support everything, or we will build our own sub-registry.
Daryl: You have people who want to use a registry for things it is not meant to be used for. If they want to use the registry for things like components and modules and things like that, you need a repository. And in the registry, you need to put services. You want people to be able to find the proper things in the registry. You should be able to discover things. You may need to have a federated registry strategy, because you are going to have more than one. You buy a portal, an APS, you will have a registry. There are two forms of registry – a meta-registry and a delegated registry. A meta-registry is like a puppetmaster, with strings reaching down into the subordinate registries. A delegated registry is a daisy chain – you ask, “do you have it?” if not, it reaches to the next one, and that reaches to the next one. Right now, it seems that most registry vendors prefer the delegated registry to the meta-registry.
Client: So nothing wrong with having both system and business services in the same registry?
Daryl: Not as long as you categorize them.
------
Client: What standards allow me to have interoperation among registries?
Daryl: If you have a reg-rep ebXML registry and a UDDI registry, they will interoperate.
Whit: Does that happen in the wild?
Daryl: Not very often.
------
You should never put in your service questions about who should use your service, or why they should use your service. Your electricity should not care whether you are going to dry your hair or cook food.
Daryl: Developers develop services and someone else puts them into production. The documentation is somewhat limited. It’s kind of haphazard. It’s not a problem right now, because people don’t have that many services -- but it will be.
------
You have to have someone in your organization who comes from the business side to aid you in determining the proper granularity for a service.
------
Client: We have 60 services, and people are asking for more. The app dev people want all the services developed to be in the registry. I want re-use. But people are telling me if it’s a system service, it shouldn’t be in the registry – that only business services should be in the registry. App dev says you need to support everything, or we will build our own sub-registry.
Daryl: You have people who want to use a registry for things it is not meant to be used for. If they want to use the registry for things like components and modules and things like that, you need a repository. And in the registry, you need to put services. You want people to be able to find the proper things in the registry. You should be able to discover things. You may need to have a federated registry strategy, because you are going to have more than one. You buy a portal, an APS, you will have a registry. There are two forms of registry – a meta-registry and a delegated registry. A meta-registry is like a puppetmaster, with strings reaching down into the subordinate registries. A delegated registry is a daisy chain – you ask, “do you have it?” if not, it reaches to the next one, and that reaches to the next one. Right now, it seems that most registry vendors prefer the delegated registry to the meta-registry.
Client: So nothing wrong with having both system and business services in the same registry?
Daryl: Not as long as you categorize them.
------
Client: What standards allow me to have interoperation among registries?
Daryl: If you have a reg-rep ebXML registry and a UDDI registry, they will interoperate.
Whit: Does that happen in the wild?
Daryl: Not very often.
------
You should never put in your service questions about who should use your service, or why they should use your service. Your electricity should not care whether you are going to dry your hair or cook food.
06 December, 2005 11:05 AM EST
Three Laws of Services Granularity
Posted By: Whit Andrews, Vice President, Gartner Research
Daryl Plummer’s three laws for establishing proper granularity of services.
1. Relate things that should be together in the same service. So when you get to something, for example, that is two different ways to do the same thing, that means you’re getting into the developer’s head, and not the user’s head, and that is a bad thing. The user does not need two services that provide the same result in different ways.
2. Break out things that are shared services. You see a lot of functions together, but some should be breaking out. If you see that a function is broadly shared, it needs to be a separate service.
3. Use multiple scenarios. You need to decide on when you have enough scenarios, and then you’re done. If you have too many scenarios, you create services that will not be profitably used. If you have too few, your services will be insufficiently granular because you will not have fully visualized the different ways you might use elements of individual services.
And a fourth admonition:
Services should be stateless. Look at the electricity in your home. If every time you turn on your hairdryer, your neighbors’ lights dim, that’s a problem. If you can get to a situation where services are autonomous and independent, that is better. Any individual service should be able to receive a message and act on it independently. It may cause a change to data in the organization that is then relevant to a subsequent service call, but the services don’t need to know about each other.
06 December, 2005 10:24 AM EST
Q&A: Competitive Differentiation
Posted By: Whit Andrews, Vice President, Gartner Research
An attendee submitted this question independently of our presentations, but it could have been asked of one of mine (Web Services Show Business IT).
Q. How do you differentiate yourself from competitors (in, for example, consumer packaged goods) when all the competitors use the same leading edge technology?
A. This is a perfectly reasonable question. Technology can itself be a differentiator (“I make a color TV; he does not”) for only so long before it becomes common and thus commoditized (“My color TV is cheaper than his color TV”). Differentiation in this case relies not so much on the promise of using technology as it does on the promise of using it better than rivals do. So, an enterprise can say, “If you buy my product, it is Wi-Fi compatible – and the way we use that is to provide you access to a private account on our Web site where we publish the data.” That’s better use of Wi-Fi technology than a competitor, because the competitor, say, only puts the data on a local PC attached to the Wi-Fi network. But, anyone can do it. That means it can be made a commodity. Increasingly, what allows a strategy to produce a sustanainable advantage is a network effect. So if the company uploads the data to a Web site that allows the user to participate in a community of like individuals, or that allows the user to access tools that work on the Web site as a platform, that makes sense and it creates a network effect that cannot be gainsaid.
06 December, 2005 09:21 AM EST
Coming Up: Solution Provider Sessions
Today features two rounds of Solution Provider Sessions. The first begins at 9:45AM, the second at 1:45PM. Among the highlights:
9:45AM
Seagull Software: Service-Enabling Legacy Applications for Right-Now Value
Speakers: Greg Mindrum, Vice President, Enterprise Applications, Fifth Third Bank and Ardy Franssen, Vice President Product Management, Seagull Software.
1:45PM
Macromedia: Service-Oriented Client: Using SOA for Great Experiences
Speaker: Andrea Eubanks, Sr. Director, Product Marketing, Macromedia
BEA Systems, Inc.: Service Infrastructure: A Practical Approach to Enterprise SOA
Speaker: Paul Patrick, VP and Chief Architect, BEA AquaLogic.
9:45AM
Seagull Software: Service-Enabling Legacy Applications for Right-Now Value
Speakers: Greg Mindrum, Vice President, Enterprise Applications, Fifth Third Bank and Ardy Franssen, Vice President Product Management, Seagull Software.
1:45PM
Macromedia: Service-Oriented Client: Using SOA for Great Experiences
Speaker: Andrea Eubanks, Sr. Director, Product Marketing, Macromedia
BEA Systems, Inc.: Service Infrastructure: A Practical Approach to Enterprise SOA
Speaker: Paul Patrick, VP and Chief Architect, BEA AquaLogic.
06 December, 2005 08:34 AM EST
Don't Be Afraid
Go ahead -- post comments, questions and critiques on the blog. Use the comments field to let yourself be heard.
Search The Blog
Categories
Archives
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 |
Related Links
Recommended Links
Contact
To learn more, please contact:
Gartner
Office: + 1 203 964 0096
sitefeedback@gartner.com
help@gartner.com
Contact Us Form
Worldwide General Contacts
Gartner
Office: + 1 203 964 0096
sitefeedback@gartner.com
help@gartner.com
Contact Us Form
Worldwide General Contacts