Sources of input to the framework

Where do we get the data points necessary to make informed architectural decisions? There are four key sources that will shape our understanding of the business problem: functional requirements, non-functional requirements, derived requirements, and organizational direction.

Functional requirements

The functional requirements of a solution dictate what the resulting system should be able to do and include scenarios that summarize the user's expected experience with the system. Functional requirements could address the type of data entities the system interacts with, how the system behaves when a user needs to invoke a particular calculation, or the order of steps to complete a business process. Functional requirements are typically gathered by a business analyst and are crucial in determining how a system should be architected. A software solution is worthless if it is architected beautifully but does not meet the business need. Staying focused on our client needs will ensure that we build a practical and architecturally responsible solution.

In order to ensure that our functional requirements help and do not hurt our effort to architect a solution, we must remain diligent and not allow system requirements to masquerade as business requirements. For instance, if we see a business requirement that says that customer profile information from System A should be copied via file transfer every night to System B, then that should raise a red flag. That business requirement is dictating system design and does not answer what the business need actually is. The proper business requirement would be "The system shall enable users of System B to view up-to-date customer information originating from System A". As architects, we can choose multiple implementation solutions (for example: shared database, data transfer, real time lookups) that can both satisfy that requirement and fit into the overall design patterns we have laid out for the project. While there may be relevant reasons for technical requirements (for example, security constraints) to get included as functional requirements, often these technical requirements are better stated as non-functional requirements.

Non-functional requirements

Wikipedia describes non-functional requirements in this way:

A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions.

http://en.wikipedia.org/wiki/Non-functional_requirements as on 10/2009.

So unlike functional requirements, which dictate system behavior, non-functional requirements stay focused on how the system needs to operate. There are multiple dimensions to look at when evaluating system operations including maintainability, security, compliance, availability, and exception management. A business or system analyst typically uses a pre-defined list of questions to interview stakeholders and identify non-functional requirements. Questions such as "How many users will the system support?", "What is the sensitivity of the data stored by the system?", "What are the regular hours of operation for the system?", "What is the acceptable latency of a user request?", and "What are the disaster recovery expectations?", will all provide insight into how to best architect our solution. It should be noted, however, that it is often the responsibility of the analyst to translate the sometimes technical, non-functional requirements into more business-relevant questions. For instance, I would not ask my client to spell out their explicit disaster recovery needs (for example recovery point objective, recovery time objective, site configurations), but rather, I would focus on questions addressing business continuity and backup procedures and extract the disaster recovery needs from their answers.

Derived requirements

We sometimes forget about the requirements that are not explicitly stated but can be uncovered through the functional and non-functional requirements. Derived requirements are implied requirements and do not come directly from our users. These are the things that go unstated (or even forgotten about), yet still belong in the registry of requirements for the solution. For instance, we may receive functional requirements that state a need to capture key data points and progress indicators during each stage of a long-running workflow process. While no reporting interface was requested by the users, we realize after reading this requirement that the users will need some way to visualize the progress of a given workflow and thus we see a derived requirement for a report. Or we have a business requirement dictating that the solution run on mobile devices but no indication of the required phone platforms, so we may derive the platform requirement based on the types of phones issued by our company. Once we identify the derived requirements, we can assess them with appropriate stakeholders and use them as yet another input to our decision making.

Organization direction

Last, but not least, we need to take broader organizational goals into account when capturing solution attributes that drive architecture. Project architecture decisions should not be made in a vacuum. While I may be able to flip a coin to decide between two perfectly viable ways to expose a web service interface for a given project, I should always be considering enterprise standards and practices when making my selections.

For instance, you may work for a company which has a strict "build instead of buy" strategy for software because of the high caliber of on-staff developers and a consistent need to deeply customize any commercial product. If that is the case, I may have a soft requirement to choose the framework technology over the more rigid commercial product.

Solution decisions also must take into account the short term and long term investments of an organization. Am I basing my solution on a technology that is under consideration for deprecation? Do we have the staff on hand with expertise in a particular product? These are valid considerations that can sway us from a seemingly ideal technology to an alternate choice.