What makes a mashup service right for you?

Everyday life is full of decisions. From the time you wake up in the morning to the time you go to bed, you spend most of your time (whether you realize or not) making decisions. It starts from the moment you wake up. What should I wear today? Do I have time for breakfast? Do I think it's going to rain today and do I need my umbrella? And the list goes on...

While on my drive to work (where I made 14 decisions not to honk my horn), I started thinking about how decisions are made. I realized most decisions are made by process of elimination. We eliminate choices we don't need or want and then we rank the remaining possiblities. We also do this for the questions themselves, avoiding choices all together that are irrelevant to our needs.

Over the past few months I have had the chance to watch the choices made by my customers.With mashups comes choices and plenty of them so how do my customers decide what services are best for their mashup?What kind/level of security do they need? Who will they share their efforts with? And in what format/media?

I thought you could benefit from the decisions that others have considered/made when building mashups. Think about just the SOURCES of data that go into a mashup. There is a very wide variety of choices to be made. (A quick disclaimer, some of these attributes are kinda technical. But that's the beauty of the decisions you make when embracing enterprise mashups. It's about what matters to you and your organization.)

Format of the data sources: Web 2.0 (HTML, RSS, ATOM), SOA (REST, SOAP), RDBMS (SQL), mainframe, document (PDF, spreadsheet), other. 

Security required to access the data source: None, simple userid/password, LDAP integration required, SSL required, certificate required.

Availability of the data sources: 7x24x365, 7x12, 5x8, whenever the owner wants to turn the system on, sporadic, unpredictable. 

'Age' of the source data: I can access the data immediately in the system that created it, there's a minor lag from the point of origin to my data source, there is a significant delay from the point of origin to my data source.

Location of the data sources: Inside the organization (my organization), inside the organization (another department), outside the organization. 

Cost of the data sources: Free, licensed, paid for by my organization.

Request frequency allowed of the data sources: Unlimited requests for data, a set # of requests per time period, I get to make a copy and then I have to leave the original data alone.

General Type of Information of the data sources: ERP, SFA, SCM, MA, BI, Custom.

As an aside, I'd be remiss if I didn't remind everyone that a good mashup platform hides all these attributes. The goal is to make all these data sources look the same no matter what they consist of. The mashup administrator cares a great deal about these things but your average masher remains oblivious. Which means the average masher has to make one less decision, with the focus on what to do with these services now that they are ready to mash.  

Applying these general categories to some of my favorite mashups, the work JackBe is doing with DISA (Defense Information Systems Agency) is a 'real-time, highly-secure, highly-available' mashup.  In contrast, our work at one major book publisher is more of a 'free, web 2.0, low-security, low bandwidth' mashup. And yet both are important solutions to each respective organization.

Both organization's employees benefit from a faster, more effective way to make decisions. Isn't that what we all looking for?