What would George Carlin say about the Ten Mistakes Companies Make When Implementing SOA?

In Paul Callahan’s recent eWeek article he lists ten mistakes companies make when they implement SOA Projects. It’s a pretty good list, and I’ll summarize it here, but I’d like to do some tweaking.

Do you remember George Carlin explaining how the Ten Commandments could be boiled down to two, with another added for good measure? If not go take a look. That’s what I think about this list. It isn’t bad, but it needs some tweaking.

Let’s take a quick look at the ten first, and then I’ll discuss how I would consolidate.

1. Taking a Shotgun Approach. That is, SOA-enable everything, regardless of whether there is a business need for the resulting services. LogicLibrary’s Brent Carlson likes to call this A Bunch of Services. (ABOS) and is one of the most common pitfalls of Big SOA.


2. Failing to Involve Business Analysts. Technologists tend to think of SOA as a technology initiative rather than a business initiative. When that happens, not only do the wrong things get built, but it is unlikely the organization will ever see the sort of ROI promised by these technologists.


3. Spending More Time on SOA Products Than SOA Planning. Given lack of business direction, IT will tend to think that SOA is something that you buy rather than something you do.


4. Tackling the Largest Projects First. Sure it is inviting to make a big splash with your SOA initiative. But isn’t it better to try to walk before you run?


5. Forgetting that SOA is a Business Problem. It’s not about the technology; it’s about the solution to a problem.


6. Treating Identity as an afterthought. Readers of this blog will know that this is one I take very seriously. Security and identity are the soft underbellies of SOA, and we need to build for security and identity up front.


7. Buying New Products When Existing Investments Suffice. This is a special case of thinking of SOA as a technology rather than a business solution. You don’t always need to buy new stuff, no matter how much you are told to do so by vendors.


8. Misunderstanding Company Key Players. We live in a world of silos, and if you want to play in a sandbox belonging to someone else, you’d better ask first. Don’t assume you will be allowed to SOA-enable legacy systems, deploy to servers or install clients. Find out first, ask, and then get to work.


9. Expecting the SOA Project to Spread Quickly. This isn’t just an issue for SOA, but for any enterprise project where the success or failure of a project is tied to ‘the enterprise’ rather than to a specific project.


10. Lacking Necessary Elements. Embarking on Big SOA without Big SOA resources.

Here’s how I would rework the list. Numbers 1, 2, 3, 5, 7, 9 and 10 are actually different manifestations of the same problem: Treating your SOA rollout as a technical rather than a business problem. If you focus on your business issue, you won’t have ABOS, you will include business in the discussions, you won’t try to ‘buy SOA’ rather than solve your problem, you won’t think it’s a necessity to buy new stuff, you will tie the success of your SOA rollout to a specific business problem and you won’t go down the Big SOA path if you won’t be able to carry through with it.

So now we have four remaining issues.

Numbers 4 and 8 belong together as well. Both are saying the same thing: Start small. Organizations that start small won’t try to tackle the big, high-profile problems first. They also won’t run into the problem of stepping on somebody’s toes. Or at least the likelihood will be much less.

That leaves number 6, treating identity as an afterthought. I’d like to expand this a bit and say that treating scalability, security and identity management as an afterthought is the real mistake.

I’d also like to add an additional mistake. Forgetting your consumers. Effective SOAs will have multiple consumers, and multiple types of consumers. Design your SOA so it can be used by composite applications developers, BPM process gurus, portal programmers and mashers. Then you will be able to get the ROI you need to make your SOA investment an unqualified success.

So like George, I’d like to restate the items in a positive light.

1. Always remember that you are solving a business problem.


2. Start small and scale up as you learn.


3. Design for scalability, security and identity management up-front.


4. Remember your consumers.

Of course, if I really wanted to be true to George I’d add a 5th to the effect that I should keep my &^%$# opinions about SOA to myself.

Linthicum on Mashup Governance...over the top?

I usually agree with David Linthicum of ZapThink when he writes about SOA. He understands the problems faced by organizations moving to SOA-based applications development. He gets that organizations need to put governance in place to avoid SOA turning into merely A Bunch of Services. (ABOS) I'm a fan.

