Charlie, thanks for taking your blog in this direction.  I believe there are many more parallels between traditional manufacturing and software development.  In both cases we are developing products.  The fact that software is more complex and dynamic than physical products doesn't make it less of a product. A couple of areas that might be worth exploring are mass customization and lean manufacturing.

 

Mass customization has some parallels with software development since it strives to achieve products of 1 produced in a highly efficient manner.  We live in a world where you can order fruit rollups with a personalized message for $1 each and have them delivered to your home in two weeks (check out http://www.myfruitrollups.com/).  This is what we are trying to do with SOA – namely, the ability to deliver a business solution quickly by leveraging reusable components.

 

Lean Software Development is an agile approach that translates lean manufacturing principles and practices to the software development domain. It was adapted from the Toyota Production System and introduced by Mary and Tom Poppendieck in the book  Lean Software Development in 2003. I didn't read their first book, but I did read their second book, Implementing Lean Software Development published in 2006. Lean Software Development can be summarized as seven principles similar to lean manufacturing:

1.      Eliminate waste

2.      Amplify learning

3.      Decide as late as possible

4.      Deliver as fast as possible

5.      Empower the team

6.      Build integrity in

7.      See the whole

 

For example, eliminating waste in manufacturing involves things like a) in-process inventory – a software parallel is undocumented code or uncoded documentation, b) over-production – a software parallel is produced gold-plated applications or shared SOA services for future needs that may never be used, c) extra processing – a software parallel is unnecessary meetings to generate requirements or multiple integration hops when a point-to-point link will do, d) transportation – a software parallel is handoffs between teams in a waterfall methodology, e) motion – a software parallel is task switching or interruptions, f) waiting – a software parallel is related to the problem of why it takes 6 months to put even a tiny piece of software into production which suggests that our batch sizes (i.e. releases) are way too big, and g) defects – there are no shortage of parallels in this area – software development could really take advantage of error-proofing techniques.

 

Mary and Tom's book is exceptionally well written both as a learning tool (each chapter wraps up with suggested exercises to reinforce the key lessons) and as a reference since it contains many attributions to other books and research.

 

Both of these technique – mass customization and lean development – are, in my opinion, perfectly applicable to the problem of enterprise data and application integration.  A typical Fotune 500 company builds hundreds (or thousands) of integrations per year that are all based on a pretty small number of patterns.  Why not build them using factory concepts rather than creating works of art by artisans.

--- In erp4it@yahoogroups.com, "Charles T. Betz" <charb@...> wrote:
>
> MRP for IT <http://erp4it.typepad.com/erp4it/2008/11/mrp-for-it.html>
> I have been posting about "ERP for IT" for some years now. While I have
> been generally familiar with the history of ERP (Enterprise Resource
> Planning) and its origins in MRP (Materials Resource Planning), my
> background is in the social sciences and software engineering - not
> operations research or industrial engineering.
>
> The relationship of software development to industrial engineering has
> been uneasy. I believe that attempts to make software development more
> predictable through increased process rigor and measurement have been
> at best partially successful. Yes, software development can be
> treated as engineering. Is it always optimal to do so? That is the
> question.  
>
> The fundamental difficulty for this is well stated by Fred Brooks
> <http://en.wikipedia.org/wiki/No_Silver_Bullet>  among others:
> software development has essential complexity and is therefore not
> easily repeatable.
>
> However, this blog is not about software development per se; it is about
> large scale IT management as an industrial process.
>
> If we isolate the particular problems of software requirements, design,
> and development from the broader concerns of the IT service lifecycle,
> we may find other areas more amenable to industrial theory. In
> particular, in the large IT organization, the forecasting and
> provisioning of base computing infrastructure (space, power, cooling,
> cabling, network, storage, CPU, RAM, & the stacks of commercial
> software products supporting functional applications) is a highly
> complex and critical set of concerns.
>
> ITIL and ITSM have adequately stated the tactical concerns around
> operating such infrastructure. However, provisioning the IT
> infrastructure may consume tens or hundreds of mllions of dollars in
> capital budgets annually in the large IT organization. And it is my view
> that the acquisition and integration of complex hardware and
> software products and sub-assemblies into serviceable production
> infrastructure is directly comparable to manufacturing.
>
> In fact, it *is* manufacturing in every sense, except the final
> disposition of the asssembled (manufactured) product. Instead of a sales
> pipeline, the computing infrastructure is placed into service in a data
> cente where the higher order (and less deterministic) application
> lifecycle then comes into play.
>
> The question for the large scale IT shop that finds itself in the
> manufacturing business: are you ready for the challege? How are
> you approaching demand forecasting? Manufacturing constraints?
> Process engineering? Metrics?  Do you have an end to end view of the
> production line?
>
> These are the questions I'm considering lately. My first pass through
> "ERP for IT" was "evocative and provocative
> <http://erp4it.typepad.com/erp4it/2008/05/erp-for-it---my.html> " as I
> stated in my book. It's time for a second more detailed reading of where
> operations theory and industrial engineering intersect with the
> particular problems of running the largest IT capabilities.
>
> I have started by re-reading The Goal
> <http://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0884270610> ,
> and now going through core operations management texts, including all
> source material I can find on the origin of Materials Resource Planning.
>
>  Suggestions appreciated.
>
> ctb
>