Ann All had a post on Agile development brings IT, business together that had the great phrase “application development 2.0”. In the article she mentioned some very worthy objectives for this 2.0 version of application development. Here they are, paraphrased slightly.
- Encourage close collaboration between developers and end users
- Involve users in quality assurance processes
- Don’t use traditional programming languages
- Stress simplicity
- Emphasize frequent releases
- Users, not developers, should determine new features
I will come back to the bit about “Use dynamic scripting languages like Ruby, Python and Perl” in a moment. Back to the list.
I am struck by the inherent contradiction between this list and traditional development technologies – code, to be blunt. How can we expect close collaboration between developers and end users if the developers are using a language (Java, C#, Perl) that the end users cannot read? How can users do quality assurance on code they can’t read? Perhaps users can be the drivers for new features, but wouldn’t it be better if they could actually so something about the features they want? How frequent can releases be if the code must go through the usual QA/test/deploy sequence?
The answer, I think, lies in “Don’t use traditional programming languages” though it is not “Use dynamic scripting languages like Ruby, Python and Perl”. As I noted before, this very focus on programming and programmers is a barrier to progress and replacing one procedural language with another won’t help because, as Ira Fuchs put it:
Programming languages today remain syntactic, abbreviated, and procedural, as opposed to semantic, verbose, and declarative
Instead of continuing to use procedural gobbledegook that no user is going to understand, it is time to move the business logic that drives our systems in to something more useful – business rules. Looking at Ann’s list in this context we see a different perspective:
- Encourage close collaboration between developers and end users
CHECK – users can actually read and write business rules, allowing them to be equal participants in the specification of business logic. - Involve users in quality assurance processes
CHECK – ditto for checking that the rules really do what is needed because users can look at the rules and say things like “Yup, that’s what the regulation says” or “That’s our policy”. - Don’t use traditional programming languages
CHECK – use a declarative, verbose and semantically rich business rules language instead - Stress simplicity
CHECK – the ratio of business rules to lines of code is often very high, making the same functionality much simpler to specify - Emphasize frequent releases
CHECK – business users can make changes to rules that can be tested in isolation and rapidly deployed, enabling “releases” of business logic daily if necessary. - Users, not developers, should determine new features
CHECK – in fact users, not developers, BUILD the new features when those features are about the business logic in the system.
So, a business rules approach should be part of Application Development 2.0. Stop writing code, start specifying business rules.
Lastly Ann correctly highlights Agile techniques as a component in Application Development 2.0 and this is entirely compatible with the use of business rules. Indeed, I wrote an article for InfoQ on this topic – rules and agile – some time ago but it is still worth a read. It is also interesting to consider the point at which Application Development 2.0 might not really be application development any more.
Comments on this entry are closed.
I completely agree with using business rules in application development as a way to introduce agility in your operations.
I also see a lot of value in having users involved in QA and requirements specification, but the the difficulty lies in engaging people so much that they are interested in helping you. You need a criticall mass of users to achive what facebook did, for example, with its translations.
Nice thread. This article should aid the lack of application developer. Minimizes the gap between end users and the programmers.
The business analyst is going to become the critical fulcrum between lines of business and IT. Their role will change in an umber of ways and will grow to include:
o Directing IT to create enablement and empowerment through the creation of a business-centric SOA strategy that puts service and technologies that consume those services in the hands of the business
o Creating complete and prototype applications on behalf of the business that the business then modify and enrich over time
o Prioritizing the work in IT so that business critical tasks are addressed in a timely manner.
All of this is going to mean extending the ALM processes and tools out of IT and into the business with the same rigor and diligence as exists in App Dev today but without the over complex and user unfriendly usabilities issues. A new breed of Office-like tools that naturally do version control, configuration management, approvals, deployments and backouts (etc.) are emerging that users are at ease with and which integrate well with IT’s own tools for doing the same.
The focus of App Dev tools needs to shift to the business.