But I think his recent article on mashup governance in the SOA Institute newsletter was off the mark. Not completely, but I think he's making the mistake that many of us make in thinking that mashups need the same level of governance, the same rigor, as composite applications developed within IT.

Here's my take: Not only don't they need the same level of governance, they won't get it.

So let's take a look at what Linthicum has to say. He's right when he says that mashups blur the line between the web-at-large and the behind-the-firewall enterprise. In his words, "...We could find that we soon live in a world where it's difficult to determine where the enterprise stops and the web begins. Now that's scary and exciting at the same time."

I completely agree.

Next he talks about how organizations need to prepare for mashups. Linthicum says that organizations need to design their SOA with mashups in mind, and on this point we also agree. Although SOA has come to be synonymous with the WS-* standards, it need not be. In fact, early SOAs were completely custom, and even today there are a number of competing SOA standards. Yes SOAs need to be designed around standards, but not just any standards. They need standards that make the services and widgets usable by many different SOA consumers.

Let's consider an example. I happen to know of a company that created SOAP-based services to expose some of their products capabilities. However, these services were built in the image of their old API. When it came time to use these services in a BPEL orchestration, never mind within a mashup, it was extremely difficult. These services weren't built with their end use in mind. More services by techies and for techies.

When it comes time to adopt your SOA standards, keep in mind that you will have many different SOA consumers. Not just by coders in VS .NET or Eclipse, but portals, BPM, and even mashups. And when it comes time to implement your SOA, remember that you may have multiple consumers about which you know little to nothing. So architect for flexibility, scalability and security.

Linthicum goes on to discuss mashup governance in some detail, and I'm afraid here is where he and I disagree. Readers will recall I've written about mashup governance before. I believe mashup governance is necessary. Mashers need version control. Mashers need some form of feedback loop to manage defects and enhancements. Mashers need to practice safe scraping and need to be aware of the provenance of the data they use in their mashups.

However, Linthicum believes mashups should be governed with the same rigor as Big Applications developed by R&D.

"So, what do you need to do to prepare for mashups? It’s a matter of addressing the following areas: Requirements, Design, Governance, Security, Deployment, and Testing. In essence, these are core architectural activities that are required to get you to the Promised Land of mashups on top of your existing activities when you create a SOA."

Nice in theory, but impractical in practice. Mashups are to be built by subject-matter experts, not IT professionals. Think Ultra-Agile rather than Waterfall when putting together a framework for mashup governance.

Requirements? How about "build it," "try it," and, "change it." In Big Applications this may be a license for creep. The on-ramp to disaster. But for mashups, inherently smaller and more agile applications, formal Requirements Management is nothing but unnecessary overhead.

Design? Those of us with Big Applications pedigrees, myself included, will cringe, but a formal design process for mashups seems like overkill. If it works, it's probably good enough. If it stops working, then fix it. Will some mashups be inefficient? Perhaps some mashups will be slow. So what? If the mashup is going to be mission critical, if it will service a large number of transactions, then it will likely be developed by IT, not as a mashup. If it's being assembled by a subject-matter expert, it's likely that inefficiencies won't be a problem. When you bet, figure pot odds.

Governance I've already talked about, as well as security. While Linthicum and I may disagree about governance, we completely agree about security. If an organization is going to over-govern any aspect of mashups, my choice would be security. Unlike SOA's notorious performance issues, security breaches have the potential to materially harm organizations. Jail time? Wall Street disfavor? Stockholder uproar? All these have resulted from IT security problems. 'Nuf said.

Deployment is an interesting issue because it should be easy, but can be difficult. After all, what's the harm in allowing a masher to put a mashup into production? A mashup can't hurt the operational environment, right?

Clearly some governance is necessary. I suggest IT provide mashers with a secure and stable deployment platform, distinct from any mission-critical applications, and then leave mashup deployment to the mashers. IT should not attempt to require the same deployment gates for mashups that they do for SAP upgrades, changes to the financial system, or updates to eCommerce. Once the secure and stable environment is in place, leave mashers to mash.

