Sunday, February 21, 2010

IT Architecture and Wicked Problems

A wicked problem is one that, for each attempt to create a solution, changes the understanding of the problem. A wicked problem exhibits one or more of these characteristics:
  1. The problem is not understood until after the formulation of a solution. Despite your best efforts you don't actually know what the problem really is and developing solutions only shows up more problems.
  2. Wicked problems have no 'stopping rule. That is to say if there is no clear statement of the problem, there can be no clear solution so you never actually know when you are finished. For wicked problems 'finished' usually means you have run out of time, money, patience or all three!
  3. Solutions to wicked problems are not right or wrong. Wicked problems tend to have solutions which are 'better', or maybe 'worse' or just 'good enough'. Further, as most wicked problems tend to have lots of stakeholders involved there is not usually any mutual agreement about which of these the solution actually is.
  4. Every wicked problem is essentially novel and unique. Because there are usually so many factors involved in a wicked problem no two problems are ever the same and each solution needs a unique approach.
  5. Every solution to a wicked problem is a 'one shot operation'. You can only learn about the problem by building a potential solution but each solution is expensive and has consequences.
  6. Wicked problems have no single solution. There may be lots of solutions to a wicked problem any one of which may be right (or wrong). Its often down to personal (or collective) judgment as to which one to follow or adopt.
By reading the list of properties that wicked problems exhibit you can easily see that many (or even most) large and complex software development projects fall into the category of wicked problems. Especially those which involve many stakeholders, multiple systems and difficult social, political, and environment challenges (e.g. such as building a nations social security or health system) or re-engineering an enterprises core systems whilst still trying to run the business.

I think that the really interesting and challenging roles out there for us IT architects are in tackling some of the wicked problems that many large and complex systems engineering projects contain. In my experience it is very often not just the technological aspects of the problem that needs to be addressed but also the social, political and economic aspects as well. I think the real challenges and also key roles that IT architects will take as we move into the next decade are in bringing new and creative approaches to solving these wicked problems. I'm currently preparing a lecture to be given at a UK university next month around this theme.

Monday, February 15, 2010

Architecture AntiPatterns: Pattern #4 - Too Many Chiefs

AntiPattern Name: Too Many Chiefs
General Form:
A large project or program is top-heavy with architects. Lots of high-level pictures and documents get produced but no real specifications are created. 
Symptoms and Consequences:
  • The project has been running for several months and there is no clear plan.
  • Lots of high-level documents not following any obvious templates or serving any useful purpose (e.g. “Functional Specification”) are created.
  • No detailed specifications are in evidence (e.g. Component Models, Operational Models).
  • Overuse of MS Office products rather than “real” architecture tools.
Refactored Solution:
  • Ensure all roles are well defined and have clear deliverables.
  • Ensure all architects understand the process they are following.
  • Ensure there is a clear plan with roles and deliverables assigned.
  • Instigate use of professional tooling
See Pattern #3

Saturday, February 13, 2010

Design Really Does Matter

I've just received a new work laptop and what a monstrosity it is! There was a time when ThinkPads were actually quite sexy as far as laptops go but this model (a T400 if you're interested) is a complete abomination of a thing. It's not only square and clunky feeling but for some mysterious reason the designers have made the battery stick out of the back like some large cancerous growth. Why, if Apple can design a laptop with a supposed 6 hour battery life where the battery is hidden completely inside the case do Lenovo designers have to create something that has the battery hanging out the back and appear to offer no more life?

What's all this got do do with the zen of architecture you might ask? I've been reading the latest book by Garr Reynolds, Presentationzen Design where Garr suggests we should take inspiration for good design from the products we see around us all day. The ThinkPad would seem to be a good design antipattern to me. Of course, as Hugh MacLeod says "there's no correlation between creativity and equipment ownership" and "a fancy tool just gives a second-rater one more pillar to hide behind." That said, I feel sure that using a tool that is both good to look and is well designed makes for an all round better experience that must aid in the flow of the creative juices. If you don't have the ideas in the first place then the best tool in the world won't help you create them but if you do have something to say what would you rather write with, the free pen from the hotel room or the Mont Blanc you got for Christmas? 

Monday, February 8, 2010

Architecture AntiPatterns: Pattern #3 - Throwing Out the Baby with the Bath Water

AntiPattern Name: Throwing Out the Baby with the Bath Water
General Form:
A new idea, technology or process comes along and everyone jumps on the bandwagon forgetting the fundamental principles developed previously.  
Symptoms and Consequences:
  • Lots of external and internal “marketware” describing the benefits of the new approach but often with very little substance behind them.
  • People being encouraged to go on education, join working groups etc where the new approach is described.
  • Skills in “legacy” technology become difficult to find as everyone is now tained in the new approach 
Refactored Solution:
  • Ensure fundamentals are captured as principles and approaches in existing methods and processes.
  • Reinforce through training and good governance.
  • Take care when/how to adopt the new approach.
See Pattern #2

Monday, February 1, 2010

Architecture AntiPatterns: Pattern #2 - Groundhog Day

AntiPattern Name: Groundhog Day
General Form:
Important architectural decisions that were once made get lost, forgotten or are not communicated effectively.  
Symptoms and Consequences:
  • People forget or don’t know a decision was made.
  • The same decision is made more than once, possibly differently.
  • New people joining the project don’t understand why a decision was made.
Refactored Solution:
  • Capture important decisions in the “Architectural Decisions” work product.
  • Ensure a process is in place for making and ratifying decisions (maybe a Design Authority responsibility).
  • Ensure decisions get known about by all the right people.
See Pattern #1