When building a system or buying a COTS solution, it is critical to ensure that the underlying system architecture will support the intended mission both now and into the future.
How can you be certain that the vendor’s proposed architecture will meet your Organization’s needs? After all, the right choice will lead to a successful system and the wrong one may lead to a disaster that you are stuck with for years.
In the past, Organizations have been challenged by overly complex architectures based on:
- Expensive and nascent third-party products
- Incomplete or immature frameworks
- Leading edge components that were a poor fit
The right architecture must be vision and business driven, agile and flexible, supportable, cost-effective, and satisfies all requirements. Read on for suggestions on understanding system architecture and determining if a proposed architecture is a good fit for your Organization.
Click Procurement Examples for system shall statements.
Defining architecture types
A System Architecture is a blueprint which systematically and completely defines the organization of a system in terms of its components and the relationships among them. System architecture communicates the structure of a system without discussing the implementation details.
A software solution’s foundation is based on its architecture. No amount of fine-tuning will compensate for a poorly architected system.
A Security Architecture provides guidance on an organization’s security policies and is closely integrated with other technical architectures. It describes the security services and components employed to reduce business risks.
There are other types of architecture such as Enterprise Architecture, Business Architecture, Data Architecture, and Technical Architecture. This post only focuses on System and Security architectures.
Benefits from evaluating a vendor’s proposed software architecture
The main benefit of architecture evaluation is that it uncovers design decisions that may be problematic later on in the project. Other benefits include:
- Highlights alignment, or lack there of, with your Organization’s technology strategy
- Communicates the complexity of a large system prior to purchase
- Identifies design strengths, weaknesses, and tradeoffs
- Highlights the strategic use of emerging technologies
- Expedites integration with existing and new systems in the portfolio
- Ensures legal and regulatory compliance
Question to build understanding
Since so much is riding on the vendor’s proposed software architecture, it is best to evaluate the architecture as early as possible to ensure it satisfies all project requirements. A software architecture that is not aligned with your Organization’s technology strategy may result is issues down the road that will be expensive to fix in the future.
Here are some questions to ask the vendors. Be sure to discuss this with your IT leadership to make sure it addresses all of their concerns.
- Does the software support service-oriented architecture (SOA)?
- Does it operate on industry standard hardware, operating systems, and relational database management systems?
- Does the architecture minimize development time?
- Is the architecture proven?
- Is the system highly scalable and designed to accommodate future growth?
- Does the architecture include functional integration?
- Is the architecture configurable allowing for programming free?
- How is the information architecture defined and managed?
- What architecture artifacts does the vendor require from Organization?
Procurement Examples
Here’s some sample text to consider for your acquisition document:
System Architecture
The System must be multi-layered with clearly defined architectural layers and interfaces between the layers. At a minimum, the presentation, business, and data layers must be separated.
The System must be designed with loosely-coupled architectural layers so that changes in one layers are isolated from the other layers.
The System must include a modular application architecture with reusable interaction patterns. The architecture must be n-tier, incorporating the design of both logical and physical abstraction layers.
The System shall use a modular architecture to support customizations as appropriate.
The System shall provide a modular architecture that allows for the Organization to add its own custom components as appropriate.
The Offeror must fully describe their application architecture including the rationale for why it was designed that way.
The System shall use technologies, standards and methodologies in its system architecture that are based on current industry best practices.
The System architecture shall minimize total cost of ownership, including third party products. The architecture shall avoid proprietary vendor lock-in.
The System architecture shall promote component substitution.
The Offeror shall provide a high-level view of the design philosophy and architecture views addressing the following topics: functions, key system abstractions, domain elements along with their dependencies, data flow, and interfaces.
The System shall meet Federal and state system and software architecture standards.
The System shall be built on a scalable platform with a flexible architecture based on common technical standards to support process improvements and system integration requirements.
The Offeror shall provide the logical and physical architecture of their System.
The System shall provide for the capability to create new system interfaces using the established application architecture.
The Offeror must include a draft version of a System Design Document; their solution’s logical, technical-level architecture; and an inventory of all third-party software and hardware products including version number with their proposal.
The Offeror must describe their solution’s architecture including, but not limited to, operating systems, database management system, software development language, hardware specifications, web servers, reporting environment and tools, and other technical specifications. Describe the solution’s target technical environment specifications including its framework; scalability; and performance metrics. Show evidence that all security infrastructure protection layers are isolated from application layers and components in such a way that compromised application components may not bypass or compromise security infrastructure protection layers or other application layers (i.e., n-tier architecture, defense-in-depth).
- Address what other UI solutions or modules share a common platform and are integrated with the UI solution.
- Address how the solution eliminates the need to support multiple technology applications and platforms.
The Offeror must provide a high-level architecture diagram, including logical and physical components.
The System shall use technologies, standards and methodologies in its system architecture that are based on current industry best practices and in accordance with the core objectives of the System: stability, sustainability, affordability, configurability, and maintainability.
The System’s architecture shall minimize total cost of ownership, including third-party products. The architecture shall be designed to avoid proprietary vendor lock-in.
The architecture shall promote component substitution.
The architecture shall maximize the solution’s sharing of computing and software resources to the practical extent feasible, minimally implementing:
- A shared network and infrastructure
- A “common core” application solution that has mechanisms to promote the cost-effective reuse on a repeated basis
- A common core application for which when a change is made the modification is only designed and coded once and tested once
- Three separate distinct instances of the production System to allow for operational independence
The architecture shall be developed using Object Oriented Development (OOD) best practices including interfaces, design patterns, and other OOD principles.
The architecture shall be interoperable between the various modules using documented standards (e.g., web services and representational state transfer (REST)) and be consistent between all modules for maximum reuse and extensibility.
The architecture shall employ a reusable common core for business processes and logic core with an interface approach that promotes “plug and play” for other COTS solutions as they become available. Products of this nature shall integrate seamlessly with the other modules of the System. The focus is on reusability and integration.
The architecture shall be built in a logical, modular fashion, with modules supporting discrete functions. Each module may require its own configuration, so requirements shall be carefully considered when modularizing.
Security Architecture
The System shall meet all Federal and state security standards and guidelines.
The System architecture shall employ a secure network environment.
The System security architecture shall provide controls for accessing business functionality.
The Offeror must include a detailed network/server diagram illustrating their solution’s relative architecture with their proposal. It must include:
- Network security zones and firewalls
- Server types and network components (e.g., switches)
- Ports and protocols used to cross security zones
- Description of how users will access the system
- Clustering of servers
The Contractor shall define and document the system’s security architecture, security policies, risk assessments, and security tests in a System Security Document
Final Thoughts
This topic is so important it warrants its own facilitated session with your Chief Architect, Data Architect, Chief Information Security Officer (CISO), and others. The procurement examples are just a starting point. Tailor the requirements to address your specific needs and make sure the next system has been designed to align with the growth strategy of your Organization.
