Tuesday, January 1, 2013

How Aggressively Should EA Tackle: Tame Issues or Wild Problems?

EA is born with an engineering attitude and simply the fact that does not fit well into a pure strategy/management by design.

There is an impression, if not conclusion from senior executives, that EA cannot solve complex or wild problems, as at CxO level, the problems (when not trivial or just system related) are mostly in the wild category. On the other side, EA is all about leveraging multitude of viewpoint, EA should be more appropriate to wild rather than tame problems because the latter rarely need shared understanding, etc, so what’s EA’s true strength, how aggressive should EA go?

1.    What are Wild/Complex Problems?

The "wild/tame" classifying of problems is a bit ambiguous. There are no unsolvable problems. Wild problems are those you cannot solve with given resources, knowledge and capabilities you have at your disposal at the time the problem arises.

And, there is no definitive formulation of a wild problem (defining wild problems is itself a wild problem), multi-dimension and complexity are two key factors in wildness: Multi-discipline (mixing hard elements with all kind of soft side elements) and complicate (Complexity you can determine, model and measure, complicate comes from a totally different angle). 

- Wild problems have no stopping rule.
- Solutions to wild problems are not true-or-false, but better or worse.
- There is no immediate and no ultimate test of a solution to a wild problem.
- Every solution to a wild problem is a "one-shot operation"; because there is no opportunity to learn by trial and error, every attempt counts significantly.
- Wild problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan.
- Every wild problem is essentially unique.
- Every wild problem can be considered to be a symptom of another problem.
- The existence of a discrepancy representing a wild problem can be explained in numerous ways. The choice of explanation determines the nature of the problem's resolution.
- The planner has no right to be wrong (planners are liable for the consequences of the actions they generate).
- The problem is not understood until after the formulation of a solution.
- Wild problems have no stopping rule.
- Solutions to wild problems are not right or wrong.
- Every wild problem is essentially novel and unique.
- Every solution to a wild problem is a 'one shot operation.'
- Wild problems have no given alternative solutions. 

In enterprise, you learn to spot these two factors (multi-discipline and complicate) as the real measurement of the difficulty of a problem. This requires extra attention, trade-off decisions cause the risk which is very high, being in a world where the two dimensions imply difficult or no measurement, high risk and low predictability. Complexity and multi-dimension is assumed as "manageable" situation with quite "normal" tools and techniques

2. What are Limitations for EA to Solve Wild/Complex Problems

  • Shade of Gray: The frequent argument is that EA will always try to insist that everything is testable and there must be a right and wrong for everything (for reference, see most EA frameworks). The problem is that for complex or wild problems, this has been proven out of date.  Most of (EA) frameworks are mostly unaware of this gray side of life and models tend to describe relationship as black or white, with a sense of mathematical rounded precision which is not so much related to real life. 

  • “Naive Transcendentalism”: Enterprise Architects are not necessarily well equipped to deal with them if they only rely on their analytical, logical and structured way of seeing the world, which some call the “Naive transcendentalism" to describe the mistaken idea that there is a single version, a single transcendent model that, if we could just find it, would define the whole universe of an enterprise. If we are talking about an enterprise above a handful of people engaged on a single simple task, there isn't. A more sophisticated transcendentalism acknowledges this truth but also acknowledges that given the limitations of our technology, we have to develop a model and practices that allows productive collaboration to continue.
  • "Not so good fit" for wild problems with EA failure: EA is born with an engineering attitude and simply the fact that does not fit well into a pure strategy/management by design. Further, the wild problems are the one which is not understood until after the formulation of a solution, so just theoretical without the sample; as such, how would you break down a problem in smaller tame parts before you understand it. Also every wild problem can be considered to be a symptom of another problem, so here again, how can you break of dependencies before they are understood?
  • Nonetheless, the EA does not solve any wild problem by itself. The EA is solely the blueprint of the enterprise. The business and technology professionals should solve (better and quicker) the wild problems when employing own business methods over the EA blueprint. You cannot integrate a wild solution in a blueprint as the wild problem is not understood until after the formulation of a solution. 
  • Primary functions of the EA are to understand the nature of the conflicts.  The maturity of the EA team would be a big factor on whether they could take on complex business problems and / or whether the problems get assigned elsewhere and / or to external consultants. Another problem of course is that the capability of the EA team versus others & external consultants may not be well understood.
  • The main barrier to EA making a contribution to any business problem is the inability of some EA practitioners to view problems from a business perspective, to be able to successfully communicate with manager and executives in non-technical terms, and to provide a technology enabling rather than technology driving approach to resolving business problems, whether wild or not. that said, a wild problem, was almost impossible to solve if you started at the technology end of the EA stick. If you started at clarifying what the business problem was, why it was a problem, which bits were really the problem parts, who you needed to get to the table to help sort it out, and then tackled it in a logical, jigsaw puzzle-ish way, that went DOWN to the technology they usually became possible. Challenging; but possible.
  • Complex business problems get assigned to the IT function sometimes for good reasons (IT is a key business enabler) and sometimes for questionable reasons (politics or bad root-cause analysis). They then get addressed through an "architecture study" sometimes successfully, sometimes not. The good IT functions train people in business issue consulting methods as well as technical methods to manage this.
  • One could also make the argument that if an enterprise problem is not amenable to an EA solution, it is by definition "wild" and while methodological EA is not necessarily the solution,  the fact is that the problem's un-solvability was uncovered by applying EA principles showing EA's (and the architect's) worth. There are enough of these type of situations around that enterprise architect's should be working till the next millennium.

  • EA’s further limitation to take wild problems:
(1). That they need to understand political motivation of the actors of the structure and political relationships;
(2) That everything cannot be modeled easily;
(3). That globally, decisions are often not rational;
(4). That people are creative (in the good and wrong sense of the term) and that this creativity cannot be always be deduced from a set of enterprise transformation scenarios;
(5). That the Deming inspired collaborative looping governance is leading to soft consensus of doing nothing. 

  • Common Design Issues cause more unnecessary complexity:
    (1) Poor, non-modular design and implementation
    (2) A lack of standardization
    (3) Really, really bad IT architecture
    (4) Siloed IT thinking
    (5) Myopic, application by application funding
    (6) An erroneous belief that each application must have its own, preferably different, hardware
    (7) All based on an ill-founded belief that the Tail wags the Dog 

A business architecture framework would support the EA at the enterprise business tier. An overall framework should integrate the business and technology tiers so that a process can be analyzed in both planes

3. Best Scenario to Solve Wild Problems?

Good EA is driven by the business, with a business focus, and a desire to leverage the business's assets - including technology assets - in order to further business objectives.

  • An "ideal" EA role supports critical business decisions, plays a role bridging between the strategic thinking and the operation structure and execution on a large scale. This is not a simple role, as it needs to be able to play effectively with both aspects, analytical and perceptive. It needs to master both dimension. EA can assist investment decisions whether in systems change or business change - and these days, there is an increasing momentum towards business change driven systems change - so, overall any EA value proposition is going to continue to become less and less IT centric, intensive or dominated, but focus on business transformation, in reality, people don't like change. Many individuals will hold on to a particular approach, strategy, organizational structure or whatever, even to the bitter end, due to their own resistance to change

  • EA Maturity: EAs have to learn that they are part of bigger team, which mean less self centered methodologies and a bit more humbleness. The second is that EA have to least try to understand generative reasoning. Thereby being a communications bridge between the IT and Business stakeholders
-Ability to balance priorities and simultaneous projects.
-Strong judgment, issues management and problem analysis techniques.
-Strong organization and coordination skills.
-Ability to work as part of an interactive, collaborative team as well as independently.

  • A successful EA needs to be able to be both abstract and concrete, and switch between the two depending on who they are speaking with. Some EAs tend to focus excessively on treating business as an abstraction, whereas business decision-makers tend to be very concrete people. An EA who has governance and a good grounding can untangle the problem enough where the development crew can solve the minutia left in completely solving the problems in the Enterprise

  • Two-step EA scenario: One thing that EA can do is uncover those "wild" problems and increase awareness of them. When the 'wild problem' is coming, the mandatory EA's processes are:
    Step 1: SHOUT (whistle-blow) that the emperor (enterprise) has no clothes (vulnerable);
    Step 2: PROVIDE alacrity with options for 'collaborative' stakeholders

  • EA has the tools and methods to deal with multi-dimensional complex issues and some architects do have the skills to find the right balance between these tools and methods, their "natural" skills, excellent communication and soft skills together with good tactics and the ability to evolve these tactics as often as one context.  These people are the ones able to get EA outside IT and at the heart of the enterprise, to do EA without having to expose and sell its mechanics. 

  • There are three possible strategies to "solve" a wild problem: - authoritative, competitive and collaborate. Wild problems need innovative solutions. The only way is to try and fail and reformulate the solution. So, try it and fail and try a different solution till you find something that succeeds. Most of the wild problems are human problems would require some people to change or leave and some management practices to end. EA has to cope with that issue that can be huge, depending upon the maturity of the organization and its management expected role.

  • EA creates shared view that enables a more flexible, responsive and agile response to identified needs and therefore to supporting those moving to the sense-and-respond end of the business model spectrum; EA aims to give visibility to and increase share understanding of problems and proposed changes; EA aims to leverage diversified viewpoint, to tame seemingly-wild issues; EA aims to ensure greater integrity of proposed changes and hence greater likelihood of success / realization of desired outcomes (which is pertinent to wild problems)
Therefore, wild problems will be adaptive rather than technical challenges, and call for adaptive leadership, amongst other elements. EA should take creative (design) thinking, and critical thinking at the same time, unify & diversify solutions to solve wild/complex problems.  


Post a Comment