The document discusses design science, solution architecture, and the solution design process. It provides definitions for key concepts like design science, design science research, and solution architecture. It also outlines the iterative process of design science research, which involves developing a design, evaluating the design, and reflecting on the results. The goal of the solution design process is to maximize known information and minimize unknowns to reduce risks and problems later in implementation.
1. Design Science and Solution
Architecture
Alan McSweeney
http://ie.linkedin.com/in/alanmcsweeney
2. Topics
• Science, Design Science (DS), Design Science Research
(DSR), Design Science Research in Information Systems
(DSR-IS), Evidence-Based Design
• Problem and Solution Knowledge
• Purpose, Objective and Scope of Solution Design
• Solution Architecture and Design Science
• Solution Design Process
• Architecture Patterns
October 7, 2018 2
3. Science, Design Science (DS), Design Science Research (DSR), Design
Science Research in Information Systems (DSR-IS), Evidence-Based
Design
October 7, 2018 3
4. Science
• Science is not
• Science is the process whereby knowledge is formally
acquired or generated, validated, accumulated and revised
and updated through observation, investigation,
experience, research and analysis
− Scientific method is the application of this process
• The resulting knowledge needs to be acted-on and applied
in a systematic manner
October 7, 2018 4
5. Theory
• The output from science and the scientific method are
theories
− These are the current best explanations consistent with the
currently available knowledge
October 7, 2018 5
6. Design Science (DS)
• Design Science is the structured and systematic process for
creating designs that resolve problems
• It is the application of formal design processes
• Design Science is also the process for developing the associated
systematic process
• Design Science is concerned with the structured process for the
acquisition and application of knowledge in relation to the
problems to the resolved and the solution knowledge to be
applied
− Problem Knowledge – how known is the problem or how much
knowledge must be acquired on the problem to understand it
− Solution Knowledge – how much existing solution knowledge can be
applied and how much new knowledge is required
October 7, 2018 6
7. Design
Theory
Design Science (DS), Design Science Research (DSR),
Design Science Research in Information Systems (DSR-IS)
Context
October 7, 2018 7
Design
Science
Research
In
Information
Systems
Systematised
Approach to
Design In
General
Outcome-Based
Research
Approach and
Methodology
DSR Applied
to
Information
System
Design
Process
Design
Research
Development of
Theoretical Basis of
Principles
Knowledge and
Practice of Design
Design
Research
Design
Science
Research
Design
Science
8. Design Science Research (DSR)
• Design Science Research is the approach and methodology
for developing Design Science within research-type
endeavours
− Research is at best a semi-structured activity that can be difficult
to formalise
• Design Science Research is concerned with the creation
and improvement of artefacts
• Intended to be have a practical approach and application
rather than pure research
October 7, 2018 8
9. Design Science Research Framework
October 7, 2018 9
Knowledge Design Process Outputs
Awareness Of The
Problem
Suggestion
Development of
Design
Evaluation of Design
Conclusion
Knowledge
Contribution
Cognitive Process
Problem Statement
and Resolution
Proposal
Indicative Solution
Design
Artefacts
Performance
Measurement
Results
Design Science
Knowledge
Abduction
Deduction
Reflection and
Abstraction
Circumscription
10. Circumscription
• Discovery of constraint knowledge about explanation
gained through detection and analysis of contraindications
when things do not work according to previously defined
expectations
October 7, 2018 10
11. Suggestion
• Suggestion is the application of creativity where new
functionality is conceived of based on a novel
configuration of either existing or new and existing
solution components
• Creativity is difficult to define in a rigorous way and its
consistent repeatability cannot be guaranteed
October 7, 2018 11
12. Abduction
• Derive a simple, plausible and reasonable explanation
based on observations and knowledge acquired
• The explanation may be plausible and is supported by the
facts but is not certain
• The explanation derived through abduction is the most
likely and best available but not absolutely provable
October 7, 2018 12
13. Deduction
• Derive a completely certain and accurate explanation
based on observations, knowledge acquired and the
application of logic and rules
• Deductions expands on the explanations produced during
the abduction phase
October 7, 2018 13
14. Outputs From Design Science Research
Type Description
Constructs The conceptual vocabulary of the problem area: concepts, terms,
ideas
Models Sets of propositions or statements expressing relationships between
constructs
Frameworks Real or conceptual guides to serve as support or guide
Architectures High-level structures of systems
Design Principles Core principles and concepts to guide solution design
Methods Sets of steps used to perform tasks
Instantiations Material artefact that realises a construct, model or method
Design Theories A defined set of statements on how to perform actions to achieve a
defined objective
October 7, 2018 14
15. DSR Artefacts
• Artefacts within DSR are intended to contain knowledge
− This knowledge ranges from the design logic, construction methods and
tool to assumptions about the context in which the artefact is intended
to function
• DSR artefacts can include any of:
− Models
− Methods
− Constructs
− Instantiations (creation of an concrete example or instance) and design
theories
− Innovations
− New or previously unknown properties of informational resources
− New explanatory theories
− New design and developments models and implementation processes
or methods
October 7, 2018 15
16. Design Science Research in Information Systems
(DSR-IS)
• Information systems research that uses the design and
construction of artefacts to generate new knowledge and
insights into a class of problems
• The use of artefacts embodies the principle of learning
through building
• There are three general activities to DSR-IS
1. Construction of artefacts where the construction is informed
and guided by either by practice-based insight or theory
2. Gathering and evaluating of data on the functional
performance of the artefact
3. Reflection on the construction process and on the implications
the gathered data
October 7, 2018 16
17. Iteration Between Development Of
Design And Evaluation Of Design
• In DSR-IS, the process iterates between the development
of design and the evaluation of design phases rather than
flowing sequentially from one phase to the next
• This iteration is a major difference between design science
research and other science research projects
− Science projects flow sequentially from the design of experiments
that yield results that are analysed to generate knowledge
October 7, 2018 17
18. Outputs From DSR-IS
• Artefacts
• Information Systems Design Theory (ISDT)
• Design-Related Explanatory/Predictive Theory (DREPT)
October 7, 2018 18
19. Information Systems Design Theory (ISDT)
• Detailed descriptions how artefacts should behave and
how they can be constructed
• These are design principles
• ISDT defines the how artefact is constructed
October 7, 2018 19
20. Design-Related Explanatory/Predictive Theory
(DREPT)
• This contains explanatory information explaining formally
why artefact has the effects it does
• The captures the knowledge about the artefacts
• These are refinements to refinements to theories that
contributed to the initial design
• Defines the how and the why the artefacts’ features have
the specified effects
October 7, 2018 20
21. Evidence-Based Design And Solution Architecture
• Create optimum solution designs by using knowledge and evidence
derived from research using a rigorous and repeatable approach
− Clarification of the problem and definition of the problem statement
− Identification of and analysis of information available on the problem and
clarification of problem to be resolved
− Identification of and analysis of information available on the possible solutions
to the problem
− Analysis of the solution options in terms of resolving the problem
− Determine and eliminate various forms of bias in the problem statement and
the solution options
− Analysis of risks in the solution options
• Risk of doing the wrong thing
• Risk of doing it in the wrong way
• Risk of underestimating complexity and scope of work
• Risk of higher than expected cost of operation and maintenance
• Risk of underestimating organisation change impact and organisation resistance
• Risk through uncertainty and unpredictability
− Validate that the solution will resolve the problem
October 7, 2018 21
23. Need For Solution Exists Because …
• I have a problem
• I want to be able to do what I am currently unable to do
• I cannot do what I want
• I need to be able to do something
• A solution is a Resolver, a Provider or an Enabler
• An originator will identify the need for a solution
• The IT function must work with the originator to provide a
usable answer to the solution need
07 October 2018 23
25. Why, What And How
• WHY?
− Why is the solution being looked for: a problem, an opportunity, an obligation?
− Why has the situation requiring a solution arisen?
− Why are we here?
− Why do it?
− Why not do it?
• WHAT
− What are the options?
− What can be done?
− What is being looked for?
− What must it do?
• HOW
− How should it be done?
− How should it operate?
− How can it be delivered?
October 7, 2018 25
26. The Complete Solution Is Always Much More Than
Just …
• … Just a bunch of software
• Complete solution is the entire set of components needed to
operate the associated business processes
• Successful solution requires the interoperation of all these
components and that the components are properly designed
and implemented
• Overall solution usage experience is the sum of the experience
of the usage of the components
• Solution architect must be aware of the usability of designed
solutions
• Usability is not an afterthought: it must be embedded in the
overall solution design from the start
October 7, 2018 26
27. Scope Of Complete Solution
October 7, 2018 27
Changes to Existing
Systems
New Custom
Developed
Applications Information Storage
Facilities
System
Integrations/Data
Transfers/Exchanges
Changes to Existing
Business Processes
Organisational
Changes
Existing Data
Conversions/
Migrations
New Data Loads
Training and
Documentation
Central, Distributed
and Communications
Infrastructure
Sets of Installation
and Implementation
Services
Cutover/Transfer to
Production
Operational
Functions and
Processes
Parallel Runs
New Business
Processes
Reporting and
Analysis Facilities
Sets of Maintenance,
Service Management
and Support Services
Application Hosting
and Management
Services
Acquired and
Customised Software
Products
28. Any Complete Solution Consists of:
• Zero or more of {Changes to Existing Systems}
• + Zero or more of {New Custom Developed Applications}
• + Zero or more of {Information Storage Facilities}
• + Zero or more of {Acquired and Customised Software Products}
• + Zero or more of {System Integrations/Data Transfers/Exchanges}
• + Zero or more of {Changes to Existing Business Processes}
• + Zero or more of {New Business Processes}
• + Zero or more of {Organisational Changes}
• + Zero or more of {Reporting and Analysis Facilities}
• + Zero or more of {Existing Data Conversions/Migrations}
• + Zero or more of {New Data Loads}
• + Zero or more of {Training and Documentation}
• + Zero or more of {Central, Distributed and Communications Infrastructure}
• + Zero or more of {Sets of Installation and Implementation Services}
• + Zero or more of {Cutover/Transfer to Production}
• + Zero or more of {Operational Functions and Processes}
• + Zero or more of {Parallel Runs}
• + Zero or more of {Sets of Maintenance, Service Management and Support Services}
• + Zero or more of {Application Hosting and Management Services}
October 7, 2018 28
29. Aspects Of Solution Design
October 7, 2018 29
Solution Design
Getting Work
Done, Making
The Solution
Work Appearance,
Utility,
Experience
Development,
Configuration,
Implementation,
Migration
People and
Organisation,
Operating
Landscape
How the Solution,
Appears, Is Accessed,
Used, Navigated
Who Uses The Solution,
How the Solution
Interacts With Other
Components
30. Simplified Organisation Context Of Solution Design
October 7, 2018 30
Organisation Strategy
Organisation
Information
Technology and
Systems Strategy
Organisation
Structure And
Processes
Set Of Solutions That
Comprise The
Organisation Solution
Landscape
Alignment
Between
Strategies
Solution
Design
Alignment
Between
Solutions
And
Organisation
Organisation
Design
External
Factors
Constraints,
Standards,
Limitations
33. Solution Architecture And Knowledge
• The amount of
already known
knowledge and
the amount of
knowledge that
must be acquired
governs the
complexity of the
solution design
process
• The solution
design process
acquires and uses
knowledge about
the problem and
the solution to
create one or
more
implementable
and usable
solution options
October 7, 2018 33
Problem Knowledge Solution Knowledge
Solution
Design
Process
34. Mapping The Problem/Solution Domain
• Combination of options based on existing knowledge
about problem and knowledge of solution options that can
be applied to the problem
October 7, 2018 34
35. Mapping The Problem/Solution Domain - Problems
October 7, 2018 35
New Or
Unquantified
Problem/No
Problem
Knowledge Where
Existing Solution
Knowledge Can Be
Adapted
Known Or
Quantified
Problem With
Existing Solution
Knowledge
New Or
Unquantified
Problem/No
Problem
Knowledge With
No Existing
Solution
Knowledge
Known Or
Quantified
Problem With No
Existing Solution
Knowledge
Amount Of Existing Knowledge That Is Known About The
Problem Or Novelty Of The Problem
Amount Of
Solution
Knowledge
That Can Be
Applied To
The Solution
or Amount
Of Solution
Knowledge
Known
HIGH
LOW
LOW HIGH
36. Mapping The Problem/Solution Domain – Solution
Approach
October 7, 2018 36
Adapt Or Apply
Existing
Solutions or
Knowledge For
New Problem
Adapt Or Apply
Existing
Solutions or
Knowledge For
Known Problem
Invent or Derive
New Knowledge
To Create New
Solution For New
Problem
Develop New
Knowledge To
Create New
Solution For
Known Problem
Amount Of Existing Knowledge That Is Known About The
Problem Or Novelty Of The Problem
Amount Of
Solution
Knowledge
That Can Be
Applied To
The Solution
or Amount
Of Solution
Knowledge
Known
HIGH
LOW
LOW HIGH
37. Mapping The Problem/Solution Domain -
Complexity
October 7, 2018 37
Amount Of Existing Knowledge That Is Known About The
Problem Or Novelty Of The Problem
Amount Of
Solution
Knowledge That
Can Be Applied
To The Solution
or Amount Of
Solution
Knowledge
Already Known
HIGH
LOW
LOW HIGH
38. Mapping The Problem/Solution Domain
October 7, 2018 38
Adapt Or Apply
Existing
Solutions or
Knowledge For
New Problem
Adapt Or Apply
Existing
Solutions or
Knowledge For
Known Problem
Invent or Derive
New Knowledge
To Create New
Solution For New
Problem
Develop New
Knowledge To
Create New
Solution For
Known Problem
New Or
Unquantified
Problem/No
Problem
Knowledge Where
Existing Solution
Knowledge Can Be
Adapted
Known Or
Quantified
Problem With
Existing Solution
Knowledge
New Or
Unquantified
Problem/No
Problem
Knowledge With
No Existing
Solution
Knowledge
Known Or
Quantified
Problem With No
Existing Solution
Knowledge
39. Maximise The Known Knowns Of The Potential
Solution
• Solution unkowns
are the source of
potential problems
during solution
delivery
• The goal of solution
design is no
surprises
• Remove the
uncertainty from
the solution design
as much as possible
07 October 2018 39
What Can Be Known
Known Unknown
What We
Know
Known
Here Be Dragons
Unknown
40. Maximise The Known Knowns Of The Potential
Solution
07 October 2018 40
Known Knowns
Known
Unknowns
Unknown
Unknowns
• The more that is
known about the
solution design the
fewer the problems
relating to scope and
changes and
associated cost, time
and resource
increase will occur
later in solution
implementation
41. Solution Design Process – Requirements To Solution
Mapping
• Solution has functional (and other) requirements that it
must have in order to be deemed to be operating correctly
− Solutions can be delivered without some of the functional
requirements – manual work
• Solution design process is concerned with mapping the
requirements to the functions of the solution
• Solution requirements identified will never include the full
scope of the solution
− Requirements identified during any requirements elicitation
process will only ever be a sparse and fragmented representation
of what the full set of solution requirements that constitute a
complete solution
October 7, 2018 41
42. Solution Design Process – Requirements To Solution
Mapping
October 7, 2018 42
Sparse Functional Requirements
Identified
Complete Solution Functionality
Implemented
= Functional Requirements Identified
= Solution Functionality Implemented But Not Explicitly Identified
= Functional Requirements Identified But Not Implemented
Solution Need To
Solution Design
Mapping
43. Requirements Space And Solution Space
• Minimise Solution Space while maximising size of
Requirements Space encompassed
• You do not deliver requirements
• You deliver solutions that encompass multiple interoperating
elements that enable business processes that allow
requirements to be complied with
• Solution Space maximises the requirements complied with
while minimising its scope and complexity and therefore its
cost, delivery time and risk
• Solution design is concerned with finding an optimal Solution
Space
• There may be many Solution Space options – solution design
needs to focus on finding the most viable ones quickly and the
deciding on the one(s) to pursue
October 7, 2018 43
45. Solution Architecture And Design
• Solution architecture and design is concerned with
designing new (IT) solutions
• These can be standard solutions where the knowledge
required to create the design is known and available or
new and innovative where there are knowledge gaps that
must be identified and completed
• Solution architecture requires a (changing) combination of
technical, leadership, interpersonal skills, experience,
analysis, appropriate creativity, reflection and intuition
applied in a structured manner
October 7, 2018 45
46. Objective Of Solution Architecture
• The central objective of solution architecture is to create a design
• The design is a specification of an IT-oriented solution whose
purpose is to realise a defined set of end states and generate a set of
outputs
• The design is intended to operate in a defined environment
• The design is based on a set of basic components
• The design satisfies a set of requirements and meet a set of
expectations
• The design is subject to a variety of environment-specific constraints
and limitations
• Solution architecture is the process for creating designs
• The purpose of the design specification is to enable the
implementation and subsequent operation and use of the solution
October 7, 2018 46
47. Scope Of Solution Design
• There are differing views of the scope of the solution
design effort and of the solution design itself
− Narrow rather than broad
• Narrow - the design should cover just the core functional elements
• Broad - the design should include details on the wider solution operation
such as data migration and transition to service
• The solution design should encompass all elements
required to ensure that the solution can be implemented,
operated, used and supported
• This means the solution design should describe all the
solution design and implementation components
October 7, 2018 47
48. Solution Design Scope
October 7, 2018 48
Changes to
Existing Systems
New Custom
Developed
Applications Information
Storage
Facilities
System
Integrations/
Data Transfers/
Exchanges
Changes to
Existing
Business
Processes
Organisational
Changes
Existing Data
Conversions/
Migrations
New Data Loads
Training and
Documentation
Central,
Distributed and
Network
Infrastructure
Sets of
Installation and
Implementation
Services
Cutover/
Transfer to
Production
Operational
Functions and
Processes
Parallel Runs
New Business
Processes
Reporting and
Analysis
Facilities
Maintenance,
Service
Management
and Support
Services
Application
Hosting and
Management
Services
Acquired and
Customised
Software
Products
49. Solution Implementation Stages
October 7, 2018 49
Idea or
Business
Concept
Initial
Discovery
Requirements
Elicitation
Outline
Solution
Design
Decision to
Proceed
Design
Review And
Approval
Development
Organisation
Change
Detailed
Solution
Design Initiate
Implementation
Implementation
Planning
Deployment
Planning
Data
Migration
Testing
Transition
To Support
Parallel Run
Hypercare
Interval
Documentation
and Training
Process
Definition
and Changes
Cutover To
Production
Operation
and Use
Evolve and
Change
Component
Procurement/
Acquisition
Infrastructure
Commissioning
50. Journey From Solution Idea To Operation And Use
• The solution implementation journey from initial concept
to operation and use is never simple
October 7, 2018 50
Compromise
Options
Strategy
Exploration
Workaround
Concession
Operation
And UseIdea
Implementation
Transition
to
Production
Training
52. Solution Implementation Stages
• What should the solution design encompass?
• What should the solution design included to ensure that
the solution will be implementable, operable and usable?
• Knowing the actual solution scope means being able to
estimate effectively and accurately and know the cost,
time, resources and risks in implementing the solution
October 7, 2018 52
53. Mapping The Solution Scope To The Solution
Implementation Stages
October 7, 2018 53
What Should the Solution Scope Be
To Achieve the Required Solution
Implementation?
Solution
Implementation
Stages
Solution
Scope
54. Solution Design Scope
October 7, 2018 54
This Is What The
Implementation of the
Solution Will
Ultimately Cost
The Solution Design
Should Include All The
Elements Needed To
Accurately Quantify
The Solution
Implementation Costs,
Resources and Time
55. Solution Design Scope
• Likely scope of complete solution • If elements of the solution scope
are omitted then the solution
design will not be complete
October 7, 2018 55
New Business
Processes
Sets of Installation
and
Implementation
Services
Sets of
Maintenance,
Service
Management and
Support Services
New Data Loads
Parallel Runs
Acquired and
Customised Software
Products
Existing Data
Conversions/
Migrations
Central,
Distributed and
Communications
Infrastructure
Cutover/ Transfer to
Production
Application Hosting
and Management
Services
Changes to Existing
Business Processes
Reporting and
Analysis Facilities
Information
Storage Facilities
New Custom
Developed
Applications
System Integrations/
Data Transfers/
Exchanges
Changes to Existing Systems
Training and Documentation
Operational Functions and
Processes
Organisational Changes
New Business
Processes
Sets of Installation
and
Implementation
Services
Sets of
Maintenance,
Service
Management and
Support Services
New Data Loads
Parallel Runs
Acquired and
Customised Software
Products
Existing Data
Conversions/
Migrations
Central,
Distributed and
Communications
Infrastructure
Cutover/ Transfer to
Production
Application Hosting
and Management
Services
Changes to Existing
Business Processes
Reporting and
Analysis Facilities
Information
Storage Facilities
New Custom
Developed
Applications
System Integrations/
Data Transfers/
Exchanges
Changes to Existing Systems
Training and Documentation
Operational Functions and
Processes
Organisational Changes
56. Solution Delivery Costs – Cost Committed And Cost
Incurred
• Most solution
delivery costs are
embedded and
committed after
the solution
design has been
completed
• The embedded
costs will just be
incurred during
subsequent
delivery stages
• If the solution
design is not
accurate and
complete then
the costs will not
be understood or
represented
correctly
October 7, 2018 56
58. Design Science And Solution Architecture – Key
Questions
• Can design science principles be applied to solution
architecture in a commercial context?
• Is there a commercial and business benefit to applying
design science in a business environment
• Can the rigour of an academic-derived process be used in
a business environment?
• Can it be adapted to suit the required flexibility and
dynamism outside the academic world?
• Can the business and commercial environment adopt the
required rigour of a design science process?
October 7, 2018 58
59. Design Science And Solution Architecture – Key
Questions
• Using a rigorous scientific approach add cost to the
solution design process but improves solution quality
• The application of DSR-IS must be a means to an end –
better solution quality – and not an end in itself – an
incentive for the design function is to become large
• A large design function can create work for itself to justify
its size and existence and so the potential value-adding
benefits of DSR-IS can be lost
− Need to avoid the problems of Conway’s Law -
https://www.slideshare.net/alanmcsweeney/conways-law-
cognitive-diversity-organisation-transformation-and-solution-
design-66522207
October 7, 2018 59
60. Types Of Solution Design Activities
• Two broad types of solution design activities:
1. Design of commercial products for sale and supply to customers
2. Design of solutions within organisations
• While design science approach and principles can be
applied to both types of design activities, it is particularly
applicable to the design of commercial solutions
• Internal organisation solutions include commercial
products
October 7, 2018 60
61. Design Science And Solution Architecture
• Solution architecture involves creativity during the solution
design process
• Creativity is difficult to define and apply rigorously
• There are tools and approaches to channel and direct
creativity
October 7, 2018 61
62. Problems With Solution Design
• Soft organisational information can be difficult to identify and
thus incorporate into the solution design
• Any solution operates in an organisational context
− Understanding this context is important to ensure the success of the
solution
• Soft information can include the way information
− Many solutions do not meet user needs, especially as these change over
time
− Many solutions require additional external manual workarounds to
operate successfully
− Many solutions are difficult to maintain and evolve to incorporate
changes
− Many solutions are difficult to reuse
− Many solutions are hard to integrate with other systems
October 7, 2018 62
63. Spectrum of Solution Delivery Failures and
Successes
October 7, 2018 63
Complete Solution
Success:
On-time, On-budget And
Delivering Specified
Benefits
Solution Delivery
Late And/Or Over
Budget
More Expensive to
Operate And Support
Than Planned Or
Expected
Performance And/Or
Operational Problems
Functionality Delivered
Does Not Meet
Business Requirements
Significant Rework
Or Replacement
Required
Solution Largely
Unused And/Or
Unusable
Complete Solution
Failure: Cancelled,
Unused, Rejected
Not What Is
Wanted Or What
Was Required/
Envisaged
Not All Specified
Business Benefits
and Savings Not
Delivered
Solution Has
Reduced
Functionality
Requiring
Workarounds
64. Spectrum of Solution Delivery Failures and
Successes
• Solution delivery success and failure are not binary options:
there is a spectrum of outcomes between complete success
and complete failure
• Complete solution delivery success is as infrequent as complete
failure
• Getting the architecture and design right puts the solution
delivery project on a solid foundation and maximises the
likelihood of success
• Getting the architecture and design wrong puts the solution
delivery project on an unstable foundation and negatively
impacts on the deliverability of the solution
• The discipline of design science can improve the quality of
solution designs
October 7, 2018 64
65. Design Science And Solution Architecture
• A key element of the application and use of Design Science
is the management of knowledge – problem knowledge
and solution knowledge
− This allows knowledge to be reused
• This means that the solution architecture function must
incorporate effective knowledge management –
knowledge storage, sharing, use and constant
maintenance
• This requires good management of the solution
architecture function
October 7, 2018 65
66. Being Good At Solution Design Means …
• Solutions are defined, designed and delivered in a reliable,
stable and innovative way to ensure that cost, time,
required functionality and quality are constantly optimised
to meet the needs of the business
• Good solution design means being aware of all the options
and selecting the most appropriate one subject to all
constraints
• Good solution design means avoiding all the conscious and
unconscious biases that lead to bad solutions
• Doing the right things and doing them the right way
October 7, 2018 66
67. Solution Design Process
October 7, 2018 67
Initial Concept Of Need/ Goal/ Objective
Formal Statement Of Need/ Goal/
Objective
Stakeholder Requirements Collection
and Specification
Solution Requirements Collection and
Specification
Solution Architecture Design and
Specification
Elicit Stakeholder Requirements
Formalise Stakeholder
Requirements
Define Solution Requirements Analyse Solution Requirements
Define Solution Architecture and
Design
Analyse, Evaluate and Refine
Solution Architecture
Implementation Project
Initial Architecture Review and Options
68. Solution Design Process
• Each stage uses the output
from the previous stage as
an input
• Detail is refined, extended
and elaborated on in
successive stages
October 7, 2018 68
Initial Concept Of Need/ Goal/ Objective
Formal Statement Of Need/ Goal/
Objective
Stakeholder Requirements Collection
and Specification
Solution Requirements Collection and
Specification
Solution Architecture Design and
Specification
Implementation Project
Initial Architecture Review and Options
69. Solution Design Process
Stage Scope
Initial Concept Of Need/
Goal/ Objective
The business have an idea for a solution based on an apparent need to solve a problem, to
do what is currently not possible, to react or respond to an external demand or to be able
to achieve a new objective.
Formal Statement Of
Need/ Goal/ Objective
This formalises the initial concept to introduce greater consistency and detail. It serves to
understand the business, objectives, purposes and potential organisational impacts. It
describes what the ideal solution will do. It also identifies the high-level potential system
impacts.
Initial Architecture Review
and Options
This uses the formal statement of need to create an initial high-level view of the overall
solution, its new and existing systems and applications components, the required
functionality, their interfaces, the required processes and the business functions impacted.
This provides a container for the requirements and a vision for the solution.
Stakeholder Requirements
Collection and
Specification
This uses this initial architectural review output in a structured way to elicit and formalise
the set of stakeholder requirements across the dimensions of functionality and processes.
Solution Requirements
Collection and
Specification
The solution requirements specification is a fuller, more detailed and elaborated set of
solution requirements encompassing all the solution components. This includes the
requirements explicitly identified by stakeholders and the implied requirements.
Solution Architecture
Design and Specification
This is the detailed solution specification derived from the stakeholder and solution
requirements.
Implementation Project This uses the detailed solution specification to act as an input to project definition and to
create a realistic implementation plan, schedule, set of costs and required resources.
October 7, 2018 69
70. Solution Design Process
• There is a decision
point after each
stage where a
decision is made if
it is worthwhile to
proceed to the
next stage
October 7, 2018 70
Initial Concept Of Need/ Goal/ Objective
Formal Statement Of Need/ Goal/
Objective
Stakeholder Requirements Collection
and Specification
Solution Requirements Collection and
Specification
Solution Architecture Design and
Specification
Implementation Project
Initial Architecture Review and Options
Decision Points
71. Solution Design Process
• Not all concepts make
it all the way to
implementation
• Process needs to
accommodate this
• Do as little as possible
to achieve as much as
possible to make an
informed decision on
whether and how to
proceed to the next
stage in the solution
journey
October 7, 2018 71
Initial Concept Of Need/ Goal/ Objective
Formal Statement Of Need/ Goal/ Objective
Stakeholder Requirements Collection
and Specification
Solution Requirements Collection
and Specification
Solution Architecture Design
and Specification
Implementation
Project
Initial Architecture Review and Options
72. Solution Design Process - Iterations
• Solution design process is
not necessarily linear
• Stages can be iterated a
number of times to
different levels of detail
October 7, 2018 72
Initial Concept Of Need/ Goal/ Objective
Formal Statement Of Need/ Goal/
Objective
Stakeholder Requirements Collection
and Specification
Solution Requirements Collection and
Specification
Solution Architecture Design and
Specification
Implementation Project
Initial Architecture Review and Options
73. Mapping Solution Design Process to DSR-IS Process
October 7, 2018 73
Initial Concept Of Need/ Goal/ Objective
Formal Statement Of Need/ Goal/
Objective
Stakeholder Requirements Collection
and Specification
Solution Requirements Collection and
Specification
Solution Architecture Design and
Specification
Implementation Project
Initial Architecture Review and Options
Awareness Of The
Problem
Suggestion
Development of
Design
Evaluation of Design
Conclusion
74. Mapping Solution Design Process to DSR-IS Process
• The DSR process can be applied standard solution design
process
• What works in an academic environment can be applied,
with care, to a commercial setting
October 7, 2018 74
76. Architectural Patterns
• Architectural patterns are template solutions to recurring
types of problems
− Not all problems are they same but there can be sufficient
similarity to allow knowledge reuse
• The pattern describes the problem and the core of the
solution to that problem
• Patterns demonstrate and communicate short-cuts
solution models
• Patterns do not contain detailed implementation-specifics
• The use of patterns can reduce design effort
October 7, 2018 76
77. Solution Design Techniques
• If you are stuck at any stage in the solution analysis and design
process, use brainstorming to create a new solution concept by first
creating a large number of ideas that are then evaluated on their
usefulness
• If conventional thinking is not yielding results, consider alternative or
unusual ideas or a combination of ideas
• Redefine the problem scope and statement after an initial review
• Conduct a rigorous cost-benefit analyst to determine if the
envisioned expenditure justifies the expected benefits
• Analyse existing solutions to determine if they can be applied when
the problem becomes more complex or whether different solutions
are required
• Restructure ill-structured problems by identifying and prioritising the
key problem objectives and clarifying any constraints. Restate the
problem in formal and precise terms
October 7, 2018 77
78. Solution Design Techniques
• Break down the complex problem into smaller constituent problems
to create manageable problems that can be worked on individually
• Develop the solution to a complex problem in an incremental and
iterative manner
• Identify tools and techniques applicable to the problem based on
analysis of existing documentation
• Look at the problem from different and unorthodox perspectives in
order to identify new dimensions to the solution
• Create a library of ideas generated over multiple solution design
exercises so they can be reviewed to determine their suitability for
future exercises
• Examine the possibility that a solution or solution approach to a
problem in one problem area can be applied or adapted or
extrapolated to a different problem
October 7, 2018 78
79. Solution Design Techniques
• Start with an simple solution first and then expand its
complexity
• Detail the desired end solution state (end state) and the start
problem state (start state) and analyse the differences
between the two states. Look for methods that can be
employed in narrowing the difference between the two states
• Understand and predict the behaviour of the designed solution
without having to build it. Explore alternative designs for the
solution. The behaviour of complex solutions may be difficult to
understand.
• Identify problems that are similar to the current problem.
Understand the solution approaches, concepts and principles
used for solving these similar problems and apply this
knowledge to the solution of current problem
October 7, 2018 79
80. Solution Design Techniques
• Explore the option that a solution or solution approach to a
problem in one discipline or domain can be applied in or
adapted to the current problem
• Divide the given complex solution design into smaller problems
that can form the building blocks for solving the original
problem
• Identify and carry out the next feasible task that can contribute
to the solution of the problem resolution and solution design
and let the succeeding tasks emerge
• Find and combine partial solutions to parts of the research
problem to form the entire solution
• Develop a solution to the problem through iterations of system
development, observation and refinement
October 7, 2018 80
81. Solution Design Techniques
• Demonstrate that the solution is implementable and valid.
Creating a prototype of a solution for a problem can be
used to show that the solution is implementable. Testing
of the solution can demonstrate the validity of the solution
• Use simulation to evaluate and validate the solution to the
problem
October 7, 2018 81
82. Summary
• Design Science principles can be applied to the solution
design process within solution architecture to improve the
rigour and accuracy of solution designs
• The application of Design Science must be a means to an
end – better solution quality – and not an end in itself – an
incentive for the design function is to become large
• Knowledge management – problem knowledge and
solution knowledge – is at the core of the application of
design science principles
• Knowledge management requires good management of
the solution architecture function
October 7, 2018 82
83. October 7, 2018 83
More Information
Alan McSweeney
http://ie.linkedin.com/in/alanmcsweeney