Service Oriented Architecture (SOA) Design Specifications

Xcelligent believes developing robust SOA design specifications begin with a vision statement (including a high level conceptual design) created and validated with your stakeholders. Its purpose is to drive ambiguity out of the planning process and understand the boundaries of each component interface. The specification (recommend using the generally accepted 4 +1 views approach for architectural specifications) is used to frame the non-functional, technical implementation as planned. This is a key input into your detailed planning and will drive the development of the product (PBS), organization (OBS), and work breakdown (WBS) structures to understand and communicate the true scope and size of this effort.

This specification will serve as a map to the overall architecture of the systems under development.  This product can be organized using a 4 plus 1 approach providing 4 views, plus testing scenarios developed from Use Cases.  The four views are Logical, Process, Development, and Physical. 

The four primary views are defined as:

• Logical – the functional requirements of the system as seen by the user.
• Process – the non–functional requirements of the system described as abilities.
• Development – organization of the software components and the teams that assemble them.
• Physical – the system’s infrastructure and components that make use of this infrastructure.

The plus 1 is defined as the scenarios (or UML based Use Cases) that describe the sequence of actions between the system and its environment or between the internal objects involved in a particular execution of the system. The architecture is documented (independent of the functional business requirements) to provide shared insight into the overall design solution. 

Using the generally accepted “four plus one” method to describe the solution is a good way to communicate the intent of the project teams to be used as:

• A vehicle for communicating the system’s design to interested stakeholders at each stage of its evolution.
• A basis for performing up-front analysis to validate (or uncover deficiencies in) architectural design decisions and refine or alter those decisions where necessary.
• A significant artifact used to achieve system understanding.