An interesting post caught my eye recently – Should we still call it Application Development? This seems like an interesting question, particularly when you start considering the decomposition of the application that has taken place over the last decade. Not so long ago, applications (especially enterprise applications) were monolithic. They handled their own data, user interfaces, business logic, and process flow in one block of code. Over time we have decomposed these applications – managing data in a database that ran across applications, using portals and other clients to manage the user interface across applications and, most recently, BPMSs to externalize workflow and build cross-application flows effectively. With enterprise decision management, EDM, we take the final step by separating out the decisions and managing them so they too can be shared across applications.
After all, if you embed decisions – business logic – in your applications, you hide these decisions from view and risk those decisions becoming a liability when the world changes and they do not. Most application development techniques hide decisions inside applications. This makes development, and even more maintenance, very expensive.You might also delegate details to programmers when you want to have those programmers collaborate with business users on the required logic. Applying EDM you can empower business users to manage those decisions, which reduces the time to make changes and reduces maintenance expenses.
As IT shops stop building “applications” and start building “services”, application development seems like a less and less useful name for what they are doing. One could view them, as Mike does in his post, as being responsible for the development of business services as well as, presumably, for the orchestration and assembly of solutions built from those services. Now decision services (wiki), in this model, are a subset of all business services (as I discussed here). I believe that most of the value add of custom development comes from building your own distinct decision services. These unique decisioning components can then be mixed with packaged services purchased from standard best practice libraries and still deliver unique experiences for your customers. Perhaps even “business service development” is too broad, perhaps we should just talk about “decision service development”? After all, IT resources are scarce and perhaps we should pick our battles.
Comments on this entry are closed.