A week back, I had the privilege of joining some industry peers at New York’s Interop conference, to discuss trends in enterprise mobility. Each of the companies represented a sub-segment of the mobility space. We had a big data company, an MDM vendor, a client virtualization company and me representing the MBaaS wing. Each presenter made a case for why their sub-segment is essential to enabling the mobile enterprise.

Not surprisingly, they all emphasized their security and management credentials as being central to their value propositions. Each vendor took a different approach to protecting the welfare of the enterprise but in the end, we all promised we could defend organizations against risk, both technological and financial. What we neglected to mention, I realized afterwards, was that a little risk is sometimes good.

Don’t get me wrong, security is something I take seriously. We at Layer 7 guard some of the most sensitive government and commercial APIs against cyber attack and misuse. But there is a downside to an unbalanced emphasis on insecurity – and that is fear. Some fear ensures prudence. Too much fear can arrest the progress of whole industries.

In a few short years, smart mobile devices have completely transformed how we communicate, socialize, shop and get entertained. Almost overnight, an economy has grown up around mobile apps. This same app explosion is poised to change how enterprises function, by completely un-tethering employees, while providing a way for companies to reach their customers beyond the PC and TV. But to get there, enterprises will have to encourage app innovation and the only way to achieve that is by opening up.

Now, no one says that opening up needs to be a foolhardy effort. Opening up data and applications to mobile apps needs to be done in a guarded and prudent manner. But in all the talk around mobile security, it’s important not to stifle innovation around mobile development. Security has to go hand-in-hand with connectivity.

The International SOA, Cloud + Service Technology Symposium takes place next week in London and the track titles remind me how much SOA has changed in the last 10 years. Mobile and cloud use cases have revolutionized the way we architect, deploy and manage SOA infrastructures, resulting in forward-looking tracks such as “New Service-Orientation Practices & Models” and “Emerging Service Technology Innovation.”

For the Layer 7 perspective on these service technology trends, come see our presentations throughout the week. On Monday, I’ll be speaking about how traditional SOA technologies such as the enterprise service bus (ESB) need to adapt to an evolving IT landscape. On Tuesday, our CTO Scott Morrison will be giving a closing keynote about “The New Governance”.  Wednesday brings an API Management Workshop at the Canadian High Commission, hosted by Layer 7 along with our customer MoneySupermarket.com and analyst firm RedMonk.

Layer 7 is a Founding Partner at the Symposium and we’re excited to welcome a who’s who of analysts, vendors and enterprises to join in the conversation. These illustrious attendees have helped to define the industry and revolutionize enterprise IT – and I’m looking forward to insightful speakers and great networking opportunities. For a more intimate conversation, stop by our booth (#110) to see a demo or discuss your SOA, cloud, API or mobile use cases.

London has shown an incredible amount of enthusiasm for sporting events this summer, from the Olympics and Paralympics to the Tour de France, which was won by a Brit for the first time in its history. Let’s keep that excitement going – see you at the Symposium!

Rome has seen its share of history. Therefore it shouldn’t have come as a surprise to hear telco after telco at last week’s SDP Global Summit echo the decade-old SOA mantra of abstraction, agility and reuse when talking about their new API initiatives. If they’d added a mention or two of loose coupling, the transportation back in time would have been complete.

On the surface, there’s no inconsistency between talking API and talking SOA: “API” usually denotes an implementation style; “SOA” an architectural approach to integration. A decade ago, SOAP and WS* formed an ideal implementation of SOA – or so thought the committees that drafted the supporting specifications behind what became known as Web services.

Like all well-intentioned products of committee, Web services represented an act of compromise, accommodating many competing interests. But their complexity became self-limiting and so Web APIs, with their familiar Web-like approach to handling machine-to-machine interactions, have become the latest hope for practical SOA among enterprises and telco carriers.

For carriers, the race to APIfication has a special urgency. With the explosion of apps running on smart phones, smart TVs and smart everything, the carrier is often relegated to providing a pipe and subsidizing devices. APIs give them hope by allowing them to expose their various assets as programmatic interfaces that can be leveraged by internal and external app developers.

This empowers carriers to stay competitive and relevant by giving them the ability to deliver software and services into the marketplace faster. APIs also allow carriers to adapt and react to failure more efficiently. If one idea doesn’t work, a telco can quickly retool and offer a new set of services that may have more appeal.

But if Web APIs are to deliver on the SOA vision of agility and reuse, they will need some of the same plumbing that made Web services work. Specifically, SOA Gateways were essential in making Web services practical. They provided a controlled, simple and economical way to connect services, regardless of differences in implementation.

Similarly, for APIs to be successful in the carrier market, telcos will need to implement API-ready SOA Gateways – or “API Gateways” – that can offload all the abstraction, adaptation, orchestration, security, SLA and identity brokering from the API logic. As with SOA, governance belongs not in the API but in an intermediary that mediates interactions with other applications. History repeats.

This week, I’m at the SDP Global Summit in Rome, which is focused on API publishing for telecom carriers. One of the comments I’m repeatedly hearing from speakers with carrier organizations is that they want to support different communities of API consumers without complicating their API publishing strategies.

Everyone wants to capture the long-tail developer but, for many carriers and non-carriers alike, developers in dorm rooms don’t generate revenue. Increasingly, the focus of many enterprise API publishers is on internal users, other enterprise customers and even partners. The mass market is great but, for APIs, it doesn’t always pay immediate benefits.

API goals around revenue, reach and retention are often realized faster by programs that expose APIs to internal developers who can turn around new services faster, customers that can build revenue-driving software faster or partners that can expand collaborative channels across mobile and cloud.

No two API consumers are the same, which means publishers need to build diversity into their API strategies from the get-go. But building flexibility without creating complexity can be tricky. And now for the Layer 7 plug…

API platforms like Layer7′s ease the whole diversification thing. Why build different APIs or API versions for different customers when you don’t have to? One of the popular features of the Layer 7 API Management Suite is the way customized versions of an API can be rendered virtually and exposed to target communities of API consumers, at will.

Something to consider – whether you’re a carrier or not!

Over the weekend of September 13-15, a small band of Web architects and developers will – for the third year in a row – descend upon the town of Greenville, SC. They’ll be getting together to catch up on the events of the past year, share stories about recent projects and contemplate the future of Web and mobile applications.

This may sound like a typical tech conference but REST Fest is hardly that. Taking its cue from OpenSpaces and similar events, REST Fest is organized by attendees, for attendees. For example, one of the days is devoted to everyone hacking on the same general topic. Another is dedicated to short workshops, all presented by selected registrants.

Similarly, all the general session talks are delivered by the attendees themselves. That’s because one of the “rules” of REST Fest is “everyone talks and everyone listens”. When you sign up to join REST Fest, you are expected to deliver at least a five-minute lightning talk – and there are no exceptions!

Notable presenters will include keynote speaker Stu Charlton (former CTO of Elastra), Matt Bishop (Senior Product Architect at Elastic Path), Pat Cappelaere (currently working on NASA’s SensorWeb project), Leonard Richardson (co-author of O’Reilly’s RESTful Web Services), Sam Ramji (Head of Strategy at Apigee) and yours truly.

I feel privileged to be co-chair of REST Fest and I’m pleased to note that Layer 7 is the event’s Head Sponsor this year. Hope to see you there!