Avoiding Unexpected Cloud Economics Pitfalls

Document ID: | Document Type: ZapFlash
By: Jason Bloomberg | Posted: April 4, 2012

Anybody who is considering a move to the Cloud knows that the greatest economic motivation for Cloud Computing is the pay-as-you-go, pay-for-what-you-need utility computing benefit, right? Deal with spikes in demand much more cost-effectively, the public Cloud service providers gush, since we can spread the load over many customers and pass the savings from our economies of scale on to you. The utility benefit is also a central premise of Private Clouds. Build a Private Cloud for your enterprise, the vendors promise, and you can achieve the same economies of scale as Public Clouds without all that risk.

Unfortunately, what sounds too good to be true usually is. There are a number of gotchas on both the Public and Private Cloud provider sides that limit—or even prevent—organizations from obtaining a full measure of the utility benefit. Let’s go back to economics class and take a closer look.

Clouds Like Water?

Turn on the faucet, only instead of water, you get Cloud. Sounds good, but we use water very differently than we do IT resources. With water, we generally use all we need without worrying about price. We may try to economize, and perhaps we’ll go through the trouble of digging a well if we need to fill our pool, but generally we don’t think about the cost of each flush or load of laundry.

The Cloud is just the opposite. The techies might not be thinking in terms of cost, but the bean counters definitely are. For a CIO or purchasing manager comfortable with entering resource costs into annual budget spreadsheets, the unknown nature of the Cloud bill strikes fear into their hearts—and their wallets. Instead of focusing on lowered costs, their worry is increased costs, since Cloud usage is inherently unpredictable. After all, that’s why landlords don’t like including heating costs in the rent. If the tenants aren’t responsible for keeping costs down then pay-as-you-go inevitably translates into pay more—and just how much more is a mystery until the bill arrives.

Enterprise Cloud customers in particular are beginning to push back, and as a result, Public Cloud providers must change their pricing model accordingly. Unfortunately, there aren’t many alternatives to simple pay-as-you go. One increasingly popular alternative that might ease Cloud purchasers’ minds is for providers to offer a tiered pricing system, with a fixed price for any consumption up to a pre-defined threshold, and pay-as-you-go above that. However, tiered pricing is not a panacea. While such a pricing model is straightforward and gives organizations an increased measure of predictability, it still doesn’t solve the problem of cost spikes.

If tiered pricing sounds more like paying for your mobile phone service than for utilities like water or electricity, you’re right. Not only does this approach reduce perceived risks for Cloud purchasers, it’s also a familiar model for the telcos, all of whom are looking to enter the Cloud market, or at the least, grow their existing Cloud offerings. As a result, ZapThink expects tiered pricing to become the norm for Public Cloud services over time, in spite of its drawbacks.

The irony with tiered Cloud pricing is that the more you require elasticity, the greater the risk that you’ll use up your allotted consumption for the month—but elasticity is the most important benefit of the Cloud. Sure, if you have steady, predictable consumption then tiered pricing is low risk, but if all you want is steady, predictable availability, then chances are keeping your resources on-premise or in a traditional hosted facility will be more cost-effective than moving to the Cloud in the first place, since you’re not particularly worried about spikes in demand.

To make matters worse, not everyone likes tiered pricing, of course. Anyone who’s used up their minutes or texts for the month only to be surprised by an excessive phone bill knows what I’m talking about. It seems the mobile phone providers love to play games with their pricing plans for the sole purpose of squeezing every penny out of their hapless customers. I’m sure we don’t want our Cloud providers to play the same dirty tricks.

The Subtleties of Cloud Churn

While it’s a common water cooler pastime to demonize mobile phone companies for their underhanded pricing policies, there is a downside for the providers as well: the dreaded customer churn. Since it’s relatively easy for customers to change phone providers, especially now that number portability is a reality, shifty behavior on the part of providers simply chases away customers.

Cloud churn is a very real problem for Public Cloud providers as well, as the ease of deprovisioning Cloud resources naturally eases the deprovisioning of customers. But there is an extra complication with Cloud churn that doesn’t have a parallel in the mobile phone world: Cloud resources that are no longer being used but still remain allocated to customers. Depending on the provider’s pricing model, the cost to the customer to maintain such resources may be minimal, but it’s not always clear whether those minimal amounts sufficiently cover the providers’ costs.

For example, I get monthly charges on my credit card from Amazon Web Services (AWS) for a few cents each month. I can’t remember how I signed up for AWS, but the amounts are so minimal, it’s not worth my time or trouble to cancel the service. Do those few cents per month cover Amazon’s costs, assuming there are potentially millions of such customers? Perhaps in Amazon’s case—but for less experienced providers with wafer thin margins, the economics might work to their disadvantage.

Furthermore, the proliferation of such idle instances may be a more significant issue for Private Cloud providers, since they typically have constrained budgets for data center buildouts. Amazon may be building new data centers as fast as they can, but your Private Cloud likely has a maximum practical size given your budget for the effort. The last thing you want is to fill it up with idle resources that various people in your organization can’t be bothered to fully deprovision.

The Demotivation Paradox

For the Public Cloud provider, the obvious solution to the problem of idle resources left over from Cloud churn is to charge enough for those resources. Either the cost will motivate people to fully deprovision them, so the argument goes, or at the very least, they generate enough money so that keeping them around is worthwhile for the providers.

But what if we’re talking about Private Clouds here? The way to charge internal customers for using Cloud resources is via chargebacks. And everybody hates chargebacks. Not only are they a bookkeeping hassle, but they also demotivate the consumption of shared resources. We went through this problem when we dealt with shared Services and SOA, and now we’re sharing Cloud resources, but the problem remains: the whole point to the Private Cloud is to achieve economies of scale across the enterprise, but the only way to make such economies work is if most or all divisions participate. Chargebacks, however, discourage that participation.

As it was with shared Services, the way to compensate for chargebacks is through effective governance: establish and enforce Cloud consumption policies that counteract the demotivational effects of chargebacks, and come up with a way to motivate people to follow such policies. While you’re at it, formulate policies governing the deprovisioning of instances that no one needs any more. But in the Cloud, such governance is especially challenging because of the diversity of resources and their corresponding consumption scenarios: policies for provisioning virtual machines as part of IaaS is quite different from, say, provisioning development tools on PaaS. It will take organizations with Private Clouds a good bit of trial and error to get the balance right.

The ZapThink Take

Another downside to the idle-resource-masquerading-as-paying-customer problem is that it makes it very difficult for financial analysts to gauge the health of a Public Cloud provider. This obfuscation can skew traditional metrics like number of customers or revenue per customer, and the distortion may be different from one provider to another. Combine the resulting confusion with the lean profit margins in today’s Cloud space, as providers push their prices ever lower to encourage growth, and you have a recipe for disaster. An ostensibly healthy Cloud provider might suddenly collapse due to a foundation of underperforming customers and idle resources.

Private Clouds face a corresponding problem, as executives review the financials for the Cloud effort. ZapThink predicts a backlash against Private Clouds in the next year or two, as vendors underdeliver on their Cloud promises—not necessarily through any fault of their technology, but rather because the reality of achieving cost advantages with Private Clouds is far more difficult than the vendors’ and analysts’ spreadsheets might have you believe.

If you’d like to learn more about the subtleties of Cloud economics, I’d be happy to have a deeper discussion at Cloud Expo in New York or The Business of Cloud Computing in Dallas, or any of the other conferences I’ll be presenting at. Please drop me a line if you’re interested. I’m curious as to whether issues of Cloud churn or Private Cloud demotivation are concerns in your organization.

------------------------------------------------------------------------
Call for Tutorial Proposals
http://iswc2012.semanticweb.org/call-tutorial-proposals
In conjunction with the
               11th International Semantic Web Conference
                http://iswc2012.semanticweb.org/
               Boston - USA
               November 11-15, 2012
------------------------------------------------------------------------

The International Semantic Web Conference (ISWC) is the primary
conference on the use of semantic technologies on the web and linked
data, constantly attracting a high number of high quality submissions
participants from academia and industry. It brings together
researchers from different areas of computer science, like artificial
intelligence, databases, natural language process, information
retrieval and others that aim at the development and use of novel
technologies for accessing, interpreting and using information on the
web in a more effective way. Besides the main technical program, ISWC
will host a number of tutorials on all major topics related to the
Semantic Web / Linked Data research, enabling attendees to fully
appreciate current issues, main schools of thought, and possible
application areas.


In order to meet these goals, tutorials should address topics that
satisfy the following criteria:

- the topic falls in the general scope of ISWC 2012,
- there is a clear focus on a specific technology, problem or
- application, and
- there is a sufficiently large community interested in the topic.


In particular, we encourage the submission of tutorial proposals on:

- fundamental problems of the Semantic Web/Linked Data such as
ontology mining, heterogeneity, scalability and distribution,
- applications of Semantic Web technologies in specific domains and
trends,
- important enabling technologies and their adaptation to the needs of
the Semantic Web,
- aspects of semantic web research that have been neglected so far,
and
- techniques from other research fields that are of relevance for
Semantic Web research (e.g., machine learning, NLP).


Additionally, we expect tutorials to:

- have practical parts in terms of examples or preferably exercises to
be carried out by the participants

Proposers of accepted tutorials have to prepare a tutorial webpage
containing detailed information about the tutorial.


