Skip to content

Data and Information Architecture: What’s the difference?

Most who read the blog title will suppose that the obvious answer is: there isn’t one.  Or, at most, the difference is found in the classical differences between data and information; such as those that are described within a typical DIKW hierarchy.  Perhaps that’s correct.  Perhaps not.  To this author, the answer is only accurate in context.  For example, are you a Business Intelligence Architect depicting the relationship between database tables (clearly data) and business entities (clearly information)?  Or are you a UX professional designing a website page map using a content taxonomy (information) and then mapping topics to each page as search engine friendly metadata (data)?  Or is the difference more generally related to how “technical” a task is: for example, is it data-work when you’re designing data warehouse dimensional models – typically the task of the data analyst, database administrator, or data architect?  But, is it information-work when you’re designing online store product categories – typically the task of the information architect or information specialist?  This distinction is not terribly important, I’ll admit, but it is interesting how the market seems to imply that data is more technical (databases, tables, services), but information is more functional (dashboards, reports, websites). 

Does this distinction matter?  Do keeping the roles of a data architect and information architect separate really serve a purpose?  I tend to wonder why DAMA International and the Information Architecture Institute appear to be on such opposite ends of the back office analyst vs. user experience professional spectrum (very different people occupy these roles).  Is there an eventual convergence or is there more to this distinction than would appear on the surface?  I would welcome your thoughts.

Advertisements

Viewpoints, Views, and Models

IT architecture makes use of views to represent aspects of a system from a related set of topics. These topics are related in their shared interest to a unique set of consumers of the information exhibited in the view. For example, the architecture description of an eCommerce website will likely use wireframes to describe the user experience to UI developers. Likewise, a set of PhotoShop mock-ups are of interest to end users who would like to visualize the finished product. Also, an database ERD can be used to describe the website’s backend database table structure to DBAs. All three “views” into the eCommerce website are accurate and complete – in that they represent the full website, but they are perspective-based; given the unique needs of the consumers of the description UI, end product, and database structure.

To carry the example further, let’s imagine that the organization developing the eCommerce website, would like to build other websites of varying degrees of similarity to the eCommerce site. Each potential future website would certainly have a UI, end users curious of the website’s look-and-feel, and database elements that would need to go to the DBAs for review. This would lead to similar views produced for the same types of consumers as the first eCommerce site. In an attempt to increase efficiency, the organization decides to create templates for these views. Each view template could include standard notation, the questions that came from the consumers of the views for the first eCommerce site, as well as common attributes characteristic of a template; such as a title and description of the data in the view. This company could achieve greater consistency, increased efficiency, and an opportunity of quality improvement by refining the template over time and allowing each use of the template to produce a view to provide feedback to the next use.

In an attempt to standardize the production of architecture descriptions for software systems, the IEEE in 2000 released a recommended practice entitled “IEEE Recommended Practice for Architecture Description of Software-Intensive Systems.” For those that are familiar with IT architecture already will know that this is the extremely commonly referenced IEEE 1471, but if you are new to the domain, or are still unclear on the differences between views, viewpoints, and models, hopefully this short description will help.

Views

In IEEE 1741, views are defined as “a representation of a whole system from the perspective of a related set of concerns.” In the eCommerce example above, the three topical views – wireframe, mockup, and ERD diagram, fit this description. Each view attempts to present the whole system, or a subcomponent of a large system, from an interest-oriented purview. This is done so that whoever is interested in the information in the view can understand the system in the way most pertinent to them. In civil and industrial engineering, an example of this concept would be the use of floor plans to describe the structure of the home to a contractor, electrical schematic to describe the wiring plan to an electrician, and a 3d model to describe the end product to the customers. Each view on the physical structure represents the entire building from a specific perspective based on the concerns of the stakeholder.

Models

Models are simply parts of the overall view. For example, wireframes of 10 different screens exhibit the view – the wireframe of the eCommerce site – with 10 different models – one for each screen. In IEEE 1471, models are not given specific definition, but they are discussed in terms of their contribution to a view and their consistency with viewpoints.

Viewpoints

