Architect’s Intent

Architects Intent

The Department of Defense has an architecture framework for enterprise architectures called DODAF.   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 compliant 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.

2 Replies to “Architect’s Intent”

  1. Thankyou for this really nicely articulated Post. I have worked for over 15 years as a Systems Engineer with expertise in Enterprise Architecture & Portfolio Management. I have had the opportunity to support several Federal PMOs in the role of a Architect. I thorughly enjoy this role of the “Artist” I play. Through my years I have found sponsors who either “Totally relate” or “Totally not-relate” to the Architecture. Unfortunately for me the contracts I have had operational focus which leaves “little” respect for Architects such as my self…. The challege has always been finding a Company & Federal “sponsor” who see’s an Architects world of “visualization”. But when you do find the “sponsor” Governance level at which this sponsor fits in the Enterprise has a great bearing to supporting the work of the Architect.Very few can really relate to products of the Architect…

    I found your article very touch – since I find few of my type that can relate to the world I as an Architect live in.


  2. Howie,
    I think you have captured this nicely but not sure I agree entirely. I am struggling with the book analogy, trying to convince my self that the purpose of the book and the purpose of the architecture are really different so integrating the “data” of similar books may not make sense. The idea of integrating architecture has to be at the data object level (yes it is ultimately all about the data) disassociated with the intent of the architecture that object resides in. For example, a fire truck is always a fire truck regardless of whether it is responding to a car accident or a fire. Two entirely differing contexts and mission sets that both require fire trucks.
    I have always thought the architects job, beyond preparing specific required views, is create a box of inter-related data that can be viewed from whatever angle a consumer needs to view it as. When you start creating these boxes of data with common data objects and instances (e.g. the fire truck responding to a fire and the fire truck responding to a car accident) you start to see the multiple uses and connctions between the objects across not only your enterprise but perhaps other enterprises that yourobject relates to. Once you start down this enterprise of enterprises thought process I believe there is a lot of benefit to be reaped.
    Anyway, thanks for the thought provoking piece. Perhaps we can have one of our mind bending discussions on this subject next time we have a chance to talk.


Leave a Reply

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

You are commenting using your 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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: