Day four of Oracle's copyright and patent lawsuit against Google's Android OS brings a lesson in API design and programming that even the judge declares 'confusing.' http://bit.ly/IBHL9N

Ever tried to explain what an API is and does to a loved one, a friend or an investor?  Imagine having to explain what an API is to a jury!  What are your favorite examples of how to explain "What is an API"?

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.

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?

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.

It's absurd... and I'm shocked by such raw behavior.

Of course, maybe I'm old-fashioned? I've been feeling my age a bit lately, so it could be.

Maybe, I'm just too hard. I've seen a lot. Did you know that I once created a song for an IT department, so that they'd remember how IP multicast worked? Yeah, that was pre-internet. Well, truth-be-told, pre-internet-as-we-know-it.

And, that's the rub.

I know things. I've seen things... NO! Don't ask. I won't tell.

What I will say is, be careful.

When you look under the covers, stick your nose into places... you'll never look at a computer application the same way. Never speak to a customer service person without wondering. Never. Book. An. Airline. Ticket. Online. Without. Wondering.

Have they used a vendor's native API for integration without creating a layer of abstraction to prevent vendor lock-in?!?!

There, I said it.

Best practice numero uno. Number one. ABOVE ALL THINGS.

Don't code to a vendor's API because you're stuck with whatever they decide to do with it. You've got their methods, and methodologies (what I like to call "integration philosophy") baked right into your application. And, if you diverge from that vendor, philosophically or commercially, you're screwed.

This is extra important when you have people in your organization using external API's. Do you even know who they are? That's problem #1. Make sure to build in a gateway layer, or intermediary layer, whatever you want to call it. The important thing is to decouple your consumers from those API's so that you can operate independently from the vendor, their methodologies and their roadmap, and switch more easily between vendors should you need to.

Good luck, and code safely.

As the details of the Amazon outage last month come to light (kudos to them for being so forthcoming), we should all be reminded that the cloud is not an opportunity to shirk our responsibilities as architects and systems engineers.  The only computers or software that can even theoretically attain 100% uptime would be those that are completely isolated from any changes.  In other words, no people could modify them.  It would be foolish to think that moving to the cloud allows us to ignore that fact.  Amazon is simply the latest example demonstrating that people can do a good job of planning for computer errors, but computers are very poor at planning for people errors.  

[Aside:  If we could ever create a computer that overcomes this, we might just be in trouble.  While I think the Matrix went a bit too far, a computer that could correct all human errors starts to look a lot like Skynet.  I’m not convinced that its possible for us to build something that intelligent or impenetrable, but we do seem to be getting closer all the time.  Ok, back to the here and now led by us flawed humans…]

Anyone that moves to the cloud must recognize that human errors can bring computers and software down whether they are in the cloud or your own data center and plan accordingly.  To borrow a familiar saying, there are two types of clouds: Those that have had outages and those that will have them in the future.  As with any kind of high availability plan (or stock portfolio), your best chance at mitigating risk is to diversify.  Like any other environment, you must understand where the outages can occur in the cloud and build in your own safeguards.  In some cases this may mean leveraging multiple data centers across the same provider.  In other cases it may require you to leverage multiple providers.  This is something that we have been thinking about a lot at OpusGrid as we get closer to our first launch (stay tuned for an announcement next week )

While the cloud can provide a tremendous value proposition, it is still a system that can be brought to its knees by the right change under the right conditions.  As long as people are in control, that will continue to be the case so you better expect and plan for those scenarios if you can’t afford that margin of error.

Inspired by William's post last week about IT's resistance to cloud computing due to security concerns or SLA limitations, I'd like to share a corollary perspective.

The cloud's not going away. In fact, it's been there all along (if not called cloud).

But,  let's say that William is wrong, and there are some environments that will NEVER be appropriate for putting into the cloud.

The corollary (in loose terms) is that some environments are appropriate to the cloud.

Don't you want to capture those benefits today?

If you can reduce costs, provide "better" service, and/or deliver solutions more quickly... well you should!

Cloud offers these advantages (and more). Cloud enables companies to deploy solutions with less fixed cost outlays, and with fewer people on staff. In a perfect world, you'll have a service level agreement to manage your experience and security, and not have to worry about the implementation details of how that SLA is achieved.

Said differently, there is no strategic advantage to owning the infrastructure, the capacity, or the know-how for such low value services.

For example, I'm bewildered that most companies still own their own email infrastructure.

