Social Glass

On the topic of enterprise architecture, some colleagues of mine talk about defining a corporate lexicon to outline what a business does, or wants to do, as a business. The aim of this activity is to arrive at a desired future-state where the business can talk about its core functions in a language that is not tied to its operational or business support systems. The language becomes an abstraction on top of those systems, and further analysis shows where core systems don’t support the corporate lexicon.

Let me give you an example of what I mean. Being a linguist at heart (I majored in Spanish in university) I thought I might simplify this approach by defining several business requirements for a telecommunications company:

1. Provision broadband internet for residential customers.
2. Provision broadband internet for small business customers.
3. Send customers an invoice monthly.

The first thing to notice is the lexicon has been standardized. When I mean “provision” I say “provision”, not “activate” or “setup”. “Customers” are not “clients” or “accounts”.

Next, sentence structure. All of the nouns in this sentence represent core data entities, the adjectives (attributes of the nouns) represent types that extend the core data entities, and the verbs represent actions that can happen to the object pronoun (data entity) of the sentence. Each of these needs to be supported by the enterprise architecture.

Let’s analyze the first requirement more closely: Provision broadband internet service for residential customers. Verbs are highlighted in yellow, adjectives in green, nouns in blue and prepositions in red.

• There are two core data entities, “service” and “customer”.
• We need a provisioning business function for services (”service” being the object pronoun of the sentence).
• “service” entities can be of type “internet”, and “internet services” can be of type “broadband”.
• “customer” entities can be type “residential”.

Furthermore, prepositions show us relationships between core data entities. In this case we see that “customers” and “services” have at least a one to one relationship (meaning a customer can have at least one service).

Applying the same analysis to all of the requirements, we’d end up with the following, semi-normalized data model:

We’d also end up with two business services (think SOA), one that sends invoices on a monthly basis, and another that provisions internet services.

Sure, this is simplified, but the requirements gathering process, when done in this way, can tell an Enterprise Architect a lot about the core data entities and functions an organization needs to support to do business. He can then perform a gap analysis to understand where his current-state architecture is deficient in supporting this future-state view.