Open Question: Common vocabulary: Blessing or Curse?
Requirements are an interesting thing. We cannot assume that we understand the business, and their needs, so we 'elicit requirements.' And we write them down. But "the business" is a collection of different people, and in order to be clear, we need to make sure that everyone use the same words in the same way.
Within the scope of a single project, this is not terribly difficult, but it is very tough to keep a single vocabulary across an entire enterprise. It can be a substantial effort to create an enterprise-wide conceptual information model, one that illustrates the relationships between key business concepts for an entire enterprise. (If you don't know what a conceptual information model looks like, here's a pretty good example from the US Department of Veteran's Affairs.) You have to get a lot of people involved to create an enterprise-wide model.
The goal is to create a common understanding that bridges across many projects. This allows planners to create information models, and future state models, and suggest project changes that will bring the enterprise information together... at least in theory. The goal is simplicity and consistency.
But how in the world do we achieve that goal? Software reflects the requirements, and business people create requirements, and business people, as a rule, are not well versed in the intricacies of the common information model. They are on a different track completely.
Business people won't use the "standard" words, and they won't use them in a standard way. Even if you get a project to create their own information model, how do you insure that it lines up to the "blessed from above" common information model?
We need to have a way to recognize that "project-level consensus" is going to be different from "enterprise consensus."
So we have competing goals:
- creating a simple information model for the enterprise, and
- creating a consistent understanding between the people involved in the project.
If we don't get the project to align with the common model BEFORE software is built, then we built the wrong software, and we have to spend more money later to fix the problem. But if we force the business to use "special" language, words that they did not create, then you won't get consensus and clarity. You risk the project.
How much is it worth to you to get alignment on information models? What processes do you use? I'd love to hear from folks.
Comments
Anonymous
June 22, 2008
The comment has been removedAnonymous
June 22, 2008
The comment has been removedAnonymous
June 22, 2008
The comment has been removedAnonymous
June 22, 2008
The comment has been removedAnonymous
June 23, 2008
The blessing of SOA is that you don't need to impose a homogeneous business vocabularyAnonymous
June 23, 2008
Further to Adrian's comments, here's a link World Keep it Clear, Keep it Simple<br /> This is a paper I originally wrote for the International Association of Software Architects (IASA) on the subject.Anonymous
June 29, 2008
Different business areas by definition work in different problem areas. They have different problems to solve. They solve common problems in different ways. Business areas need to be autonomous. They need to have the freedom to perceive and understand their environment in a way that is optimised for solving the problems they are tasked to solve and delivering the value they are tasked with delivering. Furthermore, language by its very nature is evolutionary. New terms evolve all the time in order to describe new concepts in various fields. This process should be embraced, not constrained. Through proper application of SOA such that technical services are aligned with business services, we give each business service the freedom to evolve independently. We don't require any kind of enterprise canonical schema. Such a construct only harms the semantic fidelity of service interactions. So, we should have a common vocabulary - but only within a given business service.Anonymous
July 06, 2008
The comment has been removedAnonymous
July 31, 2008
I've been thinking a lot lately about the gap between "what we have" and "what we need" in the Enterprise