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 Worth2. Strategic Advantage3. Applications Attributes

Plan1.

4. Workshop Iteration5. Publish 6. Iterate & User Test (UAT)

Develop2.

7. ReleaseRelease3.

8. Monitor/Report9. Analyse10. 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 ComputerThe place where computing platforms are installed.

Client ComputerThe place where computing applications are consumed.

Secure TCIP/IP ServiceSecure two-way communications between computers

TCIP/IP ServiceStandard 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 WizardRole:

• Admin or Sub Admin Users

• Used to give Users the ability to rapidly configure application parameters to setup the application


KeynoteRole:

• 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


LandingRole:

• 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’


HighlightsRole:

• 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


WorkpageRole:


• 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 EntryRole:


• 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


LibraryRole:


• 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.


ReportsRole:

• For Primary User and Sub Admin Roles

• Used to manage applications reporting


UsersRole:

• 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)


ShareRole:


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


ExportRole:

• For Sub Admin Role and sometimes User Roles

• Used to manage the import/export of data assets to the desktop


MetaRole:

• 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. P

urp

ose

an

d J

ob

Wo

rth


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.

1. P

urp

ose

an

d J

ob

Wo

rth


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

1. P

urp

ose

an

d J

ob

Wo

rth


Needs are Constant, Solutions VaryA 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).

1. P

urp

ose

an

d J

ob

Wo

rth


MethodAn 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).

1. P

urp

ose

an

d J

ob

Wo

rth


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)

1. P

urp

ose

an

d J

ob

Wo

rth


• 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.

1. P

urp

ose

an

d J

ob

Wo

rth

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 thinkabout 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

1. P

urp

ose

an

d J

ob

Wo

rth


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)?

1. P

urp

ose

an

d J

ob

Wo

rth


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. S

trat

egic

Ad

van

tage


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.

2. S

trat

egic

Ad

van

tage


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.

2. S

trat

egic

Ad

van

tage


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).

2. S

trat

egic

Ad

van

tage


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. A

pp

licat

ion

s A

ttri

bu

tes


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?

3. A

pp

licat

ion

s A

ttri

bu

tes


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.

3. A

pp

licat

ion

s A

ttri

bu

tes


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. W

ork

sho

p It

erat

ion


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. W

ork

sho

p It

erat

ion


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. W

ork

sho

p It

erat

ion


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. W

ork

sho

p It

erat

ion


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. W

ork

sho

p It

erat

ion


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. W

ork

sho

p It

erat

ion


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. W

ork

sho

p It

erat

ion


Outputs

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

. Wo

rksh

op

Iter

atio

n


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. P

ub

lish


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. I

tera

te a

nd

Use

r Te

st


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. R

ele

ase


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. A

nal

yze


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

. Re

com

men

d


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

. Re

com

men

d


Find out where innovation takes you

Americas

1330 Avenue of the Americas New York NY 10019 United States of America

t. 201-777-3398e. [email protected]

India

B-41, Sector - 63Noida - 201301U.P., India

Delhi Office (US TECH) t. 0120-4315902e. [email protected]

Europe

Dove Cottage OfficesMarcham RoadAbingdonOX13 6NUUnited Kingdom

t. +44 (0) 1865 596151e. [email protected]

Africa

Grapevine HouseSilverwood CloseSteenberg Office Park Tokai 7945South Africa

t. +27 (0) 21 701 3882e. [email protected]

www.encanvas.com

caad - codeless applications development methods and principles

Technology