"Getting" the Business Means "Get In" the Business

It's always fun visiting the customers at their own workplaces. What takes an hour to describe can instantly be seen; the proverbial picture that's worth a thousand words. I was out at a customer site last week and noticed a very depressing ritual that I have seen many times before. Here's how it goes ...

1. The consultants are brought in to solve a problem;
2. The business users are excited that, finally, something is going to get done to fix the problem;
3. The problem is discussed, a couple of quick suggestions and concepts are described and the business users are enthusiastic about the possibilities;
4. The business users ask, "So, what are the next steps?"
5. The IT manager says, "Well, we need to gather the requirements."
6. The business users physically roll their eyes and slump back in their seats in anticipation of another snail-paced, IT boondoggle.

Here is a very, very important lesson every technology consultant needs to be mindful of: The biggest barrier to your success as a consultant is the technology organization you are there to help/support/augment.

This isn't about folks in IT not having ever learned how to read a balance sheet or other such easily learned knowledge. This also isn't about understanding the basics about how their employer actually makes money and who the customers are. This is about being able to put yourself into the shoes of the people who actually use and need the products and services you provide/build. This is remarkably easy to do.

The key to "getting" the business is to "get in" the business. In this particular case, I had spent a significant chunk of the day on the factory floor observing how people actually accomplished their tasks, complete with impediments, workarounds, frustrations and pride. No requirements document would ever be able to describe the environment and conditions under which the tasks needed to be completed. They would only describe what the user interface was supposed to do. Hopefully I will return in a few weeks where I will resume gathering requirements from the factory floor.

That's right, turn off your computer, put down your whiteboard markers, leave that sterile ivory tower and get onto the floor or out into the field!

Sale or Adoption

James McGovern talks about failing to sell A/agile in the enterprise. While close, I believe the sales process is not at fault, rather, it's that path to adoption. Also, along with everything else, it's all truly about alignment with the business goals and strategies.

I've recently had the benefit of seeing the life-cycle of almost a dozen agile software development projects over the past year, some ranging through multi-year efforts. I have seen the victories, the failures and the in-between. I started noting some contradictory behavior between customer needs and agile practices, especially the more dogmatic ones. However, I didn't have sufficient data to make any good correlations.

One particular incident involved Test-Driven Development (TDD). In this case the dogma stated that TDD must be done. However, it was truly placing the delivery schedule in jeopardy. Moreover, the deliverables only needed to be good enough. Needless to say, a large rift developed dividing the dogmatics and the customer. Thankfully, the customer's needs prevailed and TDD was tossed and the product was barely delivered in time. This is only one such incident but, clearly the whole concept wasn't working as advertised.

A couple of weeks ago, I stumbled across this paper about software process adoptions. 7 years ago, someone has already thought through this. Bringing back the TDD example, trying to apply a technique that emphasizes quality when the real strategy is innovation (where customers willingly trade quality for newness!) is completely counterproductive. That is, avoid prescriptive processes that require discipline when quality is not the business strategy. Clearly, no matter how hard we try to sell agile, we will fail. Why? There is no logical path for adoption.

Don't sell agile!

To quote a colleague, "Nobody buys Toyota trucks because of the TPS and lean manufacturing."

Technical Requirements

Simon Brown was kind enough to comment on my previous post and said,

"I'm trying to tackle the other (easier?) problem of when technical people don't even think about NFRs. First things first, we need technical people to understand why NFRs are important."

There's a very simple way to get technical people to understand why technical requirements are important. They must be clearly and logically linked to delivering a functional requirement. Go one step further and simply remove the distinction between functional requirements and technical requirements by stating how a functional requirement must be delivered in terms of quality-of-service or a service level agreement. An example:

"The customer must be able to securely submit the final order plus payment details and receive an acknowledgment via both email and a following web page in under 10 seconds."

Separating technical and functional requirements makes it all too easy to make the former into an afterthought.

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.