We spend a lot of time these days talking about governance and management when it comes to SOA. There’s a good reason to take that macro view, because far too many people get lost in the trees and fail to see the forest when it comes to service orientation. We are talking about enterprise architecture after all, so an enterprise-level view would be appropriate.
That said, you can put the perfect governance model in place and it won’t mean a thing if you don’t understand messaging. SOA requires a lot of integration work and integration, more often than not, requires messaging. With that in mind we created a messaging lesson in our Service Orientation for Architects School. It features a Webcast with WSO2’s Paul Fremantle on service-oriented messaging, in which he breaks down a slew of messaging alternatives, including JMS, HTTP, REST, SOAP, WS-Addressing, WS-ReliableMessaging and traditional message queues.
Yet more than that, Fremantle delves into messaging practices that will aid you on the SOA front. It’s one thing to boil up a big pot of integration spaghetti, quite another to architect a reliable messaging infrastructure. The lesson is focused on the latter.
The goal of mediation is to help create a flexible messaging backbone for your company. The tip covers a host of mediation techniques, including Web Caching, load balancing and message-based routing.
It’s an ideal chance to catch up on the architectural underpinnings of messaging as they apply to SOA. Even for those of you who feel fairly confident about your messaging skills, this lesson is sure to give you a few pointers to hone your skills.
It’s probably a sign of our times that we view BEA Systems Inc. as a little fish unable to defend itself against larger predators in the software industry ocean. According to its 3rd quarter financial report, BEA is on track to rake in $1.5 billion this year. It still needs to prove in the 4th quarter it hasn’t been crippled by Oracle Corp.’s $6.7 billion October takeover bid, which it rejected, but a conversation I had last week with a BEA customer proved enlightening.
The customer in question, a CTO whom I contacted on a totally separate matter and wished to remain anonymous, believes BEA’s approach to technology can help it weather this storm.
“They adhere to standards and their tooling is open enough that we see no reason to stay away,” he said. “If a change we didn’t like occured after a takeover, we don’t feel like we’d be locked in with BEA. They get loose coupling. We could unplug from them if we had to.”
His basic argument was that BEA has become open enough and embraced heterogeneity to the extent that it can continue to compete for customers based on functionality. It’s got a service-oriented defense system.
“We need technology that works,” he said. “This takeover drama might be interesting to Wall St., but it has nothing to do with my projects. From a user standpoint, BEA was in more trouble four or five years ago when we weren’t sure if they were going to embrace more open systems. They did and because of that we’ll continue to look at them.”
He reinforced what we already know, BEA has proven successful at selling software during the past decade and it shouldn’t be taken for granted that users will stay away from a vendor that has delivered for them in the past. This isn’t some overly leveraged wannabe without the means to support itself. BEA has been a viable player in the app dev space.
Here’s something I wrote in October about why Oracle might want BEA:
While there’s massive overlap between BEA’s offering and Oracle’s Fusion line, BEA does have three particular strengths that Oracle might be looking to leverage: data services, internal portals and external transactions. Those were the three most popular types of service-based applications our users reported they are either working on or plan on undertaking in the next year. Even more importantly, the demand for these types of applications increased sharply with respondents who reported their companies had achieved some measure of architectural maturity. In other words, the farther along users are with SOA, the more important those projects are likely to become.
BEA has its AquaLogic Data Services Platform, it has its WebLogic Portal product as well as the portal functionality it acquired when it bought Plumtree Software in 2005, and it has the Tuxedo transactional business on which it built itself. So the BEA goose might be sitting on a few golden eggs … and that’s not a bad pet for a would-be giant to have.
Yet if that’s a good set strengths for Oracle to buy, then it’s also a good set of strengths for BEA to have. If a user has a data services, portal or transactional project in the works, then BEA (which reports that more than 60% of its revenues are derived from services) stands to be a player.
While the Oracle bid surely staggered BEA, don’t be surprised to see BEA do a fair job of fighting back this quarter. The fact that it has enough going for it to be a takeover target also means it might have enough going for it to fend off Oracle’s advances.
I was reading a recent blog entry by Joe McKendrick in which he noted that service-oriented architecture can save money during hard times and add revenue during good times. It got me thinking about something I’ve heard fairly regularly over the years, namely that SOA often sounds like something out of an infomercial.
You mean SOA slices, dices, chops, cooks things to perfection, cleans up easily, prepares healthier food and has zero environmental impact? You almost expect Ron Popeil to pop out from around the corner and announce that, “But wait, there’s more.”
Let’s face it, SOA sometimes sounds too good to be true. It also leads one of the great misconceptions about SOA, that it’s a tidy thing you can buy. People want SOA to be tangible. They want to be able to point to it and say, “There’s my SOA.” It’s why so many glommed onto the enterprise service bus concept. The ESB is a piece of integration middleware that follows certain service-oriented principles, but many made the mistake of thinking that buying an ESB gave you a de facto SOA. It’s a natural reaction. When something new and compelling comes along, you want it in your hands, preferably now.
Yet SOA isn’t some secret spice that comes in its own box, something you can add liberally to every project. SOA is a consistent and sensible approach to architecting your business. It’s rigor and diligence more than technology.
This week we’ll get deeper into that issue with a podcast with esteemed IT analyst and co-author of “Service Oriented Architecture for Dummies” Judith Hurwitz, in which she directly addresses the whole faulty concept of “SOA in a box.”
That brings me back to the (fair) complaint that SOA sounds too good to be true. Critics are correct that no one thing will solve all your app dev problems. That said, rigor and diligence in building a modular, adaptable architecture is exactly the sort of thing that can help you in mulitple, often diametrically opposed, situations. When the bad times hit, it can help you with cost containment. When the good times hit, it can help you seize opportunities. That’s what an adaptable infrastructure does.
Just last week, we had a story that noted an SOA infrastructure had helped Sprint/Nextel speed up integration with new trading partners twentyfold. That’s a case of saving you money and making you money in one fell swoop. Doing things in a service-oriented manner creates business agility, which is the real goal.
Building a more agile business isn’t something that sounds too good to be true. Large numbers of companies are doing it right now and they are reaping the benefits. It may be hard work, it may require creative approaches to change the corporate culture, but it is not a flimflam promise. SOA is an approach to technology, which opens up a greater number of business possibilities. It can promise more because flexibility is at its very core.
Web services and composite applications, like traditional monolithic apps, rely on data. Without the right data at the right time, the service/application has nothing to execute. In this podcast, Nexaweb Inc. COO David McFarlane talks about how composite applications involve much more than just some slick tools that make eye-popping front ends. He touts data integration as a key element in composite application development and the creation of dynamic user interfaces.
Among the topics covered are:
- The semantic technical challenges involved with data integration
- The organizational governance needed to facilitate data integration
- The creation of real-time, event-driven UIs
- Event-level integration in mashup services
- The role of business intelligence in composite development and service agility
- What constitutes a true rich user interface
It’s that time of year where people dust off old chestnuts, revive traditions and take a wistful look back. This is something we ran in 2005 as part of a newsletter, but it never had an official home in cyberspace. It only seems fitting that we rectify that situation.
Information technology is a serious business, certainly it’s one we take seriously. Even with a major national holiday looming this Thursday we’ll keep bringing you the latest in SOA, Web services and integration news.
Yet, let’s face it, you probably aren’t going to be making that enterprise-altering decision this week or going live with your latest architectural achievement. Too many people will be skipping out early and trying to beat the traffic, with gravy-covered visions dancing in their heads.
We at SearchSOA.com recognize that. This isn’t the week you’re going to change the world. Rather it’s a week to reflect on what you’ve been doing and what projects will soon be on your plate. With that in mind, here’s our top 10 reasons why service-oriented architecture is like a Thanksgiving meal:
- Like a Thanksgiving meal, it takes a lot of work to put together an SOA … and no one wants to clean up the associated mess that comes with it.
- Reuse, the next round of Web services you build are the IT equivalent of next week’s turkey sandwiches and soups. You should be getting a lot of meals out of this feast.
- Unless you find a way to spice it up or make it savory, SOA can be dry and a lot of people around the table may quickly lose interest. Also, like a big turkey meal, too much SOA can put you to sleep.
- An SOA project can bring together a lot of people you rarely see. In fact, you probably aren’t sure you want to see some of them.
- SOA can give rise to lots of interesting combinations, kind of like turducken (a chicken stuffed inside a duck stuffed inside a turkey).
- Everyone offers up advice on how to cook up an SOA, but they always leave you with the distinct feeling that they aren’t so sure these tips actually work.
- Standards, on Thanksgiving the standards are turkey, mashed potatoes, gravy, stuffing and cranberry sauce. In SOA it’s WS-* specifications and communication protocols.
- You can undertake lots of small projects while you’ve got your SOA bird in the oven
- It takes a solid network and good communication to move all the food around a Thanksgiving table so that everyone gets to pick exactly what they want. In many ways, it’s a service-oriented meal dependent on a loosely-coupled infrastructure.
- Screw up your SOA and you’ll never hear the end of it.
We at SearchSOA.com are looking for the next generation of leaders in the app dev space.
You see, we’ve got this new blogs section (you’re reading it right now) and we know we’ve got some budding stars out there. We offer a heck of a nice platform with nearly 500,000 site members. It offers the chance to establish yourself as a thought leader in an arena that has become critical to the enterprise.
So who are we looking for?
First, we’re interested in end users and integrators. Nothing against vendors, but they already do a fine job of getting out the word on their particular slant on things. What we want is the people who are trying to make service-oriented architecture work, the folks who’ve had to roll up their sleeves to tackle the untamed world of service orientation. Make no mistake about it, the best resource in this industry is the user community. It’s where the best, most incisive information can be found. We’ve got the platform from which you can be heard, all we need is folks who have something to say.
Second, have a focus. SOA is a broad topic and a good blog will find a solid niche inside of it. It could be data integration or architectural design or runtime management or REST or composite applications or WS-* standards or BPM/event handling or security or network issues. It really depends on where your expertise lies. We’re open to suggestion. What we want is smart, articulate people who want to interact with the larger SOA community. Pick your topic and let us know what issues inside of that topic you plan to cover.
Third, send us a sample. It doesn’t have to be “War and Peace”. In fact, since it’s a blog we’re talking about, “War and Peace” would be overkill, but we will need to see a sample of your writing to get an idea of what to expect from you. This is going to be a blog, so you’re going to have a lot of freedom. We won’t be editing your stuff for spelling and grammar. As such, we need to make sure we’ve got bloggers who are capable and confident writers.
Fourth, remember this is a blog and not a weekly column. A good blog is a busy blog. It’s great if you want to make a regular column-style entry part of the blog, but remember to punctuate it with quick insights and links to what you think is valuable other content. A good idea can take you a long way. If it’s a good idea that can be summed up in three paragraphs, that’s fine.
If you’re interested, send your writing sample, a quick explanation of the topic you’d like to cover and a short bio to firstname.lastname@example.org. If we like it, you’re on the blog roster. It’s that easy. You can be impressing colleagues, friends, family and would be (or ongoing) love interests in no time. Part of our site relaunch effort is to give our community more of a voice and this is a major initiative for us. Users never have needed sober advice from their peers more than they do right now. Can you be one of the people who steps up to provide it?
And don’t forget about our current reader contest. Maybe you’ve got a lesson learned to share with the community, but you want us to write it up for you (because we’ve got professionals who are paid to do that sort of thing). Well, this contest would be right up your alley in that case. Winners will receive a copy of Thomas Erl’s new book, “SOA: Principles of Service Design” as a thanks for their participation.
Over on her ebizQ blog, Krissi Danielsson has noted that the buzzword success of Software as a Service (SaaS) has spawned numerous aaS imitators, including Data, Architecture and Voice all “as a Service.” In his ZDNet blog, Phil Wainewright added that aaS is redundant because the very function of business is to provide services.
It’s about time some sane, responsible folks pointed out that we’re heading into buzzword overkill with “as a service.” Yet we’d be remiss if we didn’t have some irresponsible fun with aaS before it becomes yesterday’s catchphrase.
For instance, here’s a list of software possibilities that still haven’t had their aaSes handed to them:
- Hidden License Fees as a Service (HLFaaS)
- Stovepipe Application Sprawl as a Service (SASaaS)
- Integration Spaghetti as a Service (ISaaS)
- Every Vendor Insures Lock-in as a Service (EVILaaS)
- Must Upgrade to the Expensive Enterprise Version If You Want It to Scale as a Service (MUttEEVIYWItSaaS)
- Rogue Services as a Service (RSaaS)
Also, as we all know fortune cookie proverbs are made infinitely better by adding ‘in bed” at the end. Let’s try that with “as a service.”
- Count your blessings by thinking of those whom you love … as a service.
- Plan for many pleasures ahead … as a service.
- Something you lost will soon turn up … as a service.
- Good things are being said about you … as a service.
- Fame, riches and romance are yours for the asking … as a service.
- A friend asks only of your time … as a service.
- Romance comes into your life this year in a very unusual sort of way … as a service.
- Stop and smell the roses … as a service.
- Someday you shall see a wise person in the mirror … as a service.
- He who shows too much cheek to a lady may have it slapped … as a service.
At the Ajax Experience in Boston last week, I caught a presentation by Joshua Gertzen, primary architect at ThinWire, called “Dodging the Pitfalls of Enterprise Ajax Applications”.
Gertzen and ThinWire came into the Ajax/RIA space through an interesting side door, working on desktop banking apps at an ISV called Custom Credit Systems Inc. So Gertzen’s perspective is that of a programmer with a business focus than one who likes to make pretty Web pages. In fact, he noted that the Web traditionally doesn’t handle data-centric applications very well, which is no small issue for those building data-heavy business apps.
Even more than that, he said that a serious financial application can have thousands of business rules attached to it (16,000 was his number of choice) and it can make for a presentation layer nightmare when it doesn’t understand a rule change. The degree of difficulty only rises when you add Ajax and Web services to the mix.
“All the new application endpoint handlers on the server could number in the hundreds,” Gertzen said.
Gertzen’s proposed solution is that logic and events should be handled on the server to allow full access to server resources and to make debugging easier. That will allow developers to create a tightly coupled Ajax/RIA interface that doesn’t get bogged down with too many rules.
Of course, since this is an SOA blog, I probably just hit a trip wire for many of you when I used the words “tightly coupled.” Aren’t we trying to get away from tight coupling? Well … yes … though obviously there comes a point where you have to implement and that may involve some tight coupling.
I caught up to Gertzen after his talk to bounce that very question off of him. What does the application architect need to consider when tying these rich interfaces to a Web service that may have shifting data sources and business rules? How do you rationalize the tight coupling of the interface with the loose coupling of the service?
Gertzen suggested having the server make a Web services call to itself to create a new, separate instance with which the interface can interact. That way state and change management don’t become rolling trouble spots.
Let’s take that ball and run with it. Say you’ve got an enterprise that runs a few hundred Web services inside its SOA and you want RIA interfaces for all of them. That would seem to be a real sweet spot for virtualization tools. You could make those new instances part of your overall SOA governance strategy (specifically in how you handle change management). It’s amazing how all of these hot, new areas in IT can potentially fit together. Whether virtualization will become the secret sauce in the RIA/Web services sandwich remains to be seen, but it certainly would seem a handy way of getting around the problem of tightly coupling an interface to a service that will not remain static.
We’ve got a new reader contest at SearchSOA.com. It involves the very thing our readers tell us they most want to hear, yet it’s what they least want to talk about.
It’s worst practices, which are always fascinating when it’s someone other than you. We love other peoples’ pain … our own, not so much. Yet the demand is such that we figure some of you out there are willing to sound a warning for your colleagues out there. Users are hitting the majority adoption phase of SOA and they’re rightfully nervous about the potential pitfalls. Plus we figure part of the tale has to be how you corrected the mistake since people normally fix a mistake once they realize they’ve made one. Mac Daddy and Daddy Mac from Kris Kross don’t still wear they’re clothes backwards.
Anyway, for those interested, here are the contest details. Winners will get a free copy of SOA: Principles of Service Design by SOA guru and SearchSOA.com site expert Thomas Erl.
It is common for small and midsize business to wait out technology bubbles. If a hot new technology bursts onto the scene, the SMBs don’t immediately adopt it. Expensive and unproven technologies aren’t usually their cup of tea. It’s a sensible approach that keeps IT from being too much of a cost center for users who don’t have a ton of cash to spare.
Yet, as we all repeatedly hear, service-oriented architecture isn’t a technology. Rather it’s an approach to using technology and, like Jennifer Lopez’s love, that don’t cost a thing. Service orientation is an approach toward business that has been around for decades and embodied in things like ITIL. Enterprise architecture is a discipline. On the face of it, SOA requires nothing an SMB can’t do.
A while back, I spoke with Sandy Carter, IBM’s vice president for SOA and WebSphere strategy, about SMB adoption and she noted that three quarters of mid-market companies are using Web services and that “I’ve never seen this fast of an uptick for a technology in the SMB customer base.”
Carter then caught herself and added, “Well, we don’t consider SOA just a technology and maybe that’s the reason for the uptick.”
She noted that service orientation was allowing SMBs to create value added services and to connect to larger trading partners and markets with a minimum of custom work involved. The thing those sorts of projects have in common is they’re revenue generators. Carter said that while larger companies are often focused on cost cutting (viewing IT as a cost center), SMBs who’ve entered the arena seem to view SOA as a way of running IT as a profit center.
Ask anyone what the ideal startup project for an SOA should be and you’ll almost invariably hear the answer that it should be tied to a revenue stream in order to provide the necessary ROI for the work involved. It should be the first step in a strategic plan, but tied to a tactical business opportunity. Could it be that SMB’s fundamentally understand SOA better than some of their supersized counterparts?
Carter pointed to some other advantages SMBs might have in this area.
– “Because there are fewer business and IT people involved, they can align faster. Often the CFO has business and IT reporting directly.”
– “Big companies have significant governance issues. SMBs can be focused on targeted processes, not fixing overall categories.”
– “In a smaller business, people often wear multiple hats. They have a broader view of the business than just what they do.”
Gary Grandlienard, director of enterprise architecture for Railinc Corp., a $51 million rail industry information services business based in Cary, N.C., agreed with Carter’s take that SMBs have decided advantages over large companies when it comes to SOA.
– “I’m able to work directly with the project teams and that ensures there’s consistency in the tools they’re using.”
– “It’s a lot easier to educate everyone involved, executives and developers, about what we’re trying to achieve with SOA. It’s much easier for us to communicate with one another.”
– “A lot of our apps were using the same information, but we were still building stovepipes. The truth is we’re too small to not be sharing this information across our application portfolio. The problem isn’t so big that we can’t get our arms around it.”
– “One of the reasons we’ve been able to sell SOA is because it’s part of our data quality initiative. It’s tied to our core business.”
– “We meet weekly with our application architects to make sure they think interface first. We can do follow up at the enterprise level.”
Smaller scale has its advantages, particularly when it comes to governance. The enterprise architect can work directly with the project teams and report directly to the executives. While a lot of SMBs may lack the confidence to try a full bore SOA implementation, here’s a guess that in the coming years many of the leading SOA success stories will be coming from the SMB ranks. They can best see a targeted three- or five-year plan through to the end and they’ll probably realize SOA-related gains the quickest. In fact, expect a lot of larger companies to look at those SMB case studies and ask, “I wonder if that would scale for us?”
Michael Meehan, Site Editor, SearchSOA.com