I wonder whether it's not even 'the API approach', but 'the PUBLIC, SIMPLE API approach' that needs to be communicated. For example, some museums may have implemented OAI-PMH or Z39.whatever or some other 'API' technology and believe that they are 'on board', but will not find any benefit from these (apart from participating in the single project that they've no-doubt implemented the protocol for in the first place). We need to be proposing that they don't just expose an API, but that it is well documented and marketed (easily accessible/available), and that it follows a simple protocol (preferably REST, preferably RSS, ATOM or some standard XML format)??? Or maybe I'm talking out of my arse again!

DZ - I think you're probably right in that this is a process of education and - dare I say it - "marketing" of a *simple* approach. I don't know enough about stuff like OAI or Z39.* to comment on the detail, but that in itself might be an indicator that these approaches are too heavy (or do a different thing) to what we're trying to get across.

Having said that I don't think the final document should be technical, I guess it'll be difficult to NOT mention these kinds of standards at all. Personally, I'd actually like to see a museum-wide endorsement of REST, for example. I guess we'll tease out the detail as we go...

Mike - I'm not sure that this is identiying a 'problem' as such. If it is then it isn't clear.

Are we trying to solve -

a) the problem of expensive development costs in an environment of shrinking budgets? (APIs make dev quicker, cheaper, more flexible as demonstrated by Fiona's PDF)

b) the problem of changing user behaviour on our websites? (is this a 'problem'? is it 'real"? where is the proof?)

c) the problem of technical staff in museums not being able to develop projects that keep pace with the rest of the web industry because the museum sector doesn't want to keep up? (heh heh)

d) something else?

The other issue with APis is that they do really require an internal development team at the host museum - API development is hard to outsource.

Seb - I agree, slight rant and tangent on this page :-) - I was kind of hoping that the last sentence would bring it back on track.

Let me try and articulate what I see as the problem: "we" (you know who I mean) know that this is a very powerful way of working for all manner of reasons (pretty well articulated by your a-c). We also know that it is unusual for the museum sector to work in this way and that additional effort and investment up-front can pay huge dividends further down the line.

The question therefore is about finding a way of communicating this which has a business case for this investment set in such a solid surround of use cases / case studies / metrics that it can't be denied. That's what I see as the challenge. What do you think?

yeah i think that is a good approach but . . . again i want you (and the rest of us) to start articulating these' huge dividends'.

at my museum we charge admission. it is our business model, other than government funding. it isn't likely to change. our metrics are based around that too.

sorry to harp, but tell me (because this is important) how APIs are going to help grow that business model . . . or deliver on mission better.

i think once we can start answering those sort of questions then we are in business . . . because they are the questions execs and funders will ask.

here's the start of an answer . . . .

"The ROI of APIs"

- reduce expenditure of development (measured by staff/budget cuts in web or interactive dev team)
- reduce time to deliver (measured by time to live of new applications)

ok now your turn . . . .

"The ROI of APIs"

I'd like to generalise a little and speak about how exposing more of a museum collection on the Web will generate more physical visitors in much the way that advertising does. knowing that you can see something somewhere is a reason to visit. I often feel there's a guarded protectionism towards a museum's collection, that may lie at the heart of some of the reluctance to share.

It's just an impression, and one gained as a software developer, working with museums, rather than as a museum employee, so I may be wrong.

So my gut feel is that the easier it is to share the collection and the wider it can be shared, the more return in the form of physical visits will be gained.

Tony - I'd totally agree, in fact we have evidence of that at the Powerhouse.

I guess there are many ways of exposing ones collection and selling the idea of doing it in more traditional ways is much easier than the API approach - an API that neglects to address issues of branding is like a revolution that doesn't address who will deal with the sewerage and rubbish (taking liberties there with my quotes and metaphors!)

Seb, yes, I think that's a lot of the point of this very discussion! Getting to grips with what the ROI is (and actually what the REAL "I" is in ROI) is crucial. We need to evaluate it and be ready to articulate it to stakeholders. That's the discussion we're having here and I hope that we can tease out some real facts.

Adding to your answer:

- reduce costs and time for future development and integration
- increased exposure to online content (=increased physical visits/sales? = better for DCMS/funders? - but also need to work on metrics!!)
- increases cross-sector (and beyond) working by reducing costs and complexity