In IEEE 1741, viewpoints are defined as “a specification of the conventions for constructing and using a view.” It goes on to say that they are “a pattern or template from which to develop individual views by establishing the purposes and audience of a view and the techniques for its creation and analysis.” Returning to the eCommerce website example, the process of creating templates for views would lead to the creation of viewpoints. The viewpoint attempts to embody the concerns, or topics, that the consumers of a given view are interested in, and thereby provide the view-creator – that is the architect – the promise of addressing the concerns of the view-consumers – that is the system stakeholders.

Below is a clip of the IEEE 1471 concept model that addresses these three terms with respect to one another:

 

Relationships and Architecture

Over the last couple years, I have been working out the implications of having a new architecture practice in an organization previously without one. A key issue that continues to surface is how important relationships are to architecture. This is true particularly when previous architecture decisions require governance to enforce and inform downstream project decisions. Lately, there have been several cases where a customer of a project has desired to purchase a given product and due to the impact to the architecture of that product and the fact that it does not promote key principles, something in the project had to change. This has meant that either the nature of the project had to change – implementation to investigation, project scope had to change, or even that the project, as stated, had to be cancelled altogether. It is at this point, when relationships have played an important role, in terms of defining an approach to communicate project changes. Here are a few of the lessons that I’ve been learning about relationships when it comes to communicating project governance decisions.

 

DOs

  1. DO use good stakeholder management techniques to determine who will care about certain decisions and why? By correctly identifying these people, I have saved myself time in re-explaining and re-justifying the rationale for a particular decision.
  2. DO communicate early and often. Once you have identified the stakeholders and their motivations, make sure to communicate to them as early and as often as possible. I have found that perfectly sane people generally take a day or two to acclimate themselves to a change in direction, especially if it’s for reasons that they don’t completely understand. The earlier you can begin this process, the better.
  3. DO include your boss in the stakeholders list. It might seem obvious and probably will depend slightly on the relationship to your boss and level of delegated authority you have, but it’s generally always a good idea to have your boss agree that a particular principle is applicable or that your suggested changes to a project are correct. Otherwise, you might find yourself discussing things with people, simply to have to back pedal when your boss gets brought in. Or, worse, if he brings himself in. This one might be more clearly stated, DO acquire or verify the authority/validity of a decision before communicating it.

 

DON’Ts

  1. DON’T assume that just because someone has heard you that they agree with you. It’s easy to become so convinced that what you’re doing is correct that you don’t take time to examine body language or ask probing questions. Silence isn’t agreement. Not that you won’t have to still make the decision to change a project, but you might discover something about the user or project manager’s requirements or motivation you weren’t aware of that might influence a change.
  2. DON’T communicate the decision in terms of architectural benefits. Chances are the stakeholder won’t care about “architectural integrity” so don’t forget to use contextualization and empathy to consider this stakeholder’s chief motivations, vocabulary, and communications style. Make sure to approach them on their terms and in their terms.
  3. DON’T be afraid of conflict and debate. Conflict can definitely escalate to unhealthy or unhelpful levels of intensity, so managing conflict is important, but don’t avoid it. Many decisions are only internalized by both parties as they are processed through debate and rationalization. It might be necessary for things to become slightly heated before a change is viewed as valid or even understood. Don’t provoke an argument, but don’t smooth it over either. Conflict is like debt, you can defer it, but you can never avoid it.

 

These lists are not exhaustive, so I would be glad of comments to this post that share your examples. I have definitely been shocked at how important relationships are to good architecture decision and governance. Managing these relationships well, starts with the realization that people are more than a means to an end and that collective contribution toward decision making (“group think”), though painful, is more effective in the long run than simple “because I told you so” tactics. Externalizing assumptions and internalizing decisions – relationships help facilitate both of these.

Requirements: Project Management or Architecture?

Having relatively recently earned my PMP, I have spent considerable time learning and practicing the science of project management. One of the key topics within the discipline, especially when discussing the scope, is requirements. I have also finished a solid year of research on architecture, which culminated with a reading of the TOGAF v9 specification, and there is much said in architecture literature about capturing and managing requirements. As I am attempting to formally establish an architecture practice at Liberty, there have been several questions around whose responsibility it is to manage requirements? The project managers think, for good reason, that requirements management is their responsibility. But having read TOGAF, especially the ADM, I am convinced that architecture also plays an important role in identifying and managing requirements. I think, like so many things, the ownership depends on the practicing organization’s structure and discipline. Below are some of my musings on how requirements responsibilities are worked out in three types of organizations.

