Software Blueprint

one diagram to rule the product

Courtesy: here

Building physical, tangible objects like skyscrapers, cars or even a tiny screw got schematics, blueprint, plan or a structure drawing. A civil engineer have got a blueprint for the mansions and bridges he’s constructing. A mechanical engineer has his sketches and drawings for creating machine parts. What blueprint do a Software Engineer or an Architect have?

In spite of all the Data Flow Diagram (DFD) and Software Requirement Specification (SRS), software development (at least in startup world), is borke. Business have a set of requirement, which is ill understood by the experience designer, and conveyed completely unrelated as task by task to a developer.

Courtesy : here

Dichotomy of Functional Specification and User Experience

It’s interesting to note that software usually behaves as a single entity, according to functionality requirements on one side and a user experience to make use of the functionalities effectively on the other. But, in the startup world, and for experimental projects, they both are treated separately. I know for a fact that, there are number of such software products, which were MVP (Minimum Viable Product) with the core functionality and then user experience designed after that. THIS IS WRONG!

We must treat software projects as like a single entity with inter-operable features, each designed with it, rather than on it.

But as we all know, designing and maintaining a software monolith is ultra hard. Now, how do we do it? By splitting it into small segments, but not smaller — Separation of Concerns.


Separation of Concerns

While treating the entire software as one, we must draw the line somewhere to make it legible and not look like a “code salad”. This is where separation of concerns come into picture.

Breaking to into pieces, while still maintaining the cohesiveness is the guiding principle behind Software Blueprint.

Here we are exploring a new concept of drawing, Software Blueprint, which is created by the collaboration of business, design and technology together. It will help each of the engaged parties, leave the room with higher level of clarity on way forward, and concrete requirement specification. This drawing consists of just 6 simple elements - Event, Function, Data, Data Flow, View and Task.

To Do Application — Software Blueprint

Without much of blabbering, let me introduce you to the most basic application with CRUD, a To Do application described with a software blueprint.

Let us follow the case of designing the app ground up. The process starts by defining the user actions(events) and its results(functions). Then we have to define the data elements to be manipulated by the functions (data), this takes us to the next level which is obviously the flow of data in between components* (data flow). This is followed by the user experience design (view) around the events, functions and data. Finally we have to define any offline activities like clean up or notifications or cron jobs to be added to make the user experience cycle complete (tasks).

* and in many cases, control flow as well

we use a set of symbols to represent each element in the diagram.

Event

Anything like a user action or a trigger based in space or time can be an event in Software Blueprint. Consider, a user clicking a button, or walking into a particular location as the event. In the example above, we have add To Do, list To Do etc are events which a business person could bring to the table as user actions or a part of functional requirement. It can also be an internal software trigger as well.

Function

An action to be performed by the computer. Usually triggered by an event, and a result is returned back to the event origin and/or a user view. In the above example, creating a ToDo is a function for the computer to perform. It would be a good idea to include the input and output of the function. As a rule of thumb, try to create functions as modular as possible, to make sure it's easy to debug and reuse.

Data

Data is the critical part of any information system, and so is in software blueprint diagram. Data is defined as objects containing attributes. Once events and functions are defined, we will be able to access which all data objects are to be defined and what all attributes constitutes an object. Data definition will also help the technology to identify the Read-Write as well as the Storage requirements for the product.

Data Flow

As the name indicates, data flow lines shows data moving in between the components. Data elements defined in the data block might be travelling as an object or a part (data elements can be specified on the lines) and gets operated at the functions or displayed at the view. Depending on the requirement, you may use dotted lines to describe control flow.

View

This is where the UX designer comes into the discussion. Every user interaction element should be discussed between the business and the experience designer, to create a flawless application flow, making sure user is not getting stuck at any point of time, and user can access all the relevant information and action elements.

A basic wireframe is suffice, rather than going deep into each pixels. View is towards the end of the process, to make sure that form follows function, and not the other way around.

By adopting this methodology, you can make sure that the software you are creating will be built ground up, and not a copycat or look templated.

Task

Very much like the functions, just that tasks are invoked when a predefined trigger is invoked — may be 24 hours after an event, or every 730 hours — try to think of it as something like an advanced cron job. Sending a weekly update email can fall into a task or if you are clearing the user logs every 30 days.


Just using this simple and effective diagram, you can make sure that the everyone working on the project is having absolute clarity, resulting in shipping products on-time. Working together and defining the software blueprint will make sure that,

design fits technology built; and when combined, solves the business problem.

Try software blueprint diagram on your next project and share your experience on the comments. For more like this, follow me on twitter.