Rethinking Information Architecture for the New World (Part 4)

[Latest News Headlines]

In the last three parts of this blogging series, we discussed the fundamental impetus behind redoing the information architecture in these fundamentally changing times. New economics, technologies, user behaviors, user expectations and business climates having set the requirement for making information more available, more accessible, more malleable, more business-ready and more secure against the threats of privacy breaches. As a mechanism for making that transformation, we discussed the following 3 steps:

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.

The last blog post (part 3) discussed item 1. In this post, we will take on number 2. However, before I do, wanted to bring up a question I received in an email about these three steps - “where is the implementation step in these three?”. Great question. My answer was and is “implementation happens everywhere else :-)”. What I mean by that tongue and cheek remark is that once these three are addressed, all we do is implement. Once we have a common language of our enterprise information, a set of guiding architectural principles for our implementations and a set of processes and measures to ensure we are meeting our target information architecture (i.e. implementation governance), all we need to do is execute the actual implementation plan(s). This mindset is not something I have come up with, but is the fundamental philosophy of a practical enterprise architecture process.

Now to return to the discussion of this post – information architecture principles. Let me first list the top “data principles” that TOGAF 9 lists on its website:

1. Data is an Asset
2. Data is Shared
3. Data is Accessible
4. Data Trustee
5. Common Vocabulary and Data Definitions
6. Data Security

When you read these principles, you can often have what I call a “duh” moment. Who would disagree with “Data is as Asset”? Same for most of the others. “Data Security”, seriously? I am not a big fan of these principles as they stand. However, I think these provide a great foundation for more specific and more enforceable principles in specific solution architectures.

For example, a better principle than either “Data is an Asset” and “Data is Shared” is one such as “Data is an Asset that is Shared across all Lines of Business”. Even better is one that can be more prescriptive like “All Corporate Customer Data is an Asset that is Shared across all Lines of Business”. Imagine your CTO or CIO sets that as a general architecture principles for your IT organization. How do you think that would affect your design and implementation decisions when you are implementing the next CRM system for a specific Line of Business? Does it matter that the information is stored in an Oracle database, a file system, a DB2 system or as raw binary files? At that point, the implementation technology is less important. More important is that the architecture supports sharing that data.

Each architecture principle should not be a simple statement. While the statement is useful for communication purposes, it needs to be backed up by a rationale and a set of implications so that the entire organization, who is being targeted, understands how their day-to-day decisions should be influenced by the principle. Refer to TOGAF’s overview on architecture principles to get a more substantive overview.

Understanding and fully internalizing the notion of architecture principles can take a little time but once you are there, you will appreciate its quiet power.

Please comment if you are interested in a more examples and applications of information principles.



More from the Enterprise Architecture at Oracle Blog ...