Barriers to Information Architecture
Communication
 | Technologies - Lack of common language to allow communication |
| Communication with a diverse readership |
| Difficult to communicate (who needs to know what?) |
| Lack of common vocabulary/concepts |
| Lack of clear alignment with business objectives (BA, SA) |
| Lack of good examples and methodology |
| Lack of understanding of “Architecture” |
Cost Benefit
| The cost of doing it |
| Long term benefits require short term added cost. Who pays? |
| Justifying the IA “Why should we do this (investment, training, cultural change, etc.)?” |
| Dedicated staff to support effort |
| Benefits/justification and legacy investments |
Culture
| Trust (customer/IS) |
| Business viewing I/S as service group not strategic |
| Independence of company divisions |
| As it takes shape it impinges on existing prerogatives |
| Resistance to standardization |
| Overcoming view of Architecture as a control |
| Culture of organization (4) |
| Threat to legacy environment, people |
Design Challenges
| Designing in compatibility with solution suppliers |
| Designing in legacy systems |
| Establishing a realistic set of guiding principles that have a high probability of withstanding the test of time |
| Establishing a credible migration plan and strategy (must be practical and achievable) |
| Added level of complexity when dealing with international IA |
| Working across multiple countries |
| Obtaining global consensus to the new architectures |
| Is it a “design or is it a “consensus” (read lowest common denominator) |
| Balancing “You can't fix tomorrow's problems with yesterday's ideas” with “Don't throw the baby out with the bath water”. |
I/S Subculture
| Identification/Realization by IS professionals that the value their department adds to the company will be different (5) |
| Shifting the paradigm - forward thinking vs. - re-acting |
| Lack of common vision for IT |
| Too many people with career investments in the status quo |
| Outdated technical knowledge of MIS management |
| Conflict with personal objectives (rewards) |
Methodology
| Lack of formal technical modeling method/syntax |
| Establishing metrics to track progress of the migration towards a new architectural paradigm |
| Lack of good examples and communication |
| Lack of method/technique to “transform” from business models to application models to technical models |
| Need to get common understanding of what the TA is and how to use it (AGT) |
| Lack of “Completeness Criteria” How do I know when I've got one? |
| Validating the TA “How do we know this will work?” |
| Focus definition on the most useful parts for the business' needs |
| “So I have a business architecture; now how do I use it to drive to technical?” |
| Getting I/S people and business people with the right skills to do it |
| Ensuring the architectural vision addresses the basic business problems (Proving the Concept) |
Sponsorship
| Management support |
| Business understanding value of the effort |
| Not a priority in our organization now |
| Corporate level commitment to the process |
| Corporate sponsor |
· Scope
| Huge range of issues “It doesn't help me if it doesn't include ...........!” |
| Wanting to solve or make “product” decisions |
| Agreeing upon the scope for an Information Architecture |
| Getting acceptance of “constant” change |
| Knowing what is important to the business which is impacted by TA |
| Establishing business objectives for an architecture |
| Building highways, not bunkers |
| Large number of stakeholders |
Time
| Perception that it's a future effort because everything is changing too fast now |
| It takes a long time elapsed and work time |
| Long term focus blurred by short term pressures |
Technical Architecture (Exercise Format)
| Presentation |
| Issues (Brainstorm) |
| Affinitize (Group) |
| Prioritize |
| Summarize |