add-memberalign-toparrow-leftarrow-rightbellblockcalendarcamerachatchevron-leftchevron-rightchevron-small-downchevron-upcircle-with-crosscomposecrossfacebookflagfolderglobegoogleimagesinstagramkeylocation-pinmedalmoremuplabelShape 3 + Rectangle 1pagepersonpluspollsImported LayersImported LayersImported LayersshieldstartwitterwinbackClosewinbackCompletewinbackDiscountyahoo

How to Handle Complexity?

We are planning a Panel Debate on how to handle complexity.

Panel members:

• Tom Gilb

• Robert Smallshire

• Thor Henning Hetland

• Margunn Aanestad

• (Frank Lillehagen could not make it)

As IT organizations and their portfolios of systems get larger, they become difficult to handle. Neither human systems (organizations) or large IT architecture behave in deterministic manners and have similar properties we describe as complexity. We are faced with this every day, but there are many different strategies to comping with this.

- Should we look for ways to manage more complexity? If so how do we do that? Can tools, technologies and techniques help us in any way?

- Or on the other hand, should we try to remove complexity and look for simple solutions? Is this always possible? To what extent is complexity avoidable?

- If we have a complicated Portfolio of Legacy systems, what can we do about it?

- When we see big IT initiatives that clearly underestimate complexity, can we and should we stop them? How?

This is OSWA's contribution to the Norwegian Computing Societies Software 2014 conference.

Please let us know if you would like to take part in the panel.

Join or login to comment.

  • Vidar M.

    I feel that one of the root causes of failing to tackle complex software projects, also mentioned in the debate this evening, is that the underlying organisations are resource optimised, and not flow / value optimised.

    Our organisations are generally organised in a way that makes employees busy all the time - not organised in a way that gives most value for the customer. Most value often means shortest possible lead time from order to product. This also goes for service organisations.

    This means that the organisations we are building software for, often do not have the correct processes in place for solving the tasks at hand in a way that gives most value for the customer. This means that we often are trying to solve the wrong problem by supporting the wrong processes.

    To tackle this, it follows that we have to start with the organisations. Without organisations supporting good, customer / flow focused value chains, we will design in unneeded complexity in the systems we create.

    February 26, 2014

    • Mario Ek A.

      I totally agree with you! Peter Senge, John Seddon and recently David Anderson have really opened my eyes to this.Also I see that keeping developers busy all the time means that you don't have time to figure out what it is you need to be doing (no time for requirement analysis). This creates a lot of failure demand when the developers start working on the tasks since there's so many questions that need to be answered in order to implement the right solution.

      February 26, 2014

  • Jon L.

    And the room is: Helsingfors

    1 · February 26, 2014

  • Jon L.

    Where is it taking place. What room?

    February 26, 2014

  • Mario Ek A.

    Robert Smallshire is stepping in instead of Frank Lillehagen.

    1 · February 26, 2014

  • Thomas F.

    In principle you are right, all complexity is relative. Complexity classes are a good guideline here. A problem that on the face of it looks like an NP-Hard problem, might possibly be simplified (or solved by a simpler algorithm) to become NP-Complete only. Its still a complex problem. but its been simplified as much as can be. I think the term comprehensive is suitable in many situations. Some solutions are big and comprehensive but not necessarily complicated or complex. But its also a matter of scope. The system could be complex, but the parts of it might not be. I find the terms complex/complicated to be synonymous and not distinctive enough to help clarify the difference easily.

    February 7, 2014

    • Shiraz B.

      I think of complicated as something like putting a man on the moon, lots of things that need to be done. But if you do the same things in the same order you will get the same result. Complex is like bringing up a child, doing the same things in the same order can get very different results.

      2 · February 7, 2014

  • Eckhard J.

    People often experience "complex" being the same as "complicated". Simple solutions can have hugh complexity but never are complicated.
    So maybe it's a good idea to make handling of comlex things simple? Then there would be no point in removing complexity.

    February 5, 2014

  • Tom G.

    2 ways to handle complexity

    1. Take a top level quantified view, outside the black box of project complexity, and let the top level drivers guide you as to what works inside the box to give you your objectives.

    2. Decompose total architecture by independently implementable value (the top10 values above) deliveries. Deliver them one at a time, highest value to cost first, and measure values and costs and learn!
    "Decomposition of Projects"

    1 · February 4, 2014

  • Torben V.

    'or should we look for simpler ways to solve problems? ' - well duh :-)

    February 4, 2014

  • Tom G.


    February 3, 2014

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy