Prototype - As a Design Guideline

"A picture can replace a thousand words; a prototype can save you lots of meetings and possibly avoid a project failure."

A prototype is a dynamic view of the system, while a requirements documents and design documents create a static view. It is the same with blueprints; they are a static model. A small-scale model is a dynamic view. Using a dynamic view, you can see things in action; you can add another dimension to the design phase: the time dimension.

The most important benefit of using prototypes is that it helps promote communication with the client, project managers and other developers.

Prototypes help in tracking the requirements back and forth. They ensure that you implement what is needed, no more and no less.

Building Blocks of Design

There are three high level elements that are considered for design:

• Patterns
  A pattern is a specification for addressing a common problem in solution design. Patterns are not algorithms, they are higher level and more broadly applicable. Adopting a widely accepted pattern as part of solution design can help us address not only the problem we recognize, but also the related problems we may not recognize on first glance.

• Frameworks
  Occasionally, you may find targeted reference implementations of patterns that may be useful, and they are often in the form of a framework. In classic object-oriented design, a framework is a set of abstract classes to be incorporated into and reused as part of a software application. The current thinking is that a framework also may be a set of abstract data constructs, rules, or processes. A framework is different from a pattern in that a framework is something real that can be incorporated into and used as a foundational element of your solution—it is commonly the implementation of a pattern or specification.
  A framework provides guidance beyond that of a pattern, and typically provides deployable elements that can be used as the foundation for your solution. The more well- understood the framework, the easier it will be for an organization to support it over time.

• Components
  Components are encapsulated elements of a system (hardware, software, network, etc.) and are by definition not case-specific. Components can be wrapped into your solution seamlessly, or can be managed as separate entities, regardless of deployment environment. Incorporating well-understood components into your solution definition can save time in delivery and increase the quality of your solution, but components may have associated support costs that can be considerable.
  Most components can be satisfactorily configured to meet our needs without any custom work. Incorporating a component and customizing it beyond the standard configuration is risky—you should understand the cost associated with supporting it going forward, and the risk of losing vendor-provided support.

Enterprise Architecture

The definition of an architecture used in ANSI/IEEE Std 1471-2000 is: "the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."

An enterprise architecture (EA) is a conceptual tool that assists organizations with the understanding of their own structure and the way they work. It provides a map of the enterprise and is a route planner for business and technology change.

Normally an enterprise architecture takes the form of a comprehensive set of cohesive models that describe the structure and the functions of an enterprise. Important uses of it are in systematic IT planning and architecting, and in enhanced decision making.

The individual models in an EA are arranged in a logical manner, and this provides an ever-increasing level of detail about the enterprise, including:

• Its objectives and goals.
• Its processes and organization.
• Its systems and data.
• The technology used.

Software Architecture

Software Architecture can be defined in terms of building blocks and software components. These building blocks are software components, frameworks, IDE’s, SDK’s, and Commercial off the shelf (COTS) packages.

The primary role of a Software Architect is to choose the components, integrate the ones that can be incorporated, and lead the team in creating custom supporting code to link the components in times where there are no obvious connectors from one component to another and build something that will benefit the business.