Have you built a mobile solution for you company from scratch?
Yes, I’ve tried it too. Don’t get me wrong Visual Studio is a very powerful tool and the emulators are a great step forward but for my mind most of the pieces of the solution just aren’t there and you have to end up building most of that yourself. The risk is the components parts are not built to best practice and often aren’t as productive as they could be. In this space you are still very much on your own.
Often building your own solution can be a baptism in fire as parts of the technology aren’t as smooth as they could be, or worst still, very immature.
My other major headache was that a mobile solution was going to working in the wild with links back to base this meant that security was a major concern.
We haven’t even touched on my other headaches such as version control, performance, future proofing etc, etc, etc …
Now Microsoft does have some excellent best practice papers and wonderful examples, even a complete solution, all this does indeed go someone to alleviate the feeling that you are on your own.
The learning curve is indeed steep but unavoidable these day as many take up the gauntlet as they feel they need to be first to steal a match on competitors or indeed to catch up with them.
Microsoft admittedly is trying to do something about that and have made further strides than the Java camp at the moment. The latest creations from Microsoft will indeed bring forth a much better development platform with which to build mobile solutions, but the plain truth it isn’t here today! So what can I do today?
Often the answer is to select the right partner who has a done a deal of the work for you already, has experience in the market space, all you simply do is make your requirement and pick of the shelf, right?
Even this process I found was a minefield as many companies will want to provide the complete solution so you actually have little control over look and feel, some even use a mish-mash of technology as they fight to keep pace with advances whilst protecting their investment in established code written in an older technology.
So I found it important to sort out the wheat from the chaff and I did this by making a list of my key requirements, and they were
1) A front-end written in .Net CF technology. Why not eVB or Java? I’m not satisfied that Java was mature enough for building business applications. I have seen to date little evidence of its use in company bespoke applications as the norm. As for eVB, it is clear that this solution is at end-of-life and may not even function on the next version of the Windows Mobile platform.
2) A middle tier that abstracted the developer from most of the plumbing.
3) No proprietary database or data-store should be used on the front or back-end, so the solution could be maintained, supported and secured easily.
4) Industry standards must be obeyed in transport and data so no specialist changes would be required for our fire-walls, i.e. HTTPS, XML, SOAP
5) Easy to deploy applications.
6) A consistent technology platform used through-out. i.e. all .Net or all Java, or COM. My preference is .Net as this was consistent with the developer skill-set which we have in the organisation.
7) Allow enough freedom over the mobile front-end to make changes ourselves with limited to no lock-in.
8) Will integrate with out existing systems.
So you get the picture, no funny proprietary technology anywhere, as little lock-in as we can get away with, .Net as far as the eye can see, that won’t break anything we already have, we can move forward with, based on industry standards, oh and we can secure as tight as a ducks-butt! Need it any clearer?
Wait a minute! … I haven’t talked about business requirement yet?
As you know this is a sin in may book. In this case it’s actually very simple, good technology choice is good for business for all the right reasons, maintainability, flexibility, security, performance moving forward. So we can sit back and relax on business requirement for a change.
The example application on the table from the business was one that couldn’t be simply bought off the shelf. (Now I cannot talk anymore about this application, so don’t ask me any question about it please.) Also our vision of future applications that would be required moving forward couldn’t also been brought of the shelf. My company is far from standard, no really! Granted so features could suit, indeed! This was a fact I was relying on to get a good layer of abstraction, but at what level? Usability at the expense of flexibility? The right balance had to be struck. So how is this done? A good benchmark I always use with the business is that they will want to have the most unexpected change like yesterday. Of course the challenge will be to produce a good answer without compromise, no spaghetti solutions on my watch if I can help it (depends on the arm twisting). I know this take investment but in my experience this really does pay off.
As you can imagine we did indeed look at many companies, many have really good products, but in this post I won’t talk about every product I saw as this post will get longer than it has to be.
In this post I will talk about the product that we chose and I will try not to make it sound like an advert. Basically, I’m sure that there are a few other products that are similar in feature and function but at the end of the day it is impossible to see them all so we had to put a steak in the ground. I of course would love to know of any more that you have experience with, that’s why I have feedback switched on!
So now all that’s said and done, let’s talk about Dexterra.
Firstly let’s look at the architecture diagram,
Now let’s will in the blanks,
• The client is a .Net Smart Client.
• The middle tier is a SOA built using web services allowing for maximum flexibility using the industry standard solution moving forward.
• The adaptors allow communication to SQL Server, Oracle, BizTalk, SAP etc (you get the message more connections than you can shake stick at.)
• 100% .Net
That’s the headlines. Let’s look under the covers.
Dexterra has several products, but I will talk to your about the features that most attracted me.
• In most cases the only code a developer will need to write is in the front-end! To add to the productivity curve the front-end developer is completely abstracted away from data storage and communication coding. The developer has no need to know about how the data gets into SQL Server CE on the device and is how data conversations with base via HTTPS, using SOAP and XML are performed. The data is presented to the developer as the contents of classes. Performing operations on the data is as simple as executing a method.
• Most the work in the Dexterra products is done from inside Visual Studio or on a simple to understand web page.
• No funny business! Dexterra presents itself to the developer as a set of classes and components that are 100% .Net
• The knowledge of what the .Net and SQL Server platforms can and can’t do is apparent, the application protects you from the worst of it.
It is pretty clear that Dexterra enjoy a very close relationship with Microsoft. So, is this good for my business? Absolutely! Mobile solutions are a new technology with many pitfalls, it’s great for getting real answers to problems and hear the path to their solution and have the ability to enter into a dialogue about that, rather than the answer on a support person’s script that’s gone via corporate communications. Of course ‘influence’ can be brought to bear if required to help solve your businesses problem and the partner would be able to shout louder than perhaps you could and can do it on your behalf.
So, in up and coming posts I will be talking more about Dexterra.