CAAD - Codeless Applications Development Methods and Principles


Published on

This presentation provides an overview of the Computer-Aided-Applications-Development (CAAD) methodology for codeless software authoring. This approach is modelled on a workshop process where applications are designed in near-real-time using codeless situational applications software technology.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

CAAD - Codeless Applications Development Methods and Principles

  1. 1. ® An Introduction To Computer Aided Applications Design (CAAD)
  2. 2. AGENDA 1. Introduction 2. Process Overview 3. The Encanvas Platform 4. Application Constructs 5. CAAD Lifecycle (Methods)
  4. 4. 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.
  5. 5. 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.
  6. 6. 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
  7. 7. Organizations that have benefitted from CAAD development methods
  9. 9. Plan CAAD Process Phases 9 Phase 1 Develop Phase 2 Release Phase 3 Review Phase 4
  10. 10. 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.
  11. 11. 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.
  12. 12. 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.
  13. 13. PLATFORM
  14. 14. 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.
  15. 15. 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.
  16. 16. 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.
  17. 17. 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.
  18. 18. 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
  20. 20. 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
  21. 21. 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.
  22. 22. CONSTRUCTS
  23. 23. Start Wizard Role: • Admin or Sub Admin Users • Used to give Users the ability to rapidly configure application parameters to setup the application
  24. 24. 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
  25. 25. 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’
  26. 26. 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
  27. 27. 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
  28. 28. Data Entry Role: • For Primary User Role • Used to add new primary records where lots of fields need to be populated
  29. 29. Data Entry (Wizard Based) Role: • For Primary User Role • Used to add new primary records where lots of fields need to be populated • Streamlines data entry process for predictable data entry workflows
  30. 30. Assembly (Side-bar) Role: • For Primary User Role • Used to manage interactions with main sub-record assemblies • Normally has a repeater panel at centre with editable side-bar attribute pane
  31. 31. Assembly (Top-down) Role: • For Primary User Role • Used to manage interactions with main sub-record assemblies • Normally has a show data table at the header supported by editable form below
  32. 32. Library Role: • For Primary User Role • Used to manage ancillary documents for an application
  33. 33. 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.
  34. 34. Reports Role: • For Primary User and Sub Admin Roles • Used to manage applications reporting
  35. 35. 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)
  36. 36. Share Role: • For Primary User Role • Used to manage the URL sharing of canvas sections carrying key views, analytics or results
  37. 37. Export Role: • For Sub Admin Role and sometimes User Roles • Used to manage the import/export of data assets to the desktop
  38. 38. 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
  40. 40. PHASE 1. PLAN
  41. 41. 1. Purpose and Job Worth (Analysis)
  42. 42. 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
  43. 43. 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.PurposeandJobWorth
  44. 44. 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.PurposeandJobWorth
  45. 45. 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). 1.PurposeandJobWorth
  46. 46. 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). 1.PurposeandJobWorth
  47. 47. 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.PurposeandJobWorth
  48. 48. • 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.PurposeandJobWorth Tools
  49. 49. 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 1.PurposeandJobWorth
  50. 50. 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.PurposeandJobWorth
  51. 51. 2. Strategic Advantage (Analysis)
  52. 52. 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
  53. 53. 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.StrategicAdvantage
  54. 54. 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.StrategicAdvantage
  55. 55. 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.StrategicAdvantage
  56. 56. 3. Applications Attributes (Analysis)
  57. 57. 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
  58. 58. 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.ApplicationsAttributes
  59. 59. 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.ApplicationsAttributes
  60. 60. 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’.
  61. 61. PHASE 2. DEVELOP
  62. 62. 4. Workshop Iteration
  63. 63. 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
  64. 64. 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
  65. 65. 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
  66. 66. 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
  67. 67. 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
  68. 68. 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
  69. 69. 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
  70. 70. Outputs • The Output of this stage is a completed application that is ready for User Testing. 4.WorkshopIteration
  71. 71. 5. Publish
  72. 72. 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
  73. 73. 6. Iterate & User Test
  74. 74. 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
  75. 75. PHASE 3. RELEASE
  76. 76. 7. Release
  77. 77. 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
  78. 78. PHASE 4. REVIEW
  79. 79. 8. Monitor/Report
  80. 80. 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.
  81. 81. 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.
  82. 82. 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.
  83. 83. 9. Analyze
  84. 84. 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
  85. 85. 10. Recommend
  86. 86. 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
  87. 87. 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
  88. 88. 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. India B-41, Sector - 63 Noida - 201301 U.P., India Delhi Office (US TECH) t. 0120-4315902 e. Europe Dove Cottage Offices Marcham Road Abingdon OX13 6NU United Kingdom t. +44 (0) 1865 596151 e. Africa Grapevine House Silverwood Close Steenberg Office Park Tokai 7945 South Africa t. +27 (0) 21 701 3882 e.