Structures influence your thinking
I hear a lot about the Zachman Ontology (aka Zachman Framework), mostly from people criticizing it for what it is not. Those that assume that the Framework is a detailed methodology become sadly disappointed when it doesn’t produce a step by step process to create an architecture or a design. For what it’s worth the discussions I’ve had with my mentor, colleague and friend, John Zachman, have been around using the framework as a means to guide thinking about the structure of enterprise design information.
A recent project I’ve been consulting on -- my role in the project is as an internal consultant and mentor rather than owner or lead—has had all the earmarks of a moonshot. It has the potential to be a game changing event in the life of the organization or a catastrophic failure. Much of the tasks at a high level seem familiar to most. However, when you scale something like this up old practices are not effective. While the world seems to focus around being quick or agile, building a structure like the Empire State Building cannot be successful without some structures to manage complexity.
As Mr. Zachman has stated so often, “Architecture’s job is to manage complexity”. As I reflect on how the project is moving at each meeting I propose intellectual tools to the team to help manage this complexity. These conceptual tools come straight from the Zachman Framework.
The project stands today being focused around a project plan (e.g., WBS – lite) there are many tasks to execute upon. However, I saw one glaring gap. The “what” and the configuration of the “what” is currently left to individuals. The end result is information about what components are in the system, the state of the development and the relationship between these components is often muddled and constantly being revisited due to gaps in communications between parties. While the project plan and tasks are improving, managing the configuration of the “entire” system continues to be a struggle.
For those of you in a similar situation here is some advice taken from the pages of physical products architecture and engineering. Create a “System Bill of Material Tree (BOM)” and put it into some form of configuration management tool to share across the project staff. Having this practice and the discipline to use it on large projects is what enabled NASA to successfully make it to the moon and back.
If we consider architecture as the "structure of models in contexts", culture may be seen as a category of myriad other contexts - technical, socio-societal, legal, political, financial (monies), economic (values), etc. What we manage are the behavioral outcomes - results - of the interaction of these models in and between contexts. Given various norms for each context, we try to ameliorate risks that show up as inconsistencies within these contexts. This "complexity" has moved beyond the capability of cognition in human minds, and must be modeled and validated computationally.
Architecture and agile aren’t opposite, good architectures can be built using agility as long as there is a recognition for the value of architecture. What agile movement over years has been trying to fight is architecture that leads to inaction or analysis paralysis. I agree with the thinking that structure has a lot of influence on thinking. I drive my WBS from architectural aspects most of the times.
My thanks to Brian K. Seitz for publishing this article. I am undertaking a project to produce a video which will show how (according to my experience and research into 5 structures, namely Yourdon's Structured Analysis and Design, Jackson's System Development approach, Information Engineering, the Zachman Framework and my own) the ZF could be improved (or replaced). It should be ready in about 3 to 4 days. This video is now available. Regards ps I have completed my video on how TOGAF could be improved (or replaced)
"mostly from people criticizing it for what it is not" I miss our talks at Ready :-)