Jan
25
The Anatomy of an IT Strategic Plan
Filed Under Strategy | Leave a Comment
Stephanie Overby CIO.com presents her view of the Anatomy of an IT Strategic Plan as follows:
- Timing: Most IT leaders will want to start thinking about the IT strategic plan in the spring to best position themselves for the budgeting cycle. An IT organization’s first strategic plan can take anywhere from three months to a year to write.
- Time Frame: The plan should cover three to five years, with the most focus on the next 12 to 18 months unless there is a longer-term project on the table.
- Medium: Word document and/or PowerPoint presentation. Create an abbreviated version that you can turn to anytime someone has an issue or question.
- Length: 15 pages. Or less. If using PowerPoint, 25 slides. Or fewer.
- Executive Summary: The plan should begin with a summary targeted for the business audience.
- Scope: High-level goals and plans for all areas of information technology that affect the business, not just the infrastructure. A road map for IT is useful in illustrating overall strategy.
- Business Context: Lay out the specific business drivers, assumptions and plans that informed the IT strategic plan. (For example, the business is planning to acquire smaller companies so IT’s plan is to focus on integration technologies.)
- IT Principles: Short statements of purpose that will guide IT decision making and implementation.
- Metrics: Put measurements of progress in place when you create the strategic plan instead of waiting for review time to figure it all out. The goal is not precision but the ability to measure appropriate progress toward goals.
- Review: You should review the plan and revise it as necessary at least once during the fiscal year.
This is a great checklist for your IT strategy…
Technorati Tags: Strategy, Plan, Planning, IT Strategy, Goals, Objectives, Management
Oct
5
Heuristics as an Architectural Tool
Filed Under Definition, Heuristic | 1 Comment
The book "The Art of Systems Architecting" discusses the importance of heuristics as an architectural tool. The authors define a heuristic as follows:
"Heuristics are guides along the way - channel markings, direction signs, alerts, warnings, and anchorages - tools in the larger sense"
The word heuristic has it’s origin in the Greek word ‘heuriskein‘ which means "to find a way" or "to guide" in the sense of guiding a boat through treacherous waters. I liked this definition of a heuristic from Steve Pavlina:
"An heuristic is a rule for exploring a search space that can help you get close to an optimal solution when you cannot explore the entire search space."
Dave Snowden, discussing heuristics, provides the following insight:
"Heuristics are common sense sayings that make us think about things."
Heuristics are especially useful in decision-making, in providing guidance, and in solving ill-structured problems. There are primarily two types of heuristics:
- Descriptive heuristics: these describe a situation or context but do not provide any guidance on how to resolve it.
- Prescriptive heuristics: these provide guidance about what to do about a specific situation.
Carefully selected heuristics are great tools that architects can use to guide their journey into the unknown, they a great way to consciously apply the wisdom, insights, the lessons learned and gleaned from personal experiences and from the experiences of others. Heuristics are most useful when they are used as a set. Some example heuristics are:
- The beginning is the most important part of the work - Plato, 4th Century B.C.
- Build and maintain options al long as possible in the design and implementation of complex systems. You will need them.
- In order to understand anything you must not try to understand everything.
- Politics, not technology, sets the limits of what technology is allowed to achieve.
Deliberately and consciously selecting a set of heuristics at the start of a project is a great way to reuse the wisdom gained from past experiences. A team discussion on the most appropriate heuristics that should be "top of mind" and used as a set of guides, shared by the team, to guide their journey. Heuristics are especially important given the increasing level of complexity and uncertainty in architecting large systems.
In book "The Art of Systems Architecting" the authors provide the following rules to consider when applying heuristics:
- If it works, then it’s useful.
- Knowing when and how to use a heuristic is as important as knowing the what and why.
- Heuristics work best when applied early to reduce the solution space.
- Strive for balance - too much of a good thing or complete elimination of a bad thing may make things worse not better.
- Practice, practice, practice.
- Heuristics aren’t reality either.
To conclude:
“Heuristics are an essential complement to analytics, particularly in situations where analysis alone cannot provide either insights, or guidelines.”
How much have you learned as an architect? Have you codified some of your lessons learned into succinct expressions or heuristics to guide future architecture efforts?
Technorati Tags: Heuristics, Principles, Architecture, Rules, Guidance

