You will be redirected in 30 seconds or close now.

ColdFusion Authors: Yakov Fain, Jeremy Geelan, Maureen O'Gara, Nancy Y. Nee, Tad Anderson

Related Topics: ColdFusion

ColdFusion: Article

CFDJ Feature — An Introduction to Intent Driven Design

A practical approach to specifying projects

Often the hardest part of developing an application is getting agreement on what exactly it should do.

Intent Driven Design (IDD) is an approach that simplifies and standardizes the process of getting detailed technical requirements from non-technical business users so you can develop more complete and consistent requirements in less time.

The Importance of Intent
One of the most frustrating elements of application development is having to continually change the way an application works because of conflicting requirements from different stakeholders. Most such problems come from the lack of a clear focus for a site. You have to agree, in writing, with all of the stakeholders - why you're building the site, who will use it, and what their motivations will be - before you can even start to discuss how the site should work. If you don't, you are guaranteed weeks of wrangling as different stakeholders disagree on fundamental design decisions or priorities because of the lack of a shared vision for the site - often after much of the application has been coded.

The goal of IDD is to provide a standard but lightweight approach to capturing all of the key information that you need to specify a site. For a simple site, you might be able to go through the entire process in a couple of hours. For a more complex project, you might be discussing the issues raised for a number of weeks. Either way, you should end up with a well-structured set of somewhat traceable requirements that you can provide to your development team, and use to turn the high-level business objectives into the appropriate code to achieve those agreed objectives.

