Each building block of the enterprise architecture is as important as the next, but some blocks provide you with more insight than others. Such is the case for the business and information architectures. In "Begin with the business architecture," you stepped through the paces to explore and outline your business architecture. Using a 10-step process in that article, you documented and detailed the business you're in, which provided you with valuable insights into what your organization actually does and how it does it. If you're lucky, you might have even identified areas for improvement as you examined each facet of your business area.
In addition, because moving to an enterprise architecture means introducing change into your everyday life, you were able to rely on two additional tools: 1) being able to identify the differences between welcome and unwelcome changes and 2) being able to rely on the QUOTE system to manage change. The latter, especially, can greatly mitigate the impact of change, because it provides a proven methodology for controlling change.
Now, you’re ready to move on to the next step in the enterprise architecture design process -- building the information architecture.
Build the information architecture
You can build the information architecture in several ways. Of course, you’ll need to pace through the 10 elements of an information architecture (see Figure 1), but because you're armed with change-management tools, you should be able to reduce the impact this new architecture has on the way you do things.
Figure 1. Ten elements of an information architecture
Many organizations tend to produce an information architecture by gathering and using small focus groups to identify what must be covered. You might be inclined to do the same, but you don’t have to. Using focus groups is good, but it won’t get you immediate results. Instead, pick the "low-hanging fruit" of the Internet architecture. The advantage you already have when designing an information architecture is that no matter what your business is, you're already using and relying on information to make it run.
Because the information that supports your business already exists, begin by simply examining what you have and derive the information architecture from that. Start with the vision statement. Remember, the vision must be a short statement that addresses customers, the organization, cost control, and growth as well as future opportunities. Several examples of good visions for information architectures exist, but the best is the simplest (even if it is a bit redundant): "We need to know what we need to know, and we need to know it now."
Such a simple and straightforward vision helps drive the goals and strategies as well as the principles that support this architecture. The information architecture is the most vital of the technological architectures, because information drives business. You have already started your business architecture, so you know what type of information is critical for supporting it.
Two types of data make up information in any business: structured data and unstructured data.
Structured data is typically in the form of tables consisting of discreet, readily identified elements. Because it's stored in a row and column format, structured data forms relationships. For example, in an inventory table, you know that the Amount column has a direct relationship with the Item column. So, when the amount is 10 and the item is brooms, you immediately know that you currently have 10 brooms in your inventory. You also know that because of the nature of your business and the need to maintain minimum inventory levels, you should order more brooms as soon as that amount decreases by at least one.
Relational data such as this resides in spreadsheets, word processor tables, and databases. It includes both business data, as data about the business data, or metadata, such as administrative information. In the broom example, this "data about data" would include items such as the reorder count and the supplier’s name and contact information.
Unstructured data is typically in the form of a document of some type -- a word processing document, a presentation, or the like. The major difference between structured data and unstructured data is that structured data supports immediate interpretation, whereas unstructured data requires some level of comprehension.
Because unstructured data tends to be conceptual, you must read larger amounts of it before it becomes meaningful. In addition, you must rely on more metadata to be able to use unstructured data productively. For example, in a word processing document, you must rely on elements such as the document title and the file name; depending on its length, you must use additional information such as a table of contents, index, glossary, or executive summary before the document begins to make sense.
The goals of the information architecture
In short, you could say that structured data is concrete and unstructured data is abstract. The proper combination of concrete and abstract data makes your business run effectively. The challenge of an information architecture is to provide the proper balance between structured and unstructured data and make data -- whatever its nature -- more useful to your organization. Therefore, the goals of an information architecture should include:
- Properly identifying both structured and unstructured data.
- Properly categorizing data, identifying whether it's core data or metadata.
- Identifying the criticality level of each data element to properly secure the data.
- Implementing proper data-retention mechanisms to support new compliance requirements.
- Implementing proper search tools to make data more useful to the organization.
- Promoting data sharing to reduce data redundancy and therefore data maintenance costs.
Identify structured and unstructured data
Each goal helps you make the most of the data required to run your organization. The first goal is relatively easy to achieve initially, because you already know what data falls into each type. You can perform this initial data categorization through the identification of the applications used to generate the data. Spreadsheet and database applications generate structured data. Other tools, such as presentation or word processing applications or design and illustration applications generate unstructured data. Inventory the applications you use the most, and identify the data you create with them to identify how much data of each type you currently manage.
Next, identify real versus metadata. Real data is data that directly supports the organization. For example, a store relies heavily on structured data, because it requires inventories. In contrast, a graphic design firm most likely has more unstructured data, because its core business is to generate this type of data. Depending on the nature of your business, you will have different proportions of one type or the other. Identify this proportion, and make sure that it's right for your business type.
Now, identify the criticality level of each data element. Here, it's best to keep things simple. For example, a four-level matrix is often best (see Figure 2) because it's simple, yet it offers the required categories:
- Public information: This information can be shared publicly inside and outside the network.
- Internal information: This information is related to organizational operations. It is deemed private but not confidential -- for example, network information such as diagrams, IP addressing schemes, and internal user names. This information should be protected to some degree.
- Confidential information: This information, including staff salaries and bonus rates, should not be divulged to any unauthorized personnel.
- Secret information: This information is critical to the operation of the organization. If this information were divulged to the wrong parties, the organization itself could be at risk.
Figure 2. The four levels of data criticality
For each data category, you must identify which elements are at risk. For example, if data on your Web site -- data that is deemed public -- is modified without your knowledge, the reputation of your organization could be at risk. If payroll data is leaked within your organization, you will lose the trust of your employees. The risk is different in each case and so is the required security investment to protect the data. However, categorizing the data in this way helps you identify the security strategy you must use for each data element.
Implement data-retention mechanisms
Another core element of an information architecture is the retention level required for the data element. The Yankee Group provides retention estimates for different data types (see Resources). Recent compliance issues have raised the consciousness level of data-retention issues for organizations. The Sarbanes-Oxley Act, the Health Insurance Portability and Accountability Act (HIPAA), and the Gramm-Leach-Bliley Act are all examples of new acts that control how your organization must manage its information. Make sure you follow the guidelines of the acts that apply to your organization as you build your information architecture.
Implement search tools and promote data sharing
Finally, be sure to implement the proper tools for managing and using data. More and more organizations are relying on intranets to do this. Intranets provide the ability to manage both formal and informal data. Formal data requires proper data repositories and must be indexed and categorized under a formal taxonomy. Informal data can live in wikis or blogs that are integrated into the intranet design. Because new intranet engines include comprehensive search tools, you'll be able to categorize and index both formal and informal data, thus promoting information exchange within your organization.
Use principles to drive the information architecture
Now that you have a vision and have set goals for the architecture, you must define the principles that will drive the architecture from now on. These principles include fundamentals such as:
- Data is corporate and belongs to the organization.
- All data should have an identifiable owner who is a subject matter expert in this area.
- Data is captured at its point of origin. This capture occurs only once and, from that point on, lives in an electronic format.
- To reduce data storage requirements, the organization will focus on knowledge as much as possible. Knowledge is produced from interpretation of data.
- Data accessibility is transparent to all users, regardless of where they access it.
- Data does not depend on and is separate from applications.
- The data model that the information architecture generates drives the other elements of the enterprise architecture.
These principles are required in support of your information architecture. When you have defined them, you can move on to the other elements of this architecture: identifying the physical location of your data repositories, the stakeholders of this architecture, and the other roles stakeholders must interact with when dealing with data. At this point, you can begin using focus groups -- groups that include data experts such as librarians, Web site designers, information architects, and taxonomy experts. These groups will help with the remainder of the architecture components.
Of course, you must create an inventory of all existing data to drive the information architecture. Doing so gives you the opportunity to identify the sources of information you rely on to design the architecture. As you identify the sources, you will also be able to identify the flows of interaction that affect different data types. What's more, this is the time to define the architecture policies and standards. Finally, define an implementation plan to help you move from the existing state to the desired state outlined in the new architecture. During this entire process, keep the following question in mind: "What information or data do I need to make the business work?" The answer to this simple question will be the core of your information architecture.
Remember also that to find out what kind of data you need, you must find out what kind of data you have. Your first goal should be to organize the data you have: Then and only then can you move on to an improved data architecture that can drive the other elements of the enterprise architecture.
Learn
-
Stay current with
developerWorks
technical events and webcasts.
-
The QUOTE System was first presented in,
Preparing for .NET Enterprise
Technologies, by Danielle Ruest and Nelson Ruest (Addison Wesley, 2002).
-
Learn how configuration management can help resolve compliance issues: Read
"How to Control Your
Infrastructure with Configuration Management," (RedmondMag.com, June 2006) by Nelson Ruest and Danielle Ruest.
-
Visit the home page of the Yankee Group.
Get products and technologies
-
Build your next development project with
IBM® trial software, available for download directly from developerWorks.
Discuss
- Participate in the discussion forum.
-
Participate in developerWorks blogs
and get involved in the developerWorks community.
Danielle Ruest is a senior enterprise IT architect (EITA) focused on people and organizational issues for large IT projects. Danielle has been involved in the design and support of complex collaboration implementations, including deployment of technologies for e-mail, team sharing, and secure instant messaging. With her partner Nelson Ruest, she is the author of Preparing for .NET Enterprise Technologies, (Addison Wesley, 2001). and Windows Server 2003: Best Practices for Enterprise Deployments (McGraw-Hill Osborne, 2003) and participates in many webcasts and conferences. You can reach Danielle at architectures@reso-net.com
Nelson Ruest is a senior enterprise IT architect (EITA) with more than 20 years of experience in migration planning and network, computer, server, and overall solution design (including MCSE, MCT, Microsoft MVP Windows Server). He has been a computer operator, a systems administrator, a trainer, a help desk operator, a support engineer, an IT manager, a project manager, and now, an IT architect. He was recently named a Microsoft Most Valuable Professional for the Windows Server product line. You can reach Nelson at architectures@reso-net.com.
