Appreciate all the insights & discussion - I am reconsidering some of my
assumptions now with respect to applications development. I still think
that it is always going to be the least deterministic IT process area,
relatively speaking. And in industrial terms, it's probably equivalent
to new product development - a comparably risky area, at a guess.

My focus for the next period of time however is going to be on the
infrastructure question. I think we all can agree that there is no
reason *that* can't be handled with industrial precision.

Charlie


On Tue, 18 Nov 2008 15:40:04 -0000, "Oliver Sims"
<oliver.sims@...> said:
> Charles,
>
> You said:
> > The fundamental difficulty for this is
> <http://en.wikipedia.org/wiki/No_Silver_Bullet> well stated by Fred
> Brooks
> among others: software development has essential complexity and is
> therefore
> not easily repeatable.
>
> I'm don't think this is necessarily true. Certainly the industry (at
> least
> in the enterprise application development area) is peculiarly resistant
> to
> adopting a certain set of approaches and techniques that has been proven
> to
> reduce complexity both accidental and essential. This resistance, in my
> experience, derives from (1) the perceptible (but not absurd) additional
> up-front cost, (2) from the sad reality that the necessary initial
> (set-up)
> projects typically last longer than the sponsoring IT exec's remaining
> tenure in post, and (3) because of the mind-set change required by those
> participating. (The main mind-set change required is that the job of an
> architecture group is to make life as simple as possible for the people
> who
> actually design and produce the application code. This means that the
> architecture group needs not only good infrastructure architects but also
> good software engineers.)
>
> Btw, the set of techniques and approaches are described in several
> places,
> including a book - "Business Component Factory" - which Peter Herzum and
> I
> co-authored some years ago.
>
> Just a thought...
>
> Oliver
>
> PS: The change I'm talking about has little to do with choice of
> development
> methodology.
>
>
>
> -----Original Message-----
> From: erp4it@yahoogroups.com [mailto:erp4it@yahoogroups.com] On Behalf Of
> Charles T. Betz
> Sent: 17 November 2008 02:02
> To: erp4it@yahoogroups.com
> Subject: [erp4it] MRP for IT
>
>
>
>
>
>
> MRP for <http://erp4it.typepad.com/erp4it/2008/11/mrp-for-it.html> IT
>
>
> 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
> <http://en.wikipedia.org/wiki/No_Silver_Bullet> Brooks 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
> <http://erp4it.typepad.com/erp4it/2008/05/erp-for-it---my.html>
> "evocative and provocative" 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
> <http://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0884270610>
> Goal,
> 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
>
>
>
>
>