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.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

9 thoughts on “Open Question: Common vocabulary: Blessing or Curse?”
  1. Good topic.  I pretty much take the view that trying to get a completely enterprise-wide universal language is something that sounds good in theory but is not generally practical.  (personally I consider it a flavor of Big Design Up Front)  

    The important thing for me is to identify key overloaded words that are creating problems within a project or group of project and work on developing understanding there.  Usually people don’t just start using the right words overnight, but if there is a lack of clarity in a request or requirement its much easier to communicate and gradually the business people start making the distinctions more clear (although often in their own words, instead of the programmer’s foo and superfoo they will say Accounting foo and Shipping foo or something along those lines)

  2. One approach is to adopt an industry schema like ACORD, FIX, or OFX.  

    Another approach is to document a high level process map from the enterprise level.  Usually there is some type of process that can be captured at an enterprise level and then incrementally drill into more details.  You can then derive a common business language or entities from the process steps.  Of course, it makes a big difference if senior leadership on the business and technical side make it a priority.

  3. Hi David,

    You have provided an approach that will create a Common Information Model or "CIM."  We negotiate and analyze and the 50-or-so key people that we speak to understand that we have built something, and maybe they agree… and maybe they say that they agree to get us to go away.  Or we adopt an industry model.  Same difference.

    OK… we have a CIM.  Now what?

    The next project to come along will involve low-level people, line managers or business people that were not in that 50-or-so senior leaders.  That project will express the requirements in the terms of the business which may be parochial… not directly reflected in the consensus CIM.  

    Do we translate the requirements along the lines of the CIM and hand them back to the business for approval?

    Do we talk the business into changing them to match the CIM?  

    Do we train the business team BEFORE the requirements are gathered what the CIM terms mean, so that when we gather the requirements, we write them down using CIM terms on the first pass?

    What process do you use to make the CIM add value?

    And if you don’t have a process to derive value from the CIM, how was it valuable in the first place?

    — Nick

  4. The reality is that moving large federated organisations to a common language is a utopian goal. Like native language, business language evolves. As Nick notes it might be possible to agree on an information model in the context of a project, however getting this applied across the business is a long term process and becomes even more challenging in a multi-national environment, especially where business terms cross-over with common local useage. A (single) glossary with synonyms and making that a reference for all projects is a good starting point .

    We, as architects, need to act as translators between the realms of business and IT. This includes recognising that abstractions we might employ for forward looking design reasons (e.g. flexibility) will not be readily understood in business language.

    This and the broader topic of translating the needs of the business in to something IS understand is the topic of the recent book, Lost in Translation, by Nigel Green and Carl Bate. The book introduces a thinking framework called VPEC-T (Values, Policies, Events, Content and Trust) that explores the different stakeholder perceptions of what an information system should do.

  5. 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.

  6. A CIM – like everything else in this world – must first evolve and then adapt to its surroundings. That is a key problem of programming. This is why we at ISIS Papyrus use a central virtual metadata repository that is not only used during development but also during production. As all models are interpreted at runtime changes can happen at any time. And they are always enterprisewide. The thought freaks people out. But then – did we not want to be agile?

    The best way to run a business and thus to run IT (actually everything) is by federation, so each department can theoretically reuse things from other departments or build their own models that again can be federated. Obviously some things have to be standardized (like a common currency in economy) as otherwise there is no cooperation.

    A CIM is essential if you want each department being repsonsible for their processes but that does not mean that they have to use the same models, just that the models have to be stored in the same central place. Business department can thus be autonomous and own their processes, but still cooperate easily.

    SOA is just a huge cost overhead and it does require a  much more strict semantic model to work and it too requires a central registry/repository. In my mind a common CIM repository is more important than enforcing a complex interfacing methodology. As long as the data  are properly modelled they means to exchange them are irrelevant.

Leave a Reply

Your email address will not be published. Required fields are marked *

four + 4 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.