Marketers in the service-oriented architecture (SOA) world seem to be falling all over each other to make their new products Web 2.0 buzzword compliant.
Although Web 2.0 is a dubious term technically since there is no real Web 2.0. It is a clever catchall phrase for the more glitzy browser applications that emerged originally with wikis, and blogs, as well as Podcasts, which is another buzzword for downloadable digital audio files.
A chart of Google Trends data on Web searches indicates that Web 2.0 first came on the scene in mid-2004, when SOA was already flying high as a frequently searched topic. But after sliding under the radar for the next year, Web 2.0 took off like a rocket in late 2005 and surpassed SOA in the fourth quarter of 2006. Since then Web 2.0 has been the more popular term.
So it is perhaps not surprising that marketers are hyping their Web 2.0 capabilities in product announcements.
This week in announcing OpenLibertyJ , its open sourcing of Liberty Alliance security and privacy framework the major emphasis was on Web 2.0. SOA got only one mention in passing.
Asked why the big emphasis on Web 2.0, Brett McDowell, executive director, Liberty Alliance, said: “From my perspective service-oriented architecture is a concept that immediately resonates and gives you a vision of applications if you’re an enterprise architect. Web 2.0 gives you a vision of applications that are taking the Web by storm. What we wanted to use is the term that’s going to convey the correct expectation of what this framework is meant to enable.”
But that didn’t mean OpenLibertyJ had little or nothing to do with SOA.
“It absolutely enables the identity bus for SOA,” McDowell said. “But I think a broader audience understands the vision of Web 2.0.”
Jason Bloomberg, senior analyst for ZapThink LLC., was asked if this explanation was more about marketing or technology.Replying by email, Bloomberg wrote: “Technically correct or marketingese? Well, both. 100% marketingese with just enough truth mixed in :-).”
The Liberty Alliance is not alone in hitching a product wagon to the Web 2.0 star. Since 2006, Oracle Corp. has been talking about the convergence of the Java Enterprise Edition and Web 2.0 into something Thomas Kurian, Oracle’s senior vice president, called SOA 2.0.
That term does not appear to have caught on, as a request to Google Trends brought back this reply: “Your terms – SOA 2.0 – do not have enough search volume to show graphs.”
In 2007, Oracle began using the term Enterprise 2.0 for the Java, SOA and Web 2.0 convergence that is bringing wikis, blogs and social networks into the corporate world. Since first appearing on Google Trends charts in the fourth quarter of 2006, Enterprise 2.0 has been a hotter topic in Web searches than SOA 2.0. But when compared with SOA and Web 2.0, Enterprise 2.0 is still a flat line under their arcs.
If Oracle with its marketing muscle cannot get SOA 2.0 or Enterprise 2.0 off the ground, we may be stuck with Web 2.0, nebulous as it may be.
Discussing IBM’s SOA and Web 2.0 marketing strategy this week, Stephanie Martin, new worldwide lead for IBM Developer Relations, which includes more than 6 million coders who frequent the developerWorks Website, says she believes the two terms can play well together.
“They’re both very hot topics in the market right now,” Martin said. “In order to have the Web 2.0 experience, SOA is critical for designing and architecting these applications. That’s where I see the link between SOA and Web 2.0. Certainly they are not the same thing. SOA is the enabler of Web 2.0 but I do not see one replacing the other. We’re seeing our community’s interest in both those technologies growing consistently.”
So it appears SOA and Web 2.0 will have to co-exist as buzzwords, at least, until the next hot term is coined.
I was looking at the IBM Impact 2008 site and between the cascading images of Drew Carey and the B-52′s it dawned on me that SOA has arrived.
Say what you will about the imperial excess IBM has planned for the MGM Grand in Las Vegas next month, but Big Blue is not the type to throw around its cash like a young rapper with a hit record. IBM’s always been a buttoned-down operation. It’s not shelling out for Hollywood A-list comedians and multi-platinum selling bands on a whim. Rest assured, the only reason it’s writing the fat check for this event is because it’s making a fatter pile of money on its SOA business.
Impact is an SOA show. It doesn’t pretend to be anything but a deep dive into service orientation. Last year in Orlando IBM turned out roughly 4,000 attendees for Impact, making it easily the biggest service-oriented architecture event in history. If anything, the Vegas Impact conference looks ready to dwarf it. While it may not be quite as large as the Interop show slated for later in the spring, that one vendor can assemble that much humanity for one technology track is beyond impressive.
The event boasts 220 customer presentations. Think about that, it’s more customers than you see at a lot of shows and we’re only talking speakers.
A lot of us folk in the media play this game about when SOA will “arrive,” when it will enter the majority adoption phase? Well I’ve got a Drew Carey, B-52′s, MGM Grand, 220 customer speakers, and thousands of attendees that says SOA already has arrived … and it’s about to get the kind of platform we haven’t seen in the IT industry since the heady days of the dot-com boom. Some may say Impact exhibits more of the signs of the irrational exuberance of the dot-com heyday, but we’re not talking about some flash-in-the-pan vendor trying to gin up business in a red-hot economy. This is old money putting on the ritz during what is tantamount to a recession.
The appropriate response, after “Wow!”, should be “Looks like IBM’s making buckets of money on this SOA thing.” And if IBM’s making that kind of coin, it means a whole pile of users are hip-deep into their SOA installations. That should only become clearer next month as a few thousand people are shaking it to “Dance This Mess Around”.
We at SearchSOA.com have just finished up with the maiden run of our “Pragmatic SOA Governance” seminar. The first two shows were in suburban Philadelphia and Washington D.C. and I’m pleased to report they went swimmingly.
Here’s a few of the high points from the show:
- Anne Thomas Manes, VP and research director at Burton Group, noted that a lot of users want to standardize on a single enterprise service bus, neglecting the reality that most every company will need to support multiple ESBs. She also suggested not thinking of the ESB as a “bus” because it implies that there’s something in the middle of your services. Instead she suggested the term enterprise service network.
- Miko Matsumura, deputy CTO at Software AG, used the image of a crack pipe to illustrate a point during his presentation, namely that bad development habits can be hard to kick.
- Daud Santosa, CTO at the National Business Center inside the U.S. Department of the Interior, made a great point about choosing foundational pieces of technology — if the technology in question requires consistent and costly upkeep, then it shouldn’t be a foundational piece of technology. “This is hard enough,” he said, pointing to the detailed reference architecture he’s trying to implement at NBC. “Look for technology that makes your life easier.”
- Dan Foody, VP of Actional products at Progress Software, made a great observation in response to a question on how can you sell your business on the merits of SOA: take a sales course. His reasoning was you need to describe what service orientation means to your business and outside IT fiefdoms and that will require real professional sales skills.
- Many attendees bemoaned the communications difficulties that plague IT projects, but Matsumura offered that there is a common language everyone speaks: money. The line drew a hearty laugh from the Reston attendees, but later one person from the audience mentioned to me that the “money” line helped crystallize what he needs to do to get executive buy-in.
- John Woolbright, CTO at Synovus Financial Corp., noted that many real-time systems are undone due to a lack of data quality. He suggested defining systems of record for data. “If you want your SOA to be successful you need to know where that data is and how to access it.”
- Foody stressed creating visibility not only into the IT infrastructure, but to the business process itself. Failure to provide that visibility can lead you down the path of applications that don’t deliver as promised for the business, he noted.
- Manes continually stressed the importance of getting a handle on the producer/consumer relationship inside SOA as a key element for governance. Apparently too many users are running into problems caused by unchecked service consumption.
Most of all, a hearty thanks to our attendees. Rarely do you see audiences that are anywhere near that engaged during the presentations. It served as reminder that the practical implementation of SOA governance has become a pressing concern for app dev and IT shops.
Our sister site, TSS.com has got a spirited discussion going about WSDLs, REST, XML, JSON and Java APIs. Some are arguing “the best WSDL is no WSDL at all.”
I recently ran into an architect who was trying to wrap his head around SOA. He had sorted out most of it, but one thing was gnawing at him: what makes for a good WSDL?
Obviously that can change dependent on the service in question, but it dawned on me that a good set of examples would be in order. Thomas Erl has listed some essentials for what should be in a service description:
- the service endpoint
- each service operation
- every input and output message supported by each operation
- the data representation model of each message’s contents
- rules and characteristics of the service and its operations
That’s a great starting point, but it’s no substitute for the finished product. Fortunately there is a reservoir of WSDL expertise out there, namely you, or at least some of you who are reading this. What we’re looking for is your WSDL examples. Send them to us and we’ll publish them so that other architects and developers will have some concrete examples to reference.
It can be WSDL 2.0 or WSDL 1.1. If some of you have tried to use WADL for REST-based services, we’re interested in that as well. You should include an explainer of why you made the choices you did and any key takeaways for those who are referencing your example. What we’ll do is create a specific spot on the SearchSOA.com site for all the submissions, a working WSDL resource center.
Enough people are doing this that we ought to provide them with guidance on how to do it well. You can e-mail submissions directly to email@example.com.
I was talking with Wayne Ariola, Parasoft’s vice president of strategy and corporate development, last week about the concept of SOA quality. Parasoft’s been using the term “SOA quality” as part of the latest rollout of its SOAtest product, which now is able to query UDDI registries so that WSDL verification tests can be performed at the time they’re published.
Quality is a key element in software development and it should go without saying that the more business that gets pumped through Web services, the more important it will be to have a good QA process in place for those services. Noting that “lack of central visibility” is normal in the classic software development lifecyle, Ariola listed what he thinks are key elements in that SOA quality process.
1. SOA necessitates centralization, a role played by the registry/repository. He argued that stovepipes become inevitable without it.
2. A health check needs to be performed to make sure the asset meets the requirements. Among the potential requirements, he highlighted defining the asset’s consistency and the boundaries for its reuse.
3. You need a convenient way to emulate the service. Taking down a component could cause unintended chaos once it’s being leveraged in multiple places. Testing and changes are best handled in the virtual arena in order to avoid that trap.
4. If a component or service is going to reused, the testing expectations need to be made readily available so that different orchestration scenarios can be vetted. In general the testing environment should be as open and accessible as possible.
5. Make sure you fully and accurately define your SLAs, future users of that service will need to understand the true behavior expectations behind it.
6. Be prepared to do some sort of compliance monitoring in order to make sure your services are being properly used.
Last week WSO2 released a REST-based SOA registry, joining Mulesource, which released a REST-based SOA registry in January. Together they’re doing something we haven’t seen a lot of in the SOA space over the past few years: they’re innovating.
So much energy has been poured into establishing standards, building out distinct product markets and fleshing out platforms that it’s been a while since we’ve seen much in the way of innovation. Early in this decade the ESB, the services registry, Web services management software and XML networking hardware pushed the IT envelope. They gave users a way to combine applications in a whole new way. Suddenly component assembly was on the table and loosely coupled, autonomous, stateless, composable, reusable services moved from theory to reality.
The REST-based registry isn’t likely to create that sort of paradigm shift, but it does shake up a marketplace that may be getting a bit complacent. Both of these releases are open source and both try to support the service-oriented concept of discoverability without using the UDDI standard. You might be asking, isn’t SOA supposed to be standards-based? Well, yes, it is, but that doesn’t mean that UDDI has to be one of those standards. REST is built on the HTTP standard. It also opens up the question of how can we better enable the princples of service orientation?
I’m not implying WSO2 and Mulesource have found a better way to build a registry, UDDI may still be the gold standard as far as that’s concerned, but they have opened up the subject for debate by attacking discoverability in a new way. They also might be setting the table for the next wave of innovation in SOA. Going back to a December podcast with Forrester Research’s John Rymer, the area of dynamic business applications begs for real-time innovation. Perhaps Microsoft’s Oslo initiative will break ground in model-driven design. IBM may be unveiling its REST-based Project Zero this spring.
Wherever the innovation comes from, we need to remember that it will come. We’ve been conditioned to think of SOA as a set of products and standards that popped up seven years ago, but what it really entails is an approach to technology that will allow you to best incorporate the next wave of innovation … and the one after that … and the one after that. These REST-based registries may be the precursors of advances to come.
In the world of application development, data is king. Unfortunately many new-fangled approaches to app dev, like SOA, have neglected that importance of turning data into an accessible, reusable resource. This podcast with Marcia Kaufman, partner with Hurwitz & Associates and co-author of Service Oriented Architecture for Dummies, delves into some of the all-too-frequent data mistakes being made by users.
The podcast will cover:
- The drivers for data integration
- Why data needs to be treated like a shared and reusable resource
- The importance of data quality
- Why you need more than an ETL tool to integrate your data
- The necessity for creating a standardized way of handling data
Web 2.0 and enterprise mashups were the hot topics at this year’s Web Services/SOA on Wall St. conference. Michael Ogrinz, principal architect for global markets at Bank of America, revealed his company was heavily pushing the mashup concept to its internal users. He argued mashups are a way to overcome low user expectations that the Internet can become a dynamic, useful tool in getting their jobs done.
He also said end user IT departments ought to get involved in mashup development.
“The reason you see the emergence of these mashup vendors is IT has failed to provide the service,” he said.
That’s an interesting take, that vendors are rushing in where users haven’t dared to tread. The panel on which Ogrinz sat lauded mashups for their do-it-yourself nature and expressed hope that more companies would catch the DIY spirit.
Jonathan Rochelle, a senior product manager with Google, stated that mashups not only stand to get corporate employees to avail themselves of powerful modern tools, but he also said, “The concept that mashups will be there is what drives the architecture.” Essentially, his point was that compelling new applications are what makes all that architectural rigor worth the while.
Always ready with a good analogy, Miko Matsumura. vice president and deputy CTO at Software AG, broached the same topic as Rochelle, saying “Mashups are sexual reproduction for your apps.”
Well, that sure does sound like more fun than we’re used to in the IT business, but Matsumura was driving at something more biological, specifically “How does evolution produce variation?” He noted that humans share something on the order of 95% of their DNA with chimps. Similarly, most applications will share the same architecture (once you get a solid architecture in place). From there, variation can take place.
As Matsumura explained it, “You’re looking to enable an infinite number of things you can do in business, but a finite number of things your IT people have to do.”
That sounds like a solid plan, Web 2.0 evolution on top of an enterprise grade SOA. Yet, as Marc Adler, senior vice president of equities and head of complex event processing at Citigroup, noted, data services have a sizable role to play in that enterprise grade SOA and it has been tough to bring DBAs into the fold.
“They kick, they scream, they holler, they don’t want to let their data out,” Adler said.
He suggested a carrot and stick approach to bring the DBAs on board. The carrot is that by opening up their databases, DBAs stand to elevate their status inside the organization. The stick is having executive’s mandate the change.
At SearchSOA.com we spend a fair amount of time writing about the importance of governance and how you aren’t likely to succeed with service orientation unless you put a solid governance model around those efforts.
Yet let’s be honest, the term “SOA governance” sucks. It reeks of someone else telling you what to do, hectoring you over every little detail of a project. It sounds about as desirable as a colonoscopy with an IMAX camera.
It’s a particularly sticky term here in the U.S.A. We don’t like a lot of governance. In fact, we get uppity when we think we’ve been placed under the yoke of too much governance. We’ll dump your tea in the harbor when that happens. In fact, you can be sure many project teams have formed some unprintable thoughts about governance without representation.
That said, can we admit that stovepipe application development leads to needless duplication of effort and that it actually prevents businesses from pursuing new opportunities? Being a cowboy sure sounds like fun, but if that’s what you want, then go buy a horse. If you want to work for a company with stockholders/investors and a comprehensive benefits package, then maybe, just maybe, you might want to consider how what you do affects the bottom line.
At the end of the day, that’s the crux of SOA governance – let’s put a little organization around all these disjointed IT efforts in order to make them more profitable. I suspect everyone whose hackles rise at the sound of the word “governance” would agree with that statement. No one wants to be the square peg begging for a hammering. Beyond that, who doesn’t want their work to be considered valuable?
The rub comes in how to sum up all of the things that exist under the heading of SOA governance in a term that doesn’t cause automatic resentment. As ZapThink’s David Linthicum noted recently, SOA governance encompasses a lot of import facets in application development and management. We need to call it something. I’ve heard “productivity” and “business value” tossed around as replacement terms, but those still sound a bit too buzzwordy.
As a believer in the wisdom of humans, though, I figure someone out there has come up with a term preferable to SOA governance. Feel free to inundate us with suggestions. We’ll pool them together and then put together a poll to see which one our readers prefer. Who knows, maybe we’ll come up with something that sounds more like something you want to do and less like something someone else is forcing you to do (or trying to sell you).