Integration has become very easy. API's and standards like REST (ok, not exactly a standard) and SOAP mean that anyone with an IDE can integrate. It's even become cool to use API's, and that scares me.

Why fear? Well, I've been doing "integration" for a long time. It's hard. Or, rather, it's hard to do well.

It's not about the connection, which is now easy. It's about the best practices that we've developed over years to prevent problems down the road.

I wanted to share one of the immediate benefits of LinkSpan for people who might not have the enterprise experience that I have, or for people new to coding who might not yet realize how things can go wrong.

Ever since pagers came about, IT Administrators and Application Developers have been scripting alerts to let them know how their computers, infrastructure, and apps are doing. From pagers, to text pagers, to SMS, to mobile email… sys admins and developers grep log files and pass critical status messages to them so they can stay ahead of problems.

Stay ahead of problems.

Developers usually know when things are about to go off the rails. They simply script some of that knowledge, and use it to alert them so they can fix problems while they can still be resolved without too much bad happening.

Their knowledge, in "service or API terms" can be thought of as "the contract". The contract the developer has with the API they're using. In many cases, the contract is implied, so it's not something you might see articulated anywhere but API documentation. Specifically, how to use an API and what sorts of messages/formats/responses to expect.

The important thing about the contract is that it ends up being specific to the way you're using the interface (in some regard). The API may be up, but your expected results may not be happening in the way you expect (for a variety of reasons). Developers know that up/down isn't what matters (most app/system management tools and teams have that covered very well), and that it's usually a degradation of service that impacts things worst. Even worse, degradation of service is the problem that's most difficult to resolve.

LinkSpan provides an "everyman's scripting engine" for ensuring the contract you expect is the contract you're getting.

Simply connect to the API you're using (or import your custom API), pick the methods you're interface is supporting, then paste in the data format you're app expects. This is all much easier than it sounds, and LinkSpan gives you a simple wizard to walk your through the steps. That test can then be used to raise an alert, or to generate insightful dashboards and reports you can use to track trends and plan future projects.

Now, developers can go about their business, knowing that Facebook, Twitter, or whatever API your app depends on is working according the contract you expect. And, when things start to go sideways, you're the first to know and can take the mitigating actions necessary to prevent the API's "failure" from impacting your users.

Peace of mind. Easy.

Why not try LinkSpan free for 15 days?

Irregardless of the how much SaaS a company uses, they're still going to have internal systems. To improve integration across internal systems companies will create internal API's. They're already doing so. And, it's becoming cool to do so even more so I think we'll see some acceleration in this space.

Internal API's need to be managed just like external API's. In fact, a good API management solution will integrate on-premise and off-premise API management tools enabling developers to manage API's seamlessly no matter where the API sits.

Mashery has an interesting article about API management that unfortunately tells just half the story. A solution that only lets developers manage external services is incomplete. Internal API's are more likely to be SOAP based than REST based (my own opinion, not a research driven observation). These internal API's will need different management tools/features, but the experience of managing internal and external API's will need to be consistent (and consistently easy to use).

A SaaS API management tool is not going to be allowed access through a company's DMZ to manage internal API's. I'm pretty liberal on security implications of enterprise SaaS deployments, but even I can't see any way something like this is ever going to happen. To properly manage an internal API from a hosted API management tool will require storing your internal API contract on the external host. Way too risky.

You might want to start by managing external API's first to ensure that you're managing the service you're getting from an external provider. But keep the endgame in mind. I believe that over time your internal infrastructure will look a lot like these external ones (if they don't already). You will want to manage contracts between teams the same way you want to manage contracts to your external providers. Doing so will foster an internet-style collaboration model between internal teams, leading to more creativity in how internal systems (and their data) are used by employees (an important and desirable result).

Be careful that you don't find yourself in a situation where you invest in a tool that provides no possible path towards a unified API management experience between external and internal API's. You'll regret it. And, by the time you do, it'll be too late.

