Service Design Document (SDD)

Document: Service Design Document (SDD)

Project : <Project Name>
Version : 0.1
Status : Draft
 Solution Design Document

Document Information
This document is available in two forms, controlled and uncontrolled. The controlled variant is maintained electronically and
accessed by authorized persons of Client IT Document Library/Intranet. Uncontrolled variants are all other electronic and printed
copies.

Title
Author
File Ref.
Document Location
Document
1.0
Template version

Approval Sign-off (For formal issue)

Accountable Owner Signature Name Date Version
Project Sponsor
Approver Signature Name Date Version
Head of Technology
and Architecture

Enterprise Architect

Project/Programme
manager

Revision History
Version Status Date Author / Editor Details of Change

The latest approved version of this document supersedes all other versions, upon receipt of the latest approved version all other
versions should be destroyed, unless specifically stated that previous version (s) are to remain extant. If any doubt, please contact
the document Author.

Page 2 of 13
 Solution Design Document

TABLE OF CONTENTS
1 DOCUMENT CONTROL ........................................................................................................................................................ 5
1.1 DISTRIBUTION LIST ................................................................................................................................................................... 5
1.2 REFERENCES............................................................................................................................................................................ 5
1.3 PURPOSE ................................................................................................................................................................................ 5
1.4 TERMINOLOGY......................................................................................................................................................................... 5
2 PURPOSE & BACKGROUND ................................................................................................................................................. 7
2.1 COMPONENT DESCRIPTION ........................................................................................................................................................ 7
2.2 DESIGN ASSUMPTIONS .............................................................................................................................................................. 8
2.3 DESIGN DEPENDENCIES ............................................................................................................................................................. 8
2.4 DESIGN CONSTRAINTS............................................................................................................................................................... 8
2.5 DESIGN DECISIONS ................................................................................................................................................................... 9
3 COMPONENT DECOMPOSITION ........................................................................................................................................ 10
3.1 COMPONENT DETAILS ............................................................................................................................................................. 10
4 LOW LEVEL DESIGN ........................................................................................................................................................... 11
4.1 WMB COMPONENTS SPECIFICATIONS ............................................................................................ERROR! BOOKMARK NOT DEFINED.
4.1.1 <Flow 1> ........................................................................................................................ Error! Bookmark not defined.
5 DESIGN DISPENSATIONS ................................................................................................. ERROR! BOOKMARK NOT DEFINED.

Page 3 of 13
 Solution Design Document

Table of Figures

Figure 1 xxxx current design ............................................................................................................. Error! Bookmark not defined.

Page 4 of 13
 Solution Design Document

1 Document Control

1.1 Distribution List

Name Organisation Role Email

1.2 References
Include all the documents which have been referenced within this document. For example, HLD, requirements, design guidelines,
Client policies, LLDs of other components etc.

Ref Document Author Status Version

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

1.3 Purpose
Include the purpose of this SDD, in the context of key solution design deliverables within a project or programme. The SDD
represents the design of a service.
Text in green is guidance on how to complete this document and should be deleted prior to submission.

1.4 Terminology
Note – This section should be the delta between what is already defined in the Client Business Glossary, High Level Design and
new project definitions

Page 5 of 13
 Solution Design Document

Term Definition

Page 6 of 13
 Solution Design Document

2 Service Purpose & Background

This section should provide high level description of the service and its associated information. More specific guidelines are
provided in each sub-section.

2.1 Service Description

This section should provide high level functional summary of the service which should contain following:
 Purpose of the service
 Functional context of the service

2.2 Interface Technical Summary

Criteria
Criteria Answer/Comment
Met (Y/N)

1. Are multiple Portfolio Apps involved? No. Y

(Yes/No)

2. Consumer (s) Name Y

3. Provider (s) Name Y

