• 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 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

Michael Roberto a professor of management at Bryant University in Smithfield, Rhode Island, has an interesting post on his blog, "The Power of Integrative Thinking" where he discusses an article in the June issue of Harvard Business Review, on how successful leaders are integrative thinkers. By that, he means that they attack problems in the following manner:

• They examine problems as a whole, with careful consideration of how different parts of a situation fit together, rather than analyzing different elements in isolation.
• They consider multiple avenues of causation for a problem, as well as possible nonlinear relationships between cause and effect, rather than thinking of terms of simple linear relationships between a single cause and effect.
• They embrace the tension between opposing ideas, and they use that conflict to generate creative new alternatives, rather than making simple either-or decisions.

Integrated thinking is a critical mode of thinking which architects need to learn to master. Integrated thinking is essential if architects are to "address the enterprise as a whole". One of the challenges faced by integrated thinkers and architects in particular is cognitive overload. Michael Roberto makes the following suggestion, on how to move forward when experiencing cognitive overwhelm, based on Karl Weick’s famous 1984 article entitled "Small Wins":

"…large, complex problems can sometimes be cognitively overwhelming. Thus, he argued that decision-makers should break complex problems into parts, and seek a series of ’small wins’ as a means of generating solutions to complicated issues. …seek small wins while working through the organizational decision-making process required to solve the problem."

In my architectural and strategy work, I have often experienced cognitive overwhelm when attempting to solve complex problems. I have found that by just starting, by simply writing down your initial thoughts and ideas generates the small wins required, provides a foundation for discussion and helps to move the whole process forward.

How do you deal with cognitive overwhelm in your architectural work?

 

Technorati Tags: Complexity, Problem, Integrative Thinking, Architecture, EA, Enterprise Architecture, Thinking, Decision-Making, Paradox

 

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

“Time after time, we have found that in the midst of profound and complex change, more than one significant aspect of the enterprise is changing at once. Often key leaders or team members don’t see the whole system in the same way - each sees a different portion of the overall picture. They generally do not agree on the range of forces affecting their business or on their importance. They often do not have shared views on the key strategies the business should use to respond to these forces, what the business must become, where they currently stand, or how they will go about the change or development that is needed to survive in the changing environment. Even when different members see parts of the system from a common perspective, key elements in the system are often “invisible” to any particular group, and their disagreements often lie in just these invisible areas. Conflicts arise because not everyone is on the same page regarding the key elements of the enterprise as a whole.” - Friedman & Gyr “The Dynamic Enterprise”

Silo-based systems are developed due to a lack of seeing the whole or the big picture. Seeing the whole is a collaborative rather than individual effort as each stakeholder helps us to gain an important insight into the whole. This can be likened to the parable of the "Blind Men and the Elephant", where, “Knowing in part may make a fine tale, but wisdom comes from seeing the whole.” See the whole is analogy to effort of blind men and the elephant: In a sense, each individual is blind to the invisible big picture.

The capability to address the enterprise as a whole, distinguishes the enterprise architecture paradigm from the others. Enterprise architecture is about “seeing the whole”, as such there can only be one enterprise view of the organisation….

 

 

The value of enterprise architecture is it’s role in identifying the big picture of the enterprise and to provide the enterprise definition for each architectural domain, so architects can design the IT architecture from an enterprise consideration. Enterprise architecture can be distinguished from other styles of architecture by it’s enterprise perspective. Enterprise architecture is the discipline of seeing the whole, of seeing the big picture.

 

• 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