Mainstream Technologies Principle 19
IT solutions should use government- and industry-proven mainstream tech- nologies.
䡲 Rationale: By using mainstream technologies, the organization avoids dependence on weak vendors, reduces risk, ensures robust product support, and enables greater use of commercial-off-the-shelf solutions.
148 Building A Global Information Assurance Program
䡲 Conceptual design: The organization will need to establish criteria for vendor selection and performance measurement. The organization will also need to establish criteria to identify weak vendors and poor technology solutions. This effort requires migration away from existing weak products in the adopted technology portfolio.
Industry Standards Principle 20
Priority will be given to products adhering to industry standards and open architecture.
䡲 Rationale: Adherence to industry standards avoids dependence on weak vendors, reduces risks, ensures robust product support, enables greater use of commercial-off-the-shelf solutions, and allows for flexibility and adaptability in product replacement.
䡲 Conceptual design: Demanding such adherence, unfortunately, requires a culture shift in thinking. The organization will need to establish criteria to identify standards and the products using them, and to determine how it will transition to this mode.
Disaster Recovery/Business Continuity Principle 21
An assessment of business recovery requirements is mandatory when acquir- ing, developing, enhancing, or outsourcing systems. Based on that assessment, appropriate disaster recovery and business continuity planning, design, and testing must take place.
䡲 Rationale: Due to factors such as the explosion of Internet usage by hackers, upsurge in virus attacks, the Year 2000 (Y2K) problem, and recent terrorist activities, customers and partners have a heightened awareness of systems availability. The pressure to maintain availability will increase in importance. Any significant visible loss of system stability could negatively impact the organization’s image. The contin- uation of any business activities without the use of IT is becoming nearly impossible. Application systems and data are becoming increas- ingly valuable assets that must be protected.
䡲 Conceptual design: Systems will need to be categorized according to business recovery needs (e.g., business critical, noncritical, not required). Alternate computing capabilities need to be in place and systems should be designed with fault tolerance and recovery in mind.
Plans for work site recovery will need to be in place, which makes organizational costs higher.
A corporatewide, secure backbone network that provides a virtual, company- wide intra-network must be implemented.
䡲 Rationale: Networks are the essential enabling technology for client/
server, Internet, and collaborative computing. This is the basis of the anywhere-anytime, seamless access that is a major goal of the organi- zation. There is an increasing need for access to information across the global network, and the lack of a robust network architecture will impact the success of distributed applications. This expands the vision of the organization by reaching out to customers and suppliers.
䡲 Conceptual design: The organization will need to implement a robust, unified directory services capability. This requires higher-speed and higher-bandwidth networks and an interconnection of distributed LANs.
The organization will also need to create connections from legacy systems to client/server and Internet applications.
Scalability Principle 23
The underlying technology infrastructure and applications must be scalable in size, capacity, and functionality to meet changing business and technical requirements.
䡲 Rationale: Scalability reduces total cost of ownership by reducing the amount of application and platform changes needed to respond to increasing or decreasing demand on the system. It also encourages reuse and leverages the continuing decline in hardware costs.
䡲 Conceptual design: Scalability must be reviewed for both “top down”
and “bottom up” capability. This may increase initial costs of develop- ment and deployment and will reduce some solution choices, but will pay substantial dividends as the system matures and grows.
Concluding Remarks
Can this multitude of Conceptual Architecture Design Principles be further reduced to an acceptable level of globally interoperable constructs? The authors believe so. There are five overall recommendations that can be proposed:
1. Compile and use a common lexicon/taxonomy. This does not sound like a particularly difficult task, but it is. Organizations can lay claim to having their own (officially or unofficially), but they all use slightly
150 Building A Global Information Assurance Program
different terminologies with varying connotations. The interoperability problem is tough enough if we can communicate; it is nearly impossible if everyone is speaking a different language.
2. Define architecture development, definition, maintenance, and inter- face standards. This includes a myriad of efforts such as unifying guidance, terms of reference, common models and simulations, hard- ware interfaces, software interfaces, data standards, representation stan- dards, etc.
3. Standardize a well-defined, automated architecture process to simplify the evolution of architectures while adding a certain amount of rigor, reproducibility, and confidence to the process. We have constructed a high-level example. Congress and the President dictate the National Strategy based on their national goals and objectives, national interests, and some perceived threats. For the military and intelligence agencies, this translates into a set of missions and mission requirements. Mission requirements, in turn, drive the functional requirements or the func- tional architecture of our fighting forces and members of the various intelligence agencies. This same construct can be standardized in the commercial world as well. Unfortunately, commercial organizations cannot afford to start from scratch. All existing organizations have a physical set of legacy systems that forms the basis upon which they must build. If the functional capabilities of the physical systems that exist today are compared with where the organization wants to be functionally, the organization will, no doubt, find some areas where it has an overabundance of capabilities and others where it is lacking.
From these shortfalls and overlaps, an organization can formulate several options that will get it where it wants to go. Then an organization will pick one (based on some set of criteria such as cost, schedule, importance, etc.). The courses that each organization chooses get folded into its long-range plan. The plan is used to generate Program Objec- tives that eventually provide new systems or enhanced capabilities to the operational side of the business. These new systems then become part of the physical architecture and the cycle starts over. Do not forget that each organization needs the user’s input from the very beginning and throughout the process.
4. A commitment to interoperability on the part of organizations and individuals, backed up by accountability through a strong report card for compliance, is needed as part of the existing performance evaluation system. Acquisition Managers/Acquisition Authorities must be evaluated on meeting all of their requirements including interoperability and information assurance. It appears that these measures are beginning to be graded at the operational level and they are receiving more attention than ever before, but it is an important issue that bears emphasis.
5. An overall architect must be assigned at the very highest levels of the organization and embodied with the responsibility and authority that ensures compliance with the organization’s architecture concepts. How- ever, this assumes that an organization has a concept. Interoperability
office of Chief Information Officer (CIO), it seems that it is very difficult to exercise sufficient control in all of the necessary areas. Clearly, many organizations continue to need a different paradigm.
This page intentionally left blank
153