Architecting With 3rd Party Components: "Trust, but verify"

A proverb: “Trust, but verify” should always resonate in software architect’s mind when a decision is made to use a component that the architect does not directly control. This component may be a COTS software piece or an enterprise library developed by someone else. This becomes especially important if that component is part of the project’s critical path (e.g. a communication infrastructure component).

For example, the enterprise may require every solution to use component Foo to obtain a security token. Or the enterprise may require component Bar to be invoked to pass through messages so that certain information can be collected for enterprise auditing purposes.

Unless you have previous experience architecting with that 3rd party component take a safe path. Identify the elements of your solution that will rely on the 3rd party component. Then thoroughly analyze the external component for each quality attribute requirement that is associated with the software architecture element that uses that component. If the documented performance, security, availability, and other quality attributes match the needs of your architecture proceed with caution.

Think about mitigation strategies (alternative implementation tactics) in case the 3rd party component does not live up to the promised expectations. For example, can auditing functionality be done as a batch mode instead of real time? Can an alternative protocol be used for issuing security tokens?

As the implementation commences inspect the properties of the promised quality attributes with the intensity that is equal to the role that the 3rd party component plays. If a 3rd party component is part of the critical path of a project conduct intense quality attribute related tests prior to committing your architecture to it.

For designing with COTS software see this article.

Remember: “Trust, but verify”

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Comments

Popular posts from this blog

Why we do agile

Quality Attribute Refinement