Testing, testing, testing. I think testing falls into the same category as requirements. Should mashers test all possible configurations, scenarios and error conditions? Sure. Will they? Hardly. Putting gates in place to force mashers to test will only put mashers in an awkward position. Should they ignore the testing gates, or falsify the documentation? Darwin and sheer embarrassment will take care of quality control in the long run. That may not be optimal, but quality control will be more effective if it is instituted as a bottom-up rather than a top-down requirement.

My take-away is that mashers need to develop their own governance practices. Trying to force-feed Big Application lessons to mashers will only result in resentment and eye-rolling. Just as with Agile teams, let mashers define their own rules, and let them modify these rules as they learn, discover and create.

ZapThink Predictions for 2008

Continuing in my series on the 2008 mashup predictions made by others, I'd like to talk about a recent ZapThink article by Jason Bloomberg. He makes several predictions about the future of SOA in 2008, to include the sale of ZapThink itself. I won't comment on the acquisition discussion except to say that it seems a bit odd for ZapThink to tack up a For Sale sign like that. I can only guess they are already in the final stages of negotiation and want to boost their price with a little self-promotion, or perhaps want to get an idea of how their current clients will react to the sale.

Whatever the reason, good luck with it.

In addition to ZapThink’s future, Bloomberg makes some straightforward predictions about SOA and mashups. To summarize: The economic downturn in 2008 may cause some businesses to slow down or cancel their SOA initiatives, especially if they are struggling with ways to define the ROI. This will be good for businesses that have already turned the corner on SOA, but bad for the businesses that cancel.
"...For those organizations, we do predict cancellations of SOA projects and deferments of SOA spending, to their detriment. Because after all, their competition might very well be leveraging SOA to be more successful during a downturn, leaving the unsuccessful companies out in the cold."

I agree with both points...to a point. In difficult economic times, businesses will tend to cut back on strategic spending, especially if the ROI is a bit ephemeral, as it can be in Big SOA initiatives. So yes, I suspect we will se a number of SOA initiatives delayed or cancelled.

However, I think this only applies to Big SOA, not to Guerrilla SOA. Guerrilla SOA projects will likely continue forward because their ROI is tied to the success of a specific business initiative, not to some hard-to-define measure of enterprise IT effectiveness. Organizations with Guerrilla SOA projects in the works will still be able to leverage their investment, "...leaving the unsuccessful companies out in the cold." See my previous post on the subject, as well as predictions made by Hinchcliffe and Chappell.

Later in his post, Bloomberg defines a mashup as a "...governed, managed composition of loosely coupled Services within the context of a rich, collaborative, Internet-based environment." Except for the fact that he left out human interaction, that's a pretty good definition. He goes on to say that "...enterprise mashups are what organizations actually do with SOA."

Spot on.

Organizations leverage their SOA investments in many ways. Old-style programmers can boot up Eclipse or VS .NET and use java, C# or other languages to build applications. When used this way the services available in the context of a SOA are really just another API. I'm sure to get hate mail for this, but for an organization trying to maximize their SOA investment, relying on old-style programmers won’t do the trick.

What about portals? Once the portal framework is in place, end-users can customize at will, without depending on expensive IT resources. Making use of a SOA infrastructure will help increase an organization’s SOA ROI. Unfortunately, portals don’t scale as well. Most people want one portal, or if necessary, two or three, but only under duress. See Oracle’s comments on portals. Portal proliferation is a problem that needs to be solved, so trying to increase your SOA investment's ROI by increasing the number of portals is a losing bet.

Another way to leverage SOA investments is through BPM initiatives. BPM and SOA have been joined at the hip for several years. Before SOA, BPM tools could define a process, but executing the process was something else. With integrated SOA BPM end-user could do their jobs while actually in the BPM tool. No more application-hopping. Additionally, with SOA the BPM vendors had a workable standard for integrations. Not every install had to have a unique set of adaptors built specifically to integrate the BPM tool with back-end systems. No more introspecting DLLs to figure out how to talk to home-grown applications. Give the BPM system a WSDL and it could move the world.

