To celebrate its 40th Anniversary in Australia, Fujitsu has launched an eBook documenting its history over the last 40 years. Fujitsu Australia and New Zealand – The First 40 Years, was written by well-known journalist and analyst Graeme Philipson. The book covers the highlights of Fujitsu’s first 40 years in Australia. The book tells the story of how the company has grown to become part of the Australian and New Zealand ICT landscape.
Today Fujitsu officially announced the launch of the eBook at the Establishment Hotel in Sydney. The launch was attended by around 40 people including journalists, analysts, Fujitsu executives, as well as a number of long-standing employees. One of the highlights of the launch event was the attendance of 5 of the 6 past and present CEOs and Managing Directors of Fujitsu Australia.
In the picture above are Mike Rydon (Managing Director 1973-1985), George Ranucci (Managing Director 1985-1989), Rod Vawdrey (CEO 2003-2011 and current President of International Business), Neville Roach (Managing Director 1989-2000) and current CEO Mike Foster.
The launch event included an address by Keith Besgrove (on behalf of former Senator Stephen Conroy who wrote the foreword to the book), an overview of the book by Graeme Philipson, a business update by Mike Foster and an insight into Fujitsu’s global business by Rod Vawdrey.
The eBook can be found at:
Many corporate applications will more than adequately serve their organisation’s needs for many years to come. However the platform they are operating on is more than likely ageing, outdated and expensive to maintain.
The migration of legacy applications to more reliable platforms is an ongoing concern for organisations. According to a recent survey by Gartner of corporate CIO’s, Legacy Modernization ranked among their top 10 technology and business priorities for 2012.
Migrating from UNIX using Symantec and Red Hat
Many “industry aware” C level managers are starting to consider the implications of the longevity issues surrounding traditional UNIX systems. In many cases, the applications themselves do what is needed by the business, and there is no need, driver or desire to retire the applications.
We have a migration pathway to help organisations to move UNIX applications from expensive hardware and operating systems to newer, cheaper and readily available hardware (x86 architecture) and an up to date, well supported operating System – Red Hat Enterprise Linux.
We can also move the applications into Fujitsu’s Cloud Services or enable the applications and servers to continue to run in either a Fujitsu Data Centre or the customers own Data Centre, whichever is preferred.
What is Red Hat Pathways?
Fujitsu’s Legacy Modernization program for migrating from UNIX to Red Hat Enterprise Linux on x86 is based on the Red Hat Pathways methodology, created by our partner, Red Hat. To begin with, we conduct an “Application Value Assessment” workshop to learn about the client’s environment and desired outcomes. From this workshop, we agree on suitable application(s) to migrate and using the Pathways methodology we provide the client with a ROI document suitable for use in a business case.
Why Migrate From UNIX?
There needs to be a driver or business case for migrating applications from their traditional UNIX platform, most commonly these drivers include the requirement for better:
With any migration from one system to another, there is always an issue of production downtime during the final cutover period. Migrating large systems can lead to large periods of “read only” downtime which can sometimes be managed by cutting over during natural slow periods, but not always.
With its volume-based asynchronous replication buffer, Veritas Volume Replicator (VVR) can be configured for zero Recovery Point Objective (RPO) replication over any distance. This configuration lets Fujitsu replicate asynchronously over IP to our Cloud, while synchronously mirroring outstanding data in the asynchronous replication buffer (using Fibre Channel or IP) to a nearby site.
Then when it is time to “go-live” into the Cloud, the application downtime is minimised to just the time necessary to drain the bunker Storage Replicator Log (SRL) which can be measured in minutes, rather than hours.
Can RHEL be deployed to a Cloud Platform?
If the application is cloud ready we will be able to move it to the Fujitsu local cloud, otherwise the client can stay on-premise or move to the Fujitsu Data Centre, thereby removing reliance on UNIX and its associated costs.
Where can we deliver and do we have proof points on RHEL?
Initially this is an Australian only service, but it will be going global in the near future. With Symantec’s VVR tool, we are able to move applications into the Fujitsu cloud no matter where the existing server is located, without the need for a large downtime. Red Hat Enterprise Edition Linux is being used all over the world in almost every industry
So to summarize….
The Fujitsu, Red Hat and Symantec partnership has the ability to quickly, painlessly and efficiently “lift and shift” those existing applications from UNIX platforms to Red Hat Enterprise Linux Cloud infrastructure with precision, control and a minimum of application downtime.
One challenge for any IT project is to ensure that testing is performed efficiently and effectively. As with many things the goal is to try to find a happy balance. In this case ensuring quality without spending forever on the testing cycle. Before I go any further my intention here is not to dwell on V charts, and testing frameworks but rather to talk specifically about testing enterprise mobile applications.
- Graphical User Interface (GUI)
- Screen flow/workflows
- Mobile device/s
GUI, Screens, & Integration
Certainly a lot of the focus when testing enterprise mobility should be the application, its screens, and integration. Involving end users early (when managed correctly) can really help to ensure that the screen flows work under real use scenarios. Often functions can be tested independently during the development cycle. Device Emulators/simulators on a desktop can help rapidly test while waiting for the infrastructure and comms to be put in place. If the mobile application works in an offline way then ensure to test for data conflicts, locks, and test the resolution process. How can the solution recover from an integration error?
An important consideration that is sometimes overlooked is the wide variety of Mobile devices, models, operating systems, screen sizes, peripherals, and input methods that are being used in the solution. Don’t assume that everything that works on Model X will automatically work on Model Y.
Battery life – does your shiny new mobile application drain the battery flat in minutes? Is it using lots of CPU when decompressing or encrypting data? Does it constantly require communications or gps? Schedule some tests to simulate different levels of usage.
Communications (or lack there of) should be checked. What happens when halfway through a transaction the comms is lost. What happens if comms is slow or poor? I’ve seen some creative ways to test this. For example underground car parks, driving through dead spots, or using a Faraday chamber. When projects first move from simulators to devices they are often cradled or connected via Wi-fi. Ensure at some point to factor in tests based on real world communication scenarios.
With infrastructure it’s often not possible to directly replicate the production environment. However it’s definitely worth looking at simulating traffic. Try running functional tests while ramping up the load and find out at what point problems occur. MEAPs often come with tools for capturing, simulating, and amplifying traffic.
Authentication & Security
Its obviously important to test the authentication and security mechanisms. Consider carefully how the authentication works and schedule appropriate testing. What happens when passwords expire or the user enters it wrong too many times. Some companies hire in specialists to attempt to compromise the system.
As part of the overall strategy consider using a technical go-live where the mobile application is put into production and tested without being used for real business. This may require assistance from the business to run through some transactions and then back them out. Once the technical solution is confirmed then one or two key users can be introduced to the solution. At this stage monitor the system thoroughly and adapt any changes as necessary. Once proven expand the user base gradually and ensure that performance is managed. On some projects it’s necessary to initially throttle the performance so that the first user group does not feel negatively impacted once the entire community is live.
Please let me know your thoughts and any addtional lessons learnt from testing enterprise mobile applications…