Nuance is a company that's been around for quite some time.

I find it interesting that a change to their API can impact their strategy greatly, yet it appears that will be the case.

In fact, their API strategy is complementing their overall operational execution strategy at the highest levels as Apple appear ready to announce deep Nuance voice integration with the next generation of iPhone.

As with most other activities lately, things are being done faster with fewer people. What better way to understand how your API is being used, so that you can adapt quickly to market signals than to use a tool like theRightAPI for collaboration with your developer community and insight into their activity?

It's crunch time here at OpusGrid. All very exciting (and busy).

So, yesterday Google launched the first Google+ API's. It'll be very interesting to see how it goes. I think there was a bit of a hockey stick adoption to Google+. It seemed to launch great, then adoption seemed to fall off.

I wonder if this was because we were limited to the features and capabilities that Google launched with the first release. Now, with the release of the API we'll see some innovation by outsiders using Google Plus as a platform. This is where the rubber meets the road, and now we'll see if Google+ stands a chance.

I'm interested in seeing if I'm correct, because if I am, it seems that it's no longer OK to launch a product like this without an API. That's some change to proprietary software models which in many ways stifle innovation.

New to Google+? Why not add me to a circle, and let's figure it out together.

Last week I saw an introduction to BuddyPress 1.5. BuddyPress is a WordPress plugin for creating a social community. Like WordPress it's really more of a platform, on which others can add value with plug-ins of their own.

BuddyPress hasn't had a good update in a  while, and the 1.5 release is quite an important one as it turns out.

What I found really interesting was that a large focus of this release is making it a "good community member". Meaning, it integrates much more cleanly with WordPress than in the past. It behaves just like other plugins now - in the past, being a close part of WordPress the developers had taken some short cuts… short cuts that made it harder for other developers to work with.

Why is it so important for BuddyPress to be developer friendly?

Because in today's "game" your value is only partly what you provide out of the box. It's also important for others to be able to innovate on your platform.

While BuddyPress behaved badly, developers were reluctant to innovate because it made their lives more difficult. In particular, BuddyPress used to throw all these unnecessary error/debug messages, so when developers had to debug their own code it was a nightmare. Similarly, developers had little confidence in the quality of BuddyPress itself when their experience developing to it was so difficult.

TheRightAPI is a solution to help developers make sure that their API's are supportive of the community of innovators around them. It's a language for setting and delivering on expectations, so that developers on both sides of the API know exactly how things should work, how they are working, and what's needed in the future.

By the way, if your API is not listed on theRightAPI, let us know please.

Last week I saw an introduction to BuddyPress 1.5. BuddyPress is a WordPress plugin for creating a social community. Like WordPress it's really more of a platform, on which others can add value with plug-ins of their own.

BuddyPress hasn't had a good update in a  while, and the 1.5 release is quite an important one as it turns out.

What I found really interesting was that a large focus of this release is making it a "good community member". Meaning, it integrates much more cleanly with WordPress than in the past. It behaves just like other plugins now - in the past, being a close part of WordPress the developers had taken some short cuts… short cuts that made it harder for other developers to work with.

Why is it so important for BuddyPress to be developer friendly?

Because in today's "game" your value is only partly what you provide out of the box. It's also important for others to be able to innovate on your platform.

While BuddyPress behaved badly, developers were reluctant to innovate because it made their lives more difficult. In particular, BuddyPress used to throw all these unnecessary error/debug messages, so when developers had to debug their own code it was a nightmare. Similarly, developers had little confidence in the quality of BuddyPress itself when their experience developing to it was so difficult.

TheRightAPI is a solution to help developers make sure that their API's are supportive of the community of innovators around them. It's a language for setting and delivering on expectations, so that developers on both sides of the API know exactly how things should work, how they are working, and what's needed in the future.

Can you hear "it"? "It"'s a beautiful thing.

What's "it" you're wondering?

Why, it is innovation.