Organization 1: No Formalized Architecture

In this organization, there is no formal architecture practice. This means that there is not a department dedicated to architecture and planning within IT or the broader enterprise. It also means that while there might be individuals with the title “architect,” there has not been any structure linking their activities directly to project work. In this organization, those who manage change efforts have the title “project manager” or something similar, and are functionally responsible for requirements gathering. As project managers, PMI has outlined several tools and defined outputs of requirements management, and while I take some issue with the lack of clarity expressed through the PMBOK around this topic, these are definitely good starting points for any project manager.

Requirements Management from PMBOK

  1. Tools
    1. Interviews
    2. Focus Groups
    3. Facilitated Workshops
    4. Group Creativity Techniques such as brainstorming, mind mapping, Delphi
    5. Group Decision Making Techniques
  2. Outputs (Documents)
    1. Requirements documents
    2. Requirements Management Plan
    3. Requirements Traceability Matrix

Organization 2: No Formalized Project Management

This organization either does not have any project managers or has not formalized its project management practice around a repeatable discipline. Liberty University’s IT division has been transitioning out of this type of organization for the last few years. While we have had project managers for as long as I’ve been at LU, there has been a high degree of variability between the tools uses, processes followed, outputs produced, and ultimately quality of delivered project. For us this has meant that when the project manager wasn’t collecting good requirements, others have led the charge. Most often those people were the lead engineer or that engineer’s manager. The justification for this has typically been that in order for the engineer to produce a product or solution, he needed solid requirements. On projects without solid requirements from the project manager, they were stuck doing it themselves. While according to PMI, this isn’t ideal, I am not convinced that this is always a bad thing. As I have researched architecture, I have seen that there is often a person who bridges the gap between the contractor (project manager) and the customer. We weren’t calling that person an “architect” at Liberty, but in most mature organizations, it would appear there is almost always a back and forth between project manager, customer, and architect. I think that while we’ve made strides at maturing one role – the project manager – in that triumvirate, I think the maturing of architecture development would have had equal, if not greater impact on requirements gathering.

I think this for two reasons. First of all, in most cases the architect will have skills that the project manager does not have. For example, I have worked as a software engineer and developer long enough to recognize the value in rapid (or even paper) prototyping; that in doing so you provide a quick view into what the end product could be? The chief purpose of which is to assess, refine, and collect additional requirements. The project manager in most cases, unless they are moderately specialized, will not have the ability to produce these prototypes. I believe this would and should fall on the architect. Secondly, it is evident from TOGAF, that gathering and rationalizing requirements is a central aspect of their ADM. Therefore, I believe that in organizations where there is no formalized project management, leadership should invest in staffing and training both project managers and architects. And, in the instances where these organizations already have architecture as a formalized discipline, I would wonder if they are not also functioning as project managers? If this is the case, then having architects trained in formal project management might provide even more benefit than staffing a separate role.

TOGAF on Requirements

Organization 3: Both Architecture and Project Management

In this organization, there is at least an attempt to have a formalized discipline for both architecture and project management. Requirements gathering activities for projects in Organization 3 should be the duties of both the project manage as well as the architect. This implies that there is an architect assigned to every project. I believe this is a critical point – if an effort is sufficiently large or complex such that it merits a specific project manager, then I believe that it also merits a specific architect. This might mean that some efforts have a project manager who is able to perform the duties of an architect and it also might mean that some projects are managed by architects.

My Thoughts…My Conclusion

I recognize that this blog is less scholarly than others and that my opinion is relatively meaningless when it comes to experienced architects, but I definitely am keen to the idea that architects do architecture well and project managers do project management well and that both should be committed to the act of requirements gathering. If projects are to successfully meet customer expectations, then they must do so through solid requirements gathering and management. I close with this quote from The Atlantic Systems Guild, Inc. on Mastering the Requirements Process,

Requirements are the most misunderstood part of systems development, and yet the most crucial. Requirements must be correct if the rest of the development effort is to succeed.

CIs and BBs: ITIL meets TOGAF

