Standardizing a definition of software architecture

Collapse -

No, It's Not...

by stuart_zechman · 13 years ago In reply to Standardizing a definitio ...

"A software architecture document is a communication tool."

No, it's a CYA tool to ensure that the worthless development team can justifiably blame whatever mouthpieces were the fountainhead of poorly understood/communicated requirements.

Until the requirements/analysis/decision process is removed from organizations' hierarchical frameworks, until everyone (and I mean EVERYONE) comes to terms with why development teams are universal failures, users hate software, managers are process-ignorant overseers, analysts are paperpushers and executives are shamelessly ignorant bullies, the entire requirements documentation process is an excersise in froth.

Let's not actually believe our own propaganda, shan't we?

If we start to believe that we really do NEED our "architecture document" to get anything done, we will hand every single project right on over to people who will then black box the entire analysis/development process by conducting it in Urdu. Besides working for tap-water, they will have actually given the business software to hate/use/wait for version 2, which is the entire point.

Let's not take seriously the idea that users, or (even more laughably) managers, or even developers somehow know what software will be like BEFORE it's put in front of them.

"For example, early in a design project, developers can review the software architecture to catch improper design decisions at a time that will have the least impact on cost or software redevelopment."

What a joke!

What perverse risk-terrified ostrich concieved of that idea? The whole concept of development is not to dispense with risk as much as possible BEFORE the thing is built, it's to COURT risk, to actually learn what needs to be done by FAILING AS SOON AS POSSIBLE. The whole front-loaded design-first/build-when-we-are-absolutely-sure-what-we're-doing-is-EXACTLY-what-the-idiots-specified process is a shameful waste of time, talent and money.

"Finally, due to the standardization and focus of the software architecture on specific quality attributes, architects can focus on best practices or design patterns to create system components. This enforces standard object-oriented development goals such as code reuse. "

What!?

In reality, "best practices or design patterns" don't ever actually "create system components". They don't do anything at all other than describe what real, smart humans create in response to SPECIFIC SITUATIONS and immediate quality feedback AFTER THE FACT. This is not a semantics game, this is another obvious example of how not to think about process instead of result. Defining the issue as a judgment on process instead of value, and then droning endlessly in management/software development theory-speak only confuses what really matters (i.e., real productivity) with managers' inept justifications of glorified supervision-oriented task attempts (i.e., their worthless jobs).

There should never be "standard object-oriented development goals". There should only be business goals, not as defined by "stakeholders", but truly understood and embraced by developers. One does not substitute for the other.
Unless developers know and care themselves what should be built, and how, by deciding for themselves what projects' priorities are (and being correct), everybody involved (including CIO's) should just read this crap in English while they can still keep picking up paychecks for sitting around.

If you really, truly believe that "standardizing a definition of software architecture" is in any way whatsoever important, then you are a fool, an idealogue or insane.

Try standardizing on competence, courage and passion. If you can't, then nothing else matters.

Collapse -

Response from author Scott Withrow

by MaryWeilage Editor · 13 years ago In reply to No, It's Not...

I would like to point out that there IS a reason that all this process exists in the first place. Simply put, software projects that do not conform to standardized processes fail--and not just in small numbers but nearly all. Also, don't forget that the number one goal of a software development project is to meet customer requirements and to do so within cost constraints. Simply sitting down and writting code will not suffice. Structured processes exist
to assit this process, not get in its way. Styles may differ, but most of the mainline practices you here about have been proven repeatedly in real
business situations. Project managment, JAD, OOD, architecture drive development, agile developement, and so on. That is why the industry
braintrusts such as SEI, W3C, OMG, IEEE and many others back the practices.

As far as CYA, think of all the CYA you won't need if you do it right in the first place.

Collapse -

Definition isn't what you need

by bruce.miller · 13 years ago In reply to Standardizing a definitio ...

Perhaps it would help to have standardized descriptions of software architecture. Maybe a standard document template would be useful. Neither involves defining the term.

If you're judging a dog show, you have breed standards for each breed. The standards are all in the same format, which makes life simpler for judges. They list various standard details under headings like:
General Appearance
Size, Proportion and Substance
Head
Neck, Topline and Body
Forequarters

But wait! The AKC didn't define the word *dog*, nor a dog's architecture. How can their shows possibly work?

Nor can I imagine how defining software architecture as being comprised of *software elements* is going to help anyone do any sort of useful work.

IT Employment

General discussion