In Part 1 of this series, I took the position that extreme business agility is inseparable from extreme customizability of the company's products.  To engineer true, deep-dive business agility, you need to re-engineer the nuts and bolts of the company's know-how.  These areas of product know-how are always knowledge-rich and they can be excruciatingly complex.  The devil is in the details!

To re-engineer the nuts and bolts of product know-how, you must know what the nuts and bolts are in the first place.  So you must conceptualize them, name them, and define them.  In other words, you must be able to conduct a business conversation about them in a deeply granular, highly precise fashion.  Furthermore, you must blueprint the results — because they will be far too complicated for anyone to remember exactly and completely.

What does such a blueprint look like?  The nuts and bolts are concepts.  These concepts have names (noun-ish, of course), and they relate to each other in ways that you can talk about only if you put words to them too.  (These words will be verb-ish.)  When you do deep-dive conceptual analysis, the deliverable is therefore a structural map of business vocabulary encompassing operational-level nouns and verbs.

This business conversation needs to take place before any IT development begins in the traditional sense.  Otherwise, how can all the people involved be sure they are literally talking about the same things?!

Furthermore, this noun-and-verb blueprint should begin to serve as the foundation for all business communication, not just IT requirements.  (Think integration with Microsoft Office.)

Fortunately, we already have a technique for exploring the nuts and bolts of product engineering.  It's not use cases.  It's not business process models.  It's not class diagrams or data models.^[1]  It's fact modeling and business rules!^[2]  And we now have a standard for that — SBVR.^[3]

Does everyone have the ability to clearly conceptualize product know-how at excruciating level of detail, in pure business-speak, apart from processes or GUIs?  Unfortunately no — not by a long shot.  But you do have this latent skill in your company, somewhere — otherwise the company would cease to function.  When you find these people, by the way, treat them like gold.  They are rare and valuable commodities.

The defining problem of our generation is that this deep product know-how is currently tacit, not explicit.  And because we have no blueprint for it, we spend endless hours in meetings trying to work it in a world of legacy.  That's just something to ponder the next time you're sitting in one of those endlessly fun meetings.

The next part of this six-part series provides a set of examples to illustrate what true business agility is about.

References

[1]  Product engineering requires industrial-strength rules, which in turn require a comprehensive, deeply precise business vocabulary.  Data models are seldom designed with that need in mind.  (If they were, they wouldn't be called "data" models!)

[2]  For more, refer to Business Rule Concepts (Second Edition), by Ronald G. Ross, 2005, www.BRSolutions.com.  Chapters 1 and 4 discuss fact modeling.

[3]  Refer to Ronald G. Ross, "The Emergence of SBVR and the True Meaning of 'Semantics':  Why You Should Care (a Lot!) ~ Part 1," Business Rules Journal, Vol. 9, No. 3 (Mar. 2008), URL:  http://www.BRCommunity.com/a2008/b401.html.  And to part 2:  URL:  http://www.BRCommunity.com/a2008/b409.html.

# # #