Software Factories
Software factories
On a very high level, a software factory is the assembly of pre-fabricated components connected at construction time. This is done in order to meet a product requirement.
Once a factory has assembled its parts and turned it into a product, it is delivered to the customer through the appropriate distribution channels. In the Industrial world, this all happens separately and with significant latency. All of these concepts have been successfully integrated into the hardware sector. One company that stands out in taking advantage of this concept is Dell, which does order fulfillment online, assembles it and then delivers it effectively, efficiently at a lower cost, without sacrificing quality and customer satisfaction. The customer makes specific choices about product components, and Dell assembles and finishes the product, which then arrives at the customer’s door sometime later. Most of this process is automated.
The type of software factory and business model that I am trying to lead into is conceptually the same as that above. Of course, this concept meets an obvious need, but I’ve yet to see it deliver on its promise. A great part of this is due to the fact that one size rarely fits all. However, this is surprising, because software components are more flexible to rebuild than hardware; if anything, they should be more prevalent and more advanced! We’ll leave the why out of scope for now.
Not all is bad, industry standards have emerged through the years to solve this problem and open source implementations have come a long way. Even so, solutions often need customizations to meet the slight differences in business requirements.
Before work began on PuritySoft Endeavor, it was evident that many of our modules would be reusable and easily reassembled in different contexts. This is partially because we had a vision to do so, which in fairness is not always clear because you don’t always get to choose which products to develop. We came up with products around the Endeavor concepts even written in another blog some time ago. However, this is only half of the story.
Even though a great deal of thought has been put into the design of our flagship product PuritySoft Endeavor, I could think of some modules that are useful for most users, but not for others like the Recipe module. MS Word has the problem that most customers end up paying for features they will never use and to some degree, this is necessary because some modules are difficult to decouple. This is typically due to the irony of reusability where inter-module dependencies are common in software and greatly statically defined. Runtime Type Information (RTTI) and the refection API in java have made some strides in the last few years, particularly in the Internet arena.
In terms of FileMaker Pro, you have relationships that must be put in place at development time –they cannot be dynamically loaded at runtime. While this has some security advantages, it brings some difficulties in distributing software modularly. For example, you cannot sell a standard set of functionality and offer an upgrade without requiring a new runtime build and redistribution of a 5mb+ runtime. Nonetheless, this limitation can be offset with today’s increase of Internet bandwidth. FileMaker Pro has all the database and minimum UI functionality that is required pretty much off-the-shelve to accomplish our RAD prerequisites and while not ideal, we’re sticking to it until a business has been established.
In terms of reusability, PuritySoft Endeavor has modules in other applications that we write that could integrate easily. For example, Child Care Organizer can implement a Menu module that uses Recipes and the Child module could use Contacts, Tasks and so forth.
Enough on pre-fabricated software; how about distribution of customized software?
In a similar fashion, but perhaps even more efficiently than the Dell approach, in theory, we can automate the process and immediately produce a customized solution for the customer, with an installer and everything…this is no magic formula, but I think it would work very well for the customer and might give us a competitive edge. Though the reality check is that automation will not be available immediately, and they may be that these “roll your own software” or “build your own software program” approach could bring some interesting licensing and versioning issues.
The question is, is this worth pursuing? Absolutely. It’s not the “next” thing you’ll see from PuritySoft, but do stay turned.
Ooper,
http://www.puritysoft.com
On a very high level, a software factory is the assembly of pre-fabricated components connected at construction time. This is done in order to meet a product requirement.
Once a factory has assembled its parts and turned it into a product, it is delivered to the customer through the appropriate distribution channels. In the Industrial world, this all happens separately and with significant latency. All of these concepts have been successfully integrated into the hardware sector. One company that stands out in taking advantage of this concept is Dell, which does order fulfillment online, assembles it and then delivers it effectively, efficiently at a lower cost, without sacrificing quality and customer satisfaction. The customer makes specific choices about product components, and Dell assembles and finishes the product, which then arrives at the customer’s door sometime later. Most of this process is automated.
The type of software factory and business model that I am trying to lead into is conceptually the same as that above. Of course, this concept meets an obvious need, but I’ve yet to see it deliver on its promise. A great part of this is due to the fact that one size rarely fits all. However, this is surprising, because software components are more flexible to rebuild than hardware; if anything, they should be more prevalent and more advanced! We’ll leave the why out of scope for now.
Not all is bad, industry standards have emerged through the years to solve this problem and open source implementations have come a long way. Even so, solutions often need customizations to meet the slight differences in business requirements.
Before work began on PuritySoft Endeavor, it was evident that many of our modules would be reusable and easily reassembled in different contexts. This is partially because we had a vision to do so, which in fairness is not always clear because you don’t always get to choose which products to develop. We came up with products around the Endeavor concepts even written in another blog some time ago. However, this is only half of the story.
Even though a great deal of thought has been put into the design of our flagship product PuritySoft Endeavor, I could think of some modules that are useful for most users, but not for others like the Recipe module. MS Word has the problem that most customers end up paying for features they will never use and to some degree, this is necessary because some modules are difficult to decouple. This is typically due to the irony of reusability where inter-module dependencies are common in software and greatly statically defined. Runtime Type Information (RTTI) and the refection API in java have made some strides in the last few years, particularly in the Internet arena.
In terms of FileMaker Pro, you have relationships that must be put in place at development time –they cannot be dynamically loaded at runtime. While this has some security advantages, it brings some difficulties in distributing software modularly. For example, you cannot sell a standard set of functionality and offer an upgrade without requiring a new runtime build and redistribution of a 5mb+ runtime. Nonetheless, this limitation can be offset with today’s increase of Internet bandwidth. FileMaker Pro has all the database and minimum UI functionality that is required pretty much off-the-shelve to accomplish our RAD prerequisites and while not ideal, we’re sticking to it until a business has been established.
In terms of reusability, PuritySoft Endeavor has modules in other applications that we write that could integrate easily. For example, Child Care Organizer can implement a Menu module that uses Recipes and the Child module could use Contacts, Tasks and so forth.
Enough on pre-fabricated software; how about distribution of customized software?
In a similar fashion, but perhaps even more efficiently than the Dell approach, in theory, we can automate the process and immediately produce a customized solution for the customer, with an installer and everything…this is no magic formula, but I think it would work very well for the customer and might give us a competitive edge. Though the reality check is that automation will not be available immediately, and they may be that these “roll your own software” or “build your own software program” approach could bring some interesting licensing and versioning issues.
The question is, is this worth pursuing? Absolutely. It’s not the “next” thing you’ll see from PuritySoft, but do stay turned.
Ooper,
http://www.puritysoft.com
posted by ooper at 5:00 PM
1 Comments:
Hi I just come across your blog about recipe management software and I thought I'd let you know about the number one company in recipe management software
Post a Comment
<< Home