Posts Tagged IBM MobileFirst
* The original version of this blog post is published in IBM Mobile Frontier
As you may remember from my previous blog post, we took a look into hybrid and native development models in IBM Worklight and illustrated how SWOT analysis can help us in the mobile solution design process.
Today I will emphasize three main reasons to consider Worklight as a development platform. Although there are plenty of reasons to put Worklight into your mobile solutions, I will explain three that I think demonstrate the strongest benefits of Worklight as a development platform.
I hope the reasons listed below will answer the question, “Why should I consider IBM Worklight as a mobile development platform?”
1. Multiplatform support
Worklight supports multiple mobile platforms for development and has the ability to build once and deploy in all.
Worklight offers the strongest benefits when employing the hybrid development model, and it is designed to be able to create and build iOS, Android, Windows Phone and BlackBerry applications separately within a single Worklight project.
Consider a mobile application that has to run in all of the popular platforms. It is obvious that without Worklight we’d have to think about creating distinct project plans for each platform. Since all platforms have to be developed by specific programming languages (Java, Objective-C, C# and so on) and specific development platforms (Eclipse, Xcode, Microsoft .NET and so forth), the analysis, design, development and testing processes should be evaluated separately in the project lifecycle.
Multiplatform support of Worklight enables businesses to create cross-platform applications in a single project, and it is one of the strongest reasons to choose Worklight as your development platform.
2. Single area of expertise
Development of mobile applications regardless of mobile platforms means that you are able to create mobile projects with a development team consisting of the developers with the same expertise.
When mobile projects are developed natively and on their specific development platforms, there is always need for development teams with platform-specific expertise. For example, you will have to build a development team with XCode and Objective C skills to create a native iOS application. The case is similar for Android development and the other remaining mobile platforms. The main problem with development for multiple platforms is to build teams with different technical expertise. The other issue is that these resources are also rarely interchangable between teams.
Development by Worklight brings businesses the ease of locating resources with the same area of expertise into cross-platform mobile projects. In the worst case scenario, native coding may be required just for the device-specific cases that Apache Cordova does not support. You should be able to resolve this kind of issue with very few developers who have platform-specific development expertise.
3. Cost benefits
For the projects’ sake the most important parameter is of course the budget, and this is another area in which Worklight makes you feel comfortable.
Throughout the development phase, IBM Worklight can help you to maximize the sharing of the code base from one environment to the other, effectively reducing the costs of development, time to market and ongoing management efforts. Furthermore, multiple mobile platform support in Worklight and working with people with same area of expertise rather than platform-specific resources increases the cost benefits in the project budget.
By reducing development and maintenance costs in mobile projects, Worklight seems appealing for businesses that are looking for solutions to build a strong mobile enterprise.
For further information on the cost benefits of IBM Worklight, I strongly recommend that you download and read “The Total Economic Impact Of IBM’s Worklight Platform,” a study published by Forrester Research, Inc. A clear benefit can be seen if you compare the initial and annual costs of developing and maintaining a complex four-platform app in a native environment and on the Worklight platform.
I hope this blog post has given you a clear understanding of the main benefits and opportunities of IBM Worklight product.
Connect with me on Twitter@serkanersanli to talk more about mobile solutions.
* The original version of this blog post is published in IBM Mobile Frontier
Let’s say you have to create a solution design for a client who asked you to transform its existing mobile application. You have plenty of requirements in hand, and the client has already purchased IBM Worklight. Now you have to consider which development model will be most advantageous for your client: hybrid or native?
IBM Worklight is designed to provide hybrid and native mobile application development in one platform. However, choosing the correct development model may not always be easy. You should keep in mind all of your specific requirements and critical parameters like project budget, performance, time-to-market speed, resources and so on.
I’ve been an IT architect for almost four years in IBM, and I spend a lot of my time helping clients develop the right applications for their organizations by creating the most efficient solution design. Creating solution design sometimes becomes challenging given the complexity of the client’s requirements and IT environment. Since SWOT is a competitive analysis methodology that looks at the strengths, weaknesses, opportunities and threats of a given product or solution, whenever I am confused on anything in my design, the first thing I do is to apply SWOT analysis. Believe me—it really helps when you get stuck in a project, and it can minimize your risk as well. If you aren’t sure which development model is best for your IBM Worklight project, you may need to apply my approach. I hope this blog post will help to lighten your way.
Before we deep dive into hybrid and native SWOT analysis, readers who are not familiar with IBM Worklight application types can download and review the “Native, web or hybrid mobile-app development” white paper. Furthermore, in official IBM Worklight technical white paper documentation, IBM uses the image below to highlight the application types that can be developed by Worklight:
Regardless of your development model—hybrid or native—you have to consider how you’ll integrate your code into Worklight. Here we go!
Hybrid development model on IBM Worklight
When I considered the strengths, weaknesses, opportunities and threats of hybrid development on IBM Worklight, here’s the list I came up with:
- Ability to build once and deploy all
- Reduced development and maintenance costs
- Rapid time-to-market
- Enhanced app governance and security
- May require native coding in device-related cases when Apache Cordova does not provide anything for regarding functions
- Compatibility with changes in the mobile market regardless of mobile devices, platforms and operating systems
- Possible delays for adaptation to operating system changes (there may be reasonable delays to receive a new version of IBM Worklight when there are big changes on specific mobile platforms, like the iOS 6 to iOS 7 upgrade)
Native development model on IBM Worklight
Here is the SWOT list for native development on Worklight:
- Enhanced app governance and security (with IBM Worklight integration)
- Better performance
- Rapid adoptation to operation system changes
- Full control on the device
- Requires development for each operating system by teams with different expertise (Objective-C, Java, C# and so on)
- Requires platform-specific testing
- For now, has limited support on the Microsoft platform rather than iOS and Android
- Enhanced native support in new versions of IBM Worklight
- An ever-increasing number of devices to support
- Difficulty predicting changes in the dynamic mobile market
I hope the SWOT models will help you make the right choice regarding hybrid versus mobile development in Worklight.
Connect with me on Twitter @serkanersanli to talk more about mobile solutions.
Dear Blog Readers,
I attended to an IBM event on Twitter 2 days ago and I’m glad to share my highlights regarding tweetchat discussion..
The story has begun when I received an internal e-mail about this event almost 1 week ago and here is a small picture of the notification :
It was the first time I attended to a tweetchat discussion on Twitter.. For those who heard about tweetchat for the first time, I can say that assume it as a room with interested twitter participants who are there to discuss on a specific hashtag announced before..
During this event, we have discussed Mobile Security on behalf of an expert (@JeffRyanPeters) under #IBMMWCCHAT hashtag.
@JeffRyanPeters was the Expert of the topic and led discussion by asking his already prepared questions with “Q1”, “Q2”.. prefixes periodically within an hour. All of us (participants) shared our suggestions, opinions, re-questions on the related sub topics and Retweeted (RT), Favorited (FAV) or Replied tweets…
The most important thing that I felt during and after the event was, tweetchat rooms are so helpful for twitter users to find others who have same interests and build a great network for specific fields..
I believe all participants were satisfied with the event and I want to thank especially Jeff and all participants for this great discussion..
Here are the highlights of the event, and of course “my” contributions are marked in red borderlines 🙂