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 3^rd party component take a safe path. Identify the elements of your solution that will rely on the 3^rd 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 3^rd 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 3^rd party component plays. If a 3^rd 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

Revisiting the definition of software architecture

When was the last time you thought about the definition of a software architecture? It has been quite some time since I read the definitions posted on the SEI’s Community Software Architecture Definitions page. Some interesting definitions:

Eoin Woods (Software Architect, Investment Bank, London, UK): Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.

Adu Matthaeus (Systems Architect, Eikon, Centurion South Africa): A configurable skeleton of any kind of software beast on which you hang implementation specific muscle to make it live.

Jeff Winter (Software Engineer): … Architecture is necessarily a series of abstractions, depicting details relevant to one perspective while suppressing details relevant to other perspectives, and therefore expressed as a series of complimentary views. To say what those views are, you must embrace some ones method or make up your own.

Steve Wright (Consultant - Sr. Data Architect, Knowledge Management, Boston, MA): Architecture is the set of decisions that must be made at the enterprise level before specific applications are designed and built in order to provide conceptual integrity and sanity across the enterprise’s systems. Architecture includes a decomposition of the systems into separate orthogonal viewpoints along with the enforced rules that enable this clean decomposition and isolation of design viewpoints. This is done so functional (application requirements) and non-functional (system qualities) and other aspects of the application system may be defined and built by independent specialists in their specific field. An architecture not only divides the system, it also divides the roles and responsibilities of those who work with the system into separate organizational concerns and disciplines that are conceptually tractable and can be effectively managed.

Balakrishnan Thiruvadi (Technical Manager, HTC Global Services, Chennai, India): It is an art of defining, implementing, maintaining system and software environments that will assist and grow with business requirements.

Tim Simmons (Student, Southern Adventist University, Nashville TN USA): The architecture of a software system is its very essence. It is not merely a schematic showing interconnected components, but a description of those components and the way in which they interact. It is the foundation upon which the entire system is built.

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

Software Architecture Discipline Splits

We dreamed about the software architecture discipline becoming a mature discipline similar to the way civil engineering has evolved over time. To a certain degree this has become true: a unique set of skills is not required to develop a basic accounting back-office suite or a large scale eCommerce site. Banal solutions are reproducible by anyone with basic software design knowledge. This is good, because seasoned architects are now reaching out to solve more challenging problems.

Up until now software architects were doing two jobs under the same title: mature software engineer and mature software designer. [Note that the word 'mature' is used over 'senior' since age does not equate to seniority or ability to design complex solutions.] The software architecture discipline will eventually split into those who concentrate on the art of the discipline and those who specialize in the science of the discipline. This is inevitable due to the ever-growing complexity of responsibilities a person with a software architect title.

All software architects need to have experience from the trenches (working on serious projects in the real world) doing programming, design, and experience in all other parts of the SDLC experience. However, the architects concentrating on the 'art' aspects of the discipline will find themselves spending more time understanding and eliciting the business problem and conceptualizing the solution. The architects concentrating on the 'science' aspects of the discipline will provide cross-check the concept and provide insight on concrete implementation options. The soft side of the architecture discipline will deal with the human aspects, while the hard side of the architecture will address technical aspects.

The need for further concentration by means of splitting architecture responsibilities into soft and hard sides comes from increased demand from the business users to develop solution that solve a business problem, as well as the need to deal with the continuously growing complexity of implementations and overflow of new technologies and tools.

Firebrand on duty: Constantin K.