• Explore More Strategy Topics

  Agile Agility Alignment Architecture Benchmark Business Cost Decision-Making Definition EA Enterprise Architecture Enterprise Archuitecture Execution Framework Good Enough Governance GTD Heuristic IEEE 1457 IT IT Governance ITIL Management Measurement Methodology Performance Planning Planninig Principle Principles Process Project Reference Architecture Research Security Simple Small Wins SOA Social Architecture Software Architecture Solution Standards Strategy Technology Thinking TOGAF Trends Zachman

• Blogroll

  • Enterprise Architecture: From Incite comes Insight…
  • Pragmatic Enterprise Architecture
  • Serge Thorn’s IT Blog
  • Smart (Enough) Systems
  • Technology Architecture & Projects
  • The Practice of Leadership
  • Todd Biske: Outside the Box
  • User-Centric Enterprise Architecture

Michael Watkins wrote an interesting post "Demystifying Strategy: The What, Who, How, and Why", he defines business strategy as:

"a set of guiding principles that, when communicated and adopted in the organization, generates a desired pattern of decision making….. A good strategy provides a clear roadmap, consisting of a set of guiding principles or rules, that defines the actions people in the business should take (and not take) and the things they should prioritize (and not prioritize) to achieve desired goals."

In a nutshell, as illustrated below:

• Mission is about what will be achieved.
• The value network is about with whom value will be created and captured.
• Strategy is about how resources should be allocated to accomplish the mission in the context of the value network.
• Vision and incentives is about why people in the organization should feel motivated to perform at a high level.

Together, the mission, network, strategy, and vision define the strategic direction for a business. They provide the what, who, how, and why necessary to powerfully align action in complex organizations.

 

 

Technorati Tags: Strategy, Vision, Mission, Value, Business, Goals, Management, Leadership, Planning

 

Mike Walker wrote and interesting post on a discussion he had on “Making Sense of Architecture Standards" which resulted in the following image:

 

 

• Taxonomy and Ontology: Such as IEEE 1471, “. . .an architecture is a conception of a system. There may be many conceptions of a system… What this provides to the enterprise architect, solutions architect or domain architect is a way to have a constant set of terms for describing what it is they are building. This should be at the core to your architecture activities.”
• Information Model and Decision Support: Decision support help us to "..focus more on … What are the right questions  … How do I organize those questions … What do those answers mean … Meaning what is the process in which I get the information, consume it, process it and ultimately make it actionable."
• Process Framework: "… when talking about decision support, there is a need for a process to wrap how we make our decisions…. Having this higher level process framework is essential to architects. There are a series of benefits for the organization … Constancy in how solutions are created … The right people are selected for the right job … Proper metrics can be obtained to gauge health of the EA process … Predictability of results which lends to being able to apply some level of risk management to decisions"
• Actors: These are people with the appropriate skills and competencies.
• Manage: The ability to effectively execute strategy and tactics "…This aspect covers PMO based processes, service management and IT Governance aspects. In the service management area specifically we are seeing closer alignment with EA. The latest version of ITIL has alignment with EA practices."

This is a great overview of the enterprise architecture standards and how they relate and interact.

 

Technorati Tags: EA, Enterprise Architecture, Framework, Standards, ITIL, TOGAF, IAF, Zachman, IEEE 1457, PMO, Process

Michael Hugos has a great post on agility where he makes the following point:

“Experience shows me (again and again) that agility is not about working fast but about finding elegantly simple solutions to business problems. You’ll know you’ve found an elegantly simple solution when the business people agree it solves their most important and immediate problems and when the developers know the solution can be built and tested in 30 days or less.

Unless you find a solution that meets these two criteria, it’s not possible to be agile. And often, because people can’t find these simple solutions, they mistakenly claim that agility itself doesn’t work. They come to this conclusion because they attempt to be agile by cramming complex solutions into short development cycles through working harder, longer, and faster.

That attempt has as much chance of success as trying to cram ten pounds of you-know-what into a five pound bag. Inevitably, the bag breaks, and then there is a mess to clean up.

An elegantly simple solution (a robust 80% solution) doesn’t do everything (there isn’t time for that), just the most important things. Finding this solution is not easy; it’s the creative part. It requires business people to figure out what tasks out of all the tasks they perform are the most important ones and what system features they need to handle those tasks. Then developers have to figure out how to build and test a system to deliver those features in the short amount of time available.”

We spend too much time complicating our lives by trying to do too much, too fast! There seems to never be enough time to do something correctly, but always enough time to do it over again! Given to complexity of managing technology, we’re prone to think that complex solutions, are better solutions. Instead we need to focus on implementing good enough solutions, solution that bring about small wins. Small wins, if continually applied, in a thoughtful and strategic manner, quickly add up to significant results. Small wins are more manageable and have less of an impact if they fail. Seeking big wins are extremely difficult, prone to failure and require significant political will! Focus on the small wins…. simple things done well!

 

Technorati Tags: Agile, Agility, Simple, Small Wins, GTD, IT, Project, Management, Business, Technology, Architecture, Good Enough, Execution

As discussed in Serge’s post there is a standard being ratified for IT Governance, ISO 38500 which will cover Corporate Governance of information technology. This standard was originally defined as an Australian standard AS8015.

AS8015 provides six guiding principles for good corporate governance and the effective, efficient and acceptable use of ICT. The six principles are:

1. Establish clearly understood responsibilities for ICT (eg, ensure individuals understand and accept their responsibilities)
2. Plan ICT to best support the organisation (eg, ensure ICT plans fit current and future needs and the organisation’s corporate plans)
3. Acquire ICT validly (eg, ICT acquisitions should be made for approved reasons and in the approved way; on the basis of ongoing analysis)
4. Ensure ICT performs well, whenever required (eg, ensure ICT is fit for its purpose and is responsive to changing requirements)
5. Ensure ICT conforms with formal rules (eg, ensure compliance with external regulations and internal policies and practices)
6. Ensure ICT use respects human factors (eg, ensure ICT meets the evolving needs of the ‘people in the process’)

This is a great step forward towards effective governance of ICT within a corporate governance framework.

 

Technorati Tags: IT, Governance, IT Governance, Strategy, Alignment

• Search for:

• Welcome

  Welcome to Architecture and Change. You can subscribe to my blog using RSS or you can subscribe by e-mail

• Contact

  
  
  

• Busy Reading...

• Interesting Blog Stats

• Show of Support