Enterprise Architecture at Oracle

First of all, I am very happy to return back from my very intense month of October on the road for work and mini vacation at the end of it all in the great city of London. And now happier to be able to resume blogging on my favorite topic of information architecture.

To get back to my traveling for a minute,  I picked up the latest Harvard Business Review at Washington Dulles while I was waiting for one of my flights going somewhere at some point in October (its all a bit blurry now). Last month’s HBR had an IBM advertisement that I felt was insanely wise and sums up exactly what I have been meaning to convey all this time on the subject of information architecture. Except, they were able to say it in the following 15 words:

“Your data is trying to tell you something. 
Is your business built to hear it?”

I have to hand it to IBM for their ability to make a pitch-perfect pitch on information architecture. Whether they have anything of value to sell on that topic is another discussion, but at least they have the marketing down.

Ok, so enough about marketing and advertising. Let’s return to where we left off our discussion in part 2 of this blog series. To recap, we discussed that there are fundamentally three things an architect, dealing with modernizing their enterprise information architecture, has to define to make a successful transformation in how they leverage information in the new world:

1. Establish a common language for conversations between business and information technologists (an EA framework usually calls this the business architecture)

2. Define a shared set of principles around how information is treated and leveraged by the business

3. A governance model for course correction when strategies and tactics are not working and need to be rethought.

Let’s take them one at a time.

1. A Common Information Language

This is probably the most challenging aspect of information architecting. And especially, given we are almost always starting with a legacy environment where systems have many, often inconsistent, data models, rationalizing all the data, their semantic and their physical structures is where we tend to spend overwhelming amounts of time and, usually, resort to frustration and eventually giving up that mind-numbing endeavor. Here’s a very simplified example of lacking a lacking language of information:

Here are two data model records from two applications:

Can you guess which one is a product that the business is selling and which one is a product that the business is buying from suppliers? If you can, there is a 50% shot you are not right.

This is precisely the challenge of normalizing data definitions and models to a common semantic that all parties, relevant to producing or consuming this data, is able to easily understand and leverage this information for their purposes. While this exercise can involve solutions such as master data management, data integration, data analytics, data cleansing, etc, at the heart of it, it is about making data accessible (a key principle in data architecture).

Now, you might be wondering what is a practical and low-risk way to normalizing all the data in your enterprise so you can achieve this normalized information language. In my experience, I would recommend key high-level steps to practical information semantic normalization:

a. Select a Business Process or Function – Taking a business process lets you work with a small set of data that is consumed by a business process. This is very critical to making the enterprise data modeling process a low risk proposition for all stakeholders. You don’t want to be touching and messing around with too many moving parts since that might take too long and complicated to normalize.

b. Ignore the current data models – Define a logical data model that doesn’t dwell on the specific physical characteristics of the data model (e.g. data type, naming conventions, etc). Instead defining a clean and simple model that makes sense to a business user executing the process is a decent validation of the desired data model for architecture.

c. Map your Logical Enterprise Data Model to Specific Systems – If you are working with a specific business process, your next task is to map those logical objects you have modeled in step b, to the actual data models in the different systems that are touching the business process. This approach takes a just-enough mindset to information modeling and you are normalizing only the systems that are critical to process execution.

d. Rinse and Repeat across other business processes

This approach to information semantic normalization and building out a canonical data model for your enterprise is often supported using MDM solutions. However, it is important to keep in mind that having an MDM system doesn’t automatically buy you a master data model. You can certainly use industry standards and reference models, however at the end of the day someone has to go through this exercise to create a data model that houses your enterprise’s strategies and functions. At the end of the day, your enterprise data model might look something like this at the 10,000 feet level. What comes after this is what makes your business different from the competition.

In the next post of this blog series, we will discuss the architecture principles (and the rationale behind those principles) to govern and influence the decisions you need to make around building out the information architecture.

Happy friday to you all.