Australia's affair with mainframes
As large-scale mainframe integrations shift focus from the front to the back end, we look into the essential ingredients and stages for project success.
The IBM 360 was released in 1964, and began shipping 12 months later. Up until this point large-scale computers were purpose built, whereas the IBM 360 used the same combination of hardware and software, and came with a whole 8MB of memory, was rented rather than sold, for anywhere between AU$2700 and AU$115,000 a month.
Honeywell, RCA, NCR, Burroughs, and GE jumped on the mainframe bandwagon, and within five years the installed base of 17,000 business machines, grew to 90,000 worldwide.
For three decades the mainframe reigned supreme. Then during the nineties, personal computers grew into servers and then server farms, and mainframes were increasingly depicted as dinosaurs and decommissioned in favour of their lightweight, fast-moving counterparts.
The last decade has seen a mainframe technology battle, rumours of its imminent demise, Sun's cheeky Mainframe Migration Program, and a rapidly changing business environment. Still, mainframe vendors are reporting growth.
This year Big Blue celebrated the 40th anniversary of its first mainframe with the release of the e-Server zSeries z890 and z990 mainframes. It claims the market is going from strength to strength.
Andy Cooper, information management and brand manager for Computer Associates (CA) in Australia and New Zealand, says the business mood regarding mainframes is subject to trends. "Through the nineties some people saw mainframes as expensive legacy systems, something difficult to get value from," Cooper says. "Now we are seeing organisations opting to keep their mainframe systems rather than replace them, and looking for ways to get better value out of them."
This shift in attitude according to Cooper is due in part to new technologies which better enable businesses to use the data and processing power on their mainframes.
"The bottom line is that a little while ago people thought they would get stuck with expensive, inflexible systems while the rest of the market moved forward," Cooper says. "That is no longer the case."
However, while the tool sets available for mainframe integration projects are advancing rapidly, and providing end users with greater flexibility, the projects themselves are still large and daunting. Not in the least because they invariably deal with the very applications on which businesses are built.
Stability is perhaps the most fundamental reason as to why the mainframe still sits at the core of most business computing, according to Boris Ivancic, area sales director for Attachmate in the Asia-Pacific.
"We still find for high-transaction, highly-scalable environments. There's no better way to run than on a mainframe," Ivancic says. "A lot of the mid-tier vendors argue they can do things more effectively on smaller boxes, but if that were the case more major organisations would have made the shift."
Given that many data-dependent corporates have their core operations hardwired into the mainframe environment, Ivancic believes we are unlikely a move away from this.
Nonetheless, in the mid-business sector, there is still a gradual migration to server-based, or thin client computing. While CA's Cooper says big business is increasingly opting to leverage the full value from their mainframe systems, some are simply looking for a way out.
"It will always come down to the specifics of the organisation. There are some organisations where it absolutely makes sense to decommission the mainframe," Cooper says. "Where commercially it is a better option to migrate off onto another architecture."
"In the first wave of mainframe integrations most people wanted just to do up the front-end using browser technology," Chia says. "Now we are starting to see something different, it has got to the point where a lot of businesses can't improve performance any more without increasing integration at the back end."
Currently servicing 900 concurrent users, 250 motor dealers, 12.5 million business transactions, and 10 million applications transactions per day, the mainframe underpinning the Queensland Transport is one of the hardest working in the country.
However, it was by no means an overnight success. In fact the integration process that now provides best-of-breed service to just under four million people from the Gold Coast to Cape York, began more than decade ago.
Departmental changes in the early nineties had seen a single amalgamated department created from several disparate departments and offices. This left the newly established IT department with four major systems, and four separate customer views. Between 1993 and 1996, 500 years were invested in an effort to tightly integrate these systems into what came to be recognised as a AU$60 million mainframe "asset".
From the outset, the IT department was keen to create a centralised but open system, designed to provide a different way of accessing the data contained therein.
"When we were doing the integration we knew it would be useless if we just built a monolithic blob," explains Sam Higgins, acting manager and application architect within the information services branch of Queensland Transport. "By 1999 we'd successfully integrated it into a single mainframe and we were looking for other options to leverage the value of that mainframe."
According to Higgins the last five years has been spent doing exactly that. The transport registration and integrated licensing system (TRAILS) is now involved in up to 80 percent of customer interactions with Queensland Transport. This whole process has been facilitated by the 1996 adoption of a service-orientated architecture (SOA).
| "When we were doing the integration we knew it would be useless if we just built a monolithic blob." |
A popular approach to mainframe integration in the 1990s, EAI (enterprise application integration) was designed to connect modern applications with legacy mainframes and databases. According to Higgins, those that opted for the EAI paths still have to deal with integration headaches not fully resolved by expensive short-term approaches.
"The lipstick might be Yves Saint Laurent, but when it rubs off you still have to deal with the pig," he says.
Westpac -- single customer view Nirvana
"There is quite a lot of activity in terms of creating a Nirvana state with a single view of customers, and an increased use of mainframe integration technologies," Visentin says. "There are now a number of mature products available that provide the plumbing to integrate mainframe systems and allow them to communicate with each other. The balance between what's spent on back office integration and what's spent on the front office is shifting."
However, when it comes to front-end integrations EAI approaches have been largely replaced by SOAs. The reason for this, according to Greta James, research director for Gartner in Asia-Pacific, is that initial front ends were designed to give end users and staff access to the information. This second wave of front-end integration is necessarily more flexible, says James.
"These days you want to do front-end integration in a way the lets you communicate with other applications, over the Web, with different delivery channels, with end-users and with staff," James says. "The challenge is how do you wrap this stuff in such a way that is can be used in different contexts."
According to James, Westpac's experience with Internet banking provides an example of a best practice implementation of SOA. In 1999 Westpac set out to create a uniform customer experience, and rapid expansion of its Internet-based services. The bank's core functions were spread across 80 applications, most of which involved hard-wired delivery mechanisms, which resulted in product silos and inconsistent customer experiences.
The bank's initial step was to define specific business outcomes, then create a highly detailed map of how the project was to proceed. Rather than launch the integration as a standalone project, it was implemented gradually.
"The initial approach adopted to implement the SOA services was to wrap current applications and expose them with minimal reengineering," James says in her 2003 research paper. "Once this infrastructure and some SOA services were in place, and their benefits could be demonstrated, the CIO presented the architecture to the bank's board."
Having proved the concept through limited rollouts, a more extensive project was given the go ahead. While end users are oblivious to what is going on behind the scenes, it should be noted that Westpac is currently promoting the fluidity of its banking services, assisted, no doubt by the successful SOA-based mainframe integration.
After dealing with Y2K Greg Booker, general manager of IT architecture and planning for St George bank, faced an interesting challenge. The spate of mergers and acquisitions had left the bank with a series of core systems, consolidated to a single mainframe.
| "We will break the systems down and take the functionality out into the service layer, but the data will still reside on the mainframe systems at the core." |
"The process has evolved through different phases. The core services we began with were older and getting difficult to maintain, however, we wanted to steer away from a big bang conversion. By late 2002, we were still making functional enhancements around the core systems," Booker said. "Over time we will break the systems down and take the functionality out into the service layer, but the data will still reside on the mainframe systems at the core."
According to Booker, the creation of the service layer has increased the speed at which the bank can take new products to market, reduced the complexity that was associated with creating new applications, and reduced core systems maintenance.
Like that of Westpac, the St George integration was designed to be implemented in small steps over an extended time-period.
"We timebox all projects and do releases every three months," explains Booker. "We take small steps, but we take a lot of them."
According to Booker, St George is progressing towards a SOA where business processes can be encapsulated and lead times reduced. "In the end we are running a business and the imperative is that it be run cost effectively and with a minimal lead time on new projects," Booker says, describing the integration project the bank has carried out over the last four years as a win-win scenario for business and the IT team alike.
Slowly and deliberately, some companies make it work, and others opt for operational integration. Others, in preparation for future acquisitions, are opting to ditch the mainframe model in favour of more flexible environments.
In November 2002, health insurer HCF acquired health benefits organisation IOR Australia. The move expanded HCF's customer base from 760,000 people to 870,000 and expanding its presence in the southern states. However, it wasn't until 2004 that the two companies were operationally integrated.
| "We simulated the merge the weekend before we went live. This allowed us to sort our problems and eliminate any surprises."
Wayne Miller, HCF |
Miller believes the project's success was largely determined in the planning stage, which he sees as crucial to the project's overall success.
"Our objective was to merge IOR with HCF as soon as possible while keeping it simple, without disadvantaging the customer. This meant the business had to ensure we offered products that matched or bettered the IOR products," Miller says. "During this process the complexity/impact on IT was closely monitored, so the business understood what the cost and time estimates were for each scenario. IT was consulted and actively involved on the project team, to provide input to the business on proposed approaches or options."
Given the size differential between the two companies, migrating IOR customer data into the HCF environment seemed like the most logical approach. However, Miller wasn't about to take any chances.
"We simulated the merge the weekend before we went live. This allowed us to sort our problems and eliminate any surprises. It also gave us a very good understanding of time estimates," Miller says. "It was like a second bite of the cherry without impacting the business."
| "Testing as much as you can in an environment as close as possible to a real environment, goes a long way to ensuring a successful integration." Boris Ivancic, Attachmate |
By any measure, the HCF IOR integration has proved successful, with no data issues or system failures since the merge took place. Moreover, the integration has served to reinforce Miller's belief in keeping a tight hold on project management.
"If the scope changes, agree on its impact and don't just let the business assume IT can do more in the same timeframe. This is true for any IT project," Miller says. "Going forward, the success of the project has given the business confidence in IT's ability to support and serve the business. This can't be a bad thing. It was also a morale lifting exercise for IT, especially those heavily involved in the integration."
ANZ's trans-Tasman merger
For the time being, NBNZ continues to operate as a separate entity in the New Zealand market, with ANZ announcing its intention to keep brand and branch networks separate.
On 26 October, ANZ announced it expected to complete formal integration by late 2005. This will see a single approach to head office activities, operational and functional support areas and the Institutional, Corporate and Rural businesses.
After toying with the idea of back-end integration, this idea also had to be scrapped because the risks were deemed to outweigh the potential benefits. "ANZ no longer plans to integrate the retail banking platforms as the payback is not compelling. This avoids the cost and risk of combining very different legacy platforms that will not advance the business strategically," an ANZ release says. As the two banks will effectively operate separately in the retail sector, there was little motivation for ANZ to put the staff and effort into what promised to be a complex integration. ANZ has left the way open, however, to merge technology and operational support at a future date, spreading the costs across both Australia and New Zealand.
"The revised plans for New Zealand integration substantially reduce the management challenge and integration risk and allow management to focus on customer retention, growth and financial performance," ANZ Chief Executive OfficerJohn McFarlane said.
Although the ANZ bank opted not to go ahead with a full integration of its legacy systems, it decided to carry out a partial integration of the two banks' International systems, which will be housed in Australia with a disaster recovery capability in New Zealand.
MBF's mainframe hits the road
Looking to avoid this very dilemma, MBF is in the process of decommissioning its mainframe, and migrating its applications into a Citrix environment. With two million Australians already on its books, the health insurer is not making any secret of the fact it is on the acquisitions hunt. The shift away from mainframe technology is seen as an important step in preparing the company's IT infrastructure for just such a process.
"We initially looked at the applications we had running on the system, and as it turns out it doesn't matter what they run on, while a different environment could give us greater flexibility to access and maintain data within the business environment," explains Chris Lawrenson manager of IT services at MBF.
According to Lawrenson, the combination of Sun Solaris boxes, Citrix clients, and a new third party administration application called Diamond, will provide the flexibility the company needs for its "strategic expansion".
"We are looking for scalability. We can always add multiple services," Lawrenson says. "Decommissioning the mainframe will take about 12 months, but then we will have the flexibility we need."
With business requirements at the forefront of the decision-making process, sometimes the best option when it comes to integration is disintegration.
- Business before technology -- clearly define your goals before you consider the technology.
- Define an overall architecture, then implement it gradually as the opportunity arises.
- Start small but with a view to an enterprise-scope implementation.
- Plan ongoing management before deployment.
- Test, test to scale, then re-test just in case.
This article was first published in Technology & Business magazine.
Click here for subscription information.