Acrimony and architecture don't have to go hand-in-hand. Here are13 steps toward creating common ground.
There are probably two issues occupying the minds of most e-business enablers right now. One is the relationship between the organisation's business planning and its e-business planning. The other is how to define a consistent architectural framework under which individual projects can be conceived, justified, built and deployed.
Of course, the latter can be incredibly difficult, not least because while IT systems are originally built with a defined architecture, over time, a series of patches are typically applied. As a result, existing systems can start to resemble the famous ball of Band-Aids.
However, according to strategic business systems design specialist Peter Walsh, large-scale e-commerce integration projects finally give the organisation a chance to unravel the ball. And that, he says, is an excellent thing, because sometimes in the process of unravelling all those Band-Aids, you discover some of them are no longer covering sores.
Walsh, a principal consultant with IT consultancy Simsion Bowles & Associates, says he's learnt a great deal about managing e-commerce projects, having recently been project director for two significant e-commerce developments. The first involved developing a retail Internet banking system and an electronic services technical architecture for the National Australia Bank (NAB) during 1997 and 1998.
The second, which is ongoing, involves replacing an existing agency management system with a Web-enabled distribution management capability for Mercantile Mutual, a project embracing more than 100 interfaces. Simsion Bowles was responsible for developing the Requirements Definition and Specification and evaluating the best means for delivering the required solution. This included assessing internal organisational capacity to deliver the requirement and surveying external suppliers and packages. Now Walsh is project director for delivery of the system, which Mynd Asia Pacific is developing.
He says both projects have provided useful insights into the priorities for project managers trying to get e-commerce work off the ground.
"The [lessons learned] from the National Bank I have been able to apply in the next project," he says.
First and foremost, he has learnt that whatever the need for speed in getting an e-commerce project up and running, the process of designing the overall architecture and general requirements is vital. It can take at least six months depending on the size of the organisation and should never be rushed.
"It is really important for businesses moving into e-commerce to understand the value of different IT architectures and to use them as tools," Walsh says. "Business is now realising the significance of their existing architectures."
"Getting on top of those things is really the only way they can do their business planning and understand how they are positioning themselves in relation to competitors and their own future."
The realisation of an information strategy requires the definition of a consistent architectural framework within which individual projects are conceived, justified, built and deployed. In addition, a comprehensive architectural framework must consider application, technical, network and implementation architectures.
Walsh says before starting such a project you have to know what your total application architecture is, and you have to trace all the linkages down to the systems with which you need to interface.
In the case of Mercantile Mutual that meant managing more than 100 interfaces to existing nonWeb-enabled systems.
"To manage those, you have to know everything about them, and you often discover that although practical use of them died five years ago, for some reason you're still maintaining that interface in the existing system," Walsh says. "This is your chance to rationalise them."
By itself it is not enough just to understand fully the existing architecture. You also have to fully understand the intended architecture of the final application - well before development starts. This makes it possible to logically divide up the project into distinct - and hence more manageable - components.
"That way you can address, say, the middleware component one way; you can address the back-end systems upgrades another way; you can address the front end another way and you can address peripheral applications in yet another way," Walsh says.
He has spent the last 16 years specialising in outsourcing, best practice and the design of strategic business systems, and has also designed commercial software products in credit management, workflow management and communications.
All of that experience was put to good use when he became project director for NAB's move to provide a retail banking facility over the Internet in mid-1997, featuring digital certificate technology to protect customer accounts online.
Walsh says NAB, a "fairly conservative bank" when it came to retail Internet banking, was following the Australia Bank, St George, Westpac, the Commonwealth Bank of Australia and the ANZ into the retail online world. The project took just over 12 months to go from initiation to the first fully working prototype, with a further 12 months spent marketing the program. Indeed, it wasn't until May 1999 that NAB became the last of the big four banks to launch an Internet banking service for retail customers.
Although three of the four big banks entered into retail Internet banking before NAB, Walsh says with technology moving so fast, there was little NAB could draw from existing models before its own development started.
"And I think this is a salient point: that technology has been moving so fast over the last two or three years it is difficult to find an existing model or existing software framework that can be used. And that's especially true since some of the software platforms and technology are still emerging, and things like Web servers and the use of XML are becoming important technologies to use effectively in this environment."
When Walsh arrived at NAB, the bank had a strategic alliance with an outsourcer who was meant to deliver NAB's Web platform. This included the ability to provide security, volume, support, the ability to deliver modern flexible software components, a language and fundamental application design.
"They were the things we were looking for," Walsh says, "because the thing that you know in this business is that whatever you're doing today is going to be obsolete by the time you get it in."
So when the outsourcer ran into difficulties in rolling out the proposed platform in Australia, Walsh went to an RFT and eventually selected a European company to handle the front-end delivery.
In the overall project, the Web front end for NAB - as indeed for Mercantile Mutual - eventually accounted for somewhere between one-quarter and one-third of the overall project cost.
So with that side of things under way, Walsh turned his attention to the more critical back end. He found not only was there need to significantly upgrade batch-oriented product administration systems in order to provide 24x7 service, but also a need to eliminate inconsistencies between products.
"For instance, in some products you could get access to one month's worth of details, while in others you could get three month's worth of details. When it comes to e-commerce it's not unusual to get all kinds of tricky little business-type service discontinuities in your back-end product systems," he says.
Here he learnt another critical lesson for e-commerce projects in general: that in such cases, where various product administration systems are dispersed across various organisational structures, the project manager needs real moral authority in order to address those discontinuities.
That means it is "absolutely essential" to have the strong endorsement of executive management, since your moral authority comes from being able to quote the managing director or whoever.
From there addressing inconsistencies across applications entails communication, communication, communication, he says.
"You have to keep talking to them and you have to keep reminding them that at a certain time in the development of your project, they will be required to budget in some resources and do some work on their system.
"Sometimes - especially with old systems where you might have a year's backlog or an existing schedule of 12 to 18 months of changes - you have to intersperse your requirements into the change-management scheme along with other projects because you are often not the only project on the block."
At Mercantile Mutual, the company is building its Web-enabled distribution management capability under a strategic partnership with Australian software company Mynd, as one component of its AllFinanz Solution. This consists of building a flexible system from the ground up to provide a shell to sit on top of the many different systems already in place within leading financial organisations.
AllFinanz is designed to pull data from virtually every insurance and financial services management system currently in use and integrate it into a Web-based front end to support advanced applications such as data analysis and customer care.
Walsh says integrating Mercantile Mutual's business systems across a number of platforms - including Hewlett-Packard MPE, VMS and Windows NT - has become critically important as the organisation undergoes its current phase of fundamental business change.
"Mercantile Mutual had a relatively old system, but needed to grow to meet the challenges of the changing legislation in the Australian marketplace," he says. "We also recognised that new ways of doing business over the Internet were just over the horizon. The old platform was robust, but wouldn't have enabled the company to do that. Fortunately, Mynd was building a package that largely met our specifications, which meant we could manage our software risk at least."
Mercantile Mutual is now testing and developing the Mynd Allfinanz Enterprise Agency module in conjunction with Mynd and will eventually use it to provide a single, consistent interface to systems handling life insurance, superannuation, risk management and investment products.
The architecture of the solution has been deliberately made highly configurable so the package can potentially be implemented in numerous different business solutions.
"All of the legacy systems will make a transition over time, which is why the interfacing architecture is key. If you get the plugs between systems right, you can change either end of them without disrupting your business."
To carry over the lessons learnt at NAB and help the organisation better understand the architecture of the final application, Walsh developed one core team of people who fully understood e-commerce architectures and another that fully understood the business vision.
Walsh says for many e-commerce projects, broad consultation on the way the new business will operate will often be fairly limited since most people will still be thinking in terms of the old capability and will have limited understanding of the potential capability of the new platform.
"To overcome that difficulty, you have to find out who really has the vision of where the organisation is going and what they want to do with this platform. Are they trying to address new markets? What are the competitive threats? You have to operate at that broad strategic level in building that new platform because in an e-commerce platform, you really have to think very broadly and creatively.
"The vision is generally not held with one person. You have to identify all the stakeholders and facilitate a collective vision as to what you want to do. A lot of Mercantile business is directed towards providing a high level of service to one of the best financial planning networks in the country. This industry jealously guards that network and the industry runs on the ability to service those financial planner and agent networks effectively because they're the ones that are talking to the customers and have the ultimate dollars."
Once again, the only way the business could come to terms with making investment decisions involving a move into e-business was to first comprehensively understand both the vision and the architecture.
Walsh says for Mercantile Mutual, as for many other organisations, the move into e-commerce means a shift from an environment where computer systems were attended by trained employees to a system which will be attended by strangers and important customers who are untrained. That demands entirely new ways of thinking about the business process side of the project.
"You need to think about issues like: Who can do what? What can we let them do? What sort of services, information and transactional services can we deliver over this new platform directly to the customer, rather than going through various internal layers of control and attendance internally in the organisation?"
However, he says project managers also need to be sensitive to the political exposure within an organisation, particularly during one of the organisation's first forays into the e-commerce arena.
To help manage that exposure, Walsh publishes a monthly communiqué on the intranet - also posted on notice boards around the organisation - to help people discover what the e-commerce group is doing and the directions in which it is heading. Walsh says this can be an extremely useful way to help manage people's expectations of the work.
Meanwhile, there have been other useful lessons from his e-commerce experience. One is that when it comes to transforming a 15-year-old system and a 15-year-old data structure into a more modern object-oriented type structure, you should never underestimate the size of the conversion task.
That goes for the size of the reporting tasks also.
"People seem to think that when you're moving into online systems reports are trivial. Reports are still an essential component of the delivery of a system. In my case, doing the reporting side is about 15 per cent of my total budget and probably a bit more in terms of time."
It should probably go without saying that every e-commerce project should be undertaken with a keen eye on potential future e-commerce projects, particularly since the first phase of the project usually involves simply replacing the existing system with a modern platform.
Walsh warns all project managers with e-commerce work on their plates to be constantly aware of the "hammer principal": the notion that if you give a child a hammer, everything needs hammering. Translated to the e-commerce world, the hammer principal suggests that as people in the businesses start to realise the potential for talking directly to customers on the Web, the current scope of the initial e-commerce project is going to start to strike them as limited in the extreme. Suddenly they will all be inventing new products and services using the new platform.
The more aware people become of the potential for e-commerce the more likely they are to adopt it as their tool. Project managers had better be aware of that right from the start, Walsh says.
"And as you progress through this project, suddenly you'll find there are dependencies on you that emerge through the project that were not anticipated under the name of new business initiatives. Suddenly, if you don't deliver on the time that you said you were going to deliver, you're going to put back probably two or three other projects that are going to have to be rescheduled around your delivery date.
"So you have to continue to manage those organisation-wide impacts," Walsh says.
You also need to build a lot of technical infrastructure to support e-commerce applications, especially around security and authentication of your customers. That demands organisations know much more about their customers than many do at present.
Therefore, put in a generalised security structure from the start rather than wait until many e-commerce projects are under way. "It's all about future-proofing," Walsh says.
On the subject of technical infrastructure, Walsh points out that with e-commerce applications commonly distributed over a network, error management and incident management become very difficult.
"You have to pay a lot of attention to your operational support areas and how well that is set up. Are you capturing your errors? Do you know what they are? Have you got appropriate processes in place to address errors as and when they occur?"
Finally, communicate the risks as well as the gains as widely as possible, and for your own sake be completely honest about it, Walsh advises.
"You have to have open understandings on the risk profile of projects, and you can't just say: This is a risky project', you have to say what the risk is.
"And get everybody involved in it. Engaging the organisation as widely as possible in the discussion of risk and the strategy agreed is important, as is always telling the truth.
"If you don't know something just say: I don't know'. You are obliged to create a number in terms of estimates of cost and schedule, but you should always put a risk factor on that as well in terms of plus or minus. I'm very confident on this one but I have a low degree of confidence on another component'. That kind of honesty is the only way to go."