As with portals, BPM solutions don’t scale. They are big systems, mostly behind the firewall, built for process gurus to build big supply-chain-type solutions. BPM practitioners need to have training, they need Big IT support and they need to spend a lot of money to install and maintain BPM systems. So while BPM does help businesses get a bit closer to the sort of ROI the EA team promised as a result of Big SOA, it isn't enough.

Now let's talk about mashups. Specifically, business mashups. Mashups are easy to assemble. They are easy to deploy. They scale down beautifully, but scale to the enterprise as well. With new mashup platforms coming on the market, anyone with enough tech savvy to build Excel macros or administer a wiki can build a mashup. Better yet, mashups can take advantage not only of the SOA, but of the WOA as well, opening up the entire world to mashers. Best of all, business mashups put the aggregated data and display elements into the context of an actual business activity. You have the data you need, when you need it, and can take action on the data without having to jump from application to application.

So when Bloomberg says that enterprise mashups will become the killer use-case for SOA in 2008, I want to agree, I really do. But I don’t. First, I think business mashups are actually the killer app, not enterprise mashups. This isn't just a war over verbiage. Enterprise mashups don't include human workflow, but human workflow is a vital part of most applications. Maybe 2008 will be the year that the term 'enterprise mashup' starts to include human processes. If so, then I'll stop harping on business mashups. Until then I'll continue to make the distinction. Second, I think 2008 will be the year mashups get mindshare outside of IT. However, the business won't actually start cranking out mashups until 2009.

I hope I'm wrong and Bloomberg is right.

Good luck, ZapThink, on your pending sale. And thanks, Bloomberg, for your 2008 predictions

Here's a man excited about mashups

You can tell just by looking at this guy how excited he is about mashups. Energy and excitement just rolls off his picture in waves.

Really, Tim's a great guy, and spoke to India's Express Computer about business mashups. The gist is that organizations have too many portals and too many applications that suck up too much of IT's operating budget.

The benefits of aggregation into a portal are lost if end-users then have to remember URLs and passwords for multiple portals. Mashups in a portal context allows users to aggregate aggregations so they don't have to jump around from portal to portal.

The effects of too many applications are twofold. First, just as with portals, end-users have to jump from application to application to get anything done. The second is that there is no budget to work on new and innovative applications because IT's budget is already being spent maintaining existing apps. Mashups help with application aggregation, and because they can be developed without writing code, tech-savvy end users can build these apps themselves.

The article doesn't offer a lot of new and deeply technical information, but it does summarize nicely the view of mashups by vendors such as Serena Software and Oracle, as well as Gartner's Dave Gootzit. At the risk of being tagged as a member of the lazysphere, I'm just going to point you at the article rather than commenting on it.

Cheers.

Hinchcliffe and Chappell Predictions for 2008 Part 2 - Mashup Governance

Welcome to Part 2 of my series on 2008 mashup predictions made by Dave Chappell and Dion Hinchcliffe. In Part 1 I discussed how both are predicting the end of Big SOA. If you are interested, read the original posts and circle back to my comments. If you aren’t interested in the death of Big SOA, but are interested in mashup governance, read on.

Both Chappell and Hinchcliffe note that organizations will start pushing for mashup governance in 2008. We all cringe at the G-word, linking it with over-governance as mandated by legalistic process Nazis. Too much governance and you bring innovation to a standstill. Not enough and you have chaos. Light-handed governance can be a great help, insuring that security is in place, that there are recovery procedures, that everyone knows the lines of responsibility.

I’ve written before about how IT and business need to work together to make sure mashers have a secure and reliable mashup platform. Now let’s take a look at what Chappell and Hinchcliffe have to say along the same lines.

Chappell believes it's only a matter of time until a business-critical mashup fails. Some feed you didn’t even know you used will go away, some 3rd party service will change endpoints, somebody will change the mashup on Friday evening and then leave to hike the Inca Trail for two weeks. What happens? As Chappell says, “…many will be scrambling to figure out who is supposed to fix it, and who to point the finger at.”

He goes on to say that by the end of the year, driven by these mashup failures, mashers and IT alike will understand that mashup governance has to be put in place. Does it need to be as rigorous as the rules and processes surrounding making changes to the SAP ERP Financial system? Probably not. But neither can it be ignored completely.

