Lifecycles for a system of systems

Following on from the previous post, I was wondering whether any of the established lifecycle views really fit with a systems-thinking view of the enterprise as a system of systems. With a software engineering background, the first lifecycles that come to my mind are those for software development, e.g.:

• Waterfall - the sequential flow from requirements via analysis, design, coding and test to operations, often credited to Winston Royce. Note even in Royce's original paper on this from 1970, iterations and routes back to previous steps are anticipated.
• Spiral - as in Barry Boehm's original from 1986. Note how this includes the customer at the opposite side of the cycle (i.e. accepting objectives for the next iteration) from release (i.e. passing user acceptance testing). Also, this seems close the Deming plan-do-check-act (PDCA) cycle that's applied in ITIL continual service improvement.
• Agile - I guess the core of Agile is defined by the 2001 manifesto, but the earlier Scrum is a more concrete process based on it. I've also saw software developers naturally adopt Extreme Programming (XP) methods (like paired programming, test first and customer inclusion) before Kent Beck published. I'd like to say more on this in later posts too. 

But through experience of applying enterprise architecture to public sector systems integration problems especially, I now use some other lifecycles as points of reference:  

• The V model - which can bee seen as a way of rearranging the waterfall so that the link from earlier to later steps can be shown. The INCOSE Systems Engineering Handbook has a reference lifecycle, though I don't think the actual V diagram was in the version I used; it is a standard in Germany though. This works better for large systems than a simple waterfall, as the difference between testing components of an architecture, the design's verification and the validation of the solutions' integrated behaviour is clear.
• CADMID - the sequence of concept, assessment, demonstration, manufacture, in-service, and disposal was used by the UK MOD and others (e.g. for teaching at UCL). This sequence partly reflected the bureaucracy of different stakeholders, especially when the roles of capability sponsors and procurement were clearly split (set up for good reason, considering the costs and risks in MOD programmes that are both critical and innovative). 
• The TOGAF ADM - which in contrast seems targeted at business change programmes (for example, rationalisation of a business and its systems following the merger of two organisations). 

A few questions could guide thoughts on applying these:

1. How do these apply to the more organic evolution of a system of systems? 
2. What does that mean for stimulating and exploiting innovation?
3. So which is/ should be the reference to follow for a council's information systems?