Keith Short’s blog has a report on some of our team’s experiences at OOPSLA this year.  I’m back in the UK now, recovering from the jetlag.

One aspect of our Software Factories tutorial which I think was particularly interesting was the use of Business Capabilities to scope the requirements for a software system.  Over many years I’ve listened to people talk about “Business Process Models” in the context of model driven development, but often this turns out to be actually about automated workflows, which are only a small fraction of the actual things that go on in real businesses.

Business Capabilities have nothing to do with automated workflows. They are a way of describing what really goes on in the business, in terms which a business person can recognize and understand: such as “Understand and Analyze Competition”.  Our tutorial showed how to scope a software factory in terms of which business capabilities it supports, how to map those capabilities into system requirements, and from there how to configure the factory for a specific project, create customized project plans, and populate Visual Studio with the artifacts needed to build software to meet the chosen requirements.

Indeed, there are many artifacts that can be generated or deduced from business capabilities that only have a loose relationship with the software, such as project estimates, contracts, documentation, and training materials.