Enterprise Initiatives

Many developers work in a department within IT called Application Development. This name, Application Development, represents the way we used to approach building software. For years, managers herded developers into application teams to work on stovepipe applications like order entry, warehouse & shipping, accounting, inventory, etc. As years passed, many of these applications were being purchased off the shelf like today's CRM and ERP packages. Because of this approach developers started specializing in application silos and third party packages. In many cases, these systems had entirely different data models, user interfaces, and architectures.

Now we are in the age of SOA and we are all working hard to get these legacy systems to talk to each other. Many SOA initiatives are tied to BPM initiatives. The BPM initiatives dissolve the lines between traditional stovepipe applications and allow IT to present the users with new user interfaces that hide the complexity of the backend systems. The users now can do their work through a consistent interface guided by a business centric workflow without knowing that they are accessing multiple legacy systems.

As IT shops invest in SOA to allow their legacy systems to integrate with one another, we should stop building applications and focus our efforts on building business services. We should start building services that can be used by all systems as opposed to building code that is customized to fit a specific application. We should also be proactive and think about the different ways in which a consumer might want to use our services. It is not unlikely that a service can be consumed by a user interface by one system, feed from an XML file from another system, and called directly from another service from an entirely different system. The consumers might be a new system, a legacy system, a third party package, or an external entity like a customer system or SAAS solution.

So as we move away from our traditional stovepipe approach of application development, should we still call our department App Dev? To me, application development is the thought process of yesterday and business services is how we should be thinking today. I'd like to stick a fork in the term application development because to me it represents high maintenance, duplicate efforts, silos, and IT as a cost center. I'd like to call our department Business Services Development which represents flexibility, speed to market, business alignment, and IT as an enabler. What would you call it?