4. Portfolio Interface Style (Batch, Req/Res, Asynchronous Req/Res Y

etc.

5. Is the Data Mapping Complete, including Yes, refer to mapping section for details Y
identification of fields requiring
translation? (Yes/No)

6. Peak Volume per each time the interface 10K per day (size of record 1400 bytes) Y
runs (# of records)

7. Global peak volume per each time the 1 Y

interface runs (# of records)

8. Yearly Global Peak Volume (# of 100K Y

records)

9. Frequency of runs (per day/week/month Daily Y

or on demand etc)

10. Message type Text Y

11. Portfolio Protocol (MQ, DB, FTP, Web sFTP Y

services, etc.)

12. Portfolio message wire format (text, Text Y

XML, BAPI/IDoc, etc.)

13. Call to external apps needed? No Y

14. Look up tables involved? No Y

15. Dependent configuration available in No Y

the development system?

Page 7 of 13
 Solution Design Document

16. Acceptance criteria including test No Y

scenarios and unit test cases are clearly
documented?

17. Unit test data is available or a date for No Y

the availability of the data is agreed upon
during the review?

18. Have recovery / error handling Yes Y

processes been identified?

19. Is initial data load needed? No Y

2.3 Design Assumptions

Design assumptions form the basis for design of any system. This section should include the assumptions which have been
considered while designing this service. They may be derived from business requirements, architectural principles, project
timelines etc. However, they should be relevant and closer to this particular service.
Please note that if any of the assumptions are invalidated, it may impact the design of the service.

Ref Design Assumption

DAS001

DAS002

DAS003

2.4 Design Dependencies

These dependencies impact the sanity of the service design. If these dependencies are not met, design of the service may be
impacted.
These dependencies may be technical, timelines, people, process related.

Ref Design Dependency

DDP001

DDP002

DDP003

2.5 Design Constraints

Service may have to be designed under certain constraints which may restrict the design in certain ways. These constraints should
be documented which will be referenced from design decisions later on. Again, the constraints may be from technology,
requirements, known system limitations, timelines, resources etc.

Ref Design Constraints

DCN001

Page 8 of 13
 Solution Design Document

DCN002

2.6 Design Decisions

Design decisions form the foundation for explaining the rationale behind the target design of the service. This is one of the most
important aspects of design and should be detailed and explained well.
Every effort should be made to capture sufficient level of details and factors which influence the decisions.

Ref Design Decisions

DDC001

DDC002

Page 9 of 13
 Solution Design Document

3 Component Model
The purpose of the component model is to help organize the project, manage the complexity of the solution, and ensure that all
architectural requirements have been addressed. It helps developers to design, implements the solution; and understand the big
picture of the system design.
Component model in this document should be restricted to the design components of this particular service. If there is a specific
need to include some external components which improve the design readability, it can be added.
Attempt should be made to re-use as many as existing components while defining new services.
This section might be skipped if components in high level design are not meant to be decomposed further.

3.1 Component Relationship Diagram & Description

Purpose of this section is to describe different components of the service, list their responsibilities, and show the relationships
between them. These components form the building blocks of the design.
Since many components may be re-used or referenced from other design, they need not be detailed again. Provide reference to
those components with sufficient details about their detailed design document.

Component Name

Component
Description

Component
Responsibilities

3.2 Component Interaction Diagram

The purpose is to show the collaboration between different components of the service.
Sequence diagram is one of the suitable diagrams to show collaboration.
It is recommended to follow the diagram with write up describing and explaining the collaboration. An example is shown below –
In the above interaction diagram, the following happens:
 Step 1: <<step explanation>>
 Step 2: ….

Page 10 of 13
 Solution Design Document

4 Low Level Design

Include brief design description of the proposed low level solution, including diagrams. This should not repeat what has already
been included in the high-level design, but instead describe the next level of detail.

4.1 Source / Target System Details

Include details about the source and target systems such as server details, IP address, URL etc… These details need to be captured
for all the environments – DEV, TEST, PPE, and PROD.
It can refer to configuration matrix for development / testing / pre-prod servers.

4.2 Data Mapping

If data mapping is applicable, include mapping details and required transformation from source to target and vice versa. Data
mapping sheet should be included for reference and implementation purposes. Any update to data mapping file should be
confirmed with business owners.

4.3 Message Flow Specifications

This section elaborates the ESB message flow specifications. These specifications are important to explain the low level functioning
of the service. It should cover all the details of the nodes, flow, sub-flows, properties and exception handling etc. These details are
important for development team to follow when implementing the message flows.
IBM WebSphere Message Broker Toolkit can be used to design the flow, and snapshot can be pasted here as message flow
specifications diagram.

Node Name Node Properties Node Description

4.4 Non Functional Characteristics

Each service has certain non-functional characteristics which are derived either from the business requirements, technical
principles and policies or sometimes technology used. The following section should be used to explain the non-functional
characteristics of the service.
If any new component has been developed for any of the NFR, its design should have been explained above. Following sub sections
should only list down the properties of these NFRs.

4.4.1 Logging
If logging is applicable, explain the logging points, method of logging, log store type (database, file system, network etc),

4.4.2 Capacity and Performance

4.4.3 Security
Any security aspects of the service (like encryption, role based access etc) should be listed here. This is required for development
team to ensure that its followed during development.

4.5 Message Set Specifications

Message sets are used to handle the message during the flow. These message sets can be industry specific, enterprise data model
or custom built for the service. The message sets used in the service should be listed and detailed here.

Page 11 of 13
 Solution Design Document

IBM WebSphere Message Broker Toolkit used to design the message set. A snapshot of the message set design can be pasted
below followed by write up explaining the design.

4.6 Other Services

Any other miscellaneous service used during the design of the service which has not been explained above. Otherwise, mention
Not applicable.

4.7 Requirements Traceability

Traceability is important to demonstrate that all the requirements have been met in the design. This view gives both designers
and developers a confidence level of not missing anything.

Requirement Component Name Remarks

ID

Page 12 of 13
 Solution Design Document

5 Operational Model
Operational model gives the runtime view of the service. This will reflect the placement of the solution components to physical
software components.

5.1 Deployment Topology Overview

Deployment topology should cover the service specific details only. Underlying software and hardware platform topology should
not be duplicated here. Only relevant information for explaining service deployment topology is required.

5.2 Design Component to Deployment Unit Mapping

A deployment unit represents the smallest unit which is a deployable component. This section maps the component name to its
associated deployment unit. A deployment unit may contain multiple components.

Component Deployment Unit Remarks

Name

5.3 Deployment Unit to Application Server mapping

Deployment unit is deployed on a server. This sub-section provides the mapping of each deployment unit to corresponding
technology server. Based on the technology, the below table structure may have to be changed, which is left up to the author’s
discretion.

Component Deployment Unit Server Name Server sub-component

Name name (like EG, node,
cluster etc)

5.4 Capacity Requirements for the service

If the design of the service requires specific capacity augmentation in terms of storage, network, CPU, memory, number of VMs,
application server instances etc, this can be detailed here.

Page 13 of 13