CAAD - Codeless Applications Development Methods and Principles

®
An Introduction To
Computer Aided
Applications Design
(CAAD)

www.encanvas.comwww.encanvas.com
AGENDA
1. Introduction
2. Process Overview
3. The Encanvas Platform
4. Application Constructs
5. CAAD Lifecycle (Methods)

INTRODUCTION

Introduction
Software development is a wasteful process.
Any design exercise assumes a level of ‘trial and error’ but the risks
represented by software authoring are born out in studies both in
terms of slow time to market and burgeoning costs.
The article ‘Why Your IT Project May Be Riskier Than You Think’ by
HBR (November 2011), that followed a survey of 1,471 IT projects
with an average spend of $167m, found that:
• The average overrun was 27%
• One in six of the projects studied was a black swan, with a cost
overrun of 200%.
• Almost 70% of black swan projects also overrun their schedules.

About CAAD
• Computer Aided Applications Development (CAAD) is a rapid
method of designing and deploying situational applications
for workgroups and teams.
• It’s computer aided because applications are authored using
a platform that provides pre-formed building blocks of
technology, negating the need for the majority of
programming, testing and re-working associated with former
methods of software authoring.
• It not only makes applications ‘better-fit’ to the community of
users and beneficiaries they’re intended for, but reduces the
time, cost and risk of applications developments.

About CAAD
• CAAD methods and tools dramatically reduce the skills-
portfolio needed for authoring applications which means that
one individual can reasonably discharge the entire lifecycle.
• The fact that applications are authored ‘faster’ does not
remove the need for pre-qualification of the use-case, user
needs and benefactor outcome expectations.
• Developments are by necessity scoped using formalized
analysis methods in the PLANNING PHASE comprised of:
1. Outcome Driven Innovation (ODI) based User Role,
purpose and job worth analysis
2. Value Innovation based strategic value analysis
3. RPRS based attribute analysis

Organizations that have benefitted from
CAAD development methods

PROCESS
OVERVIEW

Plan
CAAD Process Phases
9
Phase 1
Develop
Phase 2
Release
Phase 3
Review
Phase 4

CAAD Phases and Stages
1. Purpose and Job Worth
2. Strategic Advantage
3. Applications Attributes
Plan1.
4. Workshop Iteration
5. Publish
6. Iterate & User Test (UAT)
Develop2.
7. ReleaseRelease3.
8. Monitor/Report
9. Analyse
10. Recommend
Review4.

Process Overview
How it works:
1. A new workspace is created on Encanvas Remote(Spaces)™.
2. (Plan) A business analyst/designer interviews prospective
Users and Stakeholders and defines the scope of the
application and shapes the parameters of the workspace
(data sources, users and user groups), requirements for
records, processes, reports and meta-tables.
3. The business analyst/designer authors a prototype ‘canvas’.
4. (Develop) The business analyst/designer and stakeholders
meet in a workshop and they walk through the canvas
design, iterate the application. Once satisfied with the
outcome the application is published.

Process Overview
5. Users test the application and feedback change requests to
the business analyst. Changes are made remotely to the
web-site.
6. (Release) Once the iterations have been completed, the
application is signed off for general release.
7. (Review) Once released, any change requests or technical
bugs are logged against the application and, following
analysis, recommendations for improvement may be made.

PLATFORM

Platform Characteristics
• Encanvas adopts a similar concept to LEGO™ in the use of
‘ready-made building blocks’ to de-skill the task of software
authoring and makes it possible to design apps in a workshop!
• Look-and-feel parameters are pre-defined using a template to
comply with a corporate standard.
• The design elements of Encanvas are pre-tested for
performance tuning and browser compatibility so there is no
need to conduct a testing/tuning phase.
• All components of Encanvas are built with security provisioning
in mind. This means there’s no risk of security protocols being
unwittingly usurped during the design process.
• Data access security and user permissions management duties
remain under the governance and scrutiny of IT administrators.