Hinchcliffe makes similar predictions, but believes the demand for governance won’t happen because of a catastrophe, but because IT will start voicing loud concerns. "...it will likely be widespread grassroots behavior outside of IT that will drive the need for these solutions within IT departments." Security will become an issue as mashers pull data from many sources behind the firewall, from SaaS applications, and even from the web-at-large leveraging Web-oriented Architecture. (WOA) Mashers should ask questions about these data. Are the data reliable? Are the data available? Are the data to be used appropriate for the audience? After all, you don't want sensitive financial data leaked to the wild by a clueless masher.

While mashers should ask these quesions, it is likely that IT will be the one doing the asking. IT will make noises to govern access to mashable data within the enterprise. Additionally, IT will demand a SOA governance infrastructure that will provide security, policy enforcement and scalability across both on premises and SaaS mashup platforms and data sources.

Unfortunately, I’m just not sure whether any SOA governance solution can put the necessary controls in place without unduly interfering with masher innovation. Let’s take it as given that in a SOA world IT will be able to control access to services. Will these same controls work in a WOA world? I doubt it, at least not without cutting off access to uncontrolled services and data. Frankly, I doubt if the business would stand for these tight restrictions.

As I've asked before, what's to be done?

While IT may not be able to enforce governance outside the firewall and known SaaS applications, it can act as an advisor, explaining to mashers why reliable data sources are important. Why it might not be a good idea to use the Unreliable News RSS feed as input to a mashup for the CEO. Why scraping content from a random web site may land him in trouble. In the end the masher will mash, but IT can at least help the masher understand the risks.

Besides the SOA Governance infrastructure Hinchcliffe believes will be put in place by IT, I believe there are some actions that IT and the business can take together to implement safe mashing in the enterprise.

• Agree up-front who owns the mashup and who is responsible for maintenance, updates and enhancement requests. Who is backup in case the responsible masher goes on holiday? The lines of responsibility should be documented before you have to send a helicopter down to the Andes to airlift your masher back to NY so he can fix the mashup.


• Define the deployment and rollback plan and rules of engagement. What is IT's involvement in a mashup deployment? What is the masher's involvement? What is the rollback plan in case a deployment fails?


• Give the masher access to a version control system. Mashers will be generating code, XML, a model, or some other artifact that defines the mashup. That code, model, etc. has to be saved so when the production copy needs to be modified or recovered, the masher doesn’t have to start from scratch. Hint to mashers: a copy sitting on your machine isn’t reliable version control.


• Work with IT to make sure your mashup platform is scalable, reliable and secure. IT should put a registry and a repository in place so mashers know what services are available, the SLAs for the services, and any security, scalability and reliability concerns for their use.


• Require the masher document the data sources before allowing mashups into production. I know, documentation sucks, but so does getting pulled back from your vacation to explain why you've been getting market sizing information from astrology.com

These recommendations won't cover all the bases, but they will provide a framework for governance, even in a world where there is, in Hinchcliffe's words, "...still too much steering committee and not enough operating governance infrastructure." And most importantly, they will help mashers understand that when they mashup a business application, it isn't just a cool science project. It's serious business.

Hinchcliffe and Chappell Predictions for 2008 Part 1 - The Death of Big SOA

It's that time of year again. Everyone is writing their predictions for 2008. Some are bullish, some bearish, some worth reading, some not. Of the myriad predictions out there, I like the ones written by Dave Chappell and Dion Hinchcliffe the best. I almost completely agree with everything they have to say. However because I don't completely agree, it gives me an excuse to write.

I suggest you read both posts in full. They are definitely in the 'worth reading' category. but I want to comment on two points made by both gentlemen. First is about the demise of Big SOA. The second is about the need for mashup governance. Unfortunately, there is too much to write for a single post, so I'll break it up into a two-part series for your reading pleasure.

2008 – The Year Big SOA Died

Chappell and Hinchcliffe are as one in their predictions for the demise of Big SOA. “That’s nice,” you say, “but what is Big SOA and what does it have to do with business mashups?” Good questions, both, so let me address them one at a time.