What company matches Gmail's for internal storage available for employees? That's one data point, but one is enough. Companies can't keep up with the critical mass and economies of scale that cloud providers deliver.

So, it's much more easier to assume that some infrastructure belongs in the cloud in order to capture the benefits of cloud providers' critical mass than to argue about whether cloud is appropriate for sensitive infrastructure.

If we agree that parts of your infrastructure have to transition to the cloud eventually, well... you're going to need to start. And, you want to start with something low-risk, so that you can build the skills and understand where the roadblocks/speed-bumps might be.

If you want to learn how to do it, and do it right. Why not drop us a line? We can help transition you to cloud, help you pick the right projects, and help create an environment for seamless integration between cloud services and internally firewalled ones whether you're sharing information internally, or with partners/providers across the internet.

Why is it urgent to start developing this expertise now? Because it takes time. And, the longer you wait, the longer your lead time. And, it's not trivial. Like anything new, there are things we need to learn. For example, how a script making one API call running every 5 minutes triggers an API call limit of 150 calls per hour.

What are you waiting for? Drop us a line.

Over the past few weeks, I have read a couple articles and had some conversations with customers about specific barriers to their cloud adoption.  The most common barriers referenced include security concerns, lack of trust, and weak or obscure service level agreements.  As we proceed through the cloud hype curve and start scrutinizing the value proposition of the cloud, I think each of these barriers are valid considerations, but I also think it is naïve to believe they are unique to the cloud.  In fact, it often seems that the loudest objections comes from those in glass houses.

After 13+ years of consulting experience with customers across the globe, I can honestly say that most organizations (yes, including yours) should take the same expectations they have for the cloud and take a hard look at their own infrastructure.  Mind you, I’m not saying that the cloud is bullet proof or perfect, but if I was given a choice of running my business application in an appropriate cloud environment or one of my customer’s environments, I would choose the cloud without hesitation.  Even IF the customer environment has some advantages today, those will be short lived and certainly more expensive to run and maintain going forward.

It seems the silver bullet for shooting down a move to the cloud today is PCI compliance.  If you are handling customer payments at all, this is a genuine concern that must be addressed and yes, there are many cloud environments that are not yet certified as PCI compliant.  However, PCI compliance is not a one-time validation event, but an ongoing process of ensuring that an organization is not only protecting information, but is also accounting for all activity related to that information.   This is a very expensive proposition for an organization that requires dedicated, knowledgeable staff and tools.  This also makes it one of the best tasks to leverage through a shared environment with a team of experts that can provide the appropriate expertise and continued support. 

As I look at the potential options available to OpusGrid as we start collecting customer payments and maintain PCI compliance, I am compelled to consider a cloud provider such as FireHost.  They host some of the most hacker-attractive sites in the world (picture a giant bug light!) and I would feel a lot more comfortable with their team ensuring compliance than I would a team that we could afford to hire.  I suspect many organizations feel the same way if they are honest about it.

What this points out is the true value proposition of the cloud – leveraging critical mass.  Most people think the critical mass comes from the sheer number of shared computer resources, but it also comes just as much from the shared number of specialized resources available through a provider.  FireHost specializes in high end security and compliance just as other providers specialize in specific types of apps, specific platforms, specific industries, and specific functions.  For 95+% of your applications, I am confident there is a cloud option available that could meet, and likely exceed, your requirements and do so at a lower cost. 

So not only is the cloud reducing costs, but it is raising the bar for IT which is long overdue.  As providers aggressively seek to address the barriers that most organizations cannot even overcome on their own, their value proposition will continue making the cloud a more compelling option.  I think the days of an organization maintaining best of breed IT infrastructure services internally are numbered.  The real truth is that most organizations that believe they are best of breed today probably aren’t and need to be very wary of throwing stones at the cloud. 

Boomi is the maker of Atomsphere, a product focused on integration between on-premise and cloud applications through a cloud-based platform-as-a-service (PaaS).  This acquisition is a key ingredient to Dell’s software and service capabilities for cloud computing.  They are eager to keep pace with HP after losing out in the bid to acquire 3PAR.  Just as traditional desktop software vendors are trying to protect their market share from SaaS competitors, hardware vendors are trying to protect their position against IaaS competitors.  This movement by the industry means that more and more options will become available for hosting individual components of packaged and custom applications across on premise and cloud environments in the very near future.  This translates into more composite applications with more integration points.

http://sg.news.yahoo.com/afp/20101103/ttc-us-it-company-computer-internet-dell-0de2eff.html