IT Architecture & Design
In the Department of Defense (DoD) environment, a competitive edge that leads to a completed goal is defined as victory. Within an IT/IA Architecture, any competitive edge should translate into higher levels of customer satisfaction, shorten process work cycles; and in assisted reductions in schedules, lower maintenance costs, and development time; all resulting in lower total ownership costs (TOC).
Key Architectural Issues
WITS believes the driving factors to identifying the key architectural issues requiring resolution, and the interrelationships of those issues, is knowledge of the working parts already in place and the ability to envision how any existing network will need to be enhanced, redesigned, or overhauled to conform with new mandates for key architectural improvements. WITS brings a vast wealth of detailed knowledge, skills sets, and experience in the IT Architecture and Design areas.
Beyond this existing base of knowledge, your provider’s approach must be vendor neutral and protocol agnostic. Yet the team must have a broad knowledge of prevailing technologies and close industry contacts across most of the major IT and IA manufacturers. WITS is that team. WITS has cleared experts certified in major manufacturer’s gear such as Cisco, Marconi, Nortel, CheckPoint, RIT Technologies, Siemens, HP, Dell, and others. We have contacts within these organizations that we can use for valuable background information on upcoming R&D and soon to be made end of life decisions. We bring industry certifications such as PMP, RCDD, CISSP and CCIE to the table.
We suggest that the Architecture Roadmap should be the key facilitating ingredient providing a dashboard view and mechanism for enabling the design and development as well as the communication and understanding of the enterprise. The goal fo the Architecture Roadmap will be to manage the complexity of the enterprise, align business strategies and implementations, and facilitate rapid change in order to maintain business and technical advantages.
Our standard approach to maintaining Architecture Guiding Principles is:
- Build with a purpose in mind
- Be as simple and straightforward as possible
- Facilitate, not impede, communication among shore-based and deployed war fighters
- Should be relatable and comparable across NMCI
- Should be modular, reusable, and decomposable
To get to the architecture roadmap, WITS will document Enterprise Architecture as an organized collection of information in three divisions: driving strategies, baseline, and the transition plan. Our driving strategies depict goals and objectives and show the way forward, indicating where the enterprise needs to go based on business drivers, policies, rules and regulations, and advancing technology. This will lead to the “To Be” environment which will be detailed in the Architecture Roadmap. The baseline will be the “As Is” Enterprise Architecture using any existing documentation to extrapolate information describing the current position in terms of organizations, business processes, information, applications, and technologies.
The transition plan will be a set of initiatives within a timeline to sustain and maintain the Enterprise Architecture while accomplishing the strategic missions of the enterprise and transition from the “As-Is” to the “To Be” environment.
Absent from most technical assessments are the business, financial, and technical analyses of alternatives – information needed to drive architectural decisions. How do we answer the questions of why one approach or technology was selected over another? Most significantly, how do we illustrate sound business reasons for our decisions? In short, given the method of Enterprise Architecture development in terms of strategies (“To Be”), baseline (“As Is”), and transition plan, the Technical Director will need mechanisms and work products to capture the trade-offs, analyses of alternatives, business metrics, financial considerations, and returns on investment to support architectural decision-making. Our approach to this task will include the necessary focus on business, financial, and investment criteria necessary to evaluate and prioritize the transition and modernization plans. This will provide a solid business foundation and rationale of why changes need to be made. This approach addresses the issues of metrics, risks, and best value.
The Business Case focus addresses the rationale for investing the time and resources into making the necessary changes to transform the current “As Is” to the targeted “To Be” Enterprise Architecture. The Business Case starts with the strategies, goals, and objectives regarding how the improvements fit into the enterprise, and why they are significant. The Business Case also defines the all-important financial rationale measured in dollars and captured as the return on investment (ROI) and break-even time (BET).
The investment decision focus provides a mechanism to perform an analysis of cost versus benefit to drive the decision-making process. All alternatives are viewed with regard to costs as compared with benefits. Typical considerations for cost include business process impacts, development method, integration issues, and education needs. Similarly, benefits may include increased capabilities, reduced costs, and productivity improvements.
The Risk Analysis focus provides a vehicle to identify and analyze risk. Risk is viewed with regard to the probability of occurrence and impact on occurrence. WITS calls this Security Engineering. We believe this term more closely describes the required overlapping of traditional IT and IA functions needed for a complete Architectural Road Map. The WITS Security Engineering Team will position our client’s to profit through emerging technologies and their applications. The WITS Team is visionary in its preparation and is practical in its execution. We accomplish this using the appropriate DITSCAP C-2 SSAA, DIACAP, GAO, and NIAP standards and/or Operationally Critical Threat Asset, and Vulnerability Evaluation ™ (OCTAVE ™) methodologies. There are three major tenets to Information Security (InfoSec): Confidentiality, Integrity, and Availability (C.I.A.). All of the Information Security controls and safeguards, and all of the threats, vulnerabilities, and security processes are subject to the C.I.A. yardstick.
Figure 3: The C.I.A. Triad
The primary objective of security controls is to reduce the effects of security threats and vulnerabilities to a level that is tolerable by an organization. This involves determining the impact a threat may have on an organization, and the likelihood a threat may occur. The process that analyzes the threat scenario and produces a representative value of the estimated potential loss is a Risk Analysis. The main purpose of performing a Risk Analysis is to quantify the impact of these potential threats and to put a price or value on the cost of lost business functionality.
Next is the Value vs. Risk focus. This focus provides the next step in selecting the best alternatives by providing a feedback loop to the Investment Decision focus, now comparing the best-value candidates (lowest cost/highest benefits) on the basis of risk. Risk considerations include technology maturity, numbers of interfaces, mission criticality, business process maturity, change management, and training issues.
The final focus area is the Balanced Scorecard (BSC), originally introduced by Robert S. Kaplan and David P. Norton “Translating Strategy into Action: The Balanced Scorecard” Cambridge: Harvard Business School Press, Sept. 1996. This is used by WITS to provide a common standard model to manage the business and the Enterprise Architecture. The strength of the BSC is its combination of leading (operational) and lagging (financial) indicators as well as the alignment of various enterprise capabilities. We will use the BSC to integrate various aspects of the Enterprise Architecture using a set of key performance indicators (KPI). We believe the selection of an appropriate set of KPI is critical. The KPI should map to key business metrics, i.e., the specific measures that will drive the Architecture Roadmap. Examples of these types of metrics include time to process a claim for the insurance industry and errors per source line of code for the software industry. It is critical to identify and document the appropriate metrics to use for each aspect of the BSC. These metrics become the basis for confirming improvements such as TCO, ROI, and other aspects of the business case.