Submission Guidelines
-----------------------------------
Tutorial proposals should be submitted via EasyChair
https://www.easychair.org/conferences/?conf=iswc2012tutorials as a
single PDF file of no more than 5 pages and should contain the
following information:
- Title
- Abstract (200 words)
- Motivation on why the topic is of particular interest at this time
- Overview of content, description of the aims, presentation style,
potential/preferred prerequisite knowledge
- Indication on whether the tutorial should be considered for a
half-day or full-day
- Intended audience and expected number of participants
- Audio-visual or technical requirements and any special room
requirements (for hands-on sessions, any software needed and download
sites must be provided by the tutorial presenters)
- Data of the presenters (name, affiliation, email address, homepage)
and short description of their expertise, experiences in teaching and
in tutorial presentation


Important Dates
--------------------------
- Event:                                 November 11 & 12, 2012
- Tutorial proposal due:        May 6, 2012
- Tutorial Notifications:        May 20, 2012


Chairs
--------------
  Claudia d�Amato, Unversity of Bari
  Thomas Scharrenbach, University of Zurich

Cloud-Oriented Architecture and the Internet of Things

Document ID: | Document Type: ZapFlash
By: Jason Bloomberg | Posted: April 18, 2012

Quick quiz for all your Cloud aficionados out there: what’s missing from the NIST definition of Cloud Computing? To make this challenge easy for you, here’s the definition: “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.” Give up? What’s missing is any mention of data centers. Sure, today’s Clouds typically consist of resources in data centers, running one way or another on racks full of physical servers. But there’s nothing in the definition of Cloud that specifies anything about the physical location of Cloud resources.

Look at the NIST definition again. If you’ve seen this definition before, you may notice a new word that NIST presumably added after their now-seminal definition entered the blogosphere: ubiquitous. I don’t know what fevered discussion led to the late inclusion of this word, but its addition is telling. After all, it doesn’t matter how many data centers you have, they will never be ubiquitous. But NIST in their wisdom never intended the resources in the definition of Cloud to be limited to data centers, or for the list of Cloud resources to be exhaustive, for that matter. We could add, say, mobile phones, automobiles, factory equipment, and the proverbial fridge to the list, and as long as we have the convenient, on demand network access as well as the automated provisioning and deprovisioning, then this entire “Internet of Things” is part of the Cloud.

This globally ubiquitous interpretation of Cloud Computing should be especially exciting to architects, since it falls to them to understand all the technology resources at the disposal of the organization and how to address business challenges with such resources. From ZapThink’s perspective, the Internet of Things provides a grand stage for our ZapThink 2020 vision to play out. There are fundamental differences, after all, between data centers and the Internet of Things, which means that fundamental Cloud architecture principles must also transform to support this new reality. This transformation promises to be truly disruptive—a true paradigm shift as we figure out what it means to implement what we call Cloud-Oriented Architecture.

Understanding Resources

Since Cloud-Oriented Architecture (COA, natch) extends past the data center to the ubiquitous resources of the Internet of Things, we must expand our definition of resource beyond the list in the NIST definition of Cloud Computing. The obvious place to go for such a definition is the REST architectural style, which defines a resource as “an entity or capability on a network.” Note that resources in “traditional” (i.e., data center-based) Clouds are a subset of this broader definition of resource. In RESTful terms, Web pages, php scripts, and ASP/JSP pages, for example, can all be resources. We wouldn’t normally lump such resources in with servers, storage, networks, and the other Cloud resources we typically talk about in the Cloud context. But in COA, where we free the Cloud from the data center, anything we can give a Uniform Resource Indicator (URI) to can be a resource. And of course, with IPv6 we have plenty of IP addresses to go around, where anything might have one—and if a thing has an IP address, it can certainly have one (or more) URIs.

So far, so good, but beware a pitfall in our path: Resource-Oriented Architecture (ROA). ROA takes certain elements of REST and recasts traditional integration by leveraging RESTful APIs. ROA has its place to be sure, as it resolves some of the knottier problems of Web Services-based SOA, but ROA is decidedly not COA. In fact, they are at opposite ends of a philosophical spectrum that underscores the paradigm shift inherent in moving to the Cloud.

ROA + HOA = COA

In fact, COA is really more about Hypermedia-Oriented Architecture (HOA) than ROA. The point to assigning URIs to resources, after all, is to build distributed hypermedia applications, which are the point of REST. This is where you need to make a conceptual leap: while the traditional notion of a hypermedia app is a glorified Web site, with COA, applications consist of hyperlinked resources of any type, from mobile apps to traffic signals.

We’ve been networking traffic signals for decades, of course, so what’s really new here? The answer: control. Traditional distributed applications have centralized control, while distributed hypermedia apps do not. In fact, this distribution of control is what we mean by the prefix “hyper,” and is what makes the Web what it is today. Remember the green screen menu-based interfaces from the 1960s and 1970s? You clicked on a menu item to load a different screen. But those links weren’t hyperlinks, because they couldn’t take you to a screen (or page) on a different system. The secret of hypertext (now hypermedia) is that it enables the Web to be worldwide, with no central point of control.

Fast forward to the present, and today’s world of distributed computing has a schizophrenic nature: the world of enterprise IT with its inherently centralized control, and the world of the Web—horizontally scalable, partition tolerant, and lacking a single point of control. And now we have the Cloud, and COA bringing the two together. It’s time to bring enterprise IT into the 21^st century, kicking and screaming. We managed to survive the rise of the Web itself, as IT managers begrudgingly provided Internet access to employees’ desktops. Now with the ubiquitous penetration of mobile technology (there’s the U word again!), those managers are once again struggling to maintain control, lest the enterprise rank and file download some malicious app or other malware that brings the organization to its knees.

This situation is only going to get worse (or better, depending on your point of view). Mobile devices are only going to get more powerful. The Internet of Things will continue to grow past our smartphones as Cloud resources penetrate every aspect of our daily lives. The cybersecurity implications are profound, let alone the day-to-day issues of governance. Enterprises who don’t rise to the challenge and revamp their thinking about how technology contributes to the operations of the business are sticking their heads in the sand.

We encouraged IT organizations to loosen the ties of control as far back as 2008, when we explained Why Today is a Perfect Time for No-ESB SOA. Move the control to the Service composition level, we argued, and free yourself from the limitations and inflexibility of a middleware-centric approach to integration. Four years later, this move to lightweight, decentralized Business Process Management (BPM) is still a work in progress, in part because the BPM tools on the market follow the old middleware-centric patterns, but also because the marketplace is not yet ready for the paradigm shift that we’re now in the midst of.

Today’s question, therefore, is whether the market—that is, you—are ready for COA. Are you ready to free the Cloud from the data center? Are you ready to give up centralized security in favor of a lightweight, federated approach? Are you ready to discard the API-centric ROA in favor of the truly RESTful HOA? Perhaps. But such changes in thinking take time. But ready or not, change is afoot. Be an ostrich and continue to do things the old way at your peril.

The ZapThink Take

ZapThink has been piecing this story together for years now, and we’ll pull all the threads together in our upcoming book, The Agile Architecture Revolution (John Wiley & Sons, 2013). As we move away from vertically scalable enterprise applications that require and promote central control to a Cloud of distributed resources that cross organizational boundaries, organizations will need to rethink—and in many cases, reinvent—their approach to governance, security, scalability, and change. In other words, a new way of looking at architecture.

We don’t call this shift a revolution lightly. True revolutions require paradigm shifts: throwing out old ways of thinking and replacing them with entirely different approaches. As a result, paradigm shifts suggest some manner of disruption and discontinuity that in turn differentiates revolutionary change from evolutionary change. Furthermore, revolutionary change is difficult to identify while it’s happening. People usually aren’t sure they’ve been through a revolution until after the fact. Evolutionary change, on the other hand, is far easier to detect, and can move so fast that people confuse it with a true paradigm shift.

We got it wrong in the dot.com era. The hype around the “New Economy” turned out to be just that—hype. The Web turned out to be more of a new marketing channel than a true paradigm shift. The Agile Architecture Revolution, however, is more subtle, because it involves so many different types of change across so many different areas of endeavor. We won’t be sure till we’re done, of course, but the disruption is already upon us. Don’t be an ostrich.

========================================================
      6th Int'l Workshop on Modular Ontologies (WoMO)
               Graz, Austria, July 24, 2012
            held in conjunction with FOIS 2012

              --- Second Call for Papers ---
========================================================
            Submission deadline: May 11, 2012
========================================================

INVITED SPEAKERS:

* Thomas Eiter, Vienna University of Technology, Austria
   Title TBA

* Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy
   Multi context logics: a formal support for structuring knowledge and
beliefs (Tentative title)


http://www.informatik.uni-bremen.de/~ts/womo2012

MODULARITY, studied for years in software engineering, allows
mechanisms for easy and flexible reuse, generalization, structuring,
maintenance, design patterns, and comprehension. In formal and applied
ontology, modularity is central to reducing the complexity of
designing and understanding ontologies, and to facilitating ontology
verification, reasoning, development, maintenance and integration.

Recent research on ontology modularity shows substantial progress in
foundations of modularity, techniques of modularization and modular
development, distributed reasoning and empirical evaluation. These
results provide a solid foundation and exciting prospects for further
research and development.

The workshop continues a series of successful events that have been an
excellent venue for practitioners and researchers to discuss latest
and current work; the most recent WoMOs were held at FOIS 2010 and
ESSLLI 2011.

TOPICS include, but are not limited to:

- What is modularity?: kinds of modules and their properties; modules
vs. contexts; design patterns; granularity of representation;

- Logical/foundational studies: conservativity; modular ontology
languages; reconciling inconsistencies across modules; formal
structuring of modules; heterogeneity;

- Algorithmic approaches: distributed and incremental reasoning;
modularization and module extraction; sharing, linking, reuse;
privacy; evaluation of modularization approaches; complexity of
reasoning; implemented systems;

- Applications: semantic web; life sciences; bio-ontologies; natural
language processing; space and time; ambient intelligence; social
intelligence; collaborative ontology development and ontology
versioning.

IMPORTANT DATES

Paper Submission: May 11, 2012
Notification: June 12, 2012
Camera ready: July 1, 2012
Workshop: July 24, 2012

SUBMISSION GUIDELINES:

We welcome submissions on modularity in a broad sense. The workshop is
open to papers of theoretical or practical nature. Submissions should
be of up to 11 pages in length, formatted according to Springer LNCS
style (see http://www.springer.com/comp/lncs/Authors.html ), prepared
in PDF format and submitted no later than May 11, 2012, through the
EasyChair Submission System (see
http://www.easychair.org/conferences/?conf=womo2012 ).

Submitted papers will be peer-reviewed by members of the program
committee. Accepted papers will be made available in the proceedings
to be published electronically in the CEUR Workshop Proceedings series
(see http://www.ceur-ws.org ).

(Find the WoMO 2010 and 2011 proceedings here
http://www.booksonline.iospress.nl/Content/View.aspx?piid=16268 and
http://www.booksonline.iospress.nl/Content/View.aspx?piid=20369 )

WORKSHOP CHAIRS:

Thomas Schneider, University of Bremen, Germany
Dirk Walther, Technical University of Madrid (UPM), Spain

PROGRAM COMMITTEE:

Kenneth Baclawski, Northeastern University, Boston, MA, USA
Stefano Borgo, Italian National Research Council, Trento, Italy
Oscar Corcho, Universidad Politecnica de Madrid, Spain
Bernardo Cuenca Grau, University of Oxford, UK
Mike Dean, Raytheon BBN Technologies, Ann Arbor, MI, USA
Silvio Ghilardi, Universita degli Studi di Milano, Italy
Michael Gruninger, University of Toronto, Canada
Janna Hastings, EMBL-EBI, Cambridge, UK
Robert Hoehndorf, University of Cambridge, UK
Boris Konev, University of Liverpool, UK
Roman Kontchakov, Birkbeck College, London, UK
Thomas Meyer, Meraka Institute, CSIR, Pretoria, South Africa
Till Mossakowski, University of Bremen, Germany
Immanuel Normann, Birkbeck College, London, UK
Leo Obrst, MITRE, McLean, VA, USA
Adrian Paschke, Free University of Berlin, Germany
David Perez del Rey, Universidad Politecnica de Madrid, Spain
Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy

ESB is a major components of SOA infrastructure.
In order to address the business unit and their corresponding application, vertical and horizontal integration needs using an enterprise service bus (ESB).

We have to have message flows, mediation, routing, and transformation using the ESB and a registry and shared services.

For example, To achieve the strategic goal: “to improve integration both in efficiency (e.g., reduced cost of integration and improve productivity) and effectiveness (e.g., improve flexibility and respond faster to business demands).”

We have to adopt an enterprise service bus (ESB), registry and shared services.   

Many in the IT department may not understand the difference between enterprise application integration versus using an ESB for service orientation.

In the business units and their liaisons, resistance may exist to sharing services because they see a potential negative impact on the reliance of other teams outside control of their vertical business unit for project delivery.

Others in the organization might not understand SOA, or they might have both negative and positive opinions about it.

Still others might have seen the failure of past projects that promoted sharing of software assets.

In each case, this points to the need for communication of the strategic objective before, during, and after the implementation of the ESB and its corresponding processes and organizational changes.

 
All the best

Ashraf Galal

The  2011 Readership Survey results are not surprising - people say what they do, not think. It is known for years that ESB is not needed if an enterprise already has messaging, data transformation and security-and-application servers...

I personally believe that the minimal SOA execution infrastructure should include only registries and repositories that are specially crafted for services.

Also, to Mike Rosen's comment, if we would go after what people referred to regarding SOA, we were never created service-oriented architecture.

- Michael

From: Gervas Douglas <gervas.douglas@...>

To: service-orientated-architecture@yahoogroups.com
Sent: Friday, April 20, 2012 11:55 AM
Subject: [service-orientated-architecture] Earls on Defining SOA Infrastructure

<<Is it possible to define SOA infrastructure?

Alan Earls

• E-mail
• Print
• A
• AA
• AAA
• LinkedIn
• Facebook
• Twitter
• Share This
• RSS
• Reprints

What do people mean when they say SOA infrastructure? Service-oriented architecture may be a way of thinking, but it is also represented in a range of architectural practices such as message queuing middleware and enterprise service bus (ESB). Certain types of software may be used like Legos in a typical SOA project, but there is little consensus on what counts as SOA infrastructure.

Indeed, SearchSOA.com recently conducted a 2011 Readership Survey that solicited views on which of the contenders mattered most. The range of responses was striking as was the lack of any clear “winner.” For instance, none of the seven different technologies described earned more than a 50% score and the lowest scores were in the mid-20% range. (Survey choices were message queuing middleware; enterprise service bus (ESB); publish & subscribe middleware; SOA and Web services governance; test or management software; services registry/repository; service orchestration tools; and SOA appliances/XML gateways.) 

In other words, there are a lot of choices and little agreement about what’s best. However, of the choices out there, message queuing middleware seems to be leading the pack, followed closely by ESB (see Figure 1).

Figure 1: Message queuing leads technologies for SOA infrastructure; others are close behind.

Mark Eisenberg, a former member of Microsoft’s Azure team and now director of Fino Consulting says it is no wonder there is confusion – SOA is simply too big of a concept. “I think that’s why it has had limited success in the enterprise,” he says. In his view, ESBs and similar kinds of technology are implementation details. “ESB is a way for services to communicate without having to know the specifics of how to contact the services,” he says. In that sense, he says, ESBs are simply an infrastructure element.

The long list of possible SOA infrastructure elements can make implementation difficult. Eisenberg says that the original “dream” for SOA was that you would build a service, you would register it, and then some other service that needed that functionality would simply “go there and say, I need that and simply connect to that service.” However, in fact, that represents a complex undertaking. In Eisenberg’s view, there is no simple “right” answer to the question of which technology is most relevant to the concept of SOA infrastructure. “Message queues are a very fundamental computer concept and services buses are also very fundamental to SOA,” he says.

The long list of possible SOA infrastructure elements can make implementation difficult.

A similar take on the question comes from Mike Rosen, an industry expert in business architecture, SOA and enterprise architecture and a practice director for Business and Enterprise Architecture at the Cutter Consortium (an IT Research Firm). He says, in general, when people refer to SOA infrastructure, they mean the product platform that the SOA runs on, such as an ESB. “Occasionally, if taken from a high level business perspective, they mean the entire SOA stack, including the business services, but that would be an unusual interpretation of the term,” says Rosen. Still, “interpretation” is what’s at issue.

“While ESB is probably the most relevant, it of course depends on the context of the usage and requirements,” he adds. Further, Rosen points out that ESB and queuing are not architectural 'practices', but rather an implementation of the infrastructure. “Also, virtually all ESB products include queuing as an underlying capability,” he adds.

So, is there a way to parse the SOA and infrastructure concept a little further? Possibly. According to Nate Minshew, enterprise architect/principal consultant at Asynchrony Solutions, Inc., who relied on Department of Defense definitions related to SOA to provide a degree of clarity on a recent project. “In our project we built a service taxonomy so we could classify the different services to provide a mechanism to quickly identity a service based on what functional purpose it had. The taxonomy was primarily a high level category of process services.

Minshew says decisions about infrastructure were based on the same standards taxonomy. “We wanted to identify specific taxonomy and DOD had certain standards mandated from the DOD Standards Repository. A lot of those were fairly incomplete, he says.  but there was room to make recommendations based on them such as SOAP 1.2, PKI standards and so on,” he explains.

In turn, says Minshew, he hoped to get clearer definitions of infrastructure components, like “what is an ESB?” “We found that a lot of vendors market products as ESBs but what they call an ESB also has services and governance and management tools – we wanted to look for more granular pockets of technology. Our definition of an ESB was the messaging infrastructure and the ability to do composition for web services and the routing and processing that goes on,” he says.

In short, Minshew notes, infrastructure can take many forms and no one term suffices to describe it.>>

You can find this at: http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&asrc=EM_USC_17087237&Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&

Gervas

How to manage reusable assets according architecture layers.
http://caminao.wordpress.com/2012/04/09/cases4reuse/

------------------------------------------------------------------------
Call for Tutorial Proposals
http://iswc2012.semanticweb.org/call-tutorial-proposals
In conjunction with the
               11th International Semantic Web Conference
                http://iswc2012.semanticweb.org/
               Boston - USA
               November 11-15, 2012
------------------------------------------------------------------------

The International Semantic Web Conference (ISWC) is the primary
conference on the use of semantic technologies on the web and linked
data, constantly attracting a high number of high quality submissions
participants from academia and industry. It brings together
researchers from different areas of computer science, like artificial
intelligence, databases, natural language process, information
retrieval and others that aim at the development and use of novel
technologies for accessing, interpreting and using information on the
web in a more effective way. Besides the main technical program, ISWC
will host a number of tutorials on all major topics related to the
Semantic Web / Linked Data research, enabling attendees to fully
appreciate current issues, main schools of thought, and possible
application areas.


In order to meet these goals, tutorials should address topics that
satisfy the following criteria:

- the topic falls in the general scope of ISWC 2012,
- there is a clear focus on a specific technology, problem or
- application, and
- there is a sufficiently large community interested in the topic.


In particular, we encourage the submission of tutorial proposals on:

- fundamental problems of the Semantic Web/Linked Data such as
ontology mining, heterogeneity, scalability and distribution,
- applications of Semantic Web technologies in specific domains and
trends,
- important enabling technologies and their adaptation to the needs of
the Semantic Web,
- aspects of semantic web research that have been neglected so far,
and
- techniques from other research fields that are of relevance for
Semantic Web research (e.g., machine learning, NLP).


Additionally, we expect tutorials to:

- have practical parts in terms of examples or preferably exercises to
be carried out by the participants

Proposers of accepted tutorials have to prepare a tutorial webpage
containing detailed information about the tutorial.


Submission Guidelines
-----------------------------------
Tutorial proposals should be submitted via EasyChair
https://www.easychair.org/conferences/?conf=iswc2012tutorials as a
single PDF file of no more than 5 pages and should contain the
following information:
- Title
- Abstract (200 words)
- Motivation on why the topic is of particular interest at this time
- Overview of content, description of the aims, presentation style,
potential/preferred prerequisite knowledge
- Indication on whether the tutorial should be considered for a
half-day or full-day
- Intended audience and expected number of participants
- Audio-visual or technical requirements and any special room
requirements (for hands-on sessions, any software needed and download
sites must be provided by the tutorial presenters)
- Data of the presenters (name, affiliation, email address, homepage)
and short description of their expertise, experiences in teaching and
in tutorial presentation


Important Dates
--------------------------
- Event:                              November 11 & 12, 2012
- Tutorial proposal due:        May 6, 2012
- Tutorial Notifications:        May 20, 2012


Chairs
--------------
  Claudia d�Amato, Unversity of Bari
  Thomas Scharrenbach, University of Zurich

Follow ISWC 2012 on Twitter
https://twitter.com/#!/iswcboston

Deconstructing Agile

Document ID: | Document Type: ZapFlash
By: Jason Bloomberg | Posted: May 4, 2012

Every specialization has its own jargon, and IT is no different—but many times it seems that techies love to co-opt regular English words and give them new meanings. Not only does this practice lead to confusion in conversations with non-techies, but even the techies often lose sight of the difference between their geek-context definition and the real world definition that “normal” people use.

In our Licensed ZapThink Architect course, for example, we spend far too long defining Service. This word has far too many meanings, even in the world of IT—and most of them have little to do with what the rest of the world means by the term. Even words like business have gone through the techie redefinition process (in techie-speak, business means everything that’s not IT).

It comes as no surprise, therefore, that techies have hijacked the word Agile. In common parlance, someone or something is agile if it’s flexible and nimble, especially in the face of unexpected forces of change. But in the world of technology, Agile (Agile-with-a-capital-A) refers to a specific category of software development methodology. This definition dates to 2001 and the establishment of the Agile Manifesto, a set of general principles for building better software. In the intervening decade, however, Agile has taken on a life of its own, as Scrum, Extreme Programming, and other Agile methodologies have found their way into the fabric of IT.

Such methodologies indubitably have strengths, to be sure—but what we have lost in the fray is a sense of what is particularly agile about Agile. This point is more than simple semantics. What’s missing is the fundamental connection to agility that drove the Manifesto in the first place. Reestablishing this connection, especially in the light of new thinking on business agility, is essential to rethinking how IT meets the ever-changing requirements of the business.

The Paradox of Business Requirements

How do techies know what to build? Simple: ask the stakeholders (the “business”) what they want. Make sure to write down all their requirements in the proverbial requirements document. Now build something that does what that document says. After you’re done, get your testers to verify that what you’ve built is what the business wanted.

Or what they used to want.

Or what they said they wanted.

Or perhaps what they thought they said they wanted.

And therein lies the rub. The expectation that the business can completely, accurately, and definitively describe what they want in sufficient detail so that the techies can build it precisely to spec is ludicrously unrealistic, even though such a myth is inexplicably persistent in many enterprise IT shops to this day. In fact, the myth of complete, well-defined requirements is at the heart of what we call the “waterfall” methodology, illustrated in the figure below.

In reality, it is far more common for requirements to be poorly communicated, poorly understood, or both. Or even if they’re properly communicated, they change before the project is complete. Or most aggravating at all, the stakeholder looks at what the techies have built and says, “yes, that’s exactly what I asked for, but now that I see it, I realize I want something different after all.”

Of course, such challenges are nothing new; they gave rise to the family of iterative methodologies a generation ago, including the Spiral methodology, IBM’s Rational Unified Process, and all of the Agile methodologies. By taking an iterative approach that involves the business in a more proactive way, the reasoning goes, you lower the risk of poorly communicated, poorly understood, or changing business requirements. The figure below illustrates such a project.

In the above diagram the looped arrows represent iterations, where each iteration reevaluates and reincorporates the original requirements with any further input the business wants to contribute. But even with the most agile of Agile development teams, the process of building software still falls short. It doesn’t seem to matter how expert the coders, how precise the stakeholders, or how perfect the development methodology are, the gap between what the business really needs and what the software actually does is still far wider than it should be. And while many business stakeholders have become inured to poorly fitting software, far more are becoming fed up with the entire situation. Enough is enough. How do we get what we really want and need from IT?

Changing the Way We Deal with Change

Even the most Agile development teams still struggle with the problem of changing requirements. If requirements evolve somewhat during the course of a project, then a well-oiled Agile team can generally go with the flow and adjust their deliverables accordingly, but one way or the other, all successful software projects come to an end. And once the techies have deployed the software, they’re done.

Have a new requirement? Fund a separate project. We’ll start over and include your new requirements in the next version of the project we already finished, unless it makes more sense to build something completely new. Sometimes techies can tweak existing capabilities to meet new requirements quickly and simply, but more often than not, rolling out new versions of existing software is a laborious, time-consuming, and risky process. If the software is commercial off the shelf (COTS), the problem is even worse, since the vendor must base new updates on requirements from many existing customers, as well as their guesses about what new customers will want in the future. The figure below illustrates this problem, where the software project represented by the box can be as Agile as can be, and yet the business still doesn’t get the agility it craves. It seems that Agile may not be so agile after all.

The solution to this problem is for the business to specify its requirements in a fundamentally different way. Instead of thinking about what it wants the software to do, the business should specify how agile it expects the software to be. In other words, don’t ask for software that does A, B, C or whatever. Instead, tell your techies to build you something agile.

We call this requirement the metarequirement of agility—a metarequirement because agility applies to other requirements: “build me something that responds to changing requirements” instead of “build me something that does A, B, and C.” If we can build software that satisfies this metarequirement, then our diagram looks quite different:

Because the software in the above diagram is truly agile, it is possible to meet new requirements without having to change the software. Whether the process inside the box is Agile is beside the point. Yes, perhaps taking an Agile approach is a good idea, but it doesn’t guarantee the resulting software is agile.

The ZapThink Take

Sounds promising, to be sure, but the devil is in the details. After all, if it were easy to build software that responded to changing requirements, then everybody would be doing it. But there’s a catch. Even if we built software that could potentially meet changing requirements, that doesn’t mean that it actually would—because meeting changing requirements is part of how you would use the software, rather than part of how you build it. In other words, the users of the software must actually be part of the agile system. The box in the diagram above doesn’t just represent software anymore. It represents a system consisting of software and people.

Such software/people systems of systems are a long-standing fixture in ZapThink thinking. In fact, ZapThink frequently talks about agility in the context of SOA. With SOA, IT publishes business Services that represent IT capabilities and information, and the business drives the consumption and composition of those Services. In mature SOA deployments, policies drive the behavior of Services and their compositions. If you want to change the behavior, change the policy. In other words, SOA is governance-driven, and governance applies to the behavior of both people and technology.

Agile architectural approaches like SOA, therefore, focus on implementing governance-driven technology/people systems that support changing requirements over time. The challenge, of course, is actually building such systems that meet the business agility metarequirement. Where in this system do we put the agility? It’s not in any part of the system. Instead, it’s a property of the system as a whole—what we call an emergent property. If you’ve been following ZapThink, you’ve heard this story before: business agility is an emergent property of the combination technology/human system we call the enterprise.

In other words, we started by deconstructing the notion of Agile and ended up with Enterprise Architecture, because what is Enterprise Architecture but best practices for designing and building the enterprise to better meet changing requirements over time? This is not the static, framework-centric EA from years past that presuppose a final, ideal state for the enterprise. We’re talking about a new way of thinking about what it means to architect technology-rich organizations to be inherently agile.

========================================================
      6th Int'l Workshop on Modular Ontologies (WoMO)
               Graz, Austria, July 24, 2012
            held in conjunction with FOIS 2012

              --- Third Call for Papers ---
========================================================
            Submission deadline: May 11, 2012
========================================================

INVITED SPEAKERS:

* Thomas Eiter, Vienna University of Technology, Austria
   Title TBA

* Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy
   Multi context logics: a formal support for structuring knowledge and
beliefs (Tentative title)


http://www.informatik.uni-bremen.de/~ts/womo2012

MODULARITY, studied for years in software engineering, allows
mechanisms for easy and flexible reuse, generalization, structuring,
maintenance, design patterns, and comprehension. In formal and applied
ontology, modularity is central to reducing the complexity of
designing and understanding ontologies, and to facilitating ontology
verification, reasoning, development, maintenance and integration.

Recent research on ontology modularity shows substantial progress in
foundations of modularity, techniques of modularization and modular
development, distributed reasoning and empirical evaluation. These
results provide a solid foundation and exciting prospects for further
research and development.

The workshop continues a series of successful events that have been an
excellent venue for practitioners and researchers to discuss latest
and current work; the most recent WoMOs were held at FOIS 2010 and
ESSLLI 2011.

TOPICS include, but are not limited to:

- What is modularity?: kinds of modules and their properties; modules
vs. contexts; design patterns; granularity of representation;

- Logical/foundational studies: conservativity; modular ontology
languages; reconciling inconsistencies across modules; formal
structuring of modules; heterogeneity;

- Algorithmic approaches: distributed and incremental reasoning;
modularization and module extraction; sharing, linking, reuse;
privacy; evaluation of modularization approaches; complexity of
reasoning; implemented systems;

- Applications: semantic web; life sciences; bio-ontologies; natural
language processing; space and time; ambient intelligence; social
intelligence; collaborative ontology development and ontology
versioning.

IMPORTANT DATES

Paper Submission: May 11, 2012
Notification: June 12, 2012
Camera ready: July 1, 2012
Workshop: July 24, 2012

SUBMISSION GUIDELINES:

We welcome submissions on modularity in a broad sense. The workshop is
open to papers of theoretical or practical nature. Submissions should
be of up to 11 pages in length, formatted according to Springer LNCS
style (see http://www.springer.com/comp/lncs/Authors.html), prepared
in PDF format and submitted no later than May 11, 2012, through the
EasyChair Submission System (see
http://www.easychair.org/conferences/?conf=womo2012).

Submitted papers will be peer-reviewed by members of the program
committee. Accepted papers will be made available in the proceedings
to be published electronically in the CEUR Workshop Proceedings series
(see http://www.ceur-ws.org).

(Find the WoMO 2010 and 2011 proceedings here
http://www.booksonline.iospress.nl/Content/View.aspx?piid=16268 and
http://www.booksonline.iospress.nl/Content/View.aspx?piid=20369)

WORKSHOP CHAIRS:

Thomas Schneider, University of Bremen, Germany
Dirk Walther, Technical University of Madrid (UPM), Spain

PROGRAM COMMITTEE:

Kenneth Baclawski, Northeastern University, Boston, MA, USA
Stefano Borgo, Italian National Research Council, Trento, Italy
Oscar Corcho, Universidad Politecnica de Madrid, Spain
Bernardo Cuenca Grau, University of Oxford, UK
Mike Dean, Raytheon BBN Technologies, Ann Arbor, MI, USA
Silvio Ghilardi, Universita degli Studi di Milano, Italy
Michael Gruninger, University of Toronto, Canada
Janna Hastings, EMBL-EBI, Cambridge, UK
Robert Hoehndorf, University of Cambridge, UK
Boris Konev, University of Liverpool, UK
Roman Kontchakov, Birkbeck College, London, UK
Thomas Meyer, Meraka Institute, CSIR, Pretoria, South Africa
Till Mossakowski, University of Bremen, Germany
Immanuel Normann, Birkbeck College, London, UK
Leo Obrst, MITRE, McLean, VA, USA
Adrian Paschke, Free University of Berlin, Germany
David Perez del Rey, Universidad Politecnica de Madrid, Spain
Uli Sattler, University of Manchester, UK
Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy

========================================================
      6th Int'l Workshop on Modular Ontologies (WoMO)
               Graz, Austria, July 24, 2012
            held in conjunction with FOIS 2012

              --- Final Call for Papers ---
========================================================
    +++ EXTENDED SUBMISSION DEADLINE: May 18, 2012 +++
========================================================

+++ Following requests, we have extended the submission deadline to
MAY 18, 2012. +++

INVITED SPEAKERS:

* Thomas Eiter, Vienna University of Technology, Austria
   Title TBA

* Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy
   Multi context logics: a formal support for structuring knowledge and
beliefs (Tentative title)


http://www.informatik.uni-bremen.de/~ts/womo2012

MODULARITY, studied for years in software engineering, allows
mechanisms for easy and flexible reuse, generalization, structuring,
maintenance, design patterns, and comprehension. In formal and applied
ontology, modularity is central to reducing the complexity of
designing and understanding ontologies, and to facilitating ontology
verification, reasoning, development, maintenance and integration.

Recent research on ontology modularity shows substantial progress in
foundations of modularity, techniques of modularization and modular
development, distributed reasoning and empirical evaluation. These
results provide a solid foundation and exciting prospects for further
research and development.

The workshop continues a series of successful events that have been an
excellent venue for practitioners and researchers to discuss latest
and current work; the most recent WoMOs were held at FOIS 2010 and
ESSLLI 2011.

TOPICS include, but are not limited to:

- What is modularity?: kinds of modules and their properties; modules
vs. contexts; design patterns; granularity of representation;

- Logical/foundational studies: conservativity; modular ontology
languages; reconciling inconsistencies across modules; formal
structuring of modules; heterogeneity;

- Algorithmic approaches: distributed and incremental reasoning;
modularization and module extraction; sharing, linking, reuse;
privacy; evaluation of modularization approaches; complexity of
reasoning; implemented systems;

- Applications: semantic web; life sciences; bio-ontologies; natural
language processing; space and time; ambient intelligence; social
intelligence; collaborative ontology development and ontology
versioning.

IMPORTANT DATES

Paper Submission: May 18, 2012
Notification: June 19, 2012
Camera ready: July 6, 2012
Workshop: July 24, 2012

SUBMISSION GUIDELINES:

We welcome submissions on modularity in a broad sense. The workshop is
open to papers of theoretical or practical nature. Submissions should
be of up to 11 pages in length, formatted according to Springer LNCS
style (see http://www.springer.com/comp/lncs/Authors.html), prepared
in PDF format and submitted no later than May 18, 2012, through the
EasyChair Submission System (see
http://www.easychair.org/conferences/?conf=womo2012).

Submitted papers will be peer-reviewed by members of the program
committee. Accepted papers will be made available in the proceedings
to be published electronically in the CEUR Workshop Proceedings series
(see http://www.ceur-ws.org).

(Find the WoMO 2010 and 2011 proceedings here
http://www.booksonline.iospress.nl/Content/View.aspx?piid=16268 and
http://www.booksonline.iospress.nl/Content/View.aspx?piid=20369)

WORKSHOP CHAIRS:

Thomas Schneider, University of Bremen, Germany
Dirk Walther, Technical University of Madrid (UPM), Spain

PROGRAM COMMITTEE:

Kenneth Baclawski, Northeastern University, Boston, MA, USA
Stefano Borgo, Italian National Research Council, Trento, Italy
Oscar Corcho, Universidad Politecnica de Madrid, Spain
Bernardo Cuenca Grau, University of Oxford, UK
Mike Dean, Raytheon BBN Technologies, Ann Arbor, MI, USA
Silvio Ghilardi, Universita degli Studi di Milano, Italy
Michael Gruninger, University of Toronto, Canada
Janna Hastings, EMBL-EBI, Cambridge, UK
Robert Hoehndorf, University of Cambridge, UK
Boris Konev, University of Liverpool, UK
Roman Kontchakov, Birkbeck College, London, UK
Thomas Meyer, Meraka Institute, CSIR, Pretoria, South Africa
Till Mossakowski, University of Bremen, Germany
Immanuel Normann, Birkbeck College, London, UK
Leo Obrst, MITRE, McLean, VA, USA
Adrian Paschke, Free University of Berlin, Germany
David Perez del Rey, Universidad Politecnica de Madrid, Spain
Uli Sattler, University of Manchester, UK
Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy

Many years spent building integration solutions have taught me a great deal about what makes certain approaches successful. During this time, I’ve observed many projects where traditional EAI (Enterprise Application Integration) adapters were used to connect IT assets to the integration infrastructure.

The recurring feature in all of these projects is the staggering amount of legacy code that needs to be written to make, what should be a completely configurable adapter, actually work. This isn’t necessarily a criticism of those specific vendors’ adapters; instead it’s a comment on the futility of attempting to build configurable pre-packaged adapters for every possible use case. It just isn’t practical.

The configuration threshold

Common sense suggests that vendors should only produce a pre-built plugin when it could be reasonably deployed through configuration alone. If plugins require bespoke code on top of the configuration to achieve a certain design goal, then it implies that the configuration threshold has been crossed and that the better course of action would be to produce a more specific plugin to do the job.

Adopting this approach has impacted our strategy in two main ways; the rationalisation of plugins and the encouragement of end users to create their own mediation plugins.

Rationalise not compromise

Only producing a pre-built plugin when it can simply be deployed through basic configuration, undoubtedly leads to a rationalisation of plugins produced. However, looking at the range of adapters that other vendors offer, tells me that their customers must be cutting a lot of code or making a lot of compromises.

Contained code

Secondly, and more importantly, this approach leads to organisations opening up their architecture and exposing design frameworks to allow end users to produce their own mediation plugins. For example, hooks and mechanisms are available to deploy custom code within the mediation plugins container.

This “contained” code limits the need to write legacy code outside of the plugin. In my experience, such “uncontained” code is typically 8 to 12 times more costly to develop and maintain because it is usually developed within a non-productive, code-intensive, skill-shortage legacy environment.

By following this rule, organisations can realise significant productivity improvements. Whilst some coding is required within the plugin, the result will be a perfect fit, built upon and reusing existing services, and in keeping with the design approach of the embedded mediation framework.

A pragmatist stance

I’d certainly not advocate writing bespoke code for every mediation plugin deployment – far from it. In fact, the majority of our 1250+ customer deployments have been made using our configuration tools alone. The key here has to be pragmatism. Where there is a functionality delta between the mediation plugins and the IT asset being integrated, allow the code that will reduce the delta to be accommodated within the mediation plugin.

Such pragmatism makes it possible to package new “adapters” within days rather than months or years, offering customers a greater level of flexibility in how they bring packaged applications into a Service Oriented Architecture.

What about hosting the integration logic?

One thing that often gets overlooked is the runtime aspect of the adapters. Generally adapters are hosted locally, close to the target application. Hosting locally is one option, however an increasing number of customers want to host integration logic elsewhere, or use adapters to integrate on premise applications with cloud applications. Such flexibility is undoubtedly key and ties in to my belief in integration anywhere – and something that more and more customers are looking to harness.>>

You can find this at: http://www.businesscomputingworld.co.uk/why-traditional-eai-adapters-fail/?goback=.gde_87715_member_103753297

Gervas

You Say You Want a Revolution…

Document ID: | Document Type: ZapFlash
By: Jason Bloomberg | Posted: May 14, 2012

Remember the heady dot.com days circa 1999? We thought we were reinventing business, forming a New Economy, revolutionizing the essential nature of commerce. In our dreams! By late 2001 the bubble had burst, and what we thought was a new paradigm for business—the World Wide Web—turned out to be little more than a new marketing channel.

Don’t get me wrong—I’m not trying to disparage the power and importance of the Web. After all, the Web, and the Internet in general, have deeply affected so many aspects of business today. It’s hard to remember the time when you had to talk to a teller to use a bank or a stockbroker to trade stocks! But we were wrong that the Web was a revolution. It wasn’t a paradigm shift. Fundamentally, the rise of the Internet was more evolutionary than revolutionary.

Not wanting to succumb to this delusion again, ZapThink has long held that the rise of SOA was also more evolutionary than revolutionary. We point to many SOA best practices, including abstracted interfaces, encapsulation, loose coupling, and iterative approaches to dealing with changing requirements, among others—all practices that were already well-known and favored before SOA came along. SOA moved the ball forward, to be sure, but didn’t fundamentally change the way we tackled distributed computing. It wasn’t a true paradigm shift, because we didn’t have to throw out old ways of thinking and replace them with new ways. Instead, we leveraged the existing approaches while tweaking and improving them.

Today, however, ZapThink is willing to go out on a limb and proclaim that we now have a true revolution on our hands. A true paradigm shift in the world of IT is afoot, one that is already forcing us to discard old ways of doing things, in favor of new approaches, new technologies, and new ways of thinking. Yes, we’re talking about ZapThink’s vision for Enterprise IT in 2020 with its five Supertrends and multiple Crisis Points. We’ve already laid out the context for the turbulence that is already underway and yet to come. But we haven’t explained why we’re calling this period in time a revolution. Why does this decade herald a true revolutionary change, when even the dot.com period (aka “Web 1.0”) of 1994-2001 didn’t qualify?

The Context for Revolutionary Change

The most familiar revolutions, of course, are political—the American Revolution, the French Revolution, etc. The author most responsible for extending this definition beyond the political sphere was Thomas Kuhn, whose 1962 book The Structure of Scientific Revolutions discussed the nature of revolutions such as the Copernican Revolution or the one leading to the Atomic Theory of Matter. Such revolutions in the process and theory of science represented periods of dramatic change, requiring intellectuals of the day to discard old ways of thinking and replace them with new ones—often over the course of a generation, as the old guard eventually died off. Kuhn also coined the term paradigm shift to refer to such upheaval in ways of thinking. (Yes, if you ever wondered where the notion of paradigm shifts came from, it was Thomas Kuhn who came up with the whole idea).

Kuhn’s book was so influential that his notions of revolutions and paradigm shifts expanded well past the realm of the history of science into virtually any area of human endeavor. His insights, after all, applied to fundamental aspects of human thought and behavior: human endeavors don’t progress evenly and gradually, but rather in fits and starts, and occasionally there’s a large upheaval that resets the playing field. But not every change represents a paradigm shift, and not every trend is revolutionary.

Revolution vs. Evolution

How then do we know we’re truly in a revolution, and not simply another period of evolution like the dot.com or SOA eras? Kuhn points out that, well, it’s harder than it sounds. People often don’t recognize that a revolution has taken place until well after the fact. It’s not like one day somebody wakes up and realizes that the way they were doing things is suddenly obsolete. In fact, the pre-revolutionary patterns often persist well into the revolutionary period, even though in retrospect it becomes clear their days were numbered.

Another reason why revolutions are hard to identify while in the midst of them is that the changes are numerous, often sporadic, and typically subtle. When Galileo turned his telescope toward the moons of Jupiter, it’s not clear that he realized he was helping to change an entire civilization’s world view. When the Catholic Church forced him to recant his discoveries, I’m sure the church authorities had no idea they were fighting a losing battle. Only in retrospect can we place these events into the proper context of the Copernican Revolution.

A third impediment to identifying a revolution in progress is the clichéd nature of the terms revolutionary and paradigm shift. It seems that every technology startup these days touts their new widgets as being revolutionary paradigm shifts. Hell, it seems that every minor improvement in laundry detergent or automobile oil is revolutionary. It’s no wonder we’ve become jaded about the entire subject. If the marketeers tout every minor improvement as revolutionary then nothing is revolutionary.

That is, until a real revolution comes along.

Why ZapThink 2020 Signals a Revolution

If we only spotted one trend (like SOA) or one disruptive change (e.g., the Web replacing tellers and stockbrokers), then we might have a hint of a revolution, but more likely than not, we’d be wrong to apply the term. However, there are simply too many different forces of change impacting IT today, and in turn, impacting business in general to consider such changes to be an evolutionary trend. We have Cloud Computing, mobile computing, the threat of Cyberwarfare, the rise of social media, the app store model for purchasing software, outsourcing, insourcing, complex systems engineering…the list goes on and on. Any of these trends taken separately may be considered evolutionary, but put them together and there are strong hints of a paradigm shift in progress.

The second aspect of ZapThink 2020 that indicates a revolution in progress is the potentially disruptive nature of the Crisis Points. While the Stuxnet worm may have only disrupted Iranian power plants, the next professionally designed cyberattack promises much greater disruption. And while buying enterprise-class apps via your phone is novel, it has yet to put one of the big enterprise app vendors out of business. So, we won’t really know just how disruptive this paradigm shift will be until after the fact.

Perhaps the greatest indicator of an ongoing revolution is the evolving perspective on change, and the role technology has in supporting it. People are simply getting fed up with inflexible technology. We’re sick and tired of legacy that slows down our organizations and sucks up our budgets. The need for greater agility drove the move to SOA, but SOA alone doesn’t solve our inflexibility problems, in large part because SOA is part of the old paradigm. What we need is a new paradigm for architecture-driven agility that is inherently different than today’s architectural approaches. It’s the fact that we’re already seeing the shift to this new paradigm that is the primary reason we’re calling this point in time a revolution.

The ZapThink Take

The most challenging aspect of identifying a revolution is that it’s extraordinarily difficult to do so while it’s still in progress. We understand this challenge, and realize that we may be wrong about the whole affair. After all, there are still so many unanswered questions. For example, in 20 years when we look back on this time, what will we call the revolution? We can guess, but there’s no way to know what the next big thing will be until it’s finally here.

Perhaps we can look back at the last revolution for inspiration—the postwar Information Revolution that heralded the Information Age. Starting with Colossus cracking the Nazi’s Enigma codes at Bletchley Park, through the rise of digital, programmable computers to the networked world we have today, no one can disagree that the rise of computing disrupted the pre-computer ways of thinking and conducting business, leading to an entirely new context for human endeavor writ large. But no single innovation, no single disruption signaled the revolution. Only in retrospect can we take all the disruptions together and recognize a true paradigm shift.

We’re the first to admit, therefore, that we may be completely wrong about what we call the Agile Architecture Revolution. And we may not know how right we were for another twenty years. But we can say that rethinking how we approach agility will be a critical enabler for organizations over the next ten years and beyond. Whether agile architecture heralds a revolution may be too hard to say with any certainty, but agile architecture is undoubtedly here to stay.

<<Why REST Keeps Me Up At Night

Guest Author, May 15th, 2012

Comments(0)

This guest post comes from Daniel Jacobson (@daniel_jacobson), director of engineering for the Netflix API. Prior to Netflix, Daniel ran application development for NPR where he created the NPR API, among other things. He is also the co-author of APIs: A Strategy Guide and a frequent contributor to ProgrammableWeb and the Netflix Tech Blog.

With respect to Web APIs, the industry has clearly and emphatically landed on REST as the standard way to implement these services. And for good reason… REST, which is generally implemented as a one-size-fits-all solution, is an excellent choice for a most companies who wish to expose their content to third parties, mobile app developers, partners, internal teams, etc. There are many tomes about what REST is and how best to implement it, so I won’t go into detail here. But if I were to sum up the value proposition to these companies of the traditional REST solution, I would describe it as:

REST APIs are excellent at handling requests in a generic way, establishing a set of rules that allow a large number of known and unknown developers to easily consume the services that the API offers.

In this model, everyone knows how to behave and it can be incredibly powerful. The API providers establish a set of rules and the API consumers must adhere to those rules to get what they want from the API. It is perfect, right? In many cases, the answer is obviously yes. But in other cases, as our world scales and the number of ways for people to consume digital content and services continues to expand, this one-size-fits-all model is likely to fall short.

The potential shortcomings surface because this model assumes that a key goal of these APIs is to serve a large number of known and unknown developers. The more I talk to people about APIs, however, the clearer it is that public APIs are waning in popularity and business opportunity and that the internal use case is the wave of the future. There are books, articles and case studies cropping up almost daily supporting this view. And while my company, Netflix, may be an outlier because of the scale in which we operate, I believe that we are an interesting model of how things are evolving.

Netflix is currently available on over 800 different device types, including game consoles, mobile phones, TVs, Blu-ray players, tablets, computers, and almost any other device that can stream video. Our API alone handles more than two billion incoming requests on peak days, which translates into almost ten billion real-time outgoing requests from the API to internal dependency services. These numbers are up by about 70x from just two years ago. Most companies do not have that kind of scale, but it is clear that with the continued growth of the device market more companies are resetting their strategies to be less about the public API and more about internal consumption of their own APIs to support device proliferation. When this transition occurs, the API is no longer targeting “a large number of known and unknown developers.” Rather, the key audience is a small number of known developers.

The potential conflict between the internal and public use cases is in the design of the API itself. Keep in mind that the design implications will not be problematic in many scenarios. It becomes a potential problem if the breadth of devices becomes so wide that the variability of features across them becomes substantially harder to manage. It is the breadth of devices that creates a problem for the one-size-fits-all API solutions.

If your target is a small group of teams with whom you have close relationships, the dynamics around the API change. For Netflix, we persisted on the one-size-fits-all REST model for quite a while as more and more devices got added on top of the API. But given our scale, one thing has become increasingly obvious. Our REST API, while very capable of handling the requests from our devices in a generic way, is optimized for none of them. This is the case because our REST API focuses on resources that are meant to be granular representations of the data, from the perspective of the data. The granularity is exactly what allows the API to support a large number of known and unknown developers. Because it sets the rules for how to interface with the data, it also forces all of the developers to adhere to those rules. That means that each device potentially has to work a little harder (or sometimes a lot harder) to get the data needed to create great user experiences because devices are different from each other.

The differences across these devices can be varied and sometimes significant. Here are some examples of variances across devices that may be challenging for one-size-fits-all models:

• Different devices may have different memory capacity
• Some devices may require a unique or proprietary format or delivery method
• Some devices may perform better with a flatter or more hierarchical document model
• Different devices have different screen real estate sizes which may impact which data elements are needed
• Some devices may perform better having bits streamed across HTTP rather than delivered as a complete document
• Different devices allow for different user interaction models, which could influence the metadata fields, delivery method, interaction model, etc.

Just think about the differences between an iPhone and your TV and how they beg for different user experiences. Moreover, the XBox and the Wii, both of which project to the TV, are different in the way users interact with them as well as in the hardware constraints, both of which may require different APIs to support them. When considering more than 800 different device types, the variance across them becomes overwhelming. And as more manufacturers continue to innovate on these devices, the variance may only broaden.

Because of the differences in these devices, Netflix UI teams would often have to do a range of things to get around our REST API to better serve the users of the device. Sometimes, the API team would be required to extend the base service to handle special cases, often resulting in spaghetti code or undocumented features. And because different teams have different needs, in the REST API world, we would often need to delay feature development for some due to the challenges around prioritization. In addition to these kinds of issues, significant performance and/or architectural problems are bound to emerge. For example, these more granular APIs often result in chattier interactions between device and server or chunkier payloads, as I discussed in a previous post on the Netflix Tech Blog.

To solve this issue, it is becoming increasingly common for companies (including Netflix) to think about the interaction model in a different way. Rather than having the API create a set of rather rigid rules and forcing the various devices to follow them, companies are now thinking about ways to let the UI have more control in dictating what is needed from a service in support of their needs. Some are creating custom REST-based APIs to support a specific device or category of devices. Others are thinking about greater granularity in REST resources with more batching of calls. Some are creating orchestration layers, such as ql.io, in their API system to customize the interaction. These are all smart and practical ways around the problem. But with the growing number of devices, the increasing urge for companies to be on as many of them as possible, and the desire for continued innovation across these devices, these various solutions are still somewhat restricted. They are still forcing the developers to adhere to server-side rules and non-optimized payloads in an effort to have a one-size-fits-all solution. These approaches are closer to the flexibility needed in that they are not as rigid as the typical REST-based solution, but when supporting as many devices as Netflix does, we believe they fall short for us.

For Netflix, our goal is to take advantage of the differences of these devices rather than treating them generically. As a result, we are handing over the creation of the rules to the developers who consume the API rather than forcing them to adhere to a generic set of rules applied by the API team. In other words, we have created a platform for API development. In my next post, I will discuss in more detail our implementation of this approach. In the meantime, if you are interested in helping us solve these and other problems, we are hiring!>>

You can find this at: http://blog.programmableweb.com/2012/05/15/why-rest-keeps-me-up-at-night/

Thanks to Anne for pointing this out.

Gervas

While many remain unconvinced by the benefits of reusing software artifacts it's
worth to start with requirements and reexamine the economics of the different
options.
http://caminao.wordpress.com/engineering/system-engineering-processes/reuse/

Michael,
As you suggest this forum is not the right place for such a detailed
debate, and therefore I would not even enter it. As for the material
used for the article, it is either published on the Caminao  site or
explicitly referenced. Apart from commonly accepted principles, there
isn't much that could have come from OASIS.
In any case the objective of this discussion is not to allocate points
but to initiate a reflection on two different perspectives of reuse.
Remy.

--- In service-orientated-architecture@yahoogroups.com, Michael Poulin
<m3poulin@...> wrote:
>
> It is possible I am out of sync with contemporary materials
> but I have not seen publications on "DDD vs SOA" from usability
> perspectives (and economics is one of the forms of sublimated
usability) since
> I published my analysis of superposition between SOA and DDD back in
January 2009
> (“A Domain Service-Oriented Modelling or How SOA Meets
DDD”[
http://www.ebizq.net/blogs/service_oriented/2009/01/a_domain_service-ori\
ented_modelling_or_how_soa_meets_with_ddd.php]).
> The same relates to the definition of reuse presented in the
Caminao’s
> publication (“Reusing artifacts means using them in contexts
that are different
> of their native ones” vs. multiple use of artefacts in the
immutable execution context,
> which I articulated back in 2007 when we worked on the first public
draft of the
> OASIS SOA RAF specification). So, I dare to conclude (and let
‘Caminao’ correct
> me), that aforementioned publication has been “fueled”
by my early contributions,
> which is pleasant to me.
>
> I do assure you that the publication is a very serious and
> respectful work, and deserves attentive reading. Nevertheless, I have
found a
> few discrepancies in there maybe because I am not that familiar with
the whole ontology
> model of Caminao’s Way. In particular,
>
> 1)� � � � �  OASIS SOA RAF defines execution context as
a set
> of policies that consumer of the services and the service itself
follow. In this
> case, a statement “Reuse policies may also bring positive
externalities by
> inducing a comprehensive approach to software design” contains
internal
> contradiction �" “Reuse policies” is a use of
policies in a changing policy
> environment, i.e. it is difficult to comprehend how the same policy is
a changed
> policy at the same time.
>
> 2)� � � � �  Similar confusion relates to enumeration
of Business,
> Engineering and Architecture perspectives: “�  Business
> perspective: how to factor out and reuse artifacts associated with the
> knowledge of business domains when system functionalities or platforms
are
> modified. Engineering perspective: how to reuse development artifacts
when
> business contents or system platforms are modified. Architecture
perspective:
> how to use system components independently of changes affecting
business
> contents or development artifacts.” Again, according to OASIS
SOA RAF, an
> Execution context comprises Business Execution context and Technical
Execution
> context (see “Ladder to SOE”, 2009). Policies of these
context-parts depend on
> local laws and regulations simultaneously; a change in any of the
context-parts
> constitutes a change in the Execution context as a whole. Especially,
this applies
> to the presented “Architecture perspective”, which ties
context-parts together
> (vs. “independently
> of changes”). It seems that presented enumeration is taken
outside of
> the ontology and semantic realm, i.e. for the sake of its own.
>
> 3)� � � � �  In line of logic of OASIS SOA RAF, a fact
that “reused
> artifacts are meant to be used independently of their native
context” leads to
> that the same service (artefact/component) may produce different
results in
> different Execution contexts. That is, befaviour of the service
(artefact/component)
> directly depends on the context policies. I am not sure that
‘Caminao’ really
> grasps this service specific quality. In this regard, the
recommendations
> following “From the enterprise perspective, the problem is to
reuse the
> knowledge of business domains and processes” worries me as
possibly misleading.
>
>
> I could continue this observation but I am not sure that
> this forum is the right place for such detailed debate. Moreover, I
have not found
> one reference to DDD in this � Caminao’s
> publication and got confused even more.
>
> -� � � � � � � �  -�  Michael Poulin
>

------------------------------------------------------------------------
Call for Research Papers
http://iswc2012.semanticweb.org/call-research-papers

11th International Semantic Web Conference
http://iswc2012.semanticweb.org/
Boston - USA
November 11-15, 2012
------------------------------------------------------------------------

ISWC is the premier venue for presenting innovative systems and
research results related to the Semantic Web and Linked Data. We
solicit the submission of original research papers for ISWC 2012's
research track, dealing with analytical, theoretical, empirical, and
practical aspects of all areas of the Semantic Web. Submissions to the
research track should describe original, significant research on the
Semantic Web or on Semantic Web technologies, and are expected to
provide some principled means of evaluation.

To maintain the high level of quality and impact of the ISWC series,
all papers will be reviewed by three program committee members and one
vice chair of the program committee. To assess papers, reviewers will
judge their originality and significance for further advances in the
Semantic Web, as well as the technical soundness of the proposed
approaches and the overall readability of the submitted papers. We
will give specific attention to the evaluation of the approaches
described in the papers. We strongly encourage evaluations that are
repeatable: preference will be given to papers that provide links to
the data sets and queries used to evaluate their approach, as well as
systems papers providing links to their source code or to some live
deployment.

Topics Of Interest
----------------------------

Topics of interest include, but are not limited to:

* Management of Semantic Web data and Linked Data
* Languages, tools, and methodologies for representing and managing
Semantic Web data
* Database, IR, NLP and AI technologies for the Semantic Web
* Search, query, integration, and analysis on the Semantic Web
* Robust and scalable knowledge management and reasoning on the Web
* Cleaning, assurance, and provenance of Semantic Web data, services,
and processes
* Semantic Web Services
* Semantic Sensor Web
* Evaluation of semantic web technologies
* Ontology engineering and ontology patterns for the Semantic Web
* Ontology modularity, mapping, merging, and alignment
* Ontology Dynamics
* Social and Emergent Semantics
* Social networks and processes on the Semantic Web
* Representing and reasoning about trust, privacy, and security
* User Interfaces to the Semantic Web
* Interacting with Semantic Web data and Linked Data
* Information visualization of Semantic Web data and Linked Data
* Personalized access to Semantic Web data and applications
* Semantic Web technologies for eGovernment, eEnvironment, eMobility or eHealth
* Semantic Web and Linked Data for Cloud environments

Submission
---------------------

Pre-submission of abstracts is a strict requirement. All papers and
abstracts have to be submitted electronically via the Conference
Submission System
https://www.easychair.org/conferences/?conf=iswc2012.

All research submissions must be in English, and no longer than 16
pages. Papers that exceed this limit will be rejected without review.
Submissions must be in PDF formatted in the style of the Springer
Publications format for Lecture Notes in Computer Science (LNCS). For
details on the LNCS style, see Springer�s Author Instructions.
ISWC-2012 submissions are not anonymous.

Authors of accepted papers will be required to provide semantic
annotations for the abstract of their submission, which will be made
available on the conference web site. Details will be provided at the
time of acceptance.

Accepted papers will be distributed to conference attendees and also
published by Springer in the printed conference proceedings, as part
of the Lecture Notes in Computer Science series. At least one author
of each accepted paper must register for the conference and present
the paper there.

Prior Publication And Multiple Submissions
--------------------------------------------------------------------

ISWC 2012 will not accept research papers that, at the time of
submission, are under review for or have already been published in or
accepted for publication in a journal or another conference. The
conference organizers may share information on submissions with other
venues to ensure that this rule is not violated.

Submission of a Poster or Demo together with your Accepted Research Paper
--------------------------------------------------------------------------------\
--------------------------------------

Authors of accepted papers are invited to submit also a poster or a
demo to the Posters and Demo track. The submission format is the same
as for normal poster and demo submissions but the submission must cite
the corresponding paper from the research track.

Important Dates
----------------------------

Abstracts: June 1, 2012, 11:59pm Hawaii time
Full Paper Submission: June 8, 2012, 11:59pm Hawaii time
Author Rebuttals: July 9-11, 2012
Notifications: July 26, 2012
Camera-Ready Versions: September 4, 2012
Conference: November 11-15, 2012
No extensions of the submission deadline will be granted.

Research Track Chairs
--------------------------------------

Philippe Cudre-Mauroux, University of Fribourg, Switzerland
Jeff Heflin, Lehigh University, USA


Follow ISWC 2012 on Twitter
https://twitter.com/#!/iswcboston

------------------------------------------------------------------------
Call for Evaluations and Experiments
http://iswc2012.semanticweb.org/call-evaluations-and-experiments

11th International Semantic Web Conference
http://iswc2012.semanticweb.org/
Boston - USA
November 11-15, 2012
------------------------------------------------------------------------

The Semantic Web (and Linked Data) has been an active area of research
for several years. This 11th edition of the International Semantic Web
conference introduces the Evaluations and Experiments Track. Its goal
are to consolidate research material and to gain new scientific
insights and results by providing a place for in-depth experimental
studies of significant scale. It aims at promoting experimental
evaluations in Semantic Web/Linked Data research trying to create a
research cycle between theory and experiments as in other sciences
(e.g., physics). Papers in this track can fit in different categories:

Experimental studies comparing a spectrum of approaches to a
particular problem and, through extensive experiments, providing a
comprehensive perspective on the underlying phenomena or approaches.
Analyses of experimental results providing insights on the nature or
characteristics of studied phenomena, including negative results.
Result verification focusing on verifying or refuting published
results and, through the renewed analysis, help to advance the state
of the art.
Benchmarking, focusing on datasets and algorithms for comprehensible
and systematic evaluation of existing and future systems.
Availability of experimental datasets is highly important (if not compulsory).

In addition, these papers will be more specifically judged on the
basis of their:

Precise description of control experimental conditions
Reproducibility
Applicability range (broad coverage results being better than narrow
applicability).
Special attention will be paid to reproducibility. Hence, experimental
settings will have to be extensively described so that the results
could be independently reproduced and counter-experiments could be
designed.

The experimental approach is based on systematic scientific methods
used in many disciplines. http://www.experiment-resources.com/
provides a good collection of methods, experiment design strategies,
and resources.

Topics of Interests
----------------------------------------

For a list of topic of interests please visit the Call for Research
Papers http://iswc2012.semanticweb.org/call-research-papers

Submission
----------------------------------------

Pre-submission of abstracts is a strict requirement. All papers and
abstracts have to be submitted electronically via the Conference
Submission System
http://www.easychair.org/conferences/?conf=iswc2012et.

All research submissions must be in English, and no longer than 12
pages. Papers that exceed this limit will be rejected without review.
Submissions must be in PDF formatted in the style of the Springer
Publications format for Lecture Notes in Computer Science (LNCS). For
details
on the LNCS style, see Springer�s Author Instructions. ISWC-2012
submissions are not anonymous.

Accepted papers will be distributed to conference attendees and also
published by Springer in the printed conference proceedings, as part
of the Lecture Notes in Computer Science series. At least one author
of each accepted paper must register for the conference and present
the paper there.

Important Dates
----------------------------------------

Abstracts: June 15, 2012, 11:59pm Hawaii time
Full Paper Submission: June 22, 2012, 11:59pm Hawaii time
Notifications: August 9, 2012
Camera-ready Versions: September 4, 2012
Conference  November 11-15, 2012
No extensions of the submission deadline will be granted.

Research Track Chairs
----------------------------------------

Manfred Hauswirth, DERI - National University of Galway, Ireland
J�r�me Euzenat, INRIA & LIG, France
Josiane Xavier Parreira, DERI - National University of Galway, Ireland


Follow ISWC 2012 on Twitter
https://twitter.com/#!/iswcboston

<<Growing complexity in application integration and software infrastructure is changing the middleware management space. SearchSOA.com discussed the issue with IBM’s Kathy McGroddy Goetz, vice president of connectivity and integration product management.
 

SearchSOA.com: It seems there is a growing need to manage and monitor messaging middleware and services.

Kathy McGroddy Goetz:  Absolutely. It's interesting, because we've almost grown up with SOA and the early evangelists around SOA and SOA governance. The governance aspect, on the one hand, is sort of a dirty word. People are afraid of it because it sounds like a bad thing coming from above. But it's so critically important in this day with everything—with barriers being knocked down and trying to manage within and beyond the enterprise.

You really want to be able to create dashboards and manage and monitor who's accessing your services and what they're doing with them, and whether you can monetize that. It's becoming more and more critical, in my opinion. I think you'll see a convergence in terms of governance becoming a more important capability across runtimes and then also expanding to [include] services beyond the enterprise itself. 

MQ is a long-standing middleware method. What is new there for IBM?

McGroddy Goetz:  Our WebSphere MQ Telemetry product, we put it out there as an open standard and we're trying to get it out there and make it pervasive and ubiquitous. It's really interesting to see how people are using it and taking advantage and again the number of things that people are trying to connect to.

Specifically, with WebSphere MQ, we have had a lot of additional scale and performance enhancements, very strong throughput enhancements on a variety of platforms, both for persistent and non-persistent messaging. Those are very strong performance improvements because, again, you need to be able to scale as you go forward. In addition to that, as I said, with the Telemetry protocol we've enabled our queue managers now to be able to connect with more than 100,000 MQ Telemetry endpoints. You need to be able to really scale these things.

We have the [File Transfer Edition, or FTE] which is a component for WebSphere MQ and it really helps with manage file transfer, for example, between point-of-sale and headquarters, so you can kind of push and pull file data between various sources and destinations and do a lot of it in parallel.

We also have the advanced message security capabilities. We have customers that use that, for example, for core banking applications because, again, you've got all this data flying around out there and you want to make sure that it's properly secured.

I think [messaging middleware] is a very exciting area and it's becoming so much more relevant. SOA  [is] even more important in this world of exploding endpoints and what I sometimes call "hyper-connectivity."  I think it's a great opportunity for enhancements and expansions in this space in terms of adding capabilities to continue to grow.

Does your Cast Iron cloud product give people easier ways to deal with application integration complexity?

McGroddy Goetz:  We do a lot of work in terms of trying to develop fast, easy and simple connectivity-leveraging capabilities like Cast Iron. It's got a library of what we call "chips and connectors" that provide easy templates to connect things that are commonly used.

For example, [there is] hybrid cloud connectivity, where you're taking an application running on premise—like maybe SAP—and you want to connect it into SalesForce.com. You ask: ‘How can I do that in a very rapid fashion without having to write custom code?’

The more enablement like this that we can provide customers, I think the faster we can help them connect.>>

You can find this at: http://searchsoa.techtarget.com/feature/IBM-moves-on-message-middleware-management-front?asrc=EM_NLN_17498349&track=NL-1789&ad=868228&

Gervas