1. Secrets of Going Codeless
How to Build Enterprise Apps without Coding
Building applications without code still requires methods and skills. In this article I describe
the methods that Encanvas has used for well over a decade to successfully deliver situational
applications developments.
Ian Tomlin 17 May 2014
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%. And almost 70% of
black swan projects also overrun their schedules. Small wonder then why codeless software is so
appealing to businesses. Removing the code removes the re-working, the testing, the tuning – all those
big IT project teams and expert skills. Wow.
With codeless software, the programming gets removed by using point-and-click interfaces and
parameterized selections together with ready-made building blocks that work similar to Lego® bricks.
Each design element adopts the same approach to properties and configuration choices. Just like Lego®
bricks shaped to perform different tasks, codeless design blocks can be linked together with data, with
applications logic, they can share look-and-feel settings, security settings and other stuff.
Encanvas is one of those applications that does things that you wouldn’t think could be done without a
tour bus brimming with techie heads and a few million dollars of IT software. What makes it more
surprising though is that the apps created by Encanvas since 2003 – dashboard and business intelligence
apps, spreadsheet replacement apps, CRM, project management, learning management, research
portals, quality assurance and compliance apps, performance management systems, regional transport
systems…! – have all been produced with one analyst/author.
Okay… so software that lets you build things without code, a single author…got it! That’s it right? Well
not quite. Even with good tools and people there still needs to be sound process.
Computer Aided Applications Development (CAAD) describes 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.
CAAD differs from previous systems and methods - such as Rapid Applications Development (RAD) and Agile
because it uniquely morphs the role of project manager, business analyst and developer into a single role
competency. This is made possible by employing this new genre of apps design and deployment tooling that
de-skills the programming task. It does not completely remove the need for skills through!

2. Secrets of Going Codeless, Ian Tomlin
CAAD embeds IT transformation into the change process and subsumes the role of programming in the
development of business applications in support of organizational process change. 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.
How it Works
The CAAD methodology supports the entire application life-cycle. It comprises of four phases:
Phase 1 – Plan
Prior to any programming activity, a series of analyst activities are performed to determine the role, strategic
value and attributes of the intended application.
Phase 2 – Develop
This is the phase where the application is created, published, user tested and iterated.
Phase 3 – Release
This is the phase where the application is formally released.
Phase 4 – Review
This is the phase where the application is revisited and its worth is re-qualified. The nature of situational
applications (in terms of role purpose and economics) is that after a time it may be better to absorb or throw
away applications that have achieved their value.
Stages
Each CAAD phase is further broken down into stages. These are presented in an illustrative form below but
are described in more detail later in this document.
There are usually ‘system and platform’ activities that need to happen prior to the commencement of CAAD
developments. When starting from ‘ground zero’ the full process run-through looks like this:
How it works
1. A new workspace is created.
2. (Plan Phase) A business analyst/designer interviews prospective Users and Stakeholders and defines
the scope of the application, strategic value and defines the attributes of the workspace (screen
constructs, 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 Phase) 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.
5. Users test the application and feedback change requests to the business analyst. Changes are made
remotely to the web-site.
6. (Release Phase) Once the iterations have been completed, the application is signed off for general
release.
7. (Review Phase) Once released, any change requests or technical bugs are logged against the
application and, following analysis, recommendations for improvement may be made.

