René Zeldenthuis:  Software Developer

De hoeveelheid data neemt steeds maar toe en we willen steeds meer data offline tot onze beschikking. Te denken valt aan het op het mobiele toestel beschikbaar hebben van een postcode database of misschien wel het gehele klantenbestand. Dit heeft automatisch ook tot gevolg dat de hoeveelheid data die wordt overgestuurd groter wordt; dit is eenmalig. Nog interessanter wordt het om de gegevens allemaal actueel te houden en dit op een zo slim mogelijke manier te doen. Het is nu eindelijk zover; alles is doordacht; de specificaties zijn klaar en een compleet nieuw synchronisatieprotocol wordt momenteel geïmplementeerd!

Wat er zo vernieuwend is aan dit nieuwe protocol zijn de volgende vier hoofdbestanddelen:

• Slechts veranderingen worden doorgestuurd. Hierdoor is het niet nodig om bij een wijziging (van bijvoorbeeld één postcode) de gehele database over te sturen. Ook is het niet meer nodig om een referentie van de aanwezige gegevens over te sturen naar de server.
• Bij het verbreken van de verbinding tijdens het synchroniseren kunnen alle gegevens dusver ontvangen toch worden verwerkt; het protocol is geheel ‘restartable’.
• Er wordt gebruik gemaakt van http/https. Hierdoor gaat dit nieuw protocol door de aanwezige proxy servers en deze poorten staan mestal open in de firewall. Verder is het https protocol (dat bijvoorbeeld ook voor telebanking wordt gebruikt) tegenwoordig standaard voor het versturen van gevoelige data.
• De Navara client bilijft altijd verbonden. Indien er gegevens worden ontvangen die relevant zijn voor de client worden deze direct doorgestuurd (push). Ook worden gewijzigde gegevens van de gebruikers direct teruggestuurd. Uiteraard worden deze gegevens opgespaard indien er geen verbinding mogelijk is en deze direct verstuurd zodra dit weer mogelijk is.

Uiteraard is het wel nodig dat er gebruik wordt gemaakt van een nieuwe client en server dit dit protocol kunnen ondersteunen. Dit zal even lastig zijn maar hierdoor wordt Navara nog sneller, veiliger, rubuster en actueler!

In elk software bedrijf waar complexe producten worden ontwikkeld, kom je op een punt dat er een verandering gewenst is om de markt nog beter te kunnen bedienen. Dit kan inhouden dat er nieuwe technologieën op de markt zijn die geïntegreerd moeten worden om toekomstige ontwikkelingen aan te kunnen of nieuwe features implementeren waar de huidige markt op wacht.

Hoe ingewikkelder het product, hoe lastiger het wordt om dit naast het onderhoud en huidige roadmaps in te plannen. Bij dit soort projecten wordt vaak gekeken of er gebruik gemaakt kan worden van tijdelijk extra capaciteit. Mogelijke keuzes zijn dan detachering of outsourcing. In het laatste geval kan er gekozen worden voor nearsourcing, wat inhoudt dat het project geoutsourced wordt maar vaak binnen Europa, in bijvoorbeeld Bulgarije of de Oekraïne.

Nearshoring heeft in ons geval als voordeel dat de ontwikkelaars maar met 1 uur tijdsverschil in een virtueel ontwikkelteam productief kunnen zijn,  het kennis niveau vrij hoog is, Engels op redelijk tot goed niveau is en last but not least er weinig cultuur verschil  is (zeker als je dit vergelijkt met outsourcing naar landen als India).

Het meest uitdagende in een out/nearsourcing project is, naast het project management, kennis overdracht. Hoe maak je duidelijk wat de specificaties van de geplannde taken zijn als je niet ‘face-to-face’ zit. Gelukkig is Oost-Europa maar een paar uur vliegen, dus met meer ingewikkelde specificaties kan het ook echt ‘face-to-face’, maar in de meeste gevallen is het makkelijker om gebruik te maken van hulpmiddelen als GoToMeeting of Skype en een goede projectmanagement methode.

Voor Navara is na onderzoek gekozen voor de projectmanagement methode SCRUM. Door de interactieve manier van werken, in vergelijking met de traditionele software ontwikkeling methodes, is het team enorm betrokken in het planningsproces-

Dit uit zich onder andere in:

• Grooming sessies: feature specificatie rondes voor het definiëren van specifieke features. Op deze manier hoeft de specificatie niet van te voren volledig op papier te staan en kan het gehele team meedenken over de specificatie.
• Sprints: duidelijke, korte implementatie periodes.
• Burndown Chart: duidelijk beeld over de huidige stand van voortgang.
• Backlog: overzicht van alle items die ingepland staan voor het project voorzien van heldere prioriteiten.
• Task Breakdown: Features opgesplitst in taken van 1 tot 2 dagen die zelf door een ontwikkelaar binnen een Sprint opgepakt kunnen worden.
• Daily Standup Meetings: Elke dag een korte meeting met het gehele team (vaak niet groter dan 5 tot 6 mensen) waarbij de vragen, ‘Wat is er gedaan sinds de laatste meeting?’, ‘Zijn er problemen met de taken?’, ‘Wat staat er op de planning tot de volgende meeting?’.

We zijn nu een jaar bezig, en de keuze voor nearsourcing en de SCRUM methode Blijkt een hele goede te zijn. Wij zijn uitermate tevreden.

Over SCRUM

SAP.  No three letters command such a wide range of emotion in the enterprise.  Well, in the late 90’s perhaps CRM came close.  Large-scale enterprise-wide systems are incredibly complex.  It’s a major investment not only financially but emotionally.  For those who have lived through an SAP implementation, the aftermath is varied:  Some are delighted, some frustrated, and everyone can agree that it’s a long, long road.