Installing The Platform
• Encanvas® Remote(Spaces)™ is a proprietary architectural
component of the Encanvas® Secure&Live™ platform.
• It orchestrates the formation of private clouds on-demand
using parameterized configuration settings delivered through
administration tools.
• This technology resides at the Encanvas® data centre and
removes the obstacles of infrastructure setup and
configuration.

Protecting Systems
• Encanvas® has been developed on the Microsoft® Web
Platform and inherits all of the advantages of Microsoft’s own
platform security features designed with large enterprises in
mind.
• Encanvas® employs its own Web Server used to orchestrate
the on-demand serving of pages from Microsoft® SQL Server
and other data repositories. This means it’s not possible for
hackers to target static web pages as they do not exist until
served by Encanvas® Web Server™.
• Encanvas’s User Permissions policies are based on the
progressive assignment of permissions unlike other
competitive systems that assign Users a standard level of
permissions to then progressively remove them.

Replicating and Scaling Deployments
• Encanvas® is designed to scale painlessly, creating hundreds if
not thousands of applications and workspaces from a single
integrated platform.
• Its Web Server Manager™ cockpit provides administrators
with full visibility over configuration settings.
• All aspects of deployed applications are configured through
parameterized settings negating the need for programming
or the manual setup of operating environments, log files etc.

Maintaining The Software Environment
New remote spaces
(applications instances) can
be created by systems
administrators using the
configuration tools of
Encanvas® Remote(Spaces)™
without programming or the
need to setup operating
systems or applications
environments.
Server Computer
The place where computing platforms
are installed.
Client Computer
The place where computing
applications are consumed.
Secure TCIP/IP Service
Secure two-way communications
between computers
TCIP/IP Service
Standard two-way
communications between
computers

APPLICATION
CONSTRUCTS

Introduction
• On the following pages we
describe the constructs of a
typical Encanvas application.
• Note that rarely do
applications include all of the
components described here.
• Depending on the complexity
and number of ‘jobs’
performed, the role of pages
will often merge or may
sometimes not be required.
Start Wizard
Keynote
Landing
Highlights
Workpage
Data Entry (standard, wizard)
Assembly (side-bar, top-down)
Library
Views, Previews and Maps
Reports
Users
Share
Export
Meta

Typical Role Terms
• Administrator
– The role responsible for managing the system
infrastructure components
• Sub-Administrator
– The role responsible for managing prescribed
meta-data, user permissions etc.
• Primary User
– The role responsible for actioning the primary
job that defines why the application exists
• Secondary Users
– The role of other users that access the system
normally to view rather than edit.
These are common role
terms used by
designers and analysts
when scoping a new
application.

CONSTRUCTS

Start Wizard
Role:
• Admin or Sub
Admin Users
• Used to give Users
the ability to
rapidly configure
application
parameters to
setup the
application

Keynote
Role:
• For Senior
Executives with a
peripheral interest
in the outcomes
an application
produces
• Used to deliver
signposting of
keynote analytics
showing ‘pipeline
progress’ with
limited drill-down

Landing
Role:
• For All Users
• Used as a construct
in larger
applications to
display system
parts usually with
image links
• Helps users to
navigate a complex
system servicing
multiple ‘jobs’

Highlights
Role:
• For Primary User
Role
• Used to signpost
what they need to
focus on in order
to deliver ‘the job’
• Should include
process links (job
activities) in right
hand border

Workpage
Role:
• For Primary User Role
• Used to manage day-
to-day activities for
the primary ‘job’
• Rich drill-downs to
assemblies to enable
users to navigate the
system
• See right-hand pane
used for attributes
editing

Data Entry
Role:
• Used to add new
primary records
where lots of fields
need to be populated

Data Entry (Wizard Based)
Role:
• Used to add new
primary records
where lots of fields
need to be populated
• Streamlines data
entry process for
predictable data entry
workflows

Assembly (Side-bar)
Role:
• Used to manage
interactions with
main sub-record
assemblies
• Normally has a
repeater panel at
centre with editable
side-bar attribute
pane

