While commuting to office, I noticed that Wipro is developing software factory model which will improve their delivery model. This made to think how well a factory model will fit in software development where human skill makes the difference. This is an experimental model based on Toyota Manufacturing Model.

Software factory is all about about assembling components (or plugins) to incrementaly build the application. This suits good for a product development platform.

How Wipro can leverage this for the services they offer? My guess is

1. Wipro is not building the components which will help in assembling.

2. Wipro’s process maturity will ensure the quality of product. The vast knowledge of Wipro’s large talent pool has to be documented, developed as a process to apply them in their delivery model

3. Any average engineer by following the processes rigidly can ensure the consistent quality.

How this will impact the people

1. Organizations with robust factory model need not always recruit the best guy and pay more. Any average guy who follows the process will be sufficient.

2. Opens the gate for average people and keeps the attrition in check. People skill will become commodity and might be referred as as Software Assembler

3. Engineers who build the components for assembling and who document the knowledge base and converts them as the software process will be in great demand.

As usual Wipro has shown great business acumen in adopting this approach. We need to wait and watch how this fits in Wipro’s delivery model.

SOA is touted as it going to remove all the integration pain points. But with disparate technologies and platforms supporting the services within the organization, managing the softwares is a big pain. Managing the end points and configurations to support *ability (maintainability, extensibility, availability… ) are becoming a operations nightmare in managing them in high SLA environments where penalty clauses are included for service non availablity. Everybody will prefer a platform where services autodiscover others and manage the connectivity themselves during failovers. You can incorporate this when you are working on greenfield project or with a refactoring budget. But during the course of a release, if you (as a developer) want to refactor to make your life better, you can put the following things which will help both development and operations. The following is mostly based on webservices. I will put another post for ESB models.

1. Separate the application and connectivity configurations. Let the operations manage the connectivity configurations. Application configuration has to be managed by developers and released to operations. If a application configuration changes frequently, let operations handle that parameters. Configuration loader has to manage it intelligently.

2. Put singleton configuration loaders to load the configurations and have a JMX or similar module to support refreshing. With this we can avoid restarts in high SLA environments.

3. Put the heart beat monitors to check the health of other services. By taking proactive steps, we can minimize the impact due to non-availability.

4. Put a seprate monitor to monitor the health of your service. With this you will not let down your consumers during a critical work flow.

5. Design the application for failover.

HCL is now making lot of right noices to build their brand in India. They unleashed HCL Talking Numbers campaign in the indian television channels now. I liked the innovative idea of using ‘0′ and ‘1′ in the campaign. You can find the campaign videos here. Also you can find here how this was conceptualized and made.

The success of Google homepage and iPod supports the theory of Simplicity combined with easy of use is the winning formula for the products. Philips is taking this forward through their “Sense and Simplicity” campaigns where they drive the message that their products are designed with customers experiance in mind. Hiding the complexity from the users and allowing them to experiance the product will bring users much close to the product and viral market the product. Probably Is this the reason the web2.0 applications are in perpetual beta (but Flickr moved to gamma) allowing the users to discover the features and market them to their peers.