5.1. Technology Adoption
Before undertaking the CORE project, AT&T Unisource hadn't used the Java programming language on a full-scale production system. Most system development had relied on Microsoft and Delphi component technologies on the back end with Visual Basic for client-tier development. Typical architectures used either simple client-server or three-tier models. Business logic was concentrated heavily in either the client or the database tier, with little or no logic in the component tier.
Though projects had been successfully completed, management felt that the existing development model wasn't working well. Code reuse, scalability, failover support, and development productivity all needed to be improved to keep pace with telecommunication developments and trends. In short, the company felt it needed to improve its ability to deliver robust solutions in “Internet time.” At the same time, the IT department was spending increasing time building and maintaining frameworks, an undertaking often complicated when initial creators of the frameworks moved on to new projects. Among the technologies that were repeatedly built into such frameworks were naming services, session-tracking mechanisms, persistence management, and transaction management. At the time, such services were just beginning to be made available through application servers implementing the J2EE specification. The specialized nature of these technologies often meant that the quality of the framework implementations wasn't always optimal, since infrastructure building was not the main business of the development team.
When the CORE project was proposed to the IT department, the first thought was that this would be the time to look for a general solution to these issues. The initial proposal was to build the CORE system using proprietary technologies. However, this didn't seem workable, since it would make it difficult to meet the various system requirements. There was also significant skepticism about the ambitious project timing—which, in any case, wouldn't deliver the application in time to meet the business requirements of the organization.
To address these concerns, the organization brought in a specialist in enterprise component development to assist in making a transition to newer technologies, and to act as architect and mentor to the development teams. The architect hired was a contractor, with no connection to either the company or to any specific tools vendor. On joining the team, the architect set down some ground rules for developing the solution. Though some of these rules may seem simplistic, contradictory, or amusing, they proved very useful to the team. The ground rules were:
Standardize. The architect proposed basing the system on established and emerging industry standards with the support and backing of more than one vendor. The standards at that time included the Java programming language; C++ and other languages; component technologies, such as CORBA and Enterprise JavaBeans; and other technical standards, such as XML. When selecting an implementation, the architect recommended giving preference to vendors that provided compliance to specifications and broad support of as many related standards as possible.
Use Best-of-Breed Tools. Tool selection would be based on the technical merit and effective integration with other tools. Some total-package solutions provided by vendors were seen to have significant weaknesses as end-to-end solutions. The alternative approach was to select the best available tools for each task, and to be sure that their conformance to standards enabled them to be used together effectively. Tool selection also took into account potential vendor lock-in that could result from tools that used proprietary application frameworks or produced proprietary code tags.
Take a User-Centric Approach. The system needed to be easily tailored to user needs, not shaped by the requirements of some hyped-up technology. The required systems had to be delivered to end users on time and had to effectively integrate into their workflow. The user interface technology also had to allow for new workflows that hadn't been possible with earlier technologies, due to their inherent restrictions.
These user interface design requirements suggested the need for an object-oriented approach that would be intuitive, simple, consistent, complete, extensible, and responsive. Every effort would be made to balance system processing between the client and server, while concealing the distributed nature of the system from the end user. It was also clear that the user interface needed to accommodate different user backgrounds and levels of experience. To meet all these goals, users were to be involved in the design process from the outset, not subjected to prolonged, painful, and frustrating usability issues that result from not gathering user feedback early and often.
Aim to Do Nothing. For system infrastructure, the goal was to avoid any development work at all. Delivering the CORE system was the main goal, rather than building a naming service, transaction service, persistence-mapping engine, or any other system infrastructure.
To this end, all development efforts were to be focused on delivering added value to end users. The reference architecture from the CORE system was a deliverable to the IT department. The architecture and its implementation had to provide inherent scalability, reliability, robustness, and performance. The view of the company and team echoed that of industry analyst Anne Thomas, who referred to IT departments that attempt to build their own application servers as “those who practice self-abuse.”
Partner with Vendors. The vendor for each tool involved in developing the CORE application had to demonstrate that it understood the need to be partners in the undertaking. The project was very ambitious, with no time to wait on slow communications regarding support. Where new technologies were being applied, senior members from the vendor's development team needed to be available on short notice to discuss usage, standards compliance, potential features and enhancements, product direction, bug fixes, and other critical path issues.