Assembly (Top-down)
Role:
• Used to manage
interactions with
main sub-record
assemblies
• Normally has a show
data table at the
header supported by
editable form below

Library
Role:
Role
• Used to manage
ancillary documents
for an application

Views, Previews and Maps
Role:
• For Admin, Sub-User
and sometimes
Primary User Roles.
• Used to view,
preview or view
maps as part of an
application.
• May include
configuration
options to define
how data is viewed
by public viewers.

Reports
Role:
and Sub Admin
Roles
• Used to manage
applications
reporting

Users
Role:
• For Sub Admin and
Primary User Roles
• Used to manage User
permissions relating
to the application or
‘staff records’
• Normally treated as
an Assembly page
(note the typical
assembly page layout
of this example)

Share
Role:
Role
• Used to manage
the URL sharing
of canvas
sections carrying
key views,
analytics or
results

Export
Role:
• For Sub Admin
Role and
sometimes User
Roles
• Used to manage
the
import/export of
data assets to
the desktop

Meta
Role:
• For Sub-Admin Users
• Provides a
contextual ‘single
place’ where Users
go to setup meta
tables relating to an
application or
assembly
• Reduces the number
of forms used within
an application

®
CAAD LIFECYCLE
(METHODS & PROCESS
IN DETAIL)

PHASE 1.
PLAN

1. Purpose and Job Worth (Analysis)

Purpose
• The purpose of this stage is to understand the reasons why
an application development is being considered and to
qualify whether it is really necessary.
• It’s also to qualify the function of the application and what it
‘needs to do’.
1.PurposeandJobWorth

About ODI
• Outcome driven Innovation (ODI) is an innovation process
developed by Anthony Ulwick and described in his book
‘What Customers Want: Using Outcome-Driven Innovation’
later popularised by Clayton M. Christensen, Professor of
Business Administration at the Harvard Business School.
• It is built around the belief that people hire products and
services to get a job done.

Applying ODI to Apps Design
The reason why a customer ‘hires’ your
application (goals to be achieved, problems to be
resolved) – the JOB your application does.
Save lives when there’s a fire Fireman
Find relevant content on the internet Search engine
Supply food on the run Fast food restaurant
Heat food to eat Cooker
Correct vision Glasses

Needs are Constant, Solutions Vary
A job statement describes what needs to be done:
• Job statements should not describe mechanisms or platforms
(e.g. “cutting” the grass, “brushing” teeth).
• Job statements should include an Action verb  Object of
action  and a Contextual qualifier (ODI method) such as
“Teach the reading of English language text”
• Jobs are distinct from products or a solution. It pays to
qualify what the job is before trying to find a way to do it
better (i.e. keep the need separate from the product or
solution).

