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.

I'm assuming most people who read this blog don't live with their parents. Meaning, you've purchased or rented a home/apartment/boat or something. When you shop for one of those, there are "hard" factors - # of bedrooms/bathrooms, size/shape of the layout, amenities, and so on. There are also "softer" characteristics.

Something along the lines of the "feel" of the place, or the neighborhood. If asked, maybe you could mention some hard factors that impact the feel - the lobby was dingy, or the doorman didn't make eye-contact. But, it's more than that. Imagine a fresh coat of paint in the lobby and a doorman with a smile. There'd still be something.

It's the way we take in information.

By the way, it's the same thing with dating. Ever meet that person who was "great on paper" but, still, you just didn't feel it?

This is the unnoticed problem with consumerization of IT. Because, just like the building manager who could clean up the lobby and tell his employees to smile, he'd still have a building with a bad feel.

In my opinion, that feel is the result of an aggregate of issues that individually are small, but add up to more than that collection of the issues themselves.

Some companies are starting, as a result of their falling behind consumers, to have a bad feel about them. Especially from the perspective of their target consumers/employees.

Companies are falling behind the consumerization curve, and it's not good.

IDC just published a study on the topic of consumerization. They make 3 key points:

1. Consumerization is driven by users

2. IT is not, for the most part, embracing the trend

3. Consumerization is accelerating

On the surface, they're talking about using iPhones, iPads, and Android devices. Consumers have access to these devices, and many companies don't. I worked at a bank for a short time, and we didn't even have laptops! Honest to god, I couldn't figure out how to change my personal work-flow to be in one place with my computer to get my job done. I need to communicate with people, and that means going to them... and my computer is a tool to communicate. It's inseparable.

However, consumerization is more than about some flashy devices, or the convenience of carrying one device instead of two. That's like saying you buy/rent the biggest apartment, or the one with the most bedrooms. You don't. You pick your new home because it's the one that meets your requirements and feels best.

Every marketing person knows this. I recently bought an engagement ring (yes, congratulations) and there were tons of gorgeous rings in my price range. We bought the one where buying it was a great experience.

What am I getting at? Here it is...

Consumerization is about the feel of a company's infrastructure. Technology should be invisible. It's woven into our lives these days, and companies who look like they've not left the 80's are going to look just as silly as someone walking around with a mullet today.

The trend to rapidly develop good-enough solutions using internet-accessible API's has set the baseline. Most people don't realize they're "good enough". So, for example, when you have to sign in 10 times within your company's firewall to access all your applications... people are going to ask, why not just use Facebook, or Google, or Twitter. They've all solved the problem for their communities?

Companies infrastructure are not only missing key features... they feel like they're stuck in the 80's. And, that's bad for companies trying to win the best projects or attract the best people.

Would you do business with a guy in a mullet?

Would you date a guy (or girl?) with a mullet?

Would you go work for a guy with a mullet?

Maybe, if their "stuff" were so compelling. But, you know it's extremely competitive out there today - on every front. It's competitive to hire the best employees, to win the best projects, and to stand out from the mess of options we're all bombarded with daily.

Knowing this, why are you showing up in a mullet?

Companies need to figure out how to use API's, while incorporating as much of their enterprise class requirements (that most users don't understand) as they go. They've got to figure out how to minimize risks, and recognize they won't ever eliminate them. Then, they need to work with employees to meet them part-way. Deliver some of what they're asking for, and at the same time educate people about the risks and limits companies face that are different than "internet API startups". You'll find the dialog will benefit you and your company in more ways than you could imagine.

Yeah. Bet that title got your attention.

I'll be gone for the next 10 days and didn't want you to forget me.

My soapbox about complex integration being ported from the enterprise to the cloud being a huge opportunity for the right solution had me thinking.

I wonder if a lot of the people developing "apps" using APIs even realize what governance is, and why it's critical. At a super high level, governance is the ability to articulate what to expect from an API, the formalization of that expectation into an SLA (service level agreement), and the careful monitoring of the actual API to make sure it continues to meet the SLA as defined.

Of course, one API may have many SLAs based on usage, and all that.

So, where does online dating come in as a benchmark?

I had this idea for turning Facebook into an online dating site to solve a huge problem with online dating. Let's think about the problem with the traditional online dating model.

A person goes online and tells some random website a whole bunch of personal details. Without any confirmation or reference at all, their profile is then published for other people to view. People seem surprised at all the exaggerations that are exhibited in personal profiles.

Like money, dating is something people don't seem to have such realistic views of when it comes to their situations. Makes sense too... if I met you for real, I wouldn't start the conversation by saying "Hi, I'm a compulsive neurotic who will make your life miserable." I'd more likely say something like "I'm great at my job because of my attention to detail" if I even let it come up at all in conversation.

While that's sorta funny... there are other more discrete ways to define people that aren't so "fuzzy". Like, "I'm not married" or "sure, this picture was just taken last month".

Married. Current photo. These are bits of meta data about the person that could be easily confirmed, though we're all concerned about big brother and (US) law doesn't make it easy for companies to be so intrusive in our life.

We're so embarrassed by online dating, that we keep it separate and only let other daters see dating profiles. So, we can exaggerate because our "regular" (non-datable) friends won't see what we're saying or hold us accountable.

From a technical perspective, the same analogy means that sometimes the technical infrastructure isn't there to constantly prove that what I'm saying about my API is true - even if it's a discrete measure. Like uptime. Or, expected performance.

And, that's where Facebook, or rather the community comes into play.

Imagine building a dating site layered on top of Facebook.

All of a sudden, when I say I'm 6'1" and my mother says "in heels" (that's funny because I'm a boy) someone looking at me as a prospective date will know my real height. If I say I'm not married, I'd have a hard time when I got home that day from work. And, if I thought I could create another profile, I'd need to figure out a way to get a reasonable # of friends so I look like a real person, with all the interactions on my facebook page that entails.

The community could hold people accountable.

Back to APIs.

However, if you'd like better governance of API providers, a way to let the community hold companies to a higher ethical standard of how they present their services, wouldn't it be better if the community had a place to share their experiences of the real level/quality of service provided by an API vendor so you could choose the right API for your situation? This community should be in the open, available for prospective customers, but validated by existing ones. Then, we'd have something that more reflects reality and everyone would prosper as a result.