How do you get everyone on the same page?
User stories get your team talking about requirements and “blog post driven development” can help you to engage your customers and development partners.
However, both of these approaches assume a shared understanding of the business domain and its key business concepts.
On consulting engagements, I spend a considerable amount of time asking questions about the "things" that are important to the "business".
I follow an approach based on the Five Ws. For example, "What does the business do?" Not where or when or how, only what
is done.
Questions of this form will help you to create a Business Capability model. And, a well formed Business Capability model is the foundation of a stable microservices catalogue.
As you create your Business Capability model you will find yourself grouping (classifying) the capabilities, which means you are already thinking about the domains 'bounded contexts'.
For example, Retail Banks offer financial services and products to individuals and organisations. They offer transaction accounts, savings and investment accounts, finance (e.g., personal loans and mortgages), funds transfers and payments. They may also offer investment advice.
How might we model these bounded contexts? They are course-grained or
'foundational capabilities' so they should form the first-level of the Enterprise's Business Capability Model:
Remember, capabilities define what
a business does, not how a business does something. Capabilities are nouns
, not verbs. Capabilities are stable
, not volatile. And, capabilities are defined in business
, not technical terms.
References:
- TechCrunch: The Unbundling Of Finance
- TechCrunch: Millennials Are Destroying Banks, And It’s The Banks’ Fault
- William Ulrich & Michael Rosen: The Business Capability Map
- Eric Evans: Domain-driven Design
- OOSE Informatik: The OMG's Business Motivation Model
- IBM: Information FrameWork
- BIAN: Service Landscape