Non-functional means it doesn't work!

Architects are usually quite pre-occupied with ensuring that architectural guidelines and requirements are adhered to during development yet, always struggle to justify them. One of the many attempts made by architects to provide these guidelines is the software architecture document. Simon Brown blogs about another attempt that is probably doomed. Just looking at the document structure, the non-functional view is 4-5 times larger than the functional view.

What does the customer think non-functional requirements mean? No, it's not just semantics. I vividly recall an RFP-response drafting session I was a part of, many years ago. This was the first time I had participated in a fairly large team responding to a multi-billion dollar opportunity. I had finished up one sub-section, and handed it over to my boss. Without raising his head, he took the doc and with his red pen, crossed out every single instance of "non-functional" and handed back the draft to me and said, "The customer doesn't want to pay for something that doesn't work."

Of course, in geek-speak, functional and non-functional have a very specific meaning. In standard, workaday English, functional means something works and non-functional means something doesn't work or is broken. Why then, do we architects pay so much attention to designing software that doesn't work?

If we want all of those architectural "ilities" to be accounted for and truly guide the design/construction of systems, we need to immediately start doing 2 things:

1) Start calling them technical requirements and/or constraints.
2) Directly map them to functional requirements by defining the operational characteristics the customer wants each feature to provide.

Every, single functional requirement should explicitly be able to describe just how much of each "ility" needs to be built, thereby preventing over/under-engineering. This embeds the success measurement criteria for every, single feature!

Maybe we need to start talking about measurement driven requirements (MDR)?

SOA Is Not Enterprise Architecture

Yet one more person is writing about people talking/writing about the equivalence of SOA and enterprise architecture.

A SOA is one of many possible implementations of an Enterprise Architecture. SOA is not enterprise architecture. More often than not, a SOA will need to co-exist with other architectures in a more comprehensive enterprise architecture.

Sorry boys and girls, EA just isn't that easy.