Problem Solving & Enterprise Architecture

You may be asking yourself – what do Enterprise Architecture and Problem-Solving have to do with one another? At first glance it may seem logical that there is some sort of indirect relationship between the two, but the details of that relationship aren’t entirely clear. We’ll begin to answer this question by introducing a number of fundamental assumptions associated with Enterprise Architecture (EA):

• EA is generally focused on one of two things (or both); either the introduction of new capability or the enhancement of existing capability.
• If achieving either of those objectives were simple, the concept and practice of EA never would have been contemplated and introduced.
• The enterprise is dynamic, the technology that drives it is dynamic and neither of those preconditions will ever change.
• The first three assumptions point to a complex, evolutionary environment. One can either react to change or attempt to be proactive. Usually we end up doing a combination of the two but when we become entirely reactive, management of the enterprise suffers. EA is meant to be proactive and is meant to facilitate change management.

So how does one manage change? Can change be predicted, can it be harnessed or can it be ignored? What does change management really mean?

Lot’s of questions. Here are some of the answers:

1. One manages change by defining it first, then anticipating aspects of it in advance.
2. Yes, change can be predicted – up to a point – but only if the context (both internal and external) is well understood / partially defined in advance.
3. Change cannot be ignored.
4. Change management is merely the application of an overall lifecycle dedicated to solving one problem at a time (within a defined list of problems and a defined problem solving methodology).

Key Concept: “Problem Semantics”
Reality – all reality – is defined, perceived and validated through a semantic layer. This takes many forms in everyday life. In IT, we have an exceptionally rich toolkit dedicated to managing semantics or meaning – this includes everything from programming languages to canonical models to technical standards and much more. For our discussion, Problem Semantics refers to the ability to define problem sets or problem spaces.

This is the high level exploration of the who, the what and the how of a specific issue – whether it be the introduction of mobile devices to a sales force or the transition of legacy code off a mainframe system or how to control space probes on Mars. It can be more basic or more complicated – but this is where the vocabulary of problem solving is born. The problem semantics eventually are blended into the larger semantic foundation of the enterprise – often they are defined by industry and more or less ‘imported’ into use by industry adopters. And of course, often times Problem Semantics are already well known.

We have proposed that EA is closely related to the concept of Change Management and that Change Management is associated with Problem Solving on a case by case basis within the context of a larger lifecycle. Making these associations and distinctions is important because many people believe that enterprise architects are merely exercising one part or another of the solution lifecycle. The reason this makes a difference is continuity. Many of us have experienced first-hand the enterprise where the same problems are solved over and over again by different groups – where past knowledge is discarded only to be earned again a great cost. We should be able to solve one problem at a time and not have to solve it again. Even better is the ability to solve small chunks of a large problem across multiple iterations of effort and achieve otherwise unreachable goals. These are the benefits that enterprise architecture brings to the table and why problem solving with EA is both quantitatively and qualitatively superior to scenarios without it.

Any type of Problem can be managed use the same core methodology...

 Key Concept – The Problem Space
A problem space uses Problem Semantics and EA tools to describe problems – there are often multiple related problems within a shared problem space. This does not map well to the UML concept of a Domain Model because there are generally a number of problem spaces which must be addressed for any given domain. There is a rough correlation between Use Cases or User Stories and Problem Spaces, but as yet UML doesn’t really support this high level modeling concept. Essentially, ‘problems’ are the core challenges being faced and they coexist in relationships within topically related spaces. As these Problem Spaces are better understood we begin to use that context to build more direct solution focused artifacts.

A complex Healthcare Problem Space Example
An example problem space might be something like this: a company is rolling out a new online product never before attempted (by them or anyone else) – up front it is difficult to determine:

• What customer reaction will be.
• What type of performance may be involved with the system and user experience (because initial predictions of user load and behavior have no baseline to work against).
• Whether the business model will be viable over the long term.
• Whether the current support and failover model is sufficient.

These characteristics cross a number of technical or business boundaries but they are related in the context of “new online product deployment.” The standard response to most of these questions is – “we’ll have to wait and see whether our best guesses pan out.” However, that wait might result in a complete failure. There must be a better, more methodical way of reducing risks associated with deploying evolutionary capability. Much but not all of the risk can be reduced if we have the ability predict key issues before they occur. And this leads to our next

Key Concept - Problems, like Architecture are Pattern-Based
So what does that mean, pattern-based? It means that is highly unlikely that the issues you will face in one enterprise are radically different or wholly unique from every other enterprise. This is equally valid going backwards or forwards through time. There is always a first time someone runs across a problem but most times you will not be the first one to face it. This leaves open the possibility that through the use of enterprise architecture a much wider range of problem solving can occur and that as more knowledge is captured the problem solving itself becomes less complicated and more accurate.

Another key aspect of viewing Enterprise Architecture as problem solving is the nature of problem solving itself. What we mean by this is the fact that the most effective approach to solving problems is generally by asking the right questions. The ability to string together a continuous dialog on a single topic is known as dialectic. This is what EA’s must do all the time – it is why communication is such an important part of any architect’s role or skill set. EA’s are often the ones who are asked to facilitate a larger dialectic process for an organization.

Think of it this way perhaps – one of the biggest trends in IT today is Agile Development – why is Agile so important? It’s important because it assumes as its core tenet that the people who ought to be talking together aren’t and it changes the lifecycle process to make sure they do. Now where Agile differs from EA is that Agile achieves the improved communication by shrinking the topics down to tiny – byte sized chunks. EA’s on the other hand must deal with the macro-level problems while understanding how they will be tackled on the micro level and we must be able to ensure that all low level and high level efforts fit together in the end.

Copyright 2012, Semantech Inc. All rights Reserved