I have had some recent discussions about tool that I produced which is meant to allow projects to be assessed based on their architectural reuse of a set of core building blocks (BB). The proposed value of this would be to allow architecture development within a project to demonstrate architecture building block (ABB) reuse through a BB-Requirements matrix, where each project requirement would be mapped to a standard set of core ABBs. The matrix would theoretically show that the more BB-Requirement intersection, the less risk of unnecessary and non-compliant components being introduced by that project’s proposed architecture. This tool has been sent out to a few people and interestingly, one of the first questions that has come back has been related to IT management. Essentially, the question was this:

What is the difference between a TOGAF building block and an ITIL CMDB Configuration Item?

Since we are in the process of implementing an ITIL-compliant ITSM system, people’s attention towards topics like CMDB and CIs are definitely heightened, but the more I consider the question, the more I am drawn into this topic: Truly, what is the difference? Or, are there any differences at all?

A Configuration Management Database (CMDB) according to ITIL v3 is:

A database used to store Configuration Records throughout their Lifecycle. The Configuration Management System maintains one or more CMDBs, and each CMDB stores Attributes of CIs, and Relationships with other CIs.

A Configuration Item (CI) according to ITIL v3 is:

Any Component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the Configuration Management System and is maintained through its Lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include IT Services, hardware, software buildings, people, and formal documentation such as Process documentation and SLAs.

A Building Block (BB) according to TOGAF v9:

