]]>
Most of you are either faced with a deadline that wasn’t made before year end, or with picking up the pieces after a messy year end.
]]>
Disaster Recovery is typically years of planning for a major event where pandemic planning is essentially determining which pieces of your business is non-critical so that you may take it down gracefully because you don’t have enough people to run it. How many of you have business processes that are able to facilitate that question?
Years ago, I was responsible for figuring out which databases were critical to an organization I worked at because the century’s biggest flood was coming. What if we had to relocate and run our business else where? Which systems were the most critical and which databases would we need to make available somewhere else? We were situated at the lowest level in the city, and would likely have to move if our core flood prevention methods failed.
Now turn the tables for a minute – if I had a team of ten database resources working everyday to keep the systems supported, two system resources, a security guard and a building maintenance resource, how many could be affected by a pandemic if one should hit my city? Who would decide what needed to move? Or more likely – what database operation or support function didn’t need to get done for some undefinable future?
Now even more likely, if you have a call list, what are the chances that someone on that list would be affected? How would you contact the others to get replacements if the city or area is engolfed in chaos. As the presentation suggested, many wouldn’t want to leave their homes for fear of being affected by others. Do you have a plan in place by your business architecture as to priorities for keeping your minimum technologies running?
Just a few thoughts that got me thinking about what I might suggest to a few of my customers that have been thinking in reverse for years. Business Architectures must be in place and current in order to make such rapid decisions, and the value of these exercises is most often over looked.
]]>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!
]]>Over time, we have collected a superset of principles we have included in client’s EA Plans.
Take a look, and use some that pertain to your organization. If you can, try to focus on 3-5 in each area rather than using all. If you use all, you will find that they are too much to focus on, and aren’t easily remembered, nor understood.
Be careful – you might choose two from the list that could contradict each other.
The samples provided here need to be expanded within context of your architecture and/or organization. They are provided as samples and as a starting point only. Include only those which pertain to and are specific to your organization within your architecture documentation. A suggested format allowing for context and ramifications is provided.
Get the indexed document Sample Principles. Use a handful of samples from each section and build a list custom to your organization.
]]>