New York, N.Y., April 4, 1995 – Unmanaged decentralized systems development can result in an enterprise structure that resembles an overgrown and tangled thicket. This sort of organic systems development happens gradually over the years at banks and other firms that regularly manage large volumes of data. First, someone installs a front office system in, say, the fixed income department. Then the internal systems group designs a trading system for the municipal bond desk. Later someone on the fixed income deck buys a custom module to handle exotics instruments that the front office system cannot handle. The result is a tangled "growth" of systems that tend to be expensive, inefficient, and encourage duplication of effort.
Surprisingly, though, the solution to this creeping complexity is not its polar opposite, the single vendor system. A single vendor system concentrates expertise outside your company and thus creates another type of risk: What if your vendor goes out of business or your customer support liaison gets hit by the proverbial bus?
The best possible alternative in our experience, especially for large institutions, is to create a system architecture that will allow greater coordination and control while providing the flexibility to rapidly update functionality in-house. A serviceable systems architecture is part vision, part process and part technology.
Here are eight steps that briefly outline how such an architecture can be established at any firm:

Building Blocks
1. Develop a coherent organizational vision: It is critical that the top managers formulate a firm-wide vision or overarching goal that provides a theme for system development and supports the firm’s core business objective. For example, "The system should help the firm become the customer service bank." Without an organizational vision, there is no "theme" around which development efforts can cluster. As a result, internal "fiefdoms" may vie with each other for priority and make sometimes-contradictory demands.

2. Make sure all the various corporate constituents buy into the vision: This is particularly important for managers who are moving from a completely decentralized systems-setup to a more controlled, firm-wide architecture. Although it is critical to ensure that development guidelines are consistent with a larger vision, department heads must be consulted in a meaningful way. In particular, department heads should be able to contribute a "wish" list and a "must have" list that should be taken into consideration as the architecture takes shape. Furthermore, they should be consulted regularly as "consumers" of the architecture, and they should have ample opportunity to point out bugs, inefficiencies or procedural problems.

3. Assemble an in-house team to coordinate systems development: The company must have a coherent systems development process in place to address departmental development needs in an efficient, coordinated fashion. The process should be coordinated by an internal "shadow-team" that mirrors the makeup of the firm in miniature. It may include representatives from the systems department, the back office, trading desks, as well as staff members hired specifically to develop the new system. The team should liaise with all different system "consumers," provide support, manage vendor relations and call upon outside expertise as necessary. In addition, this team should be the "keepers of the vision," ensuring consistency in development throughout the company.

4. Utilize outside expertise as needed: Banks are typically experts in finance, but they may not be experts in developing software, buying hardware or shopping for the right database. Although many banks have dedicated systems departments, in house systems personnel are often so over-burdened by everything from maintaining local area networks to maintaining legacy systems that they may not have the time to dedicate to the "big picture." In-house systems staff are often open to accusations of attempting to secure "goodies" or extra funding for their department. Outside consultants, by contrast, may be able to provide more objective recommendations.

5. Conduct a firm-wide systems inventory: Once a crack coordination team has been assembled and a consultant has been hired for the project, it is important to take an inventory of all existing software packages in each department. In particular, it is essential to identify mission critical systems as distinct from those that are peripheral and rarely used.

6. Invest in hardware suited to your needs: Hardware capacity, database platforms and programming development tools should be equal to the task at hand. A firm-wide hardware inventory should be taken, which will form the bases for answering the following questions: What condition is our hardware in? Do we have sufficient "horsepower" to meet our processing needs? Will our current hardware setup be adequate two or five years from now? Are there up-to-date operating and database platforms and development tools readily available for our hardware setup? In many cases, a total overhaul is not required. It may only be necessary to redistribute existing hardware and then make strategic upgrades.

7. Consider object- oriented technology: For large, rapidly changing organizations in which market timing is everything (i.e., large banks involved in the derivatives markets), object-oriented technology can be en effective tool. The company can maintain a "library" of programming solutions, and they can be recombined or updated as necessary. An object-oriented development environment is particularly useful when technology must be developed quickly to support a new, emerging business. A comprehensive library of code that is updated and well documented can also reduce duplication of effort.

8. Utilize in-house systems staff: Once an architecture has been developed, it’s important to make sure the coordination team and the in-house systems department are able to support the new architecture and applications without resorting to expensive outside services. Several people should be conversant enough with the architecture and systems issues to prevent the over-dependence on "one essential guy who knows everything." If you have a solid architecture, no one is indispensable.
By following these steps, the enterprise system architecture can be untangled and simplified, providing more functionality and flexibility for all users. The exercise of building a coherent architecture offers the added benefits of clarifying and prioritizing applications, especially those that are mission-critical to the business, and allocating technology resources for maximum productivity. The result is a more effective team operation, supported by more efficient systems.

TechHackers, based in New York City, builds customized financial software, specializing in the areas of securities trading and portfolio management. Address: 5 Hanover Square, 2nd Floor, New York, NY 10004; Phone: 1-908-598-1460; Fax: 1-908-522-8955.