Updates from November, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • araskazemi 22:52 on 30 Nov, 2013 Permalink | Reply

    A Company Without APIs Is Like A Computer Without Internet 

    I found this article interesting: A Company Without APIs Is Like A Computer Without Internet – via ReadWrite

    This contributed piece on the importance of APIs is from Brian Koles, Head of Business Development at ChallengePost.

    If I told you that I had a computer with the fastest processor and best display ever, but that it would never connect to the internet, you would likely consider it obsolete. That same label will soon be applied to companies without APIs that connect them with the rest of the digital world.

    As software continues its march to transform all industries, lack of connectivity increasingly equates to being broken. Application Programming Interfaces are the conduits through which data, platforms and goals come together, so the best apps are increasingly becoming collections of elegantly woven APIs. If software developers are the new rock stars, then APIs are the instruments with which they make their music.

    This may all seem a bit dramatic, but truly it’s not. I don’t want my technology siloed. I want it to play nicely with others, increase efficiencies and make life easier. That’s what APIs do. They enable convenience through integration.

    If your company doesn’t seek new channels for integration, then it will stand alone on a digital island, which is no place to be in the connected future. I’m not just talking about enterprise ERPs aligning myriad business processes either. APIs are on Main Street, enabling merchants to connect with new customers, more easily accept payments and hire help on the fly. They’re capturing memories at home, and enabling photos and prescriptions to be ordered from the corner pharmacy

    Of course, APIs are big business too. Whether it’s trading foreign equities, managing large software projects or creating the future of consumer electronics, it’s all evolving communally through APIs (and their cousins, Software Development Kits). Developer communities are consequently becoming organic business development and R&D teams, taking companies and their technologies in new and exciting directions, all on their own.

    Navigating the path from being a traditionally closed-off company to one with an API program may not be easy. Change is scary, especially when it entails inviting third parties to run wild in what’s previously been a private sandbox. Here is a broad outline of next steps for those willing to champion the cause:

    Uncover Needs to Gain Early Support

    Request meetings with executives whose departments could benefit from increased interconnectivity. Use the pretense of something like “wanting feedback on a potential project that would make our [content, systems, data] more accessible to various departments, and possibly strategic partners”.

    During the meeting, ask what new efficiencies or revenue streams they could imagine taking shape if their {content, systems, data} was liberated. Note these suggestions, and ask to be looped in if more come to mind. Getting stakeholders accustomed to thinking about the possibilities that APIs can generate will be crucial. 

    Define the End-User And Plan Accordingly

    Will the developers using this API be internal, external or both? And in what order? The painful process you want to avoid goes something like this: 

    • Most larger corporations launch APIs designed only for internal needs, integrating systems and workflows from various departments. 
    • Then an opportunity pops up where a partner wants to use this API for mutual benefit, but it isn’t engineered to allow for secure third party access … or bill for it. 
    • A few custom arrangements limp along for several months until the API can be re-engineered to accommodate a third party ecosystem. 
    • Everybody involved wonders why the API wasn’t built for the possibility of being external-facing in the first place. 

    Unless there is absolutely no circumstance where it makes sense for the API to be accessible to third parties, avoid this hassle by designing the API as if it may some day be external-facing, even if there’s no immediate need. 

    Get Buy-In

    Exposing assets is a scary proposition. Dirty laundry could be aired, and loopholes will assuredly be abused before patched. You’ll need some champions to help you endure the bumpy road. Constantly remind stakeholders about the long-term value proposition, and brace them for the turbulence that accompanies any product release. You are thinking of your API as a product, right?

    Set Up A Management Portal

    Like most software-related projects, you can make a strong argument either for building it in-house or outsourcing development to somebody with more niche expertise. There are a slew of fantastic, relatively mature API management services already optimized to handle onboarding, billing and reporting for every API use case imaginable. This probably isn’t the time to re-invent the wheel.

    Plus, these partners provide a variety of white label web portals for setting up your public developer program (likely at developer.COMPANYNAME.com). 

    Provide Documentation And Code Samples

    It’s essential that developers be provided with accurate and thorough documentation for using your API. They should not need to speak with anybody to navigate and implement your tools for accomplishing reasonable use cases. It’s also advisable to provide code samples for executing typical functionality, which enable developers to focus on coding the more difficult or unique elements of their applications.

    Dedicate Staff

    API programs are not ‘set it and forget it’ arrangements. Documentation needs to be constantly improved while answering support questions, coaching partners through implementations and evangelizing the platform to target developer communities. Make this somebody’s job. It will not get done effectively as a side project.

    Establish Communication Channels

    Even if the API is just for internal use, you should still have a discussion forum for addressing developer’s questions. Then update the documentation to reflect common issues. Public APIs should have their own blog to celebrate major updates and partner achievements, and dedicated social media accounts (or at least a Twitter handle) to tie it all together. 


    Just because you built it does not mean that developers will come. Engaging developers requires a mixed bag of attending conferences, holding workshops, and sponsoring in-person hackathons and online challenges. Internal APIs will get an adoption boost from running an internal hackathon, where employees are challenged with using the API in new and exciting ways that serve the company’s interest.

    Create A Gallery/Marketplace

    People want their work to get noticed. Use a gallery to show off all the awesome software built on your platform, and maybe even offer a rev-share agreement through an app marketplace. It will drive downloads and inspire others to do even better. Internal APIs can have a private gallery. 

    Share The Credit

    Now that your API has generated some wins, the initially hesitant managers from engineering, marketing and product teams will start glomming onto your success. Let them. You’ll need their support for the next evolution of your API program.

    So which will it be? Will your company remain relevant by knocking down institutionalized walls and becoming an open platform through APIs? Or will it be a computer without the Internet?

    Link to article: A Company Without APIs Is Like A Computer Without Internet

  • araskazemi 17:10 on 26 Nov, 2013 Permalink | Reply

    Gartner Says Bring Your Own Device Is an Applications Strategy, Not Just a Purchasing Policy 

    I found this article interesting: Gartner Says Bring Your Own Device Is an Applications Strategy, Not Just a Purchasing Policy – via Gartner Says Bring Your Own Device Is an Applications Strategy, Not Just a Purchasing Policy

    Link to article: Gartner Says Bring Your Own Device Is an Applications Strategy, Not Just a Purchasing Policy

  • araskazemi 16:52 on 23 Nov, 2013 Permalink | Reply

    Stadsnäten stoppar Säposystem 

    I found this article interesting: Stadsnäten stoppar Säposystem – via Stadsnäten stoppar Säposystem

    Link to article: Stadsnäten stoppar Säposystem

  • araskazemi 14:36 on 21 Nov, 2013 Permalink | Reply

    ”Sluta köra it-projekt”
    CIO-veteranen Christer Cragnell har sett sin beskärda del av misslyckade it-projekt. Här är hans tre tips för att få bukt med problemet http://www.quadras.se/cio-veteran-sluta-kora-it-projekt/

  • araskazemi 23:10 on 15 Nov, 2013 Permalink | Reply

    Countries with Better English Have Better Economies 

    I found this article interesting: Countries with Better English Have Better Economies – via HBR.org
    Good English is a critical business tool.

    Link to article: Countries with Better English Have Better Economies

  • araskazemi 22:52 on 15 Nov, 2013 Permalink | Reply

    tibbr tablet app wins “Best IT/Business Tool” in 2013 award show. 

    I found this article interesting: tibbr tablet app wins “Best IT/Business Tool” in 2013 award show. – via Enterprise Social Network Blog – tibbr

    On November 13th, TabTimes and the Application Developers Alliance announced the winners of The 2013 Tabby Awards, the only worldwide competition of consumer tablet apps for iOS, Android and Windows 8.

    Submissions were received from Australia, Canada, Egypt, Finland, France, Germany, Italy, Japan, Latvia, Netherlands, New Zealand, Portugal, Singapore, Spain, Sweden, the United Kingdom, and the USA. After thoroughly reviewing the many tablet applications, an international panel of independent judges selected 60 finalists and declared 24 winners.

    In the final vote counting, our own tibbr mobile app took home the award for “Best IT or Business Tool.”

    Over the w00ting and high-fiving of tibbr’s mobile engineering team, the Tabby Award judges explained their reasoning like this:

    “tibbr scores high on innovation and its organic and social approach to getting work done, particularly project work done by mobile Gen-Y engineers, developers, creative, and professional services. This tool has the potential to enhance collaboration and productivity of teams.”

    If you would like to give tibbr a try, click here to receive a free trial! (continued…)

    Link to article: tibbr tablet app wins “Best IT/Business Tool” in 2013 award show.

  • araskazemi 09:51 on 15 Nov, 2013 Permalink | Reply

    2 av mina Instagrambilder finns bland de 120 som nominerats till Instagramtävlingen #9till5 på Fotomässan 2013 #fotomässan

    Se nominerade bilder!

    This item was originally posted on Google+ – November 15, 2013 at 08:00AM

  • araskazemi 20:28 on 13 Nov, 2013 Permalink | Reply

    IDC: Android hit 81.0% smartphone share in Q3 2013, iOS fell to 12.9%, Windows Phone took 3.6%, BlackBerry at 1.7% – The Next Web 

    I found this article interesting: IDC: Android hit 81.0% smartphone share in Q3 2013, iOS fell to 12.9%, Windows Phone took 3.6%, BlackBerry at 1.7% – The Next Web – via The Next Web

    Link to article: IDC: Android hit 81.0% smartphone share in Q3 2013, iOS fell to 12.9%, Windows Phone took 3.6%, BlackBerry at 1.7% – The Next Web

  • araskazemi 20:32 on 12 Nov, 2013 Permalink | Reply

    Making Decisions Together (When You Don’t Agree on What’s Important) 

    I found this article interesting: Making Decisions Together (When You Don’t Agree on What’s Important) – via HBR.org
    Collaborative work has built-in tensions. Here’s how to resolve them.

    Link to article: Making Decisions Together (When You Don’t Agree on What’s Important)

  • araskazemi 17:10 on 8 Nov, 2013 Permalink | Reply

    In The Age Of Twitter, Do We Need Oracle? Larry Ellison Isn’t Sure 

    I found this article interesting: In The Age Of Twitter, Do We Need Oracle? Larry Ellison Isn’t Sure – via ReadWrite

    Twitter is off to a roaring start this week, closing 70% higher than its IPO price on its first day of trading. This bodes well for Twitter investors, but it may not do any favors to the traditional technology vendors that have minted billions servicing enterprise IT requirements. After all, while Oracle and other technology incumbents like to boast about how "the top five of five mega banks rely on our technology," in the age of the web giants, the scorecard looks more like "Zero out of all web companies depend upon our technology."

    Are we seeing a changing of the technology guard?

    Modern Data Infrastructure: Hadoop And Beyond

    According to Cowen & Co. analyst Peter Goldmacher, the answer is "Yes." While new technologies like Hadoop in some cases simply sustain legacy technology businesses, there is a whole class of applications enabled by such modern data infrastructure that is beyond the legacy vendors. In true Innovator’s Dilemma fashion, they simply make too much money sustaining yesterday’s application workloads to be able to invest fully in modern applications. Quoting Goldmacher at length:

    The legacy providers of data management systems have all fallen on hard times over the last year or two, and while many are quick to dismiss legacy vendor revenue shortfalls to macroeconomic issues, we argue that these macroeconomic issues are actually accelerating a technology transition from legacy products to alternative data management systems like Hadoop and NoSQL that typically sell for dimes on the dollar

    We believe these macro issues are real, and rather than just causing delays in big deals for the legacy vendors, enterprises are struggling to control costs and are increasingly looking at lower cost solutions as alternatives to traditional products. What we are gleaning from multiple conversations with users of these new technologies is that regardless of the initial reason they experiment with these new technologies, the outcome is 1) The realization that not only are these products cheaper, but they are more flexible and better suited to many legacy workloads and 2) They offer end users the optionality to expand project scope beyond the constraints associated with legacy product, whether those constraints are cost or capabilities

    Such data infrastructure was born on the web, hatched in the bowels of web giants like Google, Facebook and Twitter. Each of these companies depends upon commodity servers running open-source technology, some of which they build, some of which they download and modify. 

    None of it comes from a legacy technology vendor.

    One Out Of One Oracle CEOs Agrees

    You may not agree with Goldmacher. And it’s easy to suggest that I’m just biased (I work for a NoSQL vendor, after all).

    So don’t listen to either of us. Listen to the grandfather of data, Oracle CEO Larry Ellison. Ellison said much the same thing in his Oracle OpenWorld keynote. Even if you listened to his keynote, you can be forgiven for not noticing a huge concession he made to the modern world of modern data infrastructure. After all, he didn’t get around to saying it until the last few sentences of his keynote. Starting at at about minute 50, Ellison finally gets interesting:

    What we think the data center of the future looks like is really a core of these commodity machines [i.e., commodity LInux servers not powered by Oracle] and a collection of these purpose-built machines [like Oracle’s Exadata that serve higher-end requirements].

    Did you catch that? The CEO of the world’s largest software company thinks the core of the data center is someone else’s business. That’s huge.

    The Future Is Open

    Twitter has given us Storm and a range of other great open-source software. What it’s not giving out is a big check to SAP, Microsoft or the other incumbent technology vendors.

    And while it’s fair to say that the web giants can afford to spend their IT budgets building open source rather than buying, but mainstream enterprises don’t have that luxury, it’s also fair to note that these same mainstream enterprises are investing more and more in the same open-source technologies that Goldmacher highlights as a drag on the incumbent technology vendors.

    This doesn’t mean we’ll see exceptional companies like Oracle go out of business. But it does suggest, like Ellison himself argues, that we’re likely to see the legacy vendors take an increasingly peripheral role in an age of Twitter.


    Link to article: In The Age Of Twitter, Do We Need Oracle? Larry Ellison Isn’t Sure

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc