When it comes to IS projects, diverse systems are the enemy of flexibility and cost control. If departments and geographically dispersed offices go their own ways, IS budgets soar. Increasingly, information executives, consultants and technicians look upon controlling and fortifying the internal logic of an enterprise's IT architecture as the best means to make consistent the hodgepodge of software and hardware found in most corporations. But the creation of an enterprise IT architecture has among its goals more than keeping the budget at less-than-astronomical magnitudes; nor is it an exercise in re-engineering, knowledge management, out-of-the-box thinking or any other particularly trendy management approach. Because effective enterprise IT architectures connect decentralised organisations where decision making and accountability are scattered, such an architecture can be accomplished only by solid planning, project management and vendor negotiations.
When Giga Information Group set out to create a three-tiered analysis of companies engaged in enterprise architectural development, we studied 10 companies, six for general purposes, three in-depth and one as the basis for a detailed case study. All the companies we studied have annual revenues greater than $1.4 billion. We chose companies with geographically dispersed functions such as sales and customer service because that kind of company requires large, complex IS infrastructures. We were also interested in companies that had frequent interactions with their customers. With those prerequisites, most of the companies we studied had to be in financial services.
Enterprise IT architecture is a far-reaching concept that comprises the vision, principles and standards that govern the acquisition and deployment of technology. As such, it provides the foundation for detailed data, application and network architectures. An enterprise IT architecture is a key component of a mature IS organisation that enables alignment with business goals, consistent processes and best practices in software reuse. Furthermore, it is an effective tool for reaching Levels 2 and 3 of the Software Engineering Institute's Capability Maturity Model, the standard five-stage metric of an IT shop's competencies. At Level 2, an IT shop is able to repeat tasks it is given; at Level 3, a shop's overall organisational mission is defined.
Unfortunately, many enterprise architecture efforts become stalled or cancelled because the primary target of expectation setting is senior management, who, given the history of large project failure, want immediate results. Enterprise architecture efforts are expensive, and significant quantitative benefits will not be realised until well into the later phases of the implementation effort.
However, if the project manager focuses on benefits that can be realised quickly and on setting realistic expectations among co-workers, benefits that support the business case for a dramatic change in enterprise architecture can be realised and the effort can be sustained.
Most successful architecture implementations occur in four overlapping phases: planning, initial migration, major application migration and post-migration (see "Re-architecting: A Case Study", page 38). The subject of our case study, a financial services company, has a 7500-person user base, 500-person IT department, one primary IT location, multiple, small satellite offices and a CIO who has direct reporting relationships with all IT personnel. Its infrastructure consists of IBM mainframes, four e-mail systems, four primary DBMSs, Novell file servers and Microsoft Windows NT application servers. Also, numerous packages exist for accounts payable, customer and inventory tracking, and other functions.
Planning: During this phase, the organisation develops a business case for the enterprise IT architecture rollout, defines principles of action and technology standards, and plans the timing of future transitions. Phase 1 also identifies "quick hit" opportunities -- principles and standards that could be implemented rapidly and would result in immediate, visible benefits.
During the planning phase, IT managers from the case study company created an IT inventory, articulated a business case for the architecture project including an implementation plan that comprised deliverables, milestones, resources required, schedules and costs -- and formed a working architecture implementation team. Business and IS representatives had agreed on several key principles by which the project would go forward, and they viewed that new spirit of collaboration to be a tremendous achievement because until then cross-divisional relationships were occasionally antagonistic. For example, they agreed to have only one IT product per business category. In practice, they settled on a corporate standard of Microsoft Office with Microsoft Exchange for e-mail, a standard that implied that business units would have to migrate from Lotus Notes, Lotus 1-2-3 and other products. The principle would yield long-term benefits for purchasing and supplying support, but the business and IS reps understood that settling on a standard would yield little value in the near term.
Initial Migration: During Phase 2, the company migrated to the "quick hit" standards identified in Phase 1. The implementation team negotiated contracts, deployed software and hardware, and established support services such as training and help desks. Since any new systems will put employees at the bottom of a learning curve, there were, in addition, nonquantifiable costs for customer service and productivity degradation because of personnel's lack of familiarity with new tools and processes.
During Phase 2, the enterprise IT architecture implementation team convinced the organisation that the business case for the rollout was valid and that funding and participation should be broadened. In our case study, the CIO understood that IS's lack of credibility in delivering large projects on time and within budget required some near-term results that demonstrated the value of an architecture. Without this, commitment by participants and business units could be lost. To counteract that possibility, the CIO created a business case that clearly identified tangible near-term benefits. As part of the interior salesmanship for the project, as an example, he pointed out that PC standardisation would save $100,000 annually through greater purchasing power from a single vendor.
Major Application Migration: For most organisations, the focus for this phase is on moving nonstandard production systems such as enterprise software packages, DBMSs and systems development tools to standard ones. The costs of this phase are the highest and most situation-specific. However, in general, the cost components will include labour for management, development, support, training and deployment. Expenses will also include hardware and software for servers, applications and networks as well as consulting fees because new skills are needed quickly.
In our case study company, quantification was difficult because it was impossible to separate expenses for architecture from expenses for year 2000 fixes. But during this phase, the company realised greater quantifiable benefits by consolidating servers and, because of added purchasing power with a single vendor, eliminating or reducing licences and maintenance agreements. For example, fixing on Oracle as a standard eliminated the need for Informix but brought significant one-time development and deployment costs. The company also eliminated or reduced support costs for products being phased out.
Nevertheless, the $4 million migration costs of this phase greatly exceeded the benefits.
Post Migration: In this phase, costs are primarily labour-oriented, associated with maintaining the architecture when companies purchase consulting and/or advisory help to supplement internal expertise. Typically, with the job done, the benefits of Phase 4 dwarf those costs.
The benefits of Phase 3 expand during this phase: Hardware consolidation makes volume purchasing discounts possible; reductions in labour and technical support allow staff reductions because of a simplified infrastructure. The company can now use automated tools for network monitoring, software distribution, virus protection and other tasks made simple by standardisation.
In addition, having a simpler, more predictable technical infrastructure reduces the cost of developing new systems and the risk of new product deployments, development and daily troubleshooting. For example, at the financial company we studied, DBMS performance for the single Oracle data warehouse has become easier to anticipate because expertise is not needed for systems that no longer exist at that company -- Microsoft's SQL Server, IBM's DB2 and Sybase's Adaptive Server. Other cost benefits are realised because of faster tool selection, reuse of software modules, data interoperability, best practices knowledge databases, tighter network security and simpler administration of systems. An additional expected benefit is reduced employee turnover because of greater application of cross-training. With fewer systems to manage, more people are available to cross-train on those systems. Training on new systems is for many IT workers a strong incentive to keep their resumes in the desk drawers rather than in the mail.
Of course, the phases and corresponding benefits will not necessarily be identical for all companies that overhaul their enterprise IT architectures.
However, most companies can apply a mixture of the following tactical and strategic recommendations: - Combine technical and financial planning. Project funding decisions cannot be made without considering the effect on the enterprise architecture. People involved in the development and maintenance of an architecture must also be involved in financial planning.
- Be opportunistic. Year 2000 urgency, for example, should be exploited to persuade other executives to implement an enterprisewide IT architecture initiative. Centralising purchasing as a point of control is another selling point for establishing an architectural initiative.
- Establish baselines. An assessment of an IS organisation should emphasise components that can be objectively measured because performance metrics provide both a focus for IS management attention as well as a report card for the organisation at large. There is an axiom that the perceived value of a service diminishes exponentially after the service is rendered. That phenomenon can derail any initiative.
- Reorganise the work and the people to save money. The simplification that comes with standards will reduce the amount of necessary labour. Some savings will come from eliminating jobs, others from redeploying key employees. Since most IS people have multiple responsibilities, work assignments must be clustered around the people who will remain, and their job descriptions and incentives must be rewritten to reflect their new responsibilities.
- Implement "quick hits" and promote the long-term benefits of the project. A business case should include whatever near-term benefits can be realised. Great effort should be made in reaching these goals, which should then be publicised as hard evidence that the business case is valid.
The leader of an enterprise IT architecture initiative should be a facilitator, an evangelist and a project manager. The CIO should be continually and visibly involved in every phase of the project, although once at Phase 4 smart managers will delegate regular maintenance responsibilities.
- Use enterprise resource planning software (ERP) and other products as infrastructure building blocks. ERP products such as SAP and building blocks such as the Involv Host platform from Changepoint provide packaged functionality that implements standard processes and tools as part of their deployment.
Client/server, re-engineering, the Web and other technologies or IT initiatives have dramatically increased the number of components that IS must support.
Distributed organisational structures that arose out of the need to improve business alignment have made coordination and leverage nearly impossible.
Finally, the industry's recent emphasis on measurement of costs, risk management and benefits of IS have unearthed the fact that IS has a larger influence on the bottom line than previously believed.
Marc Cecere is director of IT management at Giga Information Group Inc. He can be reached at: firstname.lastname@example.org
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.