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?
I had written a few articles about Web 2.0 and how the younger generations have a tremendous influence on the technologies we use to communicate on the web (here and here). One of my main points was about ease of use. As IT professionals we should take lessons from the web and apply them to work. As I was drafting part two of my five part article "Are you running IT like it's your business?", my 8 year old daughter wandered in my office and asked me what I was doing. I told her I was writing a Blog and she asked me if she could write one. I created her an ID on Blogger and sent her on her way. A few minutes later she comes into my office and says, "Check out my Blog, Daddy". I typed in her blog, which was innocently named, "theseareaboutmycat.blogspot.com" and I stared at my monitor with my mouth wide open. With no instructions and no help from me she had a cute little blog about cats and dogs.
So why can't we build applications this easy for our users? Do we try to anticipate our users' every need and over design our applications? Are we making things too complex? Hmm, I see a few more articles on this topic brewing in the near future.
In the mean time, I have showed her how to add video and Site Meter to her site. I can't wait to see what she creates next!