3. Secrets of Going Codeless, Ian Tomlin
The Key Role of Site Constructs
One of the most difficult obstacles to overcome in applications development is the knowledge and
vocabulary gap that exists between IT professionals and Users. This is usually a two-way problem given that
applications Users and beneficiaries have a deeper understanding of the role, purpose, context and
environment for which the application is intended (and may have their own lexicon of knowledge on these
subjects) whereas IT professionals have knowledge of ‘what IT can do’, how IT works, how data, processes
and logic rules need to be organized in order to work effectively, and of course they understand the language
of programming – all of which is scary and alien to Users!
The tooling used for CAAD overcomes these obstacles in part by removing the need for Users and
beneficiaries to see programming code. Instead they visualize the building blocks in a near-WYWIWYG form.
Even logic rules and links are transformed into visual indicators that non-IT people can understand. Then
applications are quickly progressed to a published stage (this is a near instant act) which means Users and
beneficiaries can see the end-result as it is being manufactured. Another way that the CAAD methodology
overcomes this knowledge and vocabulary gap is to create ‘structures’ that non-technical people can grasp.
One example of this is the use of Site Constructs.
A Site Construct is a pre-defined User Interface configuration that performs a specific function in the end
application. On the following pages we describe the constructs of a typical Encanvas application. Rarely do
applications include all of the components described here. Depending on the complexity and number of
‘jobs’ performed, the role of constructs will often merge or may sometimes not be required. So far there are
14 site constructs that are regularly used in applications design using the CAAD methodology – but this
number is growing over time. These are listed below.
1. Start Wizard
2. Keynote
3. Landing
4. Highlights
5. Work Page
6. Data Entry (standard)
7. Data Entry (wizard)
8. Assembly (side-bar)
9. Assembly (top-down)
10. Library
11. Views, Previews and Maps
12. Reports
13. Users
14. Share
15. Export
16. Meta-data
Over the following pages I describe the CAAD Methodology in detail.

4. Secrets of Going Codeless, Ian Tomlin
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’.
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 popularized 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
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).
 nd 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 analyze 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:
User Roles
 Capabilities (jobs that need doing)
 Job Outcomes Statements (how the outcome of the job is measured – such as to “maximize or
minimize ‘object’ by ‘value’ + context”)

5. Secrets of Going Codeless, Ian Tomlin
 Constraints (what prevents the job being done better)
 Corrective Importance (the value of doing the job better to the role)
Life-cycle Management
Encanvas Casebook™ is a software application that 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.
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.
About Value Innovation
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.

6. Secrets of Going Codeless, Ian Tomlin
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.
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:
 What key content entities exist that will require support in the form of a record or sub-record?
 What processes does each user role fulfil (this should come from ODI)?
 What reports does each user role require from the application – and in what format/delivery
mechanism?
 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’.

7. Secrets of Going Codeless, Ian Tomlin
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’.
Method
The scope, value and attributes of the application is pre-agreed from the outputs of the Planning Phase. A
prototype is normally produced prior to the Workshop to provide a starting point for debate and review. The
Workshop is led by an analyst/designer who performs the ‘building’ activities. Each canvas is presented to
the participants who discuss the suitability of the design and provide feedback. The analyst/designer iterates
the application design until all feedback has been adopted or acknowledged as not being appropriate. 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.
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).
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.
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.

8. Secrets of Going Codeless, Ian Tomlin
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.
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.
Outputs
The Output of this stage is a completed application that is ready for User Testing.
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 an application 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.
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.

9. Secrets of Going Codeless, Ian Tomlin
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.

10. Secrets of Going Codeless, Ian Tomlin
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.
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. Analyse
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.
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.
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

11. Secrets of Going Codeless, Ian Tomlin
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.
In Summary
The methods described here have not been applied religiously to all projects. The scope of applications, their
use cases and the needs of the customer have always come first. Nevertheless, project experiences have
demonstrated that certain things have to happen for situational applications to work irrespective of the tools
and methods employed:
1. It pays to have a plan before entering the room with a group of people and the idea of building an
application.
2. Formalizing application attributes such as data management requirements, user groups, workflows and
outcomes is really important before adding the complexity of debating needs with colleagues, users,
stakeholders! This is so much easier once preparatory work has been done.
3. Engaging with users and stakeholders to produce applications that just work is always the best fun! No
question, iterating applications without the need for back-room coding to get in the way produces better fit
apps that users want to use.
4. The WAY you evolve applications with codeless software has to be different. I guess our secret lies in
following the ‘what happens next’ for each user role and make sure every detail is taken care of. Our
thoughts are always to help to ‘get the job done better’. Outcome Driven Design teaches you that.
For programmers this isn’t the end of the world; there are lots of things that coders can do that nobody else
could – but when it comes to building software applications for business affordably, faster, better, with lower
onward support costs, you simply can’t beat an analyst with great tools and a team of users and stakeholders
around a table to communicate what matters most to them.
Ian.