X

The Enterprise Architecture Blog covers commentary and insights about Cloud and Enterprise Architecture

  • January 15, 2010

Rethinking Information Architecture for the New World (Part 4)

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.

Join the discussion

Comments ( 2 )
  • Paul Naish Saturday, January 16, 2010
    Hamza, I think you make some excellent points but it is worthwhile noting the overall challenge of having a true enterprise scope. Working in the CRM space for a number of years, I've seen attempts at enterprise CRM fail when each line of business was it's own silo. This was supported by separate P&L's that did not support an enterprise perspective of shared assets. In EA, sometimes a separate line of business is the 'corporation' for practical purchases. However, due to it's size, I can see EA being utilized within this scope. However, your points should be something companies consider as best practices and one of the benefits of a EA at the corporate level.
  • Hamza Jahangir Wednesday, January 20, 2010
    Paul,
    Your comment is very valid. The challenge with traditional enterprise architecture is managing scope. So, what we are advocating is balancing strategic thinking with tactical implementation. In this context, what this could mean is that we should have a high-level set of principles and guidelines for our enterprise info architecture, but majority of our effort should be focused on solving the immediate needs from the CRM project. This way we are delivering value to the CRM stakeholder while adding a new system that complies with the enterprise's architecture.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.