Overall, I still want to nail a couple of studies into how "opening up" can increase (or even decrease!) both physical visits and/or sales - see my thread here http://tinyurl.com/4ydoxu ...

re: internal teams required for APIs - I think the sector could also put pressure on Collection Management System vendors to provide APIs. They wouldn't be tailored for the specific information environment of every museum, but offering a point of integration is a good start.

The vendors here are all offering (or planning to offer) some kind of OAI thing now, as a result of movement in the sector. Realistically, we'll never get decent IT teams in every museum. Is some kind of service model possible?

We could look at models like the document management system that's offered across New Zealand. It was mentioned at MW2008, I'll have to try and remember the details.

I want to point in a slightly different direction. As Mia says, with more vendors hopefully adding some sort of API to their CollDB wares, perhaps we'll see an increase in their use, but I think that there'll still be a lot of museums that cannot capitalise on this for one reason or another. Perhaps they can't or won't open their server up to the web because they don't think it can handle it, or they have bandwidth issues. Perhaps they don't plan to upgrade their software for a while (and I could quite understand that). Whatever, I think there'll be plenty of smaller institutions that still have nothing online at all, never mind an API.
Which is why I reckon that there's an angle to be had in arguing for an intermediary body that can gather collections data from small, technically-challenged institutions (so I'm excluding yours, Seb) and publish it via an API, thereby making it available back to the originating institution, so that they can get online when they probably could not before. This body could be (in the UK) the Collections Trust, or EDL at a European level. Hell, it might already be CHIN in Canada for all I know. So the thrust of this argument is that through someone else's API, museums get online. I'm hoping this cuts some ice with EDL (it seems to) as a selling tool to encourage participation by content owners and hence part of the business case for the API.
(out of space now)

