Architects Intent

Architects Intent

The Department of Defense has an architecture framework for enterprise architectures called DODAF. http://cio-nii.defense.gov/sites/dodaf20/   In a nutshell the DODAF is a framework in order to “facilitate the ability of Department of Defense (DoD) managers at all levels to make key decisions more effectively through organized information sharing across the Department, Joint Capability Areas (JCAs), Mission, Component, and Program boundaries.”

So, the DoD created this framework which provides guidelines on document structure and some document or product context.   If you don’t know about DODAF the link above will provide enough information to keep you busy for a while.   The purpose of my discussion today is not specifically about the DODAF but more about the people that write DODAF products.   I have worked with System Architects for years and I have also worked with managers and military members who use these products.  More recently I have spent a lot of time studying architectures with a specific focus on the data behind them.

Generally architectures are produced by a subject matter expert or an architect that interviews or collects data from subject matter experts.  It is an interesting situation because subject matter experts are not always equipped to be architects but architects always have to be flexible enough to at least understand a subject matter expert or data concerning a subject.  The reason this is important to note is because when DODAF products are produced they are not always complaint with the guidelines of DODAF.   Architectures are stories starting from the identification of what they are and what language or terms are used to describe them to what happened and why and finally what were the tools and systems involved.  What are the methods?  What was the process? What happened?  What do we want to happen?  There are questions in the thousands and lists upon lists.   The role of the architect whether designated or implied (because the subject matter expert needed to do the job) is a critical role that requires patience, understanding and the ability to separate one’s self out of the equation.   Did Picasso disconnect himself from his art as he painted his masterpiece?   This is what he would need to do if he were an architect.   Even as a (SME) Subject Matter Expert the architect needs to use his expertise but not allow his opinion to skew the product.

The reality is that it is a skillset that is by training and great practice that an architect learns to pull himself out of the story (art) and becomes the third party active observer.   It is unusual to find an architect like this and when you do find them they are very valuable.   That being the case, it is common to see architecture products with telling signatures of the person defining or designing the product.  There are plenty of products that are based on pure facts or lists of information but how those lists are mapped to each other are by the perspective of the artist (architect).

Architects create products with intent.   They have a resolve and they are determined to show the questions asked and the answers to those questions when possible.    The end result of their work is normally in the form of a picture, if it is an operational picture it can be in the form of image or movie.  Regardless of the product it is an interpretation of a situation drawn or written in context to explain or show the subject matter.   The architect was the artist who placed the images or words on the canvas to create this telling product.   Once created and shared, a manager or leader could look at this product and instantly should understand what the product represents and the context it is bound by due to the label such as Operational View 1 (high level).

Understanding the architect’s intent is important when looking to interpret the subject.     Why did they put people on one side of the image and vehicles on the other?  Why did they make one person bigger than the others?  Where did they get the information for this?  What does this tell me?   Like I said there are a number of questions.

In recent times there is a lot of discussion to become The data centric enterprise  This essentially means that we focus on the data itself that creates these architecture products and we find ways to reuse the data in order to create efficiencies and commonality though our products.  I have heard “it’s all about the data” or that we must federate and integrate data.

If I have five books all with different stories but these books used the same headings or document structure it would make sense that I could put them together into a book repository.   I could even find commonality in the books themselves.   I could search across the chapters to see where certain words were used and I could perform analysis and determine potential points on where the stories align.  I wonder how much that would cost.   I also wonder what happens to the author’s intent when you put these books into the same repository.

What if you took the Bible (New Testament), the Torah, The Koran, and other religious text or philosophical texts and integrated or federated them into a repository?   What would happen to the intent of each specific document?  What would happen when you found the common threads between them would it skew the end reader (consumers) perspective?

How far do you decompose data?  If you decompose a book into paragraphs, sentences, words, or letters most if not all are reusable but to what end?

In architectures, the job of the architect is to gather as much contextual data that is factually relevant and compose a picture that is (FOR PURPOSE).   This for purpose product can be reused but within the scope and context of the architects intent.

As we decompose datasets for reuse the only way that we can leverage that data is to keep it tagged or identified consistently with the intent of the original architecture creator.