The discussion of cloud standards at Cloud Camp Boston started by asking the question “What do we want to standardize?” As we looked at standards we found that there are three attributes of apparent concern. These include “API lock-in” (a similar concept to vendor lock-in), migration issues, and the richness or functionality of an API.

One interesting problem with setting standards (For APIs and services both) is the granularity of the work you’re standardizing. Some APIs have a very limited scope and effect only a single application with a single purpose. Others address a broad range of applications with any number of different purposes.

One example of scale issues effecting functionality is libcloud which simplifies the process of integrating with multiple popular cloud server providers. Its methods rely on using the “lowest common denominator” to ensure compatibility with all the providers it supports. In other words, it provides for the basic functionality that all providers share at the expense of losing the specifics of each system that help each one excel in their particular niche. One potential pitfall of standards could be the “dumbing-down” of new cloud applications built for mass appeal.

There are also virtualization issues in the cloud. It would be wonderful if there was a single best way to optimize the automatic scaling of applications. But there are complications involved in creating “standardized triggers”.  At what point should a system be triggered to bring more servers on line? At what point should the system know to let servers go? What metrics should be involved in the calculations?

In every case, the answer is a resounding “it depends.” Different applications have different needs. If we want to ensure five nines availability, we might be willing to suffer a little latency to avoid the risk of down time. And speed versus availability is just one dichotomy to resolve. Taken together with other issues around hardware, scripting languages and anything else developers argue over, it means once again you can’t be everything to everyone.

But there are areas where the cloud is actually fairly well standardized already, even if only in practice. For example, the infrastructure APIs for service providers are seen by some as the shining example of cloud standards.

In fact, the idea of the cloud came from telecommunications service providers as they transitioned from point-to-point services to VPNs. The cloud was their way of denoting where the clients’ responsibilities ended and the providers’ responsibilities took over.

John Zachman himself recently wrote a post in which he seemed to chide much of the IT world for not treating EA as a serious enough discipline. Zachman said EA is relative, but not arbitrary:

This is what is killing Enterprise Architecture… every computer programmer, systems designer, software architect, solutions architect, technology architect, computer operator, PC owner, data architect, database architect, network architect, business analyst, systems analyst, enterprise architect, service architect, object architect, project manager and CIO calls whatever they want to or maybe, whatever they are doing, “Architecture.” It is chaos. No wonder we don’t have Enterprises that are coherent, integrated, flexible, dynamic, interoperable, reusable, aligned, lean and mean and working.

If building architects and non-IT engineers treated their own disciplines as “arbitrary,” Zachman wrote, we would not have skyscrapers and jetliners. Perhaps in an ideal world, EA would always be ruled by common frameworks, information models and the like – but this doesn’t seem to be the case. If an airliner crashes, people die. If there is a bug in the enterprise software, some money is lost and it gets patched.

As much as Zachman may dream of a perfect world where enterprise architects all follow a common framework, changing business needs, licensing costs, skill availability, M&A, corporate politics and many other factors make that world but a distant hope.

That is not to say numerous enterprises aren’t trying to get behind some of these frameworks. The Open Group released some statistics recently saying that more than 2,000 individuals were certified in TOGAF 9 over the past year and more than 83,000 copies of the framework have been downloaded.

At The Open Group, the evolution of TOGAF toward version 9 has focused on bringing EA from an IT-driven endeavor to one that the business shares. A lot of this has to do with communication, said Gary Doherty, TOGAF product manager at The Open Group.

“By improving the ability of enterprise architects to communicate,” said Doherty, “that is improving the ability of enterprise architects to operate across an organization.”

Doherty said TOGAF 9 shows faster adoption than the framework’s previous versions. He added that it has been most popular in the U.S., U.K., The Netherlands and South Africa.

For architects focused more on the defense industry, there is the Department of Defense Architecture Framework (DoDAF) and Ministry of Defense Architecture Framework (MODAF). Both of these are at the center of a new training program offered by No Magic for learning the Unified Profile for DoDAF and MODAF (UPDM). UPDM is a modeling standard for both of these defense-centered architecture frameworks.

Returning to Zachman, there are indeed a number of great industry standards out there and common frameworks for EA seem to be growing in popularity. Yet it seems common practice for enterprises to refer to these frameworks as reference materials rather than a codified methodology. So do enterprise architects need to follow their framework of choice in blind faith, or are none of these frameworks so polished yet that this would even be viable?

One such organization is the Banking Industry Architecture Network (BIAN), which this month added pan-European banking organization UniCredit to its 23 members. BIAN works with a number of banking institutions and a few software vendors in an effort to create a framework for interoperability between large banking systems.

“BIAN is really looking at saying, is there any way we can use service-based design to help rationalize these application-to-application structures within the banks where there’s all sorts of complexity and redundancy,” said Guy Rackham, a business architect who works with BIAN.

This boils down to two main focuses: generating application-to-application service standards and developing a metamodel.

Many banks rely on large numbers of fine-grained services that tend to be domain specific, said Rackham. BIAN’s metamodel will try to organize service clusters and definitions into subdomains that can be interpreted by all of its members, he continued. The idea is to first define capabilities and then associate standardized services with them.

Presently, BIAN is working on its architectural foundations and has developed some models and designs around three main areas: payments, business partners and analytics. Rackham said interoperability around payments can be particularly troublesome because of the vast ecosystem of different services involved in the many ways that money changes hands.

Rackham said BIAN wants to make sure everything can be represented in UML, but will stay away from trying to develop any new messaging standards. Much of BIAN’s work will involve creating semantic business vocabularies, similar to the work the California Independent System Operator (CAISO) did while developing a common information model.

“We don’t want to recreate any standards or any design concepts, we want to align to that which exists and influence it where we can help fill gaps,” said Rackham. “We see ourselves mostly adding value at the semantic service definition above the more detailed message definitions – for example ISO 20022.”

BIAN’s membership includes CGI, Deutsche Bank, ING, innobis AG, Microsoft, SAP, SunGard, Standard Bank of South Africa and others.

The benchmark group is interested in hearing from enterprise architects and other users of SOA techniques to ensure that the working group understands customer needs and “can develop the best possible benchmarking solutions.”

The group plans an initial benchmark designed to cover Web services running on top of application servers, Enterprise Service Buses (ESBs) technologies that connect and mediate services, and  composite applications choreographed through BPEL (Business Process Execution Language) technologies.

SPEC is a non-profit organization formed in 1988 to measure engineering workstation performance. The effort to achieve objective performance standards branched out in recent years to include benchmarks that cover Java  (JVM and J2EE) systems. With its SOA effort, SPEC hopes to build on that earlier J2EE benchmark work.

“We want to do the same thing with SOA infrastructure that we did with [SPECjAppServer2004],” said Andrew Spyker, an SOA runtime architect and chair of the new group. “The SOA space is being used by just about [everyone] out there, but there is no standardized benchmark.”

Of course, benchmarks are challenging. We suggested to Spyker that services, which still seem to be something of a craft – if not an art – may be particularly hard to codify. Spyker does not disagree.

“We realize it is going to be a challenge to support all of the approaches that people have to a SOA. There are multiple ways to implement a service, an ESB, or a business process choreography. It is by definition, not a specification.”

“We have to try to audit what is an acceptable implementation and make sure it is something that a typical customer would do. A well described WSDL service is a good standpoint.”

According to a published statement, the SPEC benchmark group invites comments from enterprise architects and other users of SOA techniques as they work to understand needs and “develop the best possible benchmarking solutions.”

What do you think? Can SOA be benchmarked. Use the ”Comment” icon to share your opinion. Thanks!

In recent years, SearchSOA chronicled several vendor efforts to make various software components, products and Web services play well with others.

In 2006, the Open Solutions Alliance began working on guidelines and standards for getting open source components to work together in SOA. That same year, Miko Matsumura, then with Infravio, started SOA Link to promote governance interoperability. After Infravio was purchased by webMethods, which was in term acquired by Software AG, SOA Link followed Matsumura, who is now deputy CTO for the latter vendor.

This week a new group led by IBM and Oracle was founded to promote Web services interoperability.

One major vendor, IBM, appears less than thrilled with the success another major vendor, Microsoft, had getting OOXML through the Ecma and ISO approval process, which is helpful in global sales of the already ubiqitous Office products. 

Bob Sutor, vice president of open source and standards now tells Financial Times Tech Blog writer Richard Waters that Big Blue is casting a cold eye on ISO and Ecma. “It has exposed how Ecma operates, as basically a standards body for hire,” Sutor is quoted as saying. IBM is backed in its re-thinking of its support for these standards bodies by emerging countries that are protesting the Microsoft victory.

But Waters notes that there is a risk here as he concludes: “…if a big vendor unilaterally starts to abandon some standards bodies, or to end support for the technologies they have recognised, it could lead to a fragmentation that is helpful to no one.”

SOA Talk notes that this protest movement does not appear to have spread to W3C or OASIS, the two bodies responsible for most of the standards for the service-oriented approach to application development. But then again World War I started as a dispute between Austria and Serbia.

What happens is this dispute spreads?

Just asking.

Now we at SearchSOA.com are asking you to do the same thing, sort of. It won’t involve wearing a kilt or smashing a coconut over anyone’s skull. We just want you to ask some good questions.

We’ve recently revamped our site experts roster and we’re looking to put them through their paces. The way it works is you ask a question and we send the question off to an expert to get you an answer. It’s a fairly illustrious list of folks:

• SOA standards and architecture – Anne Thomas Manes, vice president and research director at Burton Group
• SOA governance and BPM – Sri Nagabhirava, founder and chief architect nLeague Services
• SOA infrastructure – Dana Gardner, principal analyst Interarbor Solutions
• RIA and enterprise mashups – Jason Bloomberg, senior analyst ZapThink
• SOA testing and QA – Rami Jaamour, product manager of SOA solutions at Parasoft
• Data services – Larry Fulton, senior analyst at Forrester Research
• SOA development – Chris Haddad, vice president and service director at Burton Group

They’re already producing some top flight insight, like data integration best practices, where grid intersects SOA and the difference between WSDL 1.1 and 2.0. Yet good answers like that depend on good questions from the user community. We sift through heaping piles of “What’s the difference between an application server and a Web server?” (a perfectly legitimate question, but we answered it back in 2003) in order to get some of the top minds in the SOA space the best questions the user base can generate.

The process for submitting a question is simple. Just go to the topic where your question fits and click on “Pose a Question.” That will take you to a question submission form. After that, it’s as simple as typing in your query. Keep us busy. We like it that way.