This is a previous blog posting:
One of the most ambiguous words in the initial understanding of Information Architecture is that of the Framework. The Framework is a generic categorization method for architecture design artifacts. Any good categorization method achieves these EA goals:
I am not saying that we would look at every single architecture cell within the Zachman frame work, but what we may want to do is approach this by reviewing a horizontal layer near the top or from a conceptual perspective at a very high level. Set a time limit, go wide
This topic is architecture frameworks.  I’ve collected some thoughts to help you decide on one to use if you are faced with this important decision…
WHAT IS AN ARCHITECTURE FRAMEWORK?
The Framework is a generic categorization method for architecture design artifacts. Any good categorization method achieves these EA goals:
1. Simplify information for understanding and communication
2. Clearly focus on independent components for analytical purposes
3. Provide and maintain a disciplined method of depicting relationships between the domains.
A Framework is a set of approaches, components, configurations, models, services, standards and principles that can guide you in your documentation adventure of a particular view of an architecture.
HOW CAN I BENEFIT BY USING A FRAMEWORK TO GUIDE DESIGN?
While there are many benefits in using a framework to guide your development efforts of an architecture, there are two that are more elementary and prevalent than others: Guidance and Communication.
The framework is a guidance tool which is used to ensure that each architecture domain is adequately reviewed and documented, and can most easily be compared in context to the other domains or views. It guides both the method and approach to completing an architecture, and enables all stakeholders to see a consistent and complete picture when reviewing an architecture.
The framework can be used as the primary communication vehicle between architects, the project team, stakeholders and IT technical staff. It can be used to show what you’ve planned, and how you will achieve flexibility in the future.
Other benefits that you may expect from using a framework, is the provision of a generic space and structure for a very complex and varying problem. It can include a starter set of principles, issues and concerns. It can provide guidance on which sets of diagrams and models to include.
WHAT FRAMEWORK CHOICES ARE AVAILABLE?
There are numerous frameworks available to be used, but they are primarily categorized by domain. They are typically designed for government, or non-government (private organization). Some are strategically oriented and some are focused on organizing the evolution of the architecture.
An organization can choose to adopt an existing architecture framework or to build a custom framework. In either case, it is rarely necessary to start from scratch, and the primary focus should be on the stakeholders and the domains you wish to capture. Try to keep in mind that the primary goal here, is ‘Communicate that architecture!’
If you choose to adopt an architecture, consider visualizing what kind of data and models you will use to populate it. Ask yourself ‘what is important to my organization?’, and ‘how have we organized our departments and business in the past?’ Many frameworks are used for a particular type of community, so try to pick the one that is most similar to yours.
Enquire with peer organizations as to which type of framework they have used. There is value in understanding and using more than one, so pick the one that is the closest, and adapt it by selecting one or more components you would need to close the gaps between the one you select and what you need for your organization.
If you choose to build one, please consider finding one or two that have components of what you need and take pieces to build your own. We really don’t need to reinvent the wheel. I prefer the ‘a la carte’ method myself, and have actually trimmed one of the most simple and straight-forward frameworks available, then customized the look, feel and tools as
well as the processes for it. Customize it to suit your culture and technical vocabularies for the ultimate in success!
WHAT FOLLOWS YOUR FRAMEWORK CHOICE?
This article won’t attempt to describe the Enterprise Architecture Process, nor the strategy to complete it. What I can do is give you a few hints about your next move after choice. I have spent a great deal of time and effort studying and customizing decision making techniques for my consulting engagements, and one of my secret weapons is the ‘litmus test’.
After a framework has been selected, evaluate it’s use within your business environment. Review the goals and objectives in using such a framework, and see if what you picked will work.  After treading through a few examples, list the lessons you may have learned and refine what you’ve selected.
Today’s Tip:
The Architecture Framework selection process is not a process that should ever be considered ‘done’. Include an ‘Architecture Framework Review’ step after every major architecture documentation project, and it can only get better and better!
After a recent week at the Enterprise Architecture Conference, I realized that the comfort level with iterative development, iterative Enterprise Architecture Planning, or iterative anything still is not abound amongst IT professionals. An especially long reach is getting started Read the rest…
Someone asked me a philosophical, yet, appropriate question the other day.
Why do I still continue to use a very simple framework in my coaching and consulting with Enterprise Architecture? I began using something called BAIT (business, application, information and technology), and turned to something else – BOAIT (business, organization, application, information and technology).
I thought for quite a while, and went through what has changed since I started working in the Enterprise Architecture space.
We went from application architecture, through system architecture (which now might be known as technical architecture). I saw Meta put forward a combined application and data layer called solution, and now we’ve hit the peak in the area of solution architecture (whereas no one really speaks of application architecture anymore).
Do we use Zachman, Dodaf, FEAF, or something else? It’s all a matter of classification, and the purpose is communication. The clearest method has to be sufficient. The rest is background noise – it’s about doing and using architecture, not just defining it.
My answer is simple. I started with a very excellent book that was very appropriate in the mid 90′s. It is Steven Spewak’s Enterprise Architecture book. At the end of the day, it all boils down to Applications (solutions if you may), Data and Technology. The business drives all of the other architectures, as they are wound within the strategic plans. None of that can really change – we can add SOA, Security Architecture, or change how we term what goes on in the operations and technical areas and we will still boil it down to all of this.
Our business strategy drives which data we need to collect, process and transmit. The systems/applications and solutions will provide mechanisms to make these transformations, and the technology in the areas of software, hardware, configuration, etc. will physically allow it to be so.
Nothing has really changed my perspective – just some of the details around how and why I would collect, analyze and interpret what I’ve categorized.
One of the most ambiguous words in the initial understanding of Information Architecture is that of the Framework. The Framework is a generic categorization method for architecture design artifacts. Any good categorization method achieves these EA goals:
1. Simplify information for understanding and communication
2. Clearly focus on independent components for analytical purposes
3. Provide and maintain a disciplined method of depicting relationshipsbetween the domains.
A Framework is a set of approaches, components, configurations,models, services, standards and principles that can guide you in your documentation adventure of a particular view of an architecture.
HOW CAN I BENEFIT BY USING A FRAMEWORK TO GUIDE DESIGN?
While there are many benefits in using a framework to guide your development efforts of an architecture, there are two that are moreelementary and prevalent than others: Guidance and Communication.
The framework is a guidance tool which is used to ensure that each architecture domain is adequately reviewed and documented, and canmost easily be compared in context to the other domains or views. It guides both the method and approach to completing an architecture,and enables all stakeholders to see a consistent and complete picture when reviewing an architecture.
The framework can be used as the primary communication vehicle between architects, the project team, stakeholders and IT technical staff. It can be used to show what you’ve planned, and how you will achieve flexibility in the future.
Other benefits that you may expect from using a framework, is the provision of a generic space and structure for a very complex and varying problem. It can include a starter set of principles, issues and concerns. It can provide guidance on which sets of diagrams and models to include.
Think of it as a “placeholders” map to what would make a complete architecture. It is also known as a set of views of an organization and its Business and IT Resources and assets.
WHAT FRAMEWORK CHOICES ARE AVAILABLE?
There are numerous frameworks available to be used, but they are primarily categorized by domain. They are typically designed for government, or non-government (private organization). Some are strategically oriented and some are focused on organizing the evolution of the architecture.
An organization can choose to adopt an existing architecture framework or to build a custom framework. In either case, it is rarely necessary to start from scratch, and the primary focus should be on the stakeholders and the domains you wish to capture. Try to keep in mind that the primary goal here, is ‘Communicate that architecture!’
If you choose to adopt an architecture, consider visualizing what kind ofdata and models you will use to populate it. Ask yourself ‘what is important to my organization?’, and ‘how have we organized our departments and business in the past?’ Many frameworks are used for a particular type of community, so try to pick the one that is most similar to yours.
Enquire with peer organizations as to which type of framework they have used. There is value in understanding and using more than one, so pick the one that is the closest, and adapt it by selecting one or more components you would need to close the gaps between the one you select and what you need for your organization.
If you choose to build one, please consider finding one or two that have components of what you need and take pieces to build your own. We really don’t need to reinvent the wheel. I prefer the ‘a la carte’ method myself, and have actually trimmed one of the most simple and straight-forward frameworks available, then customized the look, feel and tools as well as the processes for it. Customize it to suit your culture and technical vocabularies for the ultimate in success!
WHAT FOLLOWS YOUR FRAMEWORK CHOICE?
Today’s newsletter won’t attempt to describe the Enterprise ArchitectureProcess, nor the strategy to complete it. What I can do is give you a few hints about your next move after choice. I have spent a great deal of time and effort studying and customizing decision making techniquesfor my consulting engagements, and one of my secret weapons is the’litmus test’.
After a framework has been selected, evaluate it’s use within your business environment. Review the goals and objectives in using such a framework, and see if what you picked will work. After treading througha few examples, list the lessons you may have learned and refine whatyou’ve selected.
So there you have it – my quick thoughts on Frameworks. I have many more, but these are the basics that I might write about without much effort.
Want to learn more about frameworks? See our member site.