Represents a (potentially reusable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions. Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached. For instance, at an early stage, a building block can simply consist of a name or an outline description. Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanies by a full specification. Building blocks can relate to “architectures” or “solutions.”

Without claiming to be an expert in ITIL or TOGAF, I have attempted to outline similarities and differences that I believe exist at first glance. There are definitely several ways to look at the nature of the data and metadata which populate an ITIL CMDB or a TOGAF Meta Model-based Architecture Repository, but since I’m still learning to apply both knowledge areas, I’ll leave my assessment at only the surface level. Feel free to comment with additional thoughts or opposing views.

Similarities

  • Components: CIs and BBs are both discrete components – hardware, software, locations, roles, services, etc. – each with a unique set of attributes.
  • Relationships: Both are expressed not only in terms of their own attributes, but are most valuable when relationally modeled in respect to other components.
  • Abstractions: Both make use of abstraction, composition, and decomposition to express “low level” components and their relationship to “high level” components.
  • States: Some Configuration Management Systems (CMS) are able to manage transitional states between the current state and previous transitions or even proposed future states. This is similar in concept to the transitioning of a BB from a current to future state. Though, the implementation of this is dependent on the ITSM and CMS, CIs definitely support the idea of states.

Differences

  • Single vs. Multiple Perspectives

    One of the biggest differences between a CI and a BB is the framework that manages them. Since ITIL is primarily a Service Management framework, CIs are typically represented in a service model. Because of this, I would imagine that almost never is there a CMDB dedicated to managing the relationships between organizational goals and a process, nor is data typically modeled in a CMDB at all. Therefore, I believe you could consider ITIL’s service models to be a single Service Management view of the broader set of views required to model EA. This means that only the CIs required to model this view are housed in the CMDB.

  • Operational vs. Strategic Functions

    Since the CMBD typically only manages CIs related to service management, it is particularly helpful to those performing day-to-day service management activities. Consider a strategy map dashboard which shows strategic goals, their relationship to one another, and rolls up health information for each goal. This would be another operational view, supported by EA modeling which would not fit into a typical CMBD and therefore is not a candidate CI.

  • Service Management vs. Enterprise Architecture Context

    In summary, I think the biggest difference between CIs and BBs are their context. The systems which attempt to support this context do not take into account other uses. While the CIs in a CMBD are relegated to only those required to model the service management view, this does not have to be the case. Nor is it true that there shouldn’t be some collaboration between CMDB and EA repository vendors to support a dual purpose system, where BBs are able to be made into CIs in support of the IT service management view.

 

Views from Two Perspectives

A view is a tool used in enterprise and IT architecture, to display a particular perspective of a system, process, or change in a manner which communicates the most relevant, and therefore meaningful, information to a specific set of stakeholders. TOGAF says it like this,

A “view” is a representation of a whole system from the perspective of a related set of concerns.

As discussed in TOGAF v9, the formal definition for basic architectural concepts (ISO/IEC 42010:2007) shows views as the organizational tool of an architecture description. TOGAF bases its use of artifacts – catalogs, matrices, and diagrams – on this idea, stating that a variety of artifacts are necessary to communicate the architecture to the stakeholders who each have a unique viewpoint and therefore demand a view or a number of views.

While TOGAF does use views, I found the number of possible views to be incredible – 56 possible artifacts! Before reading TOGAF, I had seen views used in a less broad sense for software architecture in the 4+1 View Model of Software Architecture. In 4+1 there are 5 possible views – logical, development, process, physical (4) and use case (+1). In this model, the theory is that you start with the +1 (use case) view which helps capture what the user’s requirements are? Then you create the subsequent four views based on the needs of the architecture’s stakeholders. The stakeholder-tailored approach is found in TOGAF, 4+1, and all frameworks and methodologies that I have come across, so TOGAF’s 56 will never be the right answer for any question of “how many views to use?”

Since there are similarities between the possible views in TOGAF and the five in 4+1, I wanted to take a stab at aligning these two approaches. Below, I’ve taken each of the 4+1 views and listed the TOGAF view (diagrams only) that I thought best matched the 4+1 view. Hopefully, someone will find it interesting, helpful, or even worth commenting. I recognize others could debate which views go where, so please chime in with your thoughts.

Use Case

  • Solution Concept
  • Business Use-case
  • Process Flow
  • System Use-case
  • Events
  • Business Service/Information

Logical

  • Class
  • Class Hierarchy

Development

  • Application & User Location
  • Software Engineering
  • Application Communication

Process

  • Data Migration
  • System Use-case
  • Process / System Realization
  • Processing
  • Data Security

Physical

  • Communications Engineering
  • Platform Decomposition
  • Network Computing Hardware
  • Environments and Locations

“Big EA” and “Little ea”

Much has been published in the last five or so years about Enterprise Architecture. While Zachman and Spewek have been attempting to promote the idea for much longer, the recent frenzy around EA has been a great thing for maturing the profession and the promoting and expanding discipline of IT architecture beyond its technical realms. Many proponents have even carried this idea of “architecting the enterprise” into non-IT parts of the organization, claiming that EA is much more about strategic planning than specifically an IT process. I would agree with that. I also agree whole heartedly that EA is just as important, if not more so, to the organization’s strategic planners as to the IT program or project planners. Therefore to distinguish EA from other senses of the moniker and to partner with Zachman’s use of all capitalized letters for ENTERPRISE ARCHITECTURE, I have begun referring to this super-architecture; i.e. the process of architecting the enterprise as an independent system needing a planning process of its own; as Big EA. It’s in this sense that analysts at Gartner and Forrester to authors Bernard and Ross to Zachman to the writers of TOGAF, FEA, FSAM, etc. are referring to Enterprise Architecture. They are referring to Big EA.

There is, however, a less specific meaning to the distinction Enterprise Architecture. In organizations where there is little to no formal IT architecture process at all; where there is no formal architect, design, build progression; before Big EA can take place, there must be enterprise architecture or little ea. Little ea is the enterprise process for doing architecture, such that all people engaged in building are required to participate in a repeatable architecture process. Big EA can certainly happen before little ea, but without little ea, Big EA is forced to be focused on its own architecture alone and will have a difficult time consulting or reviewing or recommending or collaborating with other non-EA driven projects, whose specifications are non-existent. Organizationally, I am finding too, that outside the context of IT, there is generally little understanding of something as seemingly non-technical as architecture. That is until business folks sees it happening within the context of projects they directly requested. What I mean is that if we ever hope for Big EA to be a part of how the organization drives strategy, then it will need to be seen as a viable and relevant business activity on operational projects. Without little ea, the business does not experience architecture until it comes from the highest parts of the organization down. That is, of course, assuming that it would even be promoted downward by executives that probably don’t understand architecture’s presence in IT or business.

Unless you have support at the highest levels of the organization for an EA capability, in the Big EA sense, and if there isn’t architecture being employed in your IT ranks to systematize planning and execution, then my take is to start there. It will allow the organization to mature in concert with the collective frames of reference we all use to assess value and leverage tools. If EA is to be useful, then it must be practical and relevant.