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 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.
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.
Esquire 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 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 few examples, list the lessons you may have learned and refine what you’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.