BC Tel Mobility has experienced living in a world of chaos. They gained this knowledge as soon as the company decided to deploy an enterprise component architecture.
Speaking at Comdex Canada West ’99 in Vancouver recently, BC TEL Mobility employees said such chaos is, unfortunately, a normal part of the cycle when implementing this type of architecture.
The company first began deploying an enterprise component architecture in 1996 and is continually developing applications for it, such as the Interaction Voice Response system. This allows customers to access account balances directly or via the Internet. Customers will soon be able to view their bills on the Web as well.
The company currently has 600,000 customers and handles three million calls per day. The number of employees has grown from 30 to 130 in the past five years and they currently have over 80 GUI systems in production.
According to Eileen Keogh, system architect at BC TEL Mobility in Burnaby, B.C., the company was first inspired by the vision and the promise of component architecture and reuse. And she said the initial results were very encouraging.
“What actually drove us to use the component architecture was that we ran into the limits of our two-tier architecture, we ran into limits on the desktop and we ran into performance problems so we [decided] to adopt component architecture,” she said. “Our first 12 applications were just great — great performance and everything was working great. And then we got into the chaos area where we ran into some technology problems. Basically we ran into a lot of brick walls and started rewriting things (that we had already written). And our growth of rapid application deployment was down so we had to step back and take a look at everything and see how to bring order back into our world.”
Keogh refers to these limitations as “gotchas, small furry creatures with sharp teeth that came out of the mist and started biting us.”
So what is it about component architecture that attracted BC TEL Mobility? First and foremost, the promise of reuse, Keogh said.
“The vision of being able to build reusable components like tinker toys that you just string together to build a system is one that has captivated us for a while now,” she said. “In our world, the idea of building components to encapsulate our switches and our legacy VMS systems and then to reuse them was a big motivator in how we built our initial components.”
What the company found, she said, was technology works – for the most part. More problematic than the technology, however, was the lack of a process.
“A lot of people sort of throw the process out and end up with big messes,” Keogh said. “So what we found was the theory would tell you to do one thing and the technology would tell you to do another.”
All companies can do, she said, is adopt standards and an architecture.
“As well, it is critical to document (your objects) — I can’t stress that enough,” she said. “If you document your objects, (have a) user guide to your objects and document how it’s put together, it gives you a lot better chance. Get some help from experts; Microsoft now has provided us with some mentoring to help us understand technology so we can find our way through it. And for reuse, get a strategy together and follow it.”
According to Craig Slack, part of the client integration team at BC TEL Mobility, it’s important to identify up front who owns what.
“So who owns the applications, who owns the servers or the hardware and the OS?” he said. “You don’t want to have to run into a situation like we did where Development has all the experience, all the understanding how the new technology works and the new environment, and you then have to give the developers access to Production in order to publish and fix problems.”
As well, it is important, Slack stressed, to develop standards and maintain them. And in order to enforce standards, you need security. “You want to be able to protect your sensitive data,” he said. “If you’re looking at something such as MTS that sits on NT for example, you’re going to want to look at other Microsoft-type products as well that integrate with that existing technology. So for example, IIS is very tightly integrated with MTS so that’s the area you may want to look at for doing Web development access for objects on the back-end.”
Despite that planning, the group had difficulties.
“We did run into some problems,” Slack admitted. “We didn’t have a corporate security policy in place to begin with.”
So what did the company learn from its mistakes? “You need to make sure your security policies can adopt to changes. And weight the importance of security. Is it really needed? In some situations you may not need security — for example, if it’s only going to be an internal application you may not mind if everybody has access to it.”
Slack also advises companies build security into the application right from its design phase. Do not approach it as an afterthought and try to plug it because you’re going to run into problems, he said.
The company is employing COM, DCOM, Visual Basic, Microsoft Transaction Server (MTS), Java, Internet Information Server (IIS) and HTML.
“For browser apps we stuck to HTML with JavaScript. We tried just Java and found it very difficult — undocumented problems, documented solutions that don’t work and very little knowledge,” said Bill Ozeroff, manager, strategic systems and architecture at BC TEL Mobility. “For database connections we needed to get a ‘pooling’ function that handled connections to all of our databases including RMS – our indexed linked sequential record management system under VMS/DEC. We chose ODBC for this standard.”
Ozeroff suggests buying all development tools from one vendor. “They might not all be the best but at least you can be sure they have been tested and probably work together.”
