A fundamental specialty of Bare Information Architecture is the art and science of managing information as an asset. This especially includes Enterprise Conceptual (including Semantic) and Logical Architectures. Therefore, many of the articles on this website discuss topics associated with Enterprise Conceptual and Logical Architectures.
The word "Enterprise" in this context might mean an entire company or organization, but it can also mean smaller organizations within a company or larger organization. So, when the word enterprise is used on this website, it does not necessarily mean an entire organization or company.
There is a difference between architectures and models, and between architects and modelers. A future article is planned to discuss these differences. However, for all intents and purposes, the topics discussed in the articles and standards published on this website will usually apply to both architectures and models. The end goals is to have articles on this website about each of these categories.
The articles in this part of the website will fit into one of the following categories. Many of you will recognize most of these categories as being part of the overall Enterprise Architecture. Some of these categories are also used in the written works published by the Business Rules Group.
Information Architecture
- Data Architecture
- - Semantic Architecture
- - Logical Data Architecture
- Function Architecture
- - Business Process Architecture
- - Application Process Architecture
- People Architecture
- - Workflow Architecture
- Rule Architecture
- - Business Plan Architecture
- - Business Rule Architecture
Conceptual and Logical architectures are components of the overall Enterprise Architecture. These architectures are not just built for architects. Conceptual and logical architectures are built primarily from the perspective of an enterprise's business planners, owners, managers, and those how use the systems on a regular basis. Built correctly, these layers or perspectives describe the entire enterprise; they are not limited to the individual groups or departments within that enterprise.
While we categorize architectures into perspectives and basic content, architectures are a bit more complex than being simply of a specific layer or perspective. Much of the value of an overall enterprise architecture comes from the explicit relationships among various components of the individual architectures - including those among logical and physical architecture components. This is especially true in today's heavily automated world where conceptual and logical architectures are critical for the effective design, development, purchase, and management of computer systems, applications, websites, and their associated databases.
However, the articles on this website will primarily focus on conceptual and logical architectures. The exception to this rule will be articles about my experiences designing and managing websites and how these activities can greatly benefit from explicit Architectures. (Of course there is an exception. Aren't there are always exceptions to the rules?)
One of the most important distinction of these architectures as compared to physical architectures is they are independent of technology or implementation choices. What this means is these architectures are independent of whether their contents are manual or automated. It also means, very importantly, they not structured or constrained by the types or specific instances of computer systems or applications, database management systems, data warehouses, etc.
While specific physical and technology implementation choices should not constrain conceptual and logical architectures, this becomes difficult when choosing the notations and tools used to store and depict them. Even in this day and age it is difficult to find modeling tool that are not based on specific types of technology. It is especially difficult to find to robust modeling tools powerful enough to effectively define and store enterprise-wide models that contain technology independent notations. This task becomes even more difficult, if not impossible, when trying to find such a modeling tool that also either contains or is integrated with an enterprise level information or metadata repository (formerly called a data dictionary). Therefore, most architects and modelers use one or more technology constrained modeling formalisms or notations.
Because of the tool limitations and common usage of certain model notations, the articles on this website will frequently use one or more technology related notations to depict examples, most notably articles related to data modeling. Articles discussing data modeling topics will often contain examples depicted in either UML, ER, or ERD data model notations, but it is not an endorsement of any of these notations. Also, please keep in mind that semantic/conceptual or logical data models produced using any of those notations, especially UML notation, will be very different in structure and content from physical data or database models produced using those same notations.
As is the case with other conceptual and logical architectures, data architectures from these perspectives, such as ontology or other semantic models and logical data models, should be independent of technology and implementation choices. However, there are some several challenges related to keeping these architectures (and the models that represent them) completely free of technology related choices. For more discussion on this topic, please see the read the article titled "Data Architectures and Technology Independence" and subtitled "Is There Gray When It Comes To Technology Independence for Ontology Models, Semantic Models, and Logical Data Models?".
Often times modeling techniques that apply to all data types of data architectures are incorrectly thought to exist only for a physical models or databases, or only for a specific type of technology, such as relational models. One such technique or process is normalization. Normalization is actually about normalizing logic, not just relational models or physical databases. Therefore, normalization will be discussed in articles on this website related to conceptual and logical data architectures as it is imperative the models representing these architectures are normalized.
Examples of models that represent these architectures are: Ontology and other Semantic Models (Conceptual Data Architectures), and Logical Data Models.
If you want to contact Bare Information Architecture about the articles, or any other topics, please fill out the form on the Contact Us page.