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).
SearchSOA.com has gone international. Just recently we launched a version of the site in China. Now, technically speaking, we don’t have a billion new readers on the site, but you get the idea: namely, we’ve launched the site in the most populous nation on the planet.
Apparently a lot of those emerging businesses in China are thinking it might make sense not to build a haphazard and unmanageable application infrastructure. Imagine that? These companies might actually start with a well-conceived reference architecture and adhere to the basic principles of service orientation. They might be employing the best practices covered in our Service Orientation for Architects School inside those pristine greenfields with which they get to work.
It’s actually not the most comforting notion when you get right down to it. You’ve got who knows how many emerging companies looking to run IT as a profit center instead of a cost center. What if they’re agile and you’re not? How many partnerships will you miss out on? How much business will go to someone else? Suddenly the world isn’t as flat as Thomas Friedman theorized. Instead you’re surrounded by mountains to climb in every direction.
It should be fascinating to see how SOA adoption goes in China. Will the Ertan Hydropower’s Yalong River Dam project be the standard over there? If so, then app dev really will have entered a new world order.
Of course, maybe we’ll confuse our Mandarin readers as much as we help them. For instance, when our lead writer Rich Seeley makes a reference to Yogi Berra at the top of a story, it could cause people to think Yogi Berra is some famous IT guru whose wisdom must be sought out … and that could be a big clog in their machine.
Unless you’ve been under a rock, you’ve probably heard by now that Microsoft has placed a $44.6 billion bid to buy Yahoo!.
We’ll leave it to others to ponder the Wall St. implications of the move, but in her All about Microsoft blog, Mary Jo Foley posits “a Yahoo! purchase would irrevocably change the kind of company Microsoft is.” Foley focuses on advertising in her comments, but it could represent a change in Microsoft’s application development focus. Microsoft built itself around operating systems and desktop applications, the things you do with a computer. Of course, with the advent of the Internet, what you do with a computer has changed radically. Yahoo! and Google have made hay in offering up Web-based applications, leveraging search capabilities and creating dynamic user portals.
Microsoft has tried, mostly unsuccessfully, to gain a dominant position in those arenas. While Dana Gardner speculates a Microsoft-Google partnership might be a mess, it could represent a return to Microsoft’s core applications business. Yahoo! and Silverlight (for RIA and composite apps) represent where the next wave of applications are headed. On the enterprise side, easily distributed Web apps and multimedia mashups are where a lot of companies want to go. It’s where the innovation is and for Microsoft, a company which has always fancied itself an innovator, that’s a good place to be. There are those who think enterprise mashups will be the killer app once users get a service-oriented architecture in place, the idea being that a loosely coupled infrastructure will lead to dynamic new applications.
It’s no secret Microsoft has long faced criticism in SOA circles because its remedy for users grappling with a heterogeneous application environment has been to pursue homogeneity on the .NET platform. Microsoft’s Oslo model-driven development initiative is still in the planning stages, but a Yahoo! purchase begs the question “Why bother with application infrastructure?” Obviously no one expects Microsoft to pull its irons completely out of that fire, but if that’s not going to be a big growth area for the good folks in Redmond (and IBM and Oracle/BEA are gobbling up large chunks of that pie) then maybe it makes more sense to concentrate on New Wave application development. Microsoft could make leveraging service orientation its app dev enterprise play rather than implementing service orientation.
Let someone else do the tedious work and be the company that does the cool stuff.
There’s so many facets to this offer that it’s impossible to assess the true implications of a Microsoft/Yahoo! merger, but going after Yahoo! does indicate where Redmond’s heart is. If Microsoft really wanted to pursue application infrastructure, BEA Systems was a completely complimentary acquisition target. It would have given Microsoft unparalled reach across the .NET and Java platforms. Yet it didn’t make that play. Instead it’s made a Web play which could build on top of of what the application infrastructure vendors provide, potentially expanding its enterprise app dev audience well beyond the .NET platform.