Integrated Concurrent Engineering vs. Agile Software Development

Agile inspired software development is certainly all the rage.  One could argue that those processes have even crossed the chasm, with mainstream companies adopting various forms of Scrum, XP, DSDM, OpenUP and the like.  I certainly fall in the camp of people that started using Agile techniques as soon as I started to understand them (starting as early as the first publications on the c2.com wiki).

Meanwhile, over about the same time (starting in 1994 at JPL, according to Wall in “Reinventing the Design Process: Teams and Models.”), Integrated Concurrent Engineering (ICE) techniques were being tried and adopted in space systems development.  Also, some early work on concurrent engineering (CE) was published in 1996 by Prasad in Concurrent Engineering Fundamentals, Volume I: Integrated Product and Process Organization. (Note, this was 3 years earlier than Extreme Programming Explained by Beck.)  Prasad described eight fundamental principles of concurrent engineering: "“Early Problem Discovery, Early Decision Making, Work Structuring, Teamwork Affinity, Knowledge Leveraging, Common Understanding, Ownership, and Constancy of Purpose”.   ICE includes provisions and support for having a co-located customer and co-located and cross-functional teams; further, ICE is a tool for lean engineering. (A history of ICE is available starting on page 68 of http://esd.mit.edu/people/dissertations/avnet.pdf).

There has been much study (peer-reviewed and published) on the benefits (faster time to completion, lower risk of missing interfaces) and potential drawbacks of ICE (using CE when plain-old sequential engineering would due). There are almost no studies of the same type done in the Agile development world, despite emerging over about the same time period.  Why?

Words have meaning

Why is it that so many people feel it is acceptable to take words and redefine them for convenience?  Over on Herding Cats, Glen laments the borrowing and redefinition of words by the agile crowd (a crowd of which I part of until a few years back).  I am experiencing one such redefinition:  Enterprise Architecture.

I'll start with my quick and dirty definition of system architecture:  the function and form of a system and how they relate through the system concept.

To me and some others, enterprise architecture is the structure of an system where the scope is the enterprise (e.g., for profit corporation).  The enterprise architecture also describes the enterprise's relationship to outside entities such as capital markets, labor, suppliers, and customers.  Further, it describes how the enterprise system will operate and evolve over time.

To others I know, Enterprise Architecture is defined as the information technology architecture at the scope of the enterprise;  this is another example of IT co-opting a well defined term.  I personally prefer CISR's notion of how enterprise architecture and IT relate:  "A firm’s architecture describes a shared vision of how a firm will operate—thus providing a shared understanding of the role of IT."  In this way IT is a sub-system of the enterprise system.

Uncertainty Framework

Over the weekend I came across a paper by McManus and Hastings, "A Framework for Understanding Uncertainty and its Mitigation and Exploitation in Complex Systems".  The authors present a taxonomy covering uncertainty, risks & opportunities, mitigations & exploitations, and outcomes.  Then the authors cover the existing methods for dealing with uncertainty and which parts of the taxonomy are used in each method.

This is a pretty short paper and well worth the read if you are interested in all in dealing with uncertainty.