I’m not sure we have a good definition of Big SOA. Like porn, however, we know it when we see it. Does the initiative span the entire organization? Does it incorporate a lot of planning? Does it have a multi-year rollout schedule independent of any mission critical project? Does the SOA plan stress measures of effort, such as the number of services to be built, rather than results?

Most tellingly, when you ask the project owner to describe the business problem they are solving with their SOA initiative, do they say something like, “SOA enables developers to build applications more quickly, reducing costs through service reuse.” Hint: this isn’t a description of a business problem; it is a description of a technology solution in search of a business problem.

Big SOA is all about the big picture, which can be a very good thing. It’s good to have an understanding of what the organization’s SOA will look like in five years. Of course, in six months the five year plan will be out of date, but that’s beside the point. Thinking about the big picture can help tactical implementations fit into an overall strategy of growth, security and scalability. Big SOA becomes a problem, however, when the objectives are technical rather than business focused, when the measures of success describe effort rather than results, and when the initiative itself is not tied to the success of specific business initiatives.

Can Big SOA be done right?

Certainly. Let’s consider an example. Let’s say your sales organization has decided that adding social networking to your eCommerce site, currently a Web 1.0 app, will increase sales by 15% in the first year. The project gets funded, and the eCommerce product team makes an architectural decision to build the features using SOA. They consult the Enterprise Architecture group to see how the eCommerce initiative should fit into the enterprise SOA master plan. EA and App Dev work together to modify the enterprise SOA master plan, and to plan for the eCommerce upgrade. At implementation time the eCommerce team leverages work done elsewhere in the organization by re-using and re-factoring services and infrastructure.

In other words, Big SOA is the keeper of SOA strategy and an enabler of enterprise reuse strategy. Little SOA implements the strategy on a tactical level and makes use of the shared assets built in other projects.

Now consider Big SOA run amok. This is a story told to me by someone I met at a conference last year where I was giving a talk on consumption-side SOA governance. During the Q&A period, one of the attendees said her SOA project didn’t include any consumption-side considerations. This puzzled me since the consuming applications are where all the ROI will be realized. She said her company’s SOA initiative included a plan to roll out 500 services in the first year, and then make those services available to App Dev, who would be responsible for using the SOA infrastructure in any new initiative. When I asked her “Why 500 services?” she said it was the number they decided was right for an organization of their size.

Run away, far away. That’s what I told her, at least.

Big SOA has been fueled by middleware vendors trying to sell bloated app server stacks, by SOA governance and management vendors and by analyst firms. This next statement will likely generate hate mail, but I believe their efforts were cheered on by Enterprise Architects searching for a way to become more operational and less purely advisory. As a result, businesses have spent a lot of money and significant effort to plan and implement Big SOA initiatives. Every application, every server, every database had to be pulled into the SOA fold. After huge outlays for consultants and software, and after spending lots of time and effort planning for the brave new world of SOA, these same organizations ended up with a five year rollout plan, a huge proposed budget, and no well-understood way to calculate their SOA's ROI.

That’s a problem. If I’m about to spend $30M developing an enterprise-wide SOA, I’m going to want to see a return sooner rather than later. It’s not just the amount of money, it’s the politics. IT doesn’t control its own budget anymore. Not since the dot-com bust. Something as strategic as Big SOA now requires business buy-in and business approval. When it comes time to approve the Big Budget that goes along with Big SOA, business will want to know how soon and how much ROI to expect. If IT can’t answer, then the business won’t fund.

Hence the demise of Big SOA in 2008.

So let’s move on to the next question. What does this have to do with business mashups? Business mashups need services. They need widgets. They need workflow. Mashups behind the firewall need SOA to get access to the myriad enterprise data currently locked in siloed applications. Mashups outside the firewall need WOA to pull data and display elements from the web at large. For business mashers to take on the task of drawing down the application development backlog, SOA is a necessary backdrop. So if Big SOA is doomed, and I completely agree with Hinchcliffe and Chappell that it is, what’s going to take its place?

