Enterprise Systems: The Wrong Way
@TimBray has a great post contrasting modern web development to how large enterprise IT shops operate. He discusses this as a huge opportunity area and I couldn't agree more.
While this is true, we must not forget that large enterprises have piles of existing systems that they can not throw away. There are no green fields in your typical large enterprise and I believe the secret is finding a new approach to melding the Web way of doing things with the incumbent systems that inhabit the enterprise. Of course, this starts to sound like the same promise SOA made, but I maintain that your "modern" Web applications is as much of an SOA based application as anyone could have imagined 10 years ago. It's just that apps like Twitter, TripIt, etc. take a completely different approach to development, deployment, and change. Twitter, for example, has figured out how to roll out early features to targeted sets of customers without completely disrupting their entire user base. They did this with Lists and Re-tweet. In a typical IT shop, such features would typically require full scale re-deployment and it would be next to impossible to roll out "beta" features to select users in a production environment. Instead, your typical IT shop would clone the production environment (with a huge cost for the hardware and manpower to support it) and then deploy the modified application there for "user acceptance testing" requiring users to switch to a completely different system to test the new feature. Twitter not only did a targeted rollout, but they did it in their production environment. This would almost never happen in big IT.
I wonder how the development teams at Facebook, Google, Twitter, etc. track their productivity and defect rates. I think sometimes the agile style methodologies forget about some of the engineering fundamentals that help us grow as developers. In any case, I don't remember seeing that many defects on Facebook, et. al. (comparatively speaking) so whatever they are doing, they are doing well...and fast. As someone who works at the one of the world's largest software companies and has worked with many large IT shops over the past 10 years, I can tell you these types of organizations have much to gain from focusing on this one principal: remove the unecessary complexities and processes and focus on delivering value to the customer.
...Orders of magnitude wrong. Billions and billions of dollars worth of wrong. Hang-our-heads-in-shame wrong. It’s time to stop the madness.
This is where the opportunity is. How do we bring the efficiencies and scale of modern Web development to large enterprise IT? Disciplines like TDD where you take an outside in approach to application design, and "release early, release often" as seen in the open source world and in the Web 2.0 world are typically not seen in large IT shops.
The community of developers whose work you see on the Web, who probably don’t know what ADO or UML or JPA even stand for, deploy better systems at less cost in less time at lower risk than we see in the Enterprise.
While this is true, we must not forget that large enterprises have piles of existing systems that they can not throw away. There are no green fields in your typical large enterprise and I believe the secret is finding a new approach to melding the Web way of doing things with the incumbent systems that inhabit the enterprise. Of course, this starts to sound like the same promise SOA made, but I maintain that your "modern" Web applications is as much of an SOA based application as anyone could have imagined 10 years ago. It's just that apps like Twitter, TripIt, etc. take a completely different approach to development, deployment, and change. Twitter, for example, has figured out how to roll out early features to targeted sets of customers without completely disrupting their entire user base. They did this with Lists and Re-tweet. In a typical IT shop, such features would typically require full scale re-deployment and it would be next to impossible to roll out "beta" features to select users in a production environment. Instead, your typical IT shop would clone the production environment (with a huge cost for the hardware and manpower to support it) and then deploy the modified application there for "user acceptance testing" requiring users to switch to a completely different system to test the new feature. Twitter not only did a targeted rollout, but they did it in their production environment. This would almost never happen in big IT.
It’s like this: The time between having an idea and its public launch is measured in days not months, weeks not years. Same for each subsequent release cycle. Teams are small. Progress is iterative. No oceans are boiled, no monster requirements documents written. And what do you get? Facebook. Google. Twitter. Ravelry. Basecamp. TripIt. GitHub. And on and on and on.
I wonder how the development teams at Facebook, Google, Twitter, etc. track their productivity and defect rates. I think sometimes the agile style methodologies forget about some of the engineering fundamentals that help us grow as developers. In any case, I don't remember seeing that many defects on Facebook, et. al. (comparatively speaking) so whatever they are doing, they are doing well...and fast. As someone who works at the one of the world's largest software companies and has worked with many large IT shops over the past 10 years, I can tell you these types of organizations have much to gain from focusing on this one principal: remove the unecessary complexities and processes and focus on delivering value to the customer.