No Silver Bullet
In his classic book "The Mythical Man Month," Frederick P. Brooks wrote an entire chapter about an important distinction between "accidental difficulties" and "essential difficulties." For example, memory management/garbage collection is accidentally difficult - it is a problem that can be solved with a smarter programming language (Java or C# instead of C++). However, building a flexible object model for a real world application is actually difficult - there is no "silver bullet" (methodology, IDE, code generator, etc.) that can make this fundamentally difficult problem simple.

So, IDD is not a silver bullet. It doesn't make it easy to specify complex systems or to handle conflicting requirements. However, it does allow you to clearly and consistently document why you're building the system and what each group of users is expecting from it. It also allows you to "start at the beginning" with a formal process that lets you lock down the objectives which drive the tasks, which drive the screens and actions, which, in turn, drive the data model and the scripts required to implement the requirements. In short, it tries to simplify the process of capturing requirements in a way that doesn't require a degree in computer science to understand!

How Big Is Too Big?
It is often better to build a small project to meet a limited, but valuable, business intent than to try to put your entire business online, delaying the benefits of your supplier extranet or online store, while trying to decide exactly what format your online job application form should take or how to track vacation days online. I have found that if I have more than three to five major intents for a given phase of a project, unless they are being handled by independent teams, I'm probably going to end up with problems.
Too many intents make it hard to keep the focus required for developing a great site, and they increase the likelihood that different intents will conflict, leading to a "nobody likes it, but nobody hates it" kind of compromise design. Overly ambitious projects are also much more likely to ship late or even to fail to ship at all.

This doesn't mean that you can't specify complex applications using Intent Driven Design. It does mean that you might want to break down large, complex projects into smaller projects, and run through the IDD process for each phase. My general rule-of-thumb is that, if the coding (excluding specification, testing, revisions and deployment) for a phase takes more than a couple of weeks, the phase is too big. With application generators becoming more common, there are very few collections of 10-to-20-use cases that take more than a couple of weeks to implement (assuming two-to-five-use cases per programmer over the two weeks, and a maximum team size of five developers before you need a more robust methodology).

These estimates exclude "rocket science," where you're trying to solve fundamentally hard technical problems (such as seamlessly integrating Hibernate with ColdFusion). They also exclude "lab experiments" where issues like performance or load are critical and you may need to build a couple of prototypes before you find the right approach. Such projects can take orders-of-magnitude more developer time to complete, but can still benefit from the IDD approach.

Business Intent
The first step in IDD is to write a paragraph describing the business intent. Why bother building the site? What exactly will it do for your organization? Writing down and agreeing on the business intent upfront makes many of the later decisions easier by creating a shared focus. If the intent is to increase your online sales, the job board and the HR benefits pages are not essential to that intent so they can be pushed off to phase 2.

What people (and computer systems) are going to use the site? From a requirements-gathering perspective, it is usually best to break down your audience by the collections of tasks they will want to perform (as opposed to by demographics, psychographics or other such approaches). A given user will often perform multiple roles, so you may well have users that are both customers (for buying things online) and administrators (for managing site content), or are both sales people (for accessing the sales reporting system) and employees (for accessing HR benefits online). Roles in a typical project may also include one or more classes of administrators, such as data entry, content editors, approvers and reviewers, and may also include various reporting-based roles.

Roles are not always performed by a person. To capture all of the tasks that the system needs to support, you might also have roles for scheduled tasks, imports, exports or any web services and other interfaces that you provide.

Role Intent
Once you've identified all of the roles, the next step is to document the key reasons why each role would be performed. By documenting why a customer would choose to order online, or what business information a manager is looking for from an online report, you will be able to make better design decisions regarding trade offs such as balancing ease-of-use with flexibility. Also, if there is no good reason for someone to use your website, they probably won't use it. You will only achieve your objectives from your site to the extent that you help your users get what they want out of it. Don't worry if not every role has a meaningful intent, but do go through the process as you'll capture distinctions that will help when you're working on the detailed design.

Compare your role intents with your overall business intents to make sure they are consistent. If you want to increase revenues and your customers want to place orders online 24/7, supporting that intent will meet their needs and yours. However, if your customers want to be able to find the lowest cost supplier, that is probably not an intent you want to support within your site as it is unlikely to help you increase your sales.
For a medium-sized e-commerce system, you can probably document the business intent, roles and role intents on just two or three sheets of paper. Indeed, with a small team (one to five developers), if you have much more than three sheets of intents, you will probably find it hard to deliver a system that can achieve them in a timely manner.

Essential Tasks
Once you have a list of roles and their associated intents, the next step is to figure out what functionality your system must provide to help achieve your business intent by helping your users achieve their goals.

A task is just another name for what most programmers would call a "use case." We've found that by calling it a task, our non-technical clients grasp the concept more easily. A task is a series of screens and actions that allow a user to achieve a valued outcome. Examples might be "order products online," "check order status" or "compose email newsletter." The specification for each task should include any alternate paths (along with their screens and actions) for different choices and for handling error conditions.

Now, instead of having the usual "wouldn't it be cool if the site could . . ." discussions, you can come up with a much more focused list of tasks by asking what exact tasks the site must support to allow each of the roles to achieve their intents, and in a way that helps the organization get what it wants from the site. I tend to focus on essential tasks (as opposed to "nice to haves") as I prefer to deliver the absolute minimum amount of software required to meet a useful set of business and role intents. If you want, you can add "nice to have" tasks depending on the time and budget constraints on your projects, but classify your tasks into essential, useful and optional so that you can deliver the most important functionality first.

More Stories By Peter Bell

Peter Bell is CEO/CTO of SystemsForge (http://ww.systemsforge.com) and helps Web designers to increase their profits and build a residual income by generating custom web applications - in minutes, not months. An experienced entrepreneur and software architect with fifteen years of business experience, he lectures and blogs extensively on application generation and ColdFusion design patterns (http://www.pbell.com).

Comments (2)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

IoT & Smart Cities Stories
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
Chris Matthieu is the President & CEO of Computes, inc. He brings 30 years of experience in development and launches of disruptive technologies to create new market opportunities as well as enhance enterprise product portfolios with emerging technologies. His most recent venture was Octoblu, a cross-protocol Internet of Things (IoT) mesh network platform, acquired by Citrix. Prior to co-founding Octoblu, Chris was founder of Nodester, an open-source Node.JS PaaS which was acquired by AppFog and ...
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
Cloud-enabled transformation has evolved from cost saving measure to business innovation strategy -- one that combines the cloud with cognitive capabilities to drive market disruption. Learn how you can achieve the insight and agility you need to gain a competitive advantage. Industry-acclaimed CTO and cloud expert, Shankar Kalyana presents. Only the most exceptional IBMers are appointed with the rare distinction of IBM Fellow, the highest technical honor in the company. Shankar has also receive...
The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addr...