OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Re: XML As Fall Guy


These are all good points (and distinctions). 

One thing that many of these failed projects have in common is that they are SYSTEMS, and for all that we title ourselves system architects the reality is that systems are hard because complex systems are interdependent. Reductionism will take you only so far, and then feedback begins to change the nature of the system, and this holds as true (perhaps even more true) for developing systems as it does for maintaining them.

In so much as the term has become pretty meaningless, any architect is, has to be, a systemic thinker. To the extent that these projects fail, most do not do so due to a single component failure. They fail because they are systemically poorly designed - integration can't happen without a lot impedance, there's a lack of consistency with regard to data models, there are no ways of routing around a failure point. I think a point in favor of agile is that it encourages systemic understanding of the problem domain and how any solution much integrate, but even that's not a panacea when there's a failure of architecture.

In many respects the political aspects of a project should be seen as a side-show. Pointy-haired managers will always be clueless, because for the most part, they lack the technical expertise to understand the systemic nature of the process. The procurement process will always seem byzantine and inherently unfair because money is involved, and everyone will want to water their fields first before letting the river move on to the next farmer. Yet at a technology level, you need to have a person (or people) who both understands the technical challenges and can nonetheless keep a systemic view of the problem in sight. I'm not sure this is leadership - an architect is not in general a leader or even a manager. It's something different, and I don't think we are, collectively, very good at it yet. 

Kurt Cagle
Invited Expert, XForms Working Group, W3C
Managing Editor, XMLToday.org

On Sat, Nov 30, 2013 at 7:11 AM, Thomas Passin <list1@tompassin.net> wrote:
On 11/28/2013 1:46 AM, Stephen Cameron wrote:
My theory is that the idea of issuing tenders, which is based on
defining requirements up front, is just plain wrong for complex software
systems, that are essentially part of the culture of an organisation.

The problem of writing requirements up front is that one often can't know all the important aspects of the problem until one gets well into trying to solve it.  Same with quoting a project - early on, you can't quote with precision unless the job is very similar to others you have done.  But a contractor has to know what it's bidding on in good detail, so you can't just leave lots of details until later.

The only solution is to get people with the expertise to do ALL the
work, including writing a specification if necessary, and to take ALL
the risk.

And right here is a good example of the confusion many people and agencies have, one that often causes no end of difficulties.  There are requirements, and there are specifications. And they are not the same. Requirements are what the end user/agency needs to accomplish, specifications are testable statements of behavior that, if passed, help to show that the system will accomplish the requirements.

They are not the same.  The builder can only design and build a system to meet a set of specifications - because they are what can be tested. The requirements - needs of the customer - ideally will mesh with the specifications (or the other way around).

Let's say, for example, that you are the buyer of a car to be developed, and one of your requirements is that the car has to be able to transport a family of four at least 400 miles between refueling stops.  Fine.  The vendor will have to say "well, a family of four, we will take that to mean two adults weighing an average of 160 lb apiece, and two teenage children, height 5 ft 6 inches, weight 130 lb (sorry, metric users!). "transport" we will take to mean drive at an average speed of 55.

Good.  Off we go to design and prototype.  We estimate the weight of the vehicle, then we can estimate the amount of fuel, and by iteration we converge on a workable design.

But now the customer comes back and says that the adult weights must be 170 lb, the teens will need more room, and oh, yes, the customer forgot about baggage.

OK, fine, maybe the changes can be accommodated, maybe they can't.  But the vendor can't now accept all the risk for failure.  The vendor quoted the job, but now the basis for the original quoted design has been changed.  Maybe the changes make for an overall system that's no longer feasible.  Maybe a complete redesign is called for.  Now there are lots of risks, and the vendor can't know how much to charge to account for them.

Though this is a very simplified example, it's realistic in the sense that this kind of change goes on all the time, and ordinary contracting practices just aren't up to handling it.  "The" government (whichever one you want to talk about) can be pretty bad about it, but not just government buyers.


XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS