What to do with Information Architecture

Too often an enterprise’s information is an unmanaged asset — businesses can’t find consistent information and IT struggles under the resulting weight of project delays and ballooning storage costs. Information architecture (IA) helps IT address business needs by providing a framework to map and describe an enterprise’s information assets and their relationship to processes and systems. But IA programs fail if not approached the right way. To be successful build iteratively, focus on pain points, and execute top-down. It’s easy to get lost when developing IA. The current state of information management and use may be in such disarray that the effort to document it is daunting. Bottom-up approaches get lost in the details of understanding all the use cases for any specific category of information. To sustain the program’s focus, architects should:

  • Model only the business areas within scope. Initially scope may be based on a business process or a business value chain, or it may be based on defining a high-level business capability and analyzing the information categories supporting this capability. For example, product management at Acme can be analyzed as a business capability that includes profitability analysis. Product management information would include data on the cost of design, development, delivery, promotion, selling, and servicing a product.
  • Define a logical target state before investigating current state. The logical target state architecture is a clean slate, which solves for current pain points for the scoped areas. There are multiple benefits to defining this clean slate solution: First, it focuses current state investigation on the important details rather than every detail. Second, it forms the base from which the EA groups sell the solution to IT and business management. Third, the EA organization becomes better positioned to influence proposed projects to build out parts of the architecture by comparing them with the logical target state.
  • Develop alternatives to close the gap between current and target states. The value to stakeholders will be the discussion of how to solve business and IT pain points. Develop several alternatives, with analysis of the work and tradeoffs associated with each alternative to achieve stakeholder buy-in on follow-on actions. For Acme’s product profitability analysis, there may be more than one alternative for the systems of record as well as for processing into analysis-ready information. Alternatives may have different upstream and downstream implications.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s