(part 2)
Obviously what we also know is that an API onto a repository of data like that has other benefits.
I've been wondering about architecture, and what the differences and similarities are between technical architecture and one of process. It's because of that recent discussion about digitisation and whether funders should require that it always yields them a nice public-facing output at the end of the project. There is arguably an architecture of process that goes something like:digitisation->develop the data access layer->create interpretative/mediating content->design and build UI.Naturally (inevitably, given that a techy is writing this) it's got a lot in common with a half-decent technical architecture that separates conceptually and programmatically three or more layers from content/data and data access, through business logic, to user interface (and each of these layers having their own internal structure). So if these architectures are similar, but we don't want to talk techy to the board, perhaps we can work on adapting the language of the process to make the same argument?
Seb, I'd take issue with one thing you said. Yes, the business model of Powerhouse may be based on admission fees, but I suspect that that is not its mission. I would hope that you could still make a case to the board there that was based on delivery against strategic aims, not all of which will be revenue raising (please say it's true!). Of course getting cash is part of the equation, but there are other good arguments they'll understand. That's the R part of ROI (Mike did I, who's taking O?) - the return might be cash, it might be some sort of public good if you like that term - anyway, doing something that helps your audiences or the enhancement and preservation of your collections.
Finally, let's not limit ourselves to collections, though they're the most obvious and tastiest target.

Jeremy

The 'intermediary' is exactly what we're doing with CAN in Australia.

You might also want to take a look at this lovely wroking wireframe of the National Library of Australia's new mega-meta-beta search . . . . it will have full feeds and API connections of EVERY permutation of data. (Want just the related subjects to a book title search? done. Want just the picture metadata for images related to the subject of a book about a person? done.)

http://ll01.nla.gov.au/search.jsp?searchTerm=harry+potter

Let it load . . . it gets better as more loads.

Obviously they have it easy because they are dealing with books . . . . oh, no, wait . . . look . . . . they do images and music too . . . . and newspapers . . . . . oh NOW i see . . .

That NLA engine looks very cool, Seb.

I need to read up on what you've been up to with CAN, but that sounds good to me. If you're bringing in content from small museums and handing it back to them with an API having done all the work of building the functionality for them, then that's exactly what I mean and we should use it as an exemplar of how the production and consumption of APIs is good for all sides.

I'm coming in to this a bit late, but I just want to add a note of slight caution: is ROI really everything? ROI seems to be a pseudo-measurement framework to decide whether something is worth doing or not. 'Pseudo' because a lot of things just aren't measureable. And return for who? The organisation? The team who developed something? Society generally?

If you are able to use ROI to persuade funders to let you do things, then all well and good. But I'm not sure how much weight should really be hung upon it (especially when you start quoting cost:benefit ratios).

Call me idealistic, but I think it's also worth evangelising about doing the Right Thing simply because it's the Right Thing...

Frankie

If you want to get your organisation to allocate some budget and resources to your Right Thing project beyond a prototyping stage then you are almost certainly going to need to identify an ROI.

The application of corporate business and management practices to the museum sector (and public sector) is highly debatable but it is the reality right now. I'm all for arguing that this shouldn't be the case but given that it is how executives decide what is going to get the thumbs up and what gets put on the backburner or axed, it would be really helpful if some thought can be given to what the actual tangible benefits, savings, competitive advantage etc of APIs are . . . . (I think Fiona's done a pretty great job of starting this off in her internal presentation slides - again which shows how projects do need to be 'sold' to executives)

Given I linked the National Library of Australia (NLA)'s beta search - here's their strategy documents which explain WHY they are doing all this interconnectivity work (libraries, as you know, are under much greater immediate pressure than museums) - http://www.nla.gov.au/policy/itplan.html

I'm not sure if you two disagree really. The Right Thing is another way of saying that there is a return, but it's not necessarily a (purely) financial one. "Competitive advantage" is a business-like way of saying something similar, perhaps - about how we make our institutions distinct in their pursuit of their mission. Jim Collins has a lot to say about this sort of thing.

Corporate culture in our museum, at least, and I hope in others is not purely tuned to finance but to its mission (which says nothing about money), and in support of that, the strategic aims and business objectives (which of course do have something to say about money). We can make a case on the basis that our work supports any of a range of strategic aims, which might be those that address the mission directly OR those aimed at providing the support vital to the latter, in terms of finance or other resources. They are complementary and either is pointless without the other.

ROI means something that speaks directly to the mission, or something that supports us doing other stuff that speaks directly to the mission. Financial return fits into the latter group, but it's still essential. OTOH it's not the end, it's the means.

To return to what Dan and Seb said right at the top, I think we do need to tighten up or split out what we think the problem is - or what problems we think can be easily seen as such by the people we need to convince. All the aspects I can think of are closely linked (and mentioned already), but I think they still need identifying.

So Dan pointed to public APIs, which is one broad area we must of course address. The reasons they appeal to us are probably (hopefully) not too hard to pitch to our overlords, at least in principle - demonstrating that the benefits should be large enough to merit the investment may be tricky, though. They come down to interoperability with other institutions, and opening access to the public. Soon (well now, in some limited senses) we can also point to SEO and the semantic web.

Then there is the case for "private" APIs: arguments about good architecture, extensibility, and readiness for collaboration. Here perhaps there'll be more to do in order to explain how the investments payoff. This area is more about resource allocation, good management and good development practice.

There is the case for using the APIs of others, which may be a weak argument or no argument at all, but perhaps in arguing that we should be building layered architectures glued with APIs we can also argue that we'll end up better prepared to hook into other APIs. Hmm. Pretty lame.

Finally there's the bit about sector-wide change and standards, and possibly shared architecture, which means a bunch of different arguments. There's tons of overlap with the public and internal API arguments and they should reinforce the case for each other.

OK, so having come to this thread a little late, I'm going to try to summarise the aims that have been stated so far:

- Use available web services, e.g. Google Maps and Flickr, to reduce cost/time/risk of development and communicate the benefits of doing so (I think this is a good and achievable first plank of our argument)

- Share best practice examples/ documentation/ code more effectively within the sector to reduce cost/time/risk of development (good and achievable but probably doesn't require wider buy-in)

- Advocate/ educate the sector in good software architecture, i.e. private APIs etc (again, good and achievable but probably doesn't require wider buy-in)

- Make internal museum APIs/ feeds/ etc public to meet audience need/ reach a wider audience (this does require wider buy-in but is quite difficult to demonstrate)

- Make internal museum APIs/ feeds/ etc public to encourage other people to develop sites and services using our collections - and non-collections - data (this is somewhat within our control but would benefit from wider buy-in so is probably worth collaborating on - the second plank of our argument?)

- Support a third-party, possibly the IAP or EDL, to develop a collections API on behalf of the sector (this is largely out of our control but something we could possibly lead by example, so would make a good third plank of our argument?)