Balsamiq

A New Mockups Extension: SoftwareServant

The following is a guest post by Rob Crewdson of Software Servant, introducing this Mockups for Desktop extension.

---

Hi everyone, my name is Rob Crewdson. Peldi has given me the opportunity to write about turning your Mockups into a fully operational information system.

I want to talk about two things:

• The best method for specifying information systems.
• How to use this method to automatically build complete applications from a Ms Word specification.

The automation part may sound a bit crazy but it can be done for all sorts of information systems of any complexity.

First a bit of background.  I am based in Australia and have worked in the software industry for a very long time including more than 20 years managing international software vendor operations.

At age 25, I started my own software development house and specialised in turn-key contracts to build core business systems.  By turn-key, I mean that we would deliver a total solution on a fixed date for a fixed price.  This business model is obviously challenging but it proved to be very successful because of the method we devised to ensure that the signed-off system specification was both the business contract and the source document for the development team, ie. the customer could understand and authorise the specification and the developers could build the system from that same document without further amplification.  This meant that we always had a single authoritative document to reference.

The other main element of our method was to build the system specification by first identifying all the required system outputs and then sourcing each element of those outputs.

This method provides the underpinnings for the current method and supporting tools.

We have improved the documentation format, optimized the use of modern infrastructures and automated the development phase; however, it is fundamentally the same method that proved so successful on so many projects.

So, how do we go about turning your Balsamiq Mockups into fully operational information systems?

You have already made a great start by using Balsamiq Mockups to identify and specify the format of all of the UI outputs.  The direct user interface (UI or UX)  is not necessarily all of the output, you may also need to specify printed reports, charts and data formats used for information exchange with other applications.

Look at the video below to get a basic understanding of how you can copy Mockups to a system specification and then automatically build an executable application.

The specification method is simple and intuitive:

• Have a simple, consistent specification structure and language that can be understood and accessed by all stakeholders (use Ms word).
• Start by specifying all of the outputs including all of the required data elements (Balsamiq Mockups is great for this!)
• Each data element must have a source.  Identify the source, (eg. data entry, database Table.Column, file, XML feed, calculation, process, service, unknown).
• Specify the workflows, ie. how the UI forms relate to each other and under what conditions.
• Follow each data source to its natural end, eg. a database Table.Column or data entry.  A data source that is a process, service or calculation should be further specified in turn and a data source identified for each of its elements and so on.

When all of the data elements have been properly sourced and the UI and work flow has been approved, the specification is complete.

Easy eh! 🙂

Well, it is if you're project is facilitated by an experienced IT professional.  The rest of the project team can be users and managers from the business domain, they will be comfortable with the process and the specification document because there is no technology barrier and it just feels like the way it should be done.

From my experience, this is always the best method, both when the target application is manually developed and when the target application is automatically built from the specification.

Obviously, if you can automatically build the system you want from the completed system specification, this is a very big leap forward and a huge advantage over any alternative method.  Being able to build a running application from the specification is not only a good thing after the specification is signed off; it also means that you can build and review during the specification phase as often as you want.

The system specification is the sole source document for the system and is always consistent with the production application.

These systems are easily changed as business requirements change because you always have an authoritative specification document that tells you exactly what the current application does.  All system maintenance is done via the specification.

Have a look at some specification examples at www.softwareservant.net

Do I hear some objections?

What about Use Cases and all of that other great UML stuff? Maybe an interesting idea taken too far.  Modelling of this type can become a large project in itself; the models represent complex concepts that can create a barrier between the business stakeholders and the system being developed.

The models may be useful for expert analysts to gain a greater understanding of a large and complex problem but they have little to do with application development. Once development starts, the models are usually not maintained to be consistent with the implemented system so tend to become historic and interesting documents.  Have a look at the "Criticisms" section of the Wikipedia entry for UML.  I also came across this paper recently: it's written by UML supporters but, to me, it confirms the complexity of the method and its lack of suitability to specification and development.

We don't do all that work in the specification, you're doing a lot of the work that our developers do.  Not doing the necessary work in the specification is nothing to boast about!  This is a major reason for information systems development failure.  It's important that the business rules, workflow and data sourcing are specified while you are working with the relevant business experts in the project team before handing the project over to a separate development team.  Otherwise you lose control of the system development process and rely on individual developers to make correct assumptions regarding the project even though they may have had no exposure to the business or the project team.  A complete system specification represents detailed user interaction, data sources, calculations and conditional logic.  The specification structure and language needs to balance clarity for all stakeholders with brevity and consistency.   I think that SoftwareServant does all of this very well. The more complex calculations and processes are easily isolated into their own sections where only qualified project team members need to address them. Of course, it's not compulsory to specify completely before signing off and handing over to a development team to finish it off; I'm just promoting best practice. The basic rule is that the less complete the specification is at sign-off by the business, the greater the possibility of dispute at implementation.

We can develop a better product using Java or C# or .... because we have finer control etc.  Well, maybe some developers can but very few will and it will take them much longer and cost much more.  When you want to change the system, you are going to depend on an individual developer's source code and memory.  Further, you will require extensive low level unit testing to pick up program problems and performance issues and also require more complex software configuration management.

The engines that run the SoftwareServant applications are consistent in look and feel; performance and reliability; and they have had the bugs ironed out by multiple users.

Of course, this doesn't spell the death of programming as we know it!

There is a truly enormous mountain of software out there that will need looking after for a very long time; in fact, there is a serious shortage of skills out here.  In my visualised future, there will always be a vibrant development and technology community but not operating at the business interface layer.  At the next layer down we will still be building technology infrastructure, tools, components, interfaces, integrations, specialised chart controls, report writers etc that are used and re-used at the business design and specification level.

Feel free to ask questions and/or beat me up re: my opinions.

Cheers, Rob Crewdson

---

Thanks Rob. If you like Rob's approach, head over to SoftwareServant.net to try it out for yourself! 🙂

You can find more about Mockups extensions on our Community Page.

---