Are you heavily invested in Big Iron? Do you want to move to mobile but don’t know how? Don’t let Big Iron shackle you to the past. You can move to mobile and it is easier than you think.
There are many short cuts to making the move; such as running emulators/virtual machines on your device, or installing special tools that translate the green screen CICS applications within mobile devices.
But why not leverage your mainframe to do what it is good at, pushing data around!
To do that, you need effective API’s to access your data. Utilizing the HTTP protocol on your web servers you can build such API’s.
If you are looking to move your enterprise applications to a mobile environment, here are some tips to make your move a littler easier.
Background
Recently, BlueFletch was engaged by a major retailer to lead them through such a transition. After an in-depth analysis of the client’s applications, BlueFletch designed API’s and a proof of concept application.
The API design included the entry points, input parameters, and the resulting data models. The customer built the entry points while BlueFletch built the application, running on Android. The proof of concept application allowed for testing many of the new API’s, and gave the client a feel for API development.
In less than eight weeks from the first meeting, BlueFletch had moved one mainframe application to a native Android application. In less than 5 months from the first meeting BlueFletch moved 28 mainframe applications to native Android.
From that experience, here are tips to help you do the same.
Tip One – What to move
What do you want to move? Which workflow or application would benefit from being on a mobile device? Determine one application that you would want to tackle first. Start with something small. To alleviate headaches and ensure success, pick something that is well understood.
Tip Two – What is in a picture?
Make a flow chart diagram of the identified workflow. The old adage of “a picture is worth a thousand words” is so true in design. A simple workflow diagram will help to explain what task your trying to accomplish. But make sure the diagram reflects just one workflow; do not attempt to draw the world.
Tip Three – Data Relationships
Understand the data and how it relates to the workflow. Yes, you’re the owner of the data, but do you know all the dependencies? What pieces get updated? When does it get updated? What edits are needed?
Tip Four – API Design
Design your API’s to match your major object types. Many organizations place their data into databases and use complicated SQL queries to get to the data. That is all the API’s should represent, the result of those complicated queries.
If you’ve drawn a workflow (Tip Two), then add to the diagram by showing where the API’s will be used. This will help everyone involved.
You can even expand the diagram to show how data flows within the application.
On a recent project, a workflow was drawn, including all the API’s. The engineer working on the server-side code kept referring back to the drawing to ensure he was doing the proper code. With the picture in hand, he was able to tune his code to be better utilized by the client application.
Tip Five – API to do all things…not
A single API should NOT encapsulate the world, but do small portions of work. If you need 20 different object types, then look at breaking the one API into multiple API’s. Stay away from having one HUGE data response.
For instance, if you’re building a customer address API, do not return customer purchase history. Although customer related, purchase history and address are two different types of data.
The larger the response, the more complicated the processing that will need to be done. The more complicated the processing, then more points of failure will be possible.
Tip Six – Let HTTP be your friend
Understand the HTTP protocols and how to use them. By properly using the HTTP protocols, you can map your API’s to something recognizable.
- GET represents the selection of data
- POST represents the insertion of data
- PUT represents the update of data
- DELETE represents a deletion of data
Nice! Your DBA will be happy as you now have a CRUD (create, read, update, delete) relationship that they understand.
Tip Seven – Proof of Concept
Build a Proof of Concept application. Do not attempt to recreate all your applications, just pick something small. Don’t over complicate it. You want something that will send data up and receive data. A simple login with a data inquiry would be a good place to start.
Use this as a learning experience, one that can help you determine the best use of your API’s.
If this is your first foray into the mobile world, keep it simple. When building your proof of concept, do just a few screens.
Other Considerations
Security: Always keep securing your data in the back of your mind. That means investigating the different security models that are at your disposal: SSL support on your HTTP requests; using signed certificates installed on devices; encrypting cookies or session keys after login; using VPN to access your network.
There are many ways to secure your data, use them!
Data size: Remember, your sending data to a mobile device, the more data you transmit, the more that device has to process. Most devices do not have large amounts of memory, thus will get bogged down and feel sluggish.
Do not expect to provide all the data anyone would need, but be selective. Only send down what the application needs. Save your network bandwidth and your device memory.
Conclusion
By identifying application workflows, making diagrams of your application’s interaction with the data, and utilizing what your mainframe does best, you can move your applications to the mobile world in an efficient manner.
And with the right partner, you can make the move within a few weeks.