As far as installations go, SAP may be one of the most costly and complex systems in the world.  Multi-year installations are common.  SAP is so complex that many consulting businesses focus exclusively on the system.  Teams of dozens of engineers and analysts working around the clock and around the globe provide customization and integration services while project managers attempt to keep their schedules on track.  As with any long-term systems project, extensions are also common – and therefore frustration and confusion are common as well.

The roller coaster ride of emotions is understandable.  SAP often replaces many home-grown systems and affects the very heart of every business that adopts it.  Often a complete overhaul of the core systems that control every unique aspect of a business are collaborated into one system for the whole of the business. This big of a change does not come without stress for those who will use it.

Specialized Solutions

With such a wide range of customizations available, SAP can be considered a blank canvas.  This is fantastic for allowing a customer the ability to design their dream-system; and a nightmare for those who could use a little suggestion.  Of course, infinite customization takes (infinite) time and money – and when some specific system needs are identified, it can take an extremely long time and a large amount of resources to implement them.  For some businesses, searching for a third-party to provide additional specialized functionality has proven to be a great decision.

Both the strength and the weakness of wide-scope systems like SAP is in its flexibility and complexity.  Wide-scope systems are so flexible that they introduce a high level of complexity.  Enter third-party solutions which provide very specialized functionality, such as Mobility in a relatively simple product.  These solutions focus on a much more narrow set of functionality and work in conjunction with many different types of large-scale systems such as SAP.  Because they are so narrow in focus, these specialized solutions can provide increased functional and technical capabilities without increased complexity.  Over the course of the systems life cycle, the benefits of using a specialized solution increase even more as change control and enhancements are much easier and quicker to implement than with a more complex wide-scale system. The flexibility: complexity relationship changes dramatically and the customer gets the best of both worlds – a capable solution that is quick to implement and change.

Increased Functionality without Complexity

By using third-party products for specialized functionality, suddenly we don’t need teams of dozens of people.  We don’t need years to develop and implement.  By focusing on one specific functional need, specialized third-party solutions eliminate much of the complexity that would be required to configure a wide-scale system to perform the same tasks.  The resources required to use a specialized product are drastically reduced which translates into a quicker and greater ROI, and much less stress for everyone.

With multiple commercials for the iPhone on TV every single evening, the most recent of which have been targeting business applications, we have to ask – how ready is the iPhone platform for some serious enterprise use?  As consumers we have been absolutely canvassed with Apple’s marketing for the device.  From its simple design and ease of use to it’s now-lower price point – but is this really the enterprise platform to derail RIM and Microsoft?

Backoffice Integration
In one recent commercial we see Apple demonstrating a credit card terminal application on the device, so that the user can accept a credit card payment for a business transaction.  What isn’t shown is how that order ties in with the backoffice applications that manage the order.  Another segment shows a shipping label being generated and printed – but how does the application tie in with the inventory management system or the fulfillment system?  – hint: they don’t.

Without that integration, these transactions are “off the grid” for the rest of the enterprise.  Can you imagine the chaos that would result from a field force of sales people taking orders without a systematic way for the orders to be fulfilled?  The real challenge of enterprise software is in the integration, to design a system to interconnect front-office applications in a way that streamlines business processes.

Hardware and Software Limitations for Enterprise
The iPhone’s lack of Bluetooth stack support for data input devices is a serious handicap for the enterprise marketplace, specifically for asset management implementations.  Adding peripheral devices such as bar code scanners, RFID readers, mag stripe readers, and printers means all data entry must be done on the touchscreen. Without the ability to add integrated or tethered input devices, we have only one choice – the fat-finger-prone touchscreen.

That said, the touchscreen is incredibly responsive and capable for many data input tasks.   Even so, let’s not try to do a physical inventory without a bar code scanner, OK?  Some of those asset tags might be accidentally… tarnspoesd.

For other types of field services applications, the consumer-grade device construction renders the iPhone fragile by industry standards for field services devices.  Cracked glass screens are common for the device in the consumer space, and one should expect such a phenomenon to have increased occurrence in the field services demographic.  The iPhone is anything but durable, and screen protectors with silicon protective cases are all but required to keep the device intact.

That leaves us with the enterprise office environment for a potential market.  For applications in an office environment where non-ruggedized hardware is acceptable, and for those without a critical need for peripheral data input devices, the iPhone is a reasonable contender.  Applications such as CRM, Helpdesk, Change control, Sales Force Automation, and perhaps even light-duty Facilities work flow all seem feasible with the iPhone.

Conclusion
Compared to the established enterprise mobile platforms, Microsoft Windows Mobile and Research in Motion Blackberry, the iPhone is still the underdog.  While gaining considerable traction in the consumer market, the iPhone platform is still relatively new to the enterprise market.  Apple is targeting the enterprise market actively now, and it is clear that they intend to make the iPhone an enterprise platform in the future.  For now, that means somewhat limited availability of mission-critical software – for example VPN clients.  Enterprise email support now opens the doors for other application software to be developed for the platform, but just how long will it take to cross the chasm?  That’s anyone’s guess, and unless your organization has uniquely-fitting requirements AND is in the very small “early adopters’” category, it may be best to hold off on the platform for now.

With the current standardization of mobile technology and with the current lifecycle of mobile devices it is all but certain that your mobile application will never be finished. This is one of the hazards of developing proprietary applications for mobile devices. You will have to re-develop your mobile application as soon as it ready to support newer devices and OS’s
Best practices include leveraging mobile middleware that supports all the main mobile operating systems. It should behave as a generic gateway that provides the capability to integrate to multiple back end applications on one side and a variety of mobile devices on the other. There are solutions on the market today that can tremendously simply your mobilization efforts and allow your development efforts to be spent on your organizations core competencies.