In 1913 the Ford Motor Company turned on the world’s first moving assembly line. The idea was to speed up the time in which a Model T could be made, while lowering its production costs at the same time. That way Ford could, and did, charge less for their cars than other manufacturers, while paying their employees more on average than other factory workers of the day.
Likewise, most companies' IT departments think that creating an assembly line for software makes writing and assembling software more efficient. Just like Ford did with auto parts, they divide various functions of IT into their own groups, such as architects, designers, developers and testers.
IT leaders often think that once the business requirements are captured, the technical team can create almost any software easily and without complications. They believe that the architects working with the business analysts can come up with a good conceptual solution. Once that conceptual solution is completed to everybody’s satisfaction, the work can move to the next “assembly” station for designers to design. After the design is completed, work moves to the developer's shop where they develop the software, and send it on for testing. It all seems very logical and efficient, at least until you take a closer look under that hood.
In the real world, it's not quite this simple, but that doesn’t prevent some IT departments from deploying an assembly line approach. As noted, the idea of the assembly line came from the automobile industry. However, in the auto industry, the assembly line is only used to make copies of a concept car that has been fully vetted and is ready for production. The concept car is created by a group of engineers working very closely with many other distinct functional groups, including potential consumers, or in our IT department example, business people. It takes several iterations and prototyping before a concept car can be created. After its creation, it is thoroughly tested in a safety laboratory before it can be approved for production. Throughout the testing, the engineers and business people work closely to monitor and gauge the car's quality. Once it is complete, it can then, and only then, be sent to the assembly line for mass production.
Most of the time, when the business needs IT, it is for custom software development, just like creating a concept car. Therefore, the IT team and business team need to work closely together to achieve their goal. There are times when the business buys the software directly from a vendor, but even then the software always requires some customization or integration with rest of the systems in the enterprise. Recently I worked on a project to build a data mart for an analytics team composed of data scientists. We worked very closely with the team to understand their needs, and together we created various prototypes along the way. Finally, we turned these prototypes into the final product, providing this analytical team with the advantage of utilizing a data mart that was custom built for their specific needs. As a result, the analytics team is able to fulfill the needs of their customer business areas, like the actuarial and wellness care departments. Using our auto industry analogy, we designed and built the concept car (the analytics prototype), and that was subsequently turned into a production ready model (the analytics database and platform).
By way of contrast, this same company built an enterprise data warehouse using the aforementioned assembly line approach. The way the warehouse was constructed and implemented has led to frustration on the part of the business users. The following small example illustrates the constraints and problems with the software assembly line approach. After the warehouse was implemented, the claims team wanted to add one new field to correspond to a field that was added in during a maintenance upgrade of the claims system. The business request forgot to put the word “add” in their requirements document and the data modeler who was implementing the change, not fully knowing the purpose of the field, decided to put the data in one of existing fields in the warehouse. Since there was no collaborative dialogue with the business requestors, and since everyone on the assembly line worked on just their own part of the assembly line, no one questioned the request until the customer actually looked at it and said that it was not what they wanted or needed. In the end, the result was that even though this was a very small change and the business was expecting it to be done quickly and correctly, because of the software assembly line approach it required some rework and that delayed the production timeline.
The lesson here is that good software development is more like building a concept car, than it is like building Model Ts on an assembly line. And although it may seem obvious, in practice it is often given short shrift due to resource constraints and target dates: as much as is possible and practical, software development should be done using a small, tight team that collaborates with the business stakeholders every step of the way. Otherwise, the software will end up looking like the color choices for Ford’s Model T you can have one in any color you’d like, so long as that color is black.
This blog entry has been reprinted with permission.
Readers are encouraged to respond using the “Add Your Comments” box below.
The opinions posted in this blog do not necessarily reflect those of Insurance Networking News or SourceMedia.
