Information Is Power Principle 1
Information is power. Information in and of itself is valued as an asset, which must be shared to enhance and accelerate decision making and at the same time protected from those who do not have a “need-to-know.”
䡲 Rationale: In the global information assurance program, decision mak- ing requires information beyond the traditional borders of a system or company or even government agency. The efficiency and effectiveness of the delivery services must be enhanced, enabling new systemwide, companywide or agencywide solutions across multiple systems, com- panies, or government agencies. Today, most information is in isolated pockets such that the value of information is not always recognized.
However, treating the information as a business asset increases its integrity and the relevance of the information.
䡲 Conceptual design: Policies pertaining to information ownership must be developed. The value of the information must be identified, authenticated, and leveraged. To do so will require a unified information management approach. There will also be an ancillary requirement to establish sup- porting policies for security, privacy, confidentiality, and information shar- ing. Finally, data needs to be structured for easy access and management.
Exhibit 2 Poor Operational Design
The planning and management of a corporatewide architecture emanating from the organization must be unified and have a planned evolution that is governed across the organization.
䡲 Rationale: Without a unified approach, there will be multiple and possibly conflicting architectures. Common sense tells us that good change requires collaboration and collective planning. Any architecture must be well thought out, and governance over the architecture must be simplified.
䡲 Conceptual design: A unified approach will require a change in cultural attributes. Normal evolution will require prioritization and reprioritization across all organizational and IT initiatives. While dependencies must be maintained, the architecture must be continually reexamined and refreshed. Short-term results vs. long-term impact must be constantly considered and everyone needs to understand that establishing the architecture takes time and involves a considerable amount of change.
Architecture Compliance Principle 3
Architecture support and review structures must be employed to ensure that the integrity of the architecture is maintained as systems and infrastructure are acquired, developed, and enhanced.
䡲 Rationale: To realize the benefits of a standards-based architecture, all IT investments must ensure compliance with the established IT archi- tecture. For maximum impact, the review of standards should begin as early in the solution planning process as possible.
䡲 Conceptual design: A structured project-level review process will be needed to ensure that information systems comply with the IT archi- tecture and related standards. Processes incorporating the principles of this architecture must be developed for all application procurement, development, design, and management activities. This compliance pro- cess must allow for the introduction of new technology and standards, and conceptual architecture principles should be used as evaluation criteria for purchasing as well as developing software.
Leverage Global Data Warehouses Principle 4
Data warehouses must be secured and at the same time leveraged to facilitate the sharing of existing information to accelerate and improve decision making at all levels.
140 Building A Global Information Assurance Program
䡲 Rationale: Data can be replicated and combined from multiple systems, companies or government agencies without changing the originating systems or developing new systems. Lately, reduced business cycle times have led to a need for faster access to ever-increasing quantities of information. There is a significant burden on programmers to gen- erate reports, data queries, and statistical information on the data itself.
Data warehouses and their associated end-user tools make it possible to relieve this burden by placing the responsibility on end users.
Therefore, warehouses fulfill the need for internally consistent data.
䡲 Conceptual design: Data warehousing must become a core competency of IT. Data warehouses become types of configuration standards that need to be developed and maintained. End-user tools must be provided and the users themselves will have to become more knowledgeable about information and the tools that they use to access and analyze it.
The processes and procedures for data extraction, “cleansing,” and the loading of warehouses will require high levels of reliability and integrity.
Ensure Security, Confidentiality, and Privacy Principle 5
The organization and its IT systems must be designed and implemented in strict adherence to all security, confidentiality, and privacy policies, as well as applicable international, federal, state, and local statutes.
䡲 Rationale: Adhering to such statutes helps safeguard confidential and proprietary information that, in turn, enhances public trust. This also establishes the proper ownership of public information and helps to ensure the integrity of the information.
䡲 Conceptual design: Applicable policies must be identified, published, and kept current and at the same time monitored for compliance. The requirements for security, confidentiality, and privacy must be made clear to everyone. Education on issues of privacy and confidentiality must become a routine part of normal business processes.
Reduce Integration Complexity Principle 6
The architecture must reduce integration complexity to the greatest extent possible.
䡲 Rationale: Reducing integration complexity increases the ability of the company or agency to adapt and change while also minimizing product and support costs.
䡲 Conceptual design: Such reduction will decrease the proliferation of vendors, products, and configurations in any given organizational envi- ronment, although some vendor-supplied components will be required
make a determination of the wording “to the greatest extent possible”
in this principle to determine if it includes consideration of how reducing complexity can negatively impact providing critical client services.
Reuse Before Buying, Buy Before Building Principle 7
The reuse of existing applications, systems, and infrastructure must be consid- ered before investing in new solutions. Only those applications or systems that provide clear business advantages and demonstrable cost savings will be built.
䡲 Rationale: The use and availability of effective packaged solutions is increasing. Using tested solutions reduces risks and the total cost of ownership.
䡲 Conceptual design: Software license agreements and system develop- ment contracts should be written to allow for reuse across systems, even at the global level, barring encryption problems. The definition of “reusable” will include solutions available from other industry and government entities (e.g., other corporations, states, federal government agencies, etc.). Areas that provide clear advantages and business case cost savings are likely to require quick adaptation. Each organization must identify the areas in which it is seeking to distinguish itself.
Integration Principle 8
Systems must be designed, acquired, developed, or enhanced such that data and processes can be shared and integrated across the global reach of the organization and with other corporate or government partners.
䡲 Rationale: There is always a need to increase efficiency while better serving customers (e.g., the public, agencies, etc.). Although redundant systems cause higher support costs, we are assured of more accurate information, with a more-familiar look and feel. The bottom line is that integration leads to better decision making and accountability.
䡲 Conceptual design: The IT staff will need to consider the impacts on their wide-scale systems when designing applications. They will require new tools and training for their proper use. They will certainly need a method for identifying data and processes to be integrated, when inte- gration should take place, which processes should have access to the data, and cost justification for integration. An overall “architect” will be needed who can maintain and arbitrate a common set of domain tables,
142 Building A Global Information Assurance Program
data definitions, and processes across the organization. At the same time, apply the KISS principle (keep it simple, stupid), i.e., over-integration can lead to difficult data management and inefficient processes.
Reengineer First Principle 9
New information systems must be implemented after business processes have been analyzed, simplified, or otherwise redesigned, as appropriate.
䡲 Rationale: There is no real “value” in applying technology to old, inefficient legacy processes. Work processes will need to be more streamlined, efficient, and cost effective, and as such, work processes, activities, and associated business rules must be well understood and documented. This reduces the total cost of ownership.
䡲 Conceptual design: The organization must establish an agreed upon business reengineering process and new technology must be applied in conjunction with the business process reviews. It will be understood by all participants that business processes must be optimized to align with business drivers and additional time and resources will have to be invested in analysis early in the system’s life cycle. Organizational change may be required to implement reengineered work processes due to regulatory or legislative change.
Total Cost of Ownership Principle 10
A total cost of ownership (TCO) model for applications and technologies must be adopted, and it must balance the costs of development, support, disaster recovery, and retirement against the costs of flexibility, scalability, ease of use, and reduction of integration complexity.
䡲 Rationale: Consideration of all costs associated with a system over its entire life span will result in significantly more cost-effective system choices. This effort enables improved planning and budget decision making, reduces the IT skills required for support of obsolete systems or old standards, simplifies the IT environment, and leads to higher- quality solutions.
䡲 Conceptual design: The organization’s budget process needs to accom- modate TCO of a system over a longer timeframe than current budgeting models allow. Unfortunately, this does not work well within the annual budget cycles of the U.S. government and many large corporations.
Accommodating TCO will require looking closely at technical and user training costs, especially when making platform or major software upgrades during the lifetime of the system. This effort requires designers and developers to take a systems engineering approach that may
Minimize Platform Configurations Principle 11
A small number of consistent configurations for deployment across the orga- nization must be created.
䡲 Rationale: Reducing uniqueness in product selection and standardiza- tion of installed components reduces support and maintenance costs, and simplifies training and skills transfer.
䡲 Conceptual design: Initial capital investment will increase and must be planned. The applications must be deployed on uniformly configured servers. The organization must also plan to replace multiple, nonstand- ard configurations with a small number of consistent configurations, as well as plan for the regular replacement of platform components to ensure the retirement of obsolete and unique configurations.
Basic Information Services Principle 12
A standardized set of basic information services (e.g., e-mail, voice mail, user training) must be provided to all employees.
䡲 Rationale: Providing basic information services increases productivity;
reduces costs of maintenance; provides the basis for international, state, local, or regional business initiatives; and provides for organizationwide access to information.
䡲 Conceptual design: The “Basic Services” definition must to be created and regularly reviewed. This may increase “one-time” costs to upgrade to the minimum service level and to provide training to all users of basic services, but should reduce overall cost and complexity in the long haul.
Technology Design Considerations
Shared Components Using an n-tier Model Principle 13
Applications, systems, and infrastructure will employ reusable components across the organization, using an n-tier model. The term n-tier refers to the various levels of responsibility in a system’s design; the “n” can be any number from two and up. For example, a very common design is the three-tier model in which the application is divided into three distinct tiers of responsibility:
144 Building A Global Information Assurance Program
the user interface, the business logic, and the database. Each of these tiers can be implemented using one or more objects that are dedicated to the responsibilities of that tier.
䡲 User interface: The user interface tier would contain all of the visual aspects of the system. This tier handles anything that involves interaction with the system user. All dialogs, message boxes, forms, reports, and other user-interaction components resides in the user-interface tier of the system.
䡲 Business logic: The business logic layer fills the responsibility of deter- mining where the data comes from and how it should be formatted for the user interface. It also applies any constraint rules on the data coming from the user interface before posting the data to the system database. The business logic tier does not have user-interface compo- nents as it has no responsibility to interact with the user. Problems sensed with the data should be communicated to the user interface layer through return values from methods or procedures while the user interface tier displays these messages to the user.
䡲 Database management: The database is responsible for handling the domain constraints on the data and for updating and retrieving the data in the tables. The rules in the database should be restricted to only those that are a direct implementation of the domain constraints.
“Business rules” are not part of the database rules; instead they are enforced in the business logic tier.
Three-tier is not the only n-tier design, although many practitioners and theorists advocate it. Andrew P. Sage used the same three-tiered concept to explain Decision Support Systems (DSS) and labeled them Dialogue Genera- tion and Management System (DGMS) (the user interface), Model Base Man- agement System (MBMS) (business logic), and Data Base Management System (DBMS) (data management) [Sage, 1995]. Some of the things that might be considered for additional tiers are operating system interface, network inter- face, and multiple levels of business logic tiers. For example, one might design a system for a bank where the business logic object for an account needs to have various different formats, depending on which department of the bank is using the data. In this case, we may have one business logic object for
“account” that is generic across the entire bank, and others that are specific to particular departments, each using the generic account object and adding or restricting features based on the department’s requirements.
The advantages of n-tier system design include:
䡲 The business logic, or any other tier for that matter, may be modified without making changes to either the user interface or the database or any other tier.
䡲 If built correctly, the business logic object can be used by multiple user interfaces and databases.
䡲 It isolates the knowledge, processes, and procedures required in any given tier to that tier.
䡲 The memory footprint of the application is likely to increase.
With these disadvantages, why would someone want to build an n-tier system? The answer is a single word: scalability (see Principle 23). The n-tier design can scale up to extremely large systems without compromise. By “large,”
we are referring to the number of users, the number of differing user-interface and business-logic components, the size of the database, the structure of the network, and a variety of other size and complexity issues.
Using the n-tier design, one can design a system that will handle multiple divergent user interfaces without requiring a rewrite of the business logic for each interface built. The business logic can be shared by multiple user interfaces. Through subclassing, the business logic classes can be customized to handle different database servers. While n-tier design is not right for every project, it is an extremely powerful design approach.
䡲 Rationale: Changes can be made to a component of a system, such as changing from a Windows client to a Web browser client, without changing the rest of the system. This enables simplification of the environment and geographical independence of servers. N-tier design takes advantage of modular off-the-shelf components and the life-cycle approach in reuse will show lower costs and lower maintenance efforts.
This allows for leveraging skills across the organization.
䡲 Conceptual design: Component management must become a core com- petency. This requires developing a culture of modularity and reuse and at the same time ensures that reusable components are platform independent. The Information Analysis Center will need to understand that physical configuration standards must be established, and with that, design reviews become crucial. Application systems must be highly modularized without making components too small or too simple to do useful “work.”
Logical Partitioning and Boundaries Principle 14
The logical design of application systems and databases should be highly partitioned. These partitions must have logical boundaries established, and the logical boundaries must not be violated.
䡲 Rationale: A change in a database or application can potentially affect many large programs if they are not highly partitioned. The organization cannot separate the components in a system from each other without creating logical boundaries. One will need to understand that recoding leads to time-consuming retesting, and that partitioning isolates and
146 Building A Global Information Assurance Program
minimizes change impact. Partitioned code is more adaptive to changes in internal logic, platforms, and structures.
䡲 Conceptual design: Applications need to be divided into coded entities or modules (e.g., presentation, process, and data access). For databases, there will be a need to develop competency in partitioning horizontally and vertically that will result in more but simpler tables. This may require sacrificing data normalization for simplicity and optimization.
Design reviews must ensure logical boundaries are kept intact.
Message-Based Interfaces Principle 15
The interfaces between separate application systems must be message-based;
this applies to both internal and external systems.
䡲 Rationale: The use of messaging is important for enforcing the archi- tecture principle of logical partitioning and boundaries. This enables rapid response in maintenance and enhancement activities as required by changes in business processes. Messaging technology simplifies integration efforts and allows for transparency in locations, databases, and data structures.
䡲 Conceptual design: The implementation of a messaging infrastructure will be necessary. In designing the roles and responsibilities of the organization’s staff, one will find that trust, or letting go of control, is often the most difficult aspect among IT staff when messaging is introduced into the IT culture. During this process, common messaging formats, IDs, and standards must be established and developers must learn how to use messaging. Overall, the organization will also notice an increase in network traffic.
Event-Driven Systems Principle 16
Application systems that are driven by business events must be the only systems deployed.
䡲 Rationale: Deploying only event-driven systems enables applications to adapt quickly to changes in business processes by changing only the application component related to the changed business event. This strengthens linkages to the business by mirroring the actual business environment. It is easier to realign IT when change occurs.
䡲 Conceptual design: This will require systemic thinking as event-based processing crosses traditional system boundaries. The business pro- cesses need to be optimized to obtain full benefits, and the organization will need to retrain developers to incorporate business concepts in software development methods.