I ran across a social experiment this week. In it, Jonathan has shared his Starbucks card. No kidding. You can download a picture of it, and buy yourself a coffee if there's money on it. If you're feeling generous, you can put money on it. He shares instructions on how to do both.

The interesting part… he's created an API for this experiment.

I can't help but wonder if the API will help him understand the parameters of his experiment. With the API others can innovate on his idea, perhaps spark something that he didn't think of. These sparks might help him fine-tune his project to make it even more useful. They might even spark a whole community of activity around his concept.

Can you do this in your enterprise? Can you release a set of services, whoops - there I went and confused API with services again. Silly me. Can you release an API that let's your community extend your idea as a way of listening to what the community wants?

NYC held it's first hackathon last week and I can't help but wonder if this is a model enterprises should copy.

Rachel Sterne, the city's first digital officer talks about making nyc.gov (NYC's main citizen portal) transparent, open, and participatory.

Aren't these goals admirable? Aren't they something enterprises should want to adopt for their employees, and possibly their customers?

There's tons of data hanging around within companies that would help people do their jobs better. Only, it's usually locked up quite tightly. One needs permission, and a "business justification". Often there is a domain guardian protecting their fiefdom, represented by the information the guardian controls.

When I think about city government, I think about people who control rather than collaborate. I think about an organization that is complex seemingly for the sake of being complex. And, I think about tons of information that would make people's lives easier, if only it were available.

I also think about having very little money to spend on little things.

I see a hackathon as a way to get other people to "do the work for you (for fun)", assume the risk of failure, and let you take credit for enabling those who are successful, even if only 1 in 10 is does something that sticks. It is also an opportunity for the government to get in front of a constituency, in a non-threatening venue, and partner with participants. A true opportunity to listen to citizens, with an equal give and take - NYC gives access to the data, the citizen makes something useful with it and contributes it back to the government for all citizens to share.

If NYC can do this, why can't the Fortune 1000?

I read an article yesterday (forgive me, I forget where) that said employees are the least engaged than they've been in decades. Google's pretty extreme in letting people spend 20% of their time on Google related projects outside of their job description. But, why can't companies let people spend 2 days a month? That's 2 hackathon's a month for people to innovate and connect at a whole new level, and companies to be the transparent and participatory environment that we all wish them to be.

Hah! No, it really doesn't.

What it does need are similar capabilities to help companies manage the complexity of integration, even when integrating using standards based service models and API's.

In a very interesting Information Week report on ERP, writer Doug Henschen makes some really interesting points that I believe is a "must read" for companies using API's as a core part of their application/IT strategy and vendors who sell to those companies.

In a section titled "the integration imperative" Doug shares a Starbucks use case. Many who look at that use case would think of it as a mobile application, or even an example of social technologies used for business. Underlying all of that are a few key things, without which such innovation would be impossible:

1. Be willing to deploy pretty good, not perfect, apps. Gen Y and Millenials are used to things mostly working, and getting them faster. As a solution provider, having a solid infrastructure and a good understanding of your data and API will let you be nimble and have short release cycles.

2. API's are a core feature requirements. This report states that 64% of respondents cited easy integration as the most important thing they look for in enterprise apps. That's a huge difference to the secondmost cited quality which came in at 38%. Implied in this, if you are a vendor, is that you deliver an API that people can use easily for complete use cases. Said in "MBA terms" - you need a "whole product offering" around the API. Not just a REST interface.

3. Develop a way to listen and respond to the user community. The report shares an example from Guess, but I'm going to share a personal one. I was once in a Kinko's getting business cards printed, and the guy helping me was clearly having a hard time with his software. Within a few minutes, I was behind the counter, pointing and clicking with him, asking him how IT decided what the software should do, how it was deployed, what's wrong with it, etc. The people that use this stuff actually know something. Now, you don't want to just deliver "faster horses" but you do want to interpret their insights and add value based on your deeper technical understanding of the possibilities. (PS That's a reference to Henry Ford who said something like "had he listened to cusotmers, he wouldn't have created the car but built faster horses.)