Smaller, directed SOA initiatives, called Guerrilla SOA by ThoughtWorks practice lead Jim Webber, have a much better chance of succeeding. Rather than taking an enterprise-wide approach, Guerrilla SOA initiatives are funded by specific projects. Because they are part of a larger project, they don't have the visibility, nor the political liabilities that come with big ticket IT infrastructure projects. Also because they are funded by specific projects, it isn’t necessary to calculate the ROI for the SOA work itself. If the project is a success, that’s enough.

2005 was supposed to be the year of SOA and wasn’t. Then 2006 was supposed to be the year of SOA and wasn’t. Then 2007 was supposed to be the year of SOA and wasn’t. If we toss out Big SOA and go with guerrilla SOA, 2008 actually has the chance to be the year of SOA, only nobody will know it. The ROI won’t come from the SOA initiative itself, but rather from IT finally getting to those pesky integrations, and from subject matter experts in the business building mashups.

The demise of Big SOA may be just what’s needed to get SOA off the drawing board and into production. And that’s what mashers need to start cranking out those mashups.

Next post: Mashup governance. Will IT help or will IT hinder?

Mashup vendors need to work with our frenemies or the bell will be tolling for us

I’ve had a nice long break over the holidays but now it’s time to roll up my sleeves, gird my loins and otherwise prepare to get back to work. And what better subject to start off the new year than turning enemies into friends, working with foes or partnering with competitors?

Gwyneth Dwyer has posted on this very subject. Back in the 90s we called it co-opetition. The new terms are frenemies and froes, meaning working with your competition, either on a deal-by-deal basis, or more likely, on a strategic basis as partners.

I’m sure the idea has been around since The First Floridians Met the Last Mastodons, but in the Web 1.0 dot-com era it surfaced again. The web was opening up everyone's horizons. It used to be hard for customers to find niche products, and for niche vendors to find customers. The web changed all that. With the web, little guys could not only innovate on a dime, they could get the attention of customers without going through an analyst firm. These same little guys didn’t have the pull to say ‘my way or the highway.' Back when TeamShare was a small vendor selling bug tracking software, customers used to insist we work with Rational, so of course we did. One day we'd work with them to promote our ClearCase integration, the next we'd be in fierce competition against ClearQuest.

Dwyer's post on the subject takes a collaboration spin. If you end up working with a competitor, and you likely will, be sure to set expectations, define boundaries, leave turf battles at the door, and finally, communicate, communicate, communicate. Sound advice for partner collaborations of all sorts, frenemies or no.

So what does this have to do with business mashups? I'm always asking that question. Sometimes the answer is obvious, sometimes obscure. In this case it's pretty straightforward. Co-opetition is at the very heart of mashups, whether the mashup vendors want it that way or not. Mashers don't care that some of their data comes from JackBe, some from StrikeIron hosted services, some from back-end SAP systems, all displayed on a GoogleMap and pulled together with process from Serena. Mashers care that they have accurate and timely data, widgets, and process from wherever they can get them.

Imagine trying to convince a masher that they could only use technology and content from a single vendor.

Oracle: I’m sorry, Mr. Masher, but you have to use the Oracle stack, Oracle applications and Oracle services to create your mashups.

Masher: Bite me.

Marketplaces and content aggregators like StrikeIron will have the upper-hand when it comes time for mashers to search for content. Kapow's open services will draw those same mashers. Will Kapow and StrikeIron work together or will they compete? The answer is ‘Yes.’

In a mashup world we are all connected. I’m reminded of a meditation about the island and the bell by John Donne. (Sure I’m taking it out of context, but I’m a masher as well as a blogger.) “No man is an island, entire of itself; every man is a piece of the continent, a part of the main.”

We in the mashup ISV world have to change to that mindset. We not only need to make our services open and usable by mashers, but we need to work together, defining standards to make it easy to mash content. It's not enough for us to publish our APIs. As I've discussed in a previous post, we need to work with other vendors on security standards, quality metrics and semantic vocabularies so mashers can pull content from pages painlessly. If we don’t do it, somebody else will, and we will wake up some day to find that we know exactly for whom the bell is tolling.

So JackBe, ready to let me review your software yet?