There's been a lot of talk about IT and software "industrialization" lately -- the idea that software development can be broken down into standardized, low-level, highly automated tasks that can mass produce applications on demand, at low cost.
Does software really belong on the assembly line?
At IBM's Pulse event last week, IBM Tivoli's Al Zollar said that IT industrialization is the next great phase in information technology. (I've been trying to get either a transcript or recording of Zollar's speech to get more details, but IBM hasn't been able to produce one up yet -- so all I have for now is a press release.)
Nevertheless, there's been thinking out there for some time that software development is evolving from a craft -- painstakingly undertaken one project at a time -- to a more of a mass production mode. How far along is that vision, and is it even an appropriate vision?
Eric Newcomer has had some interesting things to say lately on the subject of IT and software industrialization. A few months back, he discussed whether the automobile analogy -- a la Henry Ford's assembly line -- fit the mold for software creation today. He concludes that while companies continue to look for ways to squeeze costs and increase productivity, you simply can't take a process as sophisticated as software development and break it down into low-level tasks that can be assumed by commodity priced outsourcing shops:
"The Ford analogy can't work. You cannot really get lower skilled, untrained developers to tackle sophisticated problems such as component reuse. They can create simple objects incorporating business logic, and to use one description, the plainer the old Java object (POJO) the better.... What we need are not simple tools for business analysts to compose services into flows. We need sophisticated tools for architects and designers to import POJOs and plain old anything else, check them for conformance to the plan, and fix them up for deployment. What's the right analogy here? Farming?"
Eric recently followed up on this post with more thoughts on the subject, wondering if there actually won't be some sort of third way for software production -- perhaps more in patterns than industrialization. As Eric puts it: "I am not sure any clear recommendation is emerging for how to improve the software development process. So now I am wondering whether we can get at this problem through patterns." He cites the Apache Camel project as an example of standardizing enterprise integration through patterns:
"If we look at patterns, and how Camel is representing them in software, we see a different type of abstraction being used - basically a variation on the theme of domain specific languages. The domain in this case being integration, and the realization of integration patterns in particular. One of the challenges of DSLs is integration in fact - that is, how do you join together programs written using different DSLs into a system or application? It sounds like a crazy idea, but what if we were to use integration techniques, such as patterns, themseleves implemented using DSLs, to join programs together written using other DSLs? Would we have the abstractions right? I.e. in the language instead of in pictures or interfaces? And would we be able to assemble programs together quickly and easily? Maybe we need some patterns specifically for application assembly?"
Eric raises some good issues. There is also the point to be made that on a macro scale, we have moved out of the Henry Ford-ish industrialization era to one of the "prosumer" (a termed coined by Alvin Toffler). That is, consumers have the power to design and customize their own products and services. This is what we're seeing in software as well.
First, we're all becoming both creators and consumers of services -- that line is blurring more every day. Second, more of the creation is being pushed out to the consumers -- in the case of enterprise, the business users. Third, there's that whole "Lego Block" analogy, which suggests that applications can be built to order -- perhaps by users themselves -- from pre-assembled components. These components may have been built by developers elsewhere in the enterprise, by a vendor, or by open-source communities.
Eric mentioned farming as a better analogy -- perhaps homebuilding as well?