Method
An interviewer will analyse the jobs done by role holders. Then
he/she will seek to discover how the job can be done better for
each role.
For any activity there may be several role types and it therefore
becomes necessary to interview a number of people performing
each role to ask them:
• What jobs do they do?
• What activities take time to do, or inhibit the job from being done
well? (i.e. posing questions that expose where a sub-optimal
activity exists?
• What inhibitors and constraints prevent them from accomplishing
the job as well as it can be done? (i.e. exposing what customers
thing is the cause of the constraint and qualifying how it could be
improved by doing things better or differently).

Tools
• Capturing insights on roles, jobs and constraints benefits from a
simple framework in the form of a spreadsheet or database
application.
• For each job stage, the data captured should include:
1. User Roles
2. Capabilities (jobs that need doing)
3. Job Outcomes Statements (how the outcome of the job is
measured – such as to “maximize or minimize ‘object’ by
‘value’ + context”)
4. Constraints (what prevents the job being doe better)
5. Corrective Importance (the value of doing the job better to
the role)

• Encanvas Casebook™ provides an online tool-set for creating a Job Card
and Job Definition for a workshop project.
• It establishes a simple project process where milestones can be assigned
and responsibilities allocated. This builds a record of project actions and
contributions to ensure appropriate governance.
• The structure of the Casebook builds a complete picture of requirements
and the desired outcome.
• This knowledge of project activities builds as a casebook for future review
and scrutiny so learning lessons can be captured.
Tools

Outputs
The focus of ODI interviews is to produce a job definition – a
factual account of the job – not how the customer does it, what
tools and platforms they use to achieve it or what they think
about the state of the industry!
The output of this stage is an article that qualifies the job and its
attributes of:
• User Roles
• Job Stages
• Job Outcomes
• Job Constraints
• Corrective Importance

Summary
• To qualify the purpose of an application (ODI) methods
are employed.
• ODI principles pre-suppose that applications are
employed to get a job done better.
• The key questions therefore are:
 What are the roles?
What are the jobs?
What constraints exist that prevent the job
being done better (i.e. What takes the time)?
How important is it to overcome the
constraint(s)?

2. Strategic Advantage (Analysis)

Purpose
• There are many ways organizations can improve their
business processes and systems to work more profitably. The
key question becomes ‘Why this and why now?
• The purpose of this stage is to place a strategic value on a
software development exercise.
2.StrategicAdvantage

About Value Innovation
• Value Innovation methods originated from the book ‘Blue
Ocean Strategy’, by W. Chan Kim and Renee Mauborgne
(Harvard Business School Press, 2005)
• In it, the authors observe Value innovation is created in the
region where a company’s actions favourably affect both its
cost structure and its value proposition to buyers.
• Cost savings are made by eliminating and reducing the
factors an industry competes on.
• Buyer value is lifted by raising and creating elements the
industry has never offered. Over time, costs are reduced
further as scale economies kick in due to the high sales
volumes that superior value generates.

Method
• The ‘value of innovation’ is quantified by establishing the
impacts of change on targeted customer and stakeholder
actions.
• Key attributes should be qualified in terms of how they
eliminate and reduce costs or raise and create value.
• Each attribute should be assigned a weighted value of
importance (normally a mark out of 10 where 1 is low and 10
is high).
• These values can then be debated with stakeholders and
customers to assign an Innovation Value.

Outputs
• Innovation Value can be presented in the form of a strategy
canvas as illustrated below that shows how an application
beats its competition (i.e. the previous method employed to
complete the process).

3. Applications Attributes (Analysis)

Purpose
Preparing a prototype design not only requires a fundamental
understanding of the job that people are hiring the intended
application to perform, and the roles that contribute to that job, it
also requires a more fundamental picture of:
• Records
• Processes
• Reports
• Settings and data access requirements
The purpose of RPRS Analysis is to document the attributes of an
application so that a prototype design can be easily determined.
3.ApplicationsAttributes

Method
• Like ODI, the insights required for RPRS are captured through
interviews with application stakeholders and by benchmarking
existing applications (or competitive applications).
• In order to complete the case-file application design definition,
business analysts/designers will need to qualify:
1. What key content entities exist that will require support in the
form of a record or sub-record?
2. What processes does each user role fulfil (this should come from
ODI)?
3. What reports does each user role require from the application –
and in what format/delivery mechanism?
4. What related data is needed to populate referencing
tables/meta-tables/drop-downs?

Outputs
• Outputs are presented in a case-file (or a spreadsheet when
Encanvas CaseBook™ is not used).
• From these insights a prototype can be formed so that
Workshop discussions can be framed around ‘something’
rather than working from a blank canvas.

Creating A Prototype/Design Concept
• It’s normal for workshops to be pre-empted by the
development of a straw-man prototype. This is to avoid
contributors starting their workshop looking at a blank
canvas!
• The information gained through the job definition and
discovery phase forms the basis of the prototype design.
• This can then be iterated in the workshop phase working
collegiately with stakeholders.
• There is no pressure for the prototype to be ‘perfect’ from
the outset because the activity of iteration engages
stakeholders more into thinking about ‘what will work’.

PHASE 2.
DEVELOP

4. Workshop Iteration

Purpose
The purpose of a Design Workshop is to create an application from
the insights gathered during the planning phase, and with the
active participation of application Users and Stakeholders
Using tools like Encanvas, Users and Stakeholders can be fully
engaged during a workshop while the application being developed
takes shape. The absence of ‘code’ from the design environment
and the use of placeholders for design elements and data/logic
links makes it easy for Workshop participants to envision the end
solution. One click publishing means the outputs of the workshop
are visible and can be reviewed as a ‘live system’.
4.WorkshopIteration

Method
1. The scope, value and attributes of the application is pre-agreed from
the outputs of the Planning Phase.
2. A prototype is normally produced prior to the Workshop to provide a
starting point for debate and review.
3. The Workshop is led by an analyst/designer who performs the
‘building’ activities.
4. Each canvas is presented to the participants who discuss the suitability
of the design and provide feedback.
5. The analyst/designer iterates the application design until all feedback
has been adopted or acknowledged as not being appropriate.
6. Once all changes have been made the product is released for User
Testing. If a large amount of changes are needed, a follow-up
workshop may be scheduled.
4.WorkshopIteration

The Design Workshop
• A workshop involves an analyst/designer and various
stakeholders and contributors.
• Workshops take the form of a design forum where the initial
prototype is debated by participants and changes are made
iteratively to the design. Some of the changes will be made
immediately.
• Where the design needs considerable iteration, it’s not
uncommon for the workshop to be halted and re-convened
once the bulk of change requests have been applied.
• A project manager may attend to capture the change
requests and ensure the application is progressing towards its
ideal design (consistent to the Casebook outcome definition).
4.WorkshopIteration

Publishing the Application
• The outcome of the workshop phase is an application that
stakeholders believe will meet the required need.
• Once an agreement is reached by the project team that the
solution is fit for purpose ‘in principle’ it is made available as
a published application for User Acceptance Testing (UAT).
• There is no significant transition between the pilot phase and
the UAT phase given that the Encanvas platform removes any
need for platform installation, design iteration, testing or
performance tuning.
• There may nevertheless be activities such as the authoring of
help notes and documentation (and the assignment of
permissions, data structures etc.) that can delay UAT by
hours and sometimes days.
4.WorkshopIteration

User Testing
• The nature of UAT testing for a situational application is one
of further iteration that extends ‘design’ into a quasi-
operational or alpha-test mode.
• Requests for change by Users are formalized (by using tools
such as Encanvas Casebook™). All User requests are logged
and assigned to a business analyst.
4.WorkshopIteration

Documenting the Application
• Most applications require some form of documentation and instructions of
use.
• Documentation may simply to catalogue the existence of the application
and its compliance with information security policies.
• It may also include terms of use and detailed instructions to Users on what
the application is for and how to use the features of the application.
• Increasingly, User guidance is presented on-screen and in the form of help
videos which are easier for Users to learn.
4.WorkshopIteration

Making Enhancements
• Each change request received through UAT is reviewed and must be
accepted for adoption by the project manager and business analyst prior to
work being commenced.
• This prevents unnecessary work being adopted before appropriate levels of
sponsorship have been gained.
4.WorkshopIteration

Outputs
• The Output of this stage is a completed application that is
ready for User Testing.
4.WorkshopIteration

5. Publish

Purpose and Output
• The publishing process using Encanvas is painless because it is
a ‘one-click’ activity.
• Publishing an application does not mean that it is released!
• Applications may undergo several rounds of User Testing and
Iteration before being signed off for general release.
• Published applications may still lack documentation and help
notes etc. that will be created as Users become satisfied with
a version of the application.
5.Publish

6. Iterate & User Test

Purpose
The purpose of User Testing is to ensure the applications performs
as it should in operating including:
• Successful delivery of outcomes
• Usability
• Ease of learning/on-boarding for new Users
• Integrity of data model/environment and data connections
• Effectiveness of reporting tools
• Ability of technical staff to support the application
Applications may go through several cycles of User Iteration before
they are judged to be suitable for release. Fortunately, using
platforms like Encanvas, the cost of iteration is extremely low.
6.IterateandUserTest

PHASE 3.
RELEASE

7. Release

Purpose and Output
Applications are made available for GR once the Designer/Project
Manager is satisfied that:
• Desired outcomes identified in the Planning Phase have been met in
full.
• Change requests identified in the Development Phase have been
completed and no further change requests are being received and the
stakeholders believe the application has reached a point where it is as
good as it’s ever going to get.
• The application is appropriately documented and can be realistically
supported by IT helpdesk staff.
The output of this phase is a released application.
7.Release

PHASE 4.
REVIEW

8. Monitor/Report

Providing Day-to-Day User Support
• Even after General Release, Users will often make change
requests for the applications they use. How these are
actioned and delivered will vary according to the design of
the improvement and IT functions within an organization.
• Ordinarily, business analysts will be appointed to support
specific processes or parts of a business and will retain
responsibility for supporting applications in their allocated
support areas.

Tools
• Encanvas makes it easier to iterate applications during their life as the
user organization retains complete control over the application and how
it is used within their business.
• The economics of the platform mean that organizations are not penalized
for making changes to their applications as needs change. Neither are
they required to pay version upgrade costs.
• Day-to-day support of applications is made easier by administrators
having access to all deployed applications from a single cockpit (Example:
Encanvas Web Server Manager™).
• The use of a single platform removes many of the complexities of the
deployed environment. It also de-skills the support task so that one
person can support applications in their totality rather than having
multiple support experts managing discrete parts of an application.

Tools
• The ability to respond to support requests faster is aided by
Encanvas Version-Rollback™ (VR) technology that ensures
deployed applications and the Encanvas platform will always
remain on a consistent version.
• This obviates the need to load a previous platform version
before correcting a bug or application discrepancy.

9. Analyze

Purpose and Output
• Business processes and released applications should undergo
continuous analysis and review for their effectiveness and
suitability. It is the nature of business that nothing stays the
same for long and so a review cycle is necessary (and built
into tools like Encanvas Casebook).
• The purpose of the analysis stage is to identify which
processes or applications could be improved through
iteration or new development.
• Analysis data can be aggregated using an application like
Encanvas Casebook or a spreadsheet.
9.Analyze

10. Recommend

Recommending Changes to Apps
• The purpose of this stage is to make recommendations to
improve applications as the result of analysis conducted on
current and future systems requirements.
• Recommendations are logged using an application like
Encanvas Casebook or a spreadsheet.
10.Recommend

Recommending New Apps
• The CAAD process encourages the development of new
situational applications as needs arise.
• This reduces the use of shadow data and shadow systems
(self-served applications normally developed by Users using
SaaS tools or desktop applications like Microsoft® Excel,
PowerPoint, Word or Access)
• Shadow systems are not only a risk to the business, because
of the risk of data loss and non-compliance through errors in
spreadsheets (etc.), but also prohibit the effective re-use of
corporate information assets.
10.Recommend

Find out where
innovation takes you
Americas
1330 Avenue of the Americas
New York NY 10019
United States of America
t. 201-777-3398
e. americas@encanvas.com
India
B-41, Sector - 63
Noida - 201301
U.P., India
Delhi Office (US TECH)
t. 0120-4315902
e. asia@encanvas.com
Europe
Dove Cottage Offices
Marcham Road
Abingdon
OX13 6NU
United Kingdom
t. +44 (0) 1865 596151
e. europe@encanvas.com
Africa
Grapevine House
Silverwood Close
Steenberg Office Park
Tokai 7945
South Africa
t. +27 (0) 21 701 3882
e. info.sa@encanvas.com
www.encanvas.com

CAAD - Codeless Applications Development Methods and Principles

More Related Content

What's hot

Similar to CAAD - Codeless Applications Development Methods and Principles

More from Newton Day Uploads

Recently uploaded

CAAD - Codeless Applications Development Methods and Principles