It goes without saying that OpusGrid can help with the three key requirements above. Whether you are a small company looking ot use other API's, a cusotmer using services inside your internal integration infrastructure (dare I call that a "private cloud"?), or a vendor trying to make sure you're deliver a whole product around your API's.

Why not check out The Right API, or drop us a line?

With the API craze that started sometime in the last 24 months, it might be easy to forget that API's are not new. Nor are the things we do with them.

There's been a lot of discussion about understanding your API. What's your business model? Who are your users? I know there are some grey hairs (and some blond-highlights) wondering what the commotion is about.

It's all about integration.

And, when it comes to integration you need an API.

I remember building networks that needed multiple network cards. You know, one for each network protocol (remember Novell Netware or Banyan Vines?). Back then, there was plenty of time to figure out the "application integration stuff" because what was happening at lower layers of the OSI model gave developers the time to react.

Then along came Cisco and others, and they consolidated the network. Yeah, there was a time there was something called a BRouter - a router that also bridged traffic.

(Forgive me, I think the heat-induced lethargy is causing me to be a bit nostalgic... reminding me of when I was young enough that the heat didn't slow me down.)

Anwyays, networks were much harder to build. You actually had to know where your users were, keep them as local as possible to the servers and the apps they were using. VPN's crushed that complexity, adding some more of their own.

The good news was, with VPN's any user could be on any network, but access their apps as if they were local. The bad news was that with VPN's any user could be on any network, but access their apps as if they were local.

It was easy to know - if a user called from the 5th floor, you'd go check out the 5th floor network. Now how are you supposed to know where that user is on your network. (Reminds me of the time a customer lost a server - they knew it was down because it stopped responding, but they couldn't find it. It took about 2-3 hours to find it. It was in a closet, which is also why it failed. There wasn't enough ventilation.)

Fast forward a bit more.

Now there are widespread standards all the way up the stack. Take a WSDL and within minutes someone without any knowledge of the target system at all, but with a reasonable development tool could be integrating systems.

Just like with the users in my VPN example... this creates some great opportunity only we've moved up the stack, so instead of talking about users, we're talking about data. Now, the good news (and the bad news) is that data can be anywhere.

What data? Well, any data. Let's say - customer data. Well, what makes up customer data?

Address. Phone number. You know, customer data.

What does it look like? How is it stored (in each an every system you're working with)?

I know what you're thinking... and let me tell you - Yeah, it does matter. And, it can be complicated.

Let me give you an example.

I upgraded to OS X Lion (for my Mac) this week. I went into iTunes, clicked "buy", and Apple asked me to validate my identity before allowing the purchase. It brought up a panel that asked for my credit card info, name, address, and phone number.

Simple, right?

I was on support for 15 minutes, frustrated, when I figured out the solution.

I logged into American Express, looked up my credit card information, and saw that on my American Express account, my apartment was listed simply as #37F, in a separate apartment field.

Now, I happen to know that the USPS standard for writing addresses is to put the apartment number on the first line, no comma separating. Something like '40 Harrison Street APT 37F'.

When I matched what I put into iTunes to what American Express showed on my account profile, bingo-bammo, it went right through.

Are you doing the integration dance? This isn't some leading-edge SMS-map-real-time-mobile-startup. This is Apple and American Express.

What's going on?

They use different data models. Neither particularly adhering to the Post Office's standard. Remember, it's not just Apple and American Express. It's Visa. Discover. And, so on. And, it's Spotify, Google, Amazon and every other service.

So what do you do? I mean, besides make your users hate you?

Manage your API properly. Deal with the trust, visibility AND data issues in a systemic way. API providers and consumers (both internal- and external-consumers) will have the ability to manage your data model, easily map that data model to the API's that make up your virtual integration infrastructure, and manage your user experience in a way consistent with your brand and user-experience goals.