Friday, January 02, 2009
Worst Practices of Enterprise Architects
Have you ever considered some of the worst practices of enterprise architects? I bet Gunnar Peterson, Nick Malik, James Tarbell, Chris Swan, Todd Biske and others could make the list even larger...
1. Instead of focusing on perception management, concentrate on becoming a skilled negotiator. We need to strike balance between technical complexity and business needs. Don't just change perception, focus on reality.
2. Spread the wealth. Enterprise architects who are the single source of knowledge on a given topic within an enterprise is dangerous. We all need to plan for when we all get thrown under the bus and the best way to do this is to make all decisions transparent and all communications open.
3. Governance is not about financial controls but is all about a behavior model. Command and control doesn't work, neither does design by committee. Remember that the best architectures are realized by self-organizing teams.
4. Don't be afraid to ask for help. Enterprise architecture is not about posturing and hand waving. It is important to understand your limitations and ask for help when you don't have a clue.
5. Think like a developer. Way too many architects throw daggers at developers, yet we haven't thought about what it is like to walk in their shoes. By using minimalist architecture approaches such as keeping things simple, you increase the odds that the code will be as high quality as the architecture.
6. Process is not a substitute for competence. CMMI, maturity models and all that is wonderful, but your budget, governance and thinking need to include ways to increase the competencies of the IT organization as a whole by incorporating training into the equation.
7. Don't always trust analyst information as being complete or having integrity. For example, if you are looking for information on a BPM or ECM platform, did the analyst firm have enough integrity to place open source offerings into their Quadrant? Remember, that analyst firms are comparing vendors which puts open source at a disadvantage where you need to understand the comparison of products which makes open source more favorable.
8. The enterprise architecture should not be a walled garden. Strategies are not insular and need to include components for making the ecosystem more secure. Within my vertical (insurance) the ecosystem starts with insurance agents and includes participants such as autobody shops, those in the medical profession and so on. They are also participants in the architecture even though they may not have adequate businessrepresentationevangelism.
9. Distillation is a mental disorder. Let's acknowledge that some disciplines such as security is hard and not everything can nor should be distilled down into a few bullet points for non-technical IT executives to understand. Loss of fidelity in many situations hurts, not helps enterprises in their decision making process.
10. Don't mistake productecture for architecture. Stop getting giddy because of some new feature added to a product. Instead focus on the strategic intent of your business. Architecture is not simply a collection of products deployed on an infrastructure with components being mediated by a firewall/DMZ.
| | View blog reactions1. Instead of focusing on perception management, concentrate on becoming a skilled negotiator. We need to strike balance between technical complexity and business needs. Don't just change perception, focus on reality.
2. Spread the wealth. Enterprise architects who are the single source of knowledge on a given topic within an enterprise is dangerous. We all need to plan for when we all get thrown under the bus and the best way to do this is to make all decisions transparent and all communications open.
3. Governance is not about financial controls but is all about a behavior model. Command and control doesn't work, neither does design by committee. Remember that the best architectures are realized by self-organizing teams.
4. Don't be afraid to ask for help. Enterprise architecture is not about posturing and hand waving. It is important to understand your limitations and ask for help when you don't have a clue.
5. Think like a developer. Way too many architects throw daggers at developers, yet we haven't thought about what it is like to walk in their shoes. By using minimalist architecture approaches such as keeping things simple, you increase the odds that the code will be as high quality as the architecture.
6. Process is not a substitute for competence. CMMI, maturity models and all that is wonderful, but your budget, governance and thinking need to include ways to increase the competencies of the IT organization as a whole by incorporating training into the equation.
7. Don't always trust analyst information as being complete or having integrity. For example, if you are looking for information on a BPM or ECM platform, did the analyst firm have enough integrity to place open source offerings into their Quadrant? Remember, that analyst firms are comparing vendors which puts open source at a disadvantage where you need to understand the comparison of products which makes open source more favorable.
8. The enterprise architecture should not be a walled garden. Strategies are not insular and need to include components for making the ecosystem more secure. Within my vertical (insurance) the ecosystem starts with insurance agents and includes participants such as autobody shops, those in the medical profession and so on. They are also participants in the architecture even though they may not have adequate business
9. Distillation is a mental disorder. Let's acknowledge that some disciplines such as security is hard and not everything can nor should be distilled down into a few bullet points for non-technical IT executives to understand. Loss of fidelity in many situations hurts, not helps enterprises in their decision making process.
10. Don't mistake productecture for architecture. Stop getting giddy because of some new feature added to a product. Instead focus on the strategic intent of your business. Architecture is not simply a collection of products deployed on an infrastructure with components being mediated by a firewall/DMZ.
