Category Archives: Enterprise Architecture

Enterprise Architecture

Albert Einstein – Problem solving

581px-Albert_Einstein_Head_cleaned
March 14, 1879 – April 18, 1955

Einstein is quoted as having said that if he had one hour to save the world he would spend fifty-five minutes defining the problem and only five minutes finding the solution.

This quote does illustrate an important point: before jumping right into solving a problem, we should step back and invest time and effort to improve our understanding of it. Here are 10 strategies you can use to see problems from many different perspectives and master what is the most important step in problem solving: clearly defining the problem in the first place!

The Problem Is To Know What the Problem Is

The definition of the problem will be the focal point of all your problem-solving efforts. As such, it makes sense to devote as much attention and dedication to problem definition as possible. What usually happens is that as soon as we have a problem to work on we’re so eager to get to solutions that we neglect spending any time refining it.

What most of us don’t realize — and what supposedly Einstein might have been alluding to — is that the quality of the solutions we come up with will be in direct proportion to the quality of the description of the problem we’re trying to solve. Not only will your solutions be more abundant and of higher quality, but they’ll be achieved much, much more easily. Most importantly, you’ll have the confidence to be tackling a worthwhile problem.

Problem Definition Tools and Strategies

The good news is that getting different perspectives and angles in order to clearly define a problem is a skill that can be learned and developed. As such, there are many strategies you can use to perfect it. Here are the most effective ones I know.

1. Rephrase the Problem

When a Toyota executive asked employees to brainstorm “ways to increase their productivity”, all he got back were blank stares. When he rephrased his request as “ways to make their jobs easier”, he could barely keep up with the amount of suggestions.

Words carry strong implicit meaning and, as such, play a major role in how we perceive a problem. In the example above, “be productive” might seem like a sacrifice you’re doing for the company, while “make your job easier” may be more like something you’re doing for your own benefit, but from which the company also benefits. In the end, the problem is still the same, but the feelings — and the points of view — associated with each of them are vastly different.

Play freely with the problem statement, rewording it several times. For a methodical approach, take single words and substitute variations. ‘Increase sales’? Try replacing ‘increase’ with ‘attract’, ‘develop’, ‘extend’, ‘repeat’ and see how your perception of the problem changes. A rich vocabulary plays an important role here, so you may want to use a thesaurus or develop your vocabulary.

2. Expose and Challenge Assumptions

Every problem — no matter how apparently simple it may be — comes with a long list of assumptions attached. Many of these assumptions may be inaccurate and could make your problem statement inadequate or even misguided.

The first step to get rid of bad assumptions is to make them explicit. Write a list and expose as many assumptions as you can — especially those that may seem the most obvious and ‘untouchable’.

That, in itself, brings more clarity to the problem at hand. But go further and test each assumption for validity: think in ways that they might not be valid and what could happen if that was the case. What you will find may surprise you: that many of those bad assumptions are self-imposed — with just a bit of scrutiny you are able to safely drop them.

For example, suppose you’re about to enter the restaurant business. One of your assumptions might be ‘restaurants have a menu’. While such an assumption may seem true at first, try challenging it and maybe you’ll find some very interesting business models (such as one restaurant in which customers bring dish ideas for the chef to cook, for example).

3.1 Chunk Up

Each problem is a small piece of a greater problem. In the same way that you can explore a problem laterally — such as by playing with words or challenging assumptions — you can also explore it at different “altitudes”.

If you feel you’re overwhelmed with details or looking at a problem too narrowly, look at it from a more general perspective. In order to make your problem more general, ask questions such as: “What’s this a part of?”, “What’s this an example of?” or “What’s the intention behind this?”.

Another approach that helps a lot in getting a more general view of a problem is replacing words in the problem statement with hypernyms. Hypernyms are words that have a broader meaning than the given word. (For example, a hypernym of ‘car’ is ‘vehicle’). A great, free tool for finding hypernyms for a given word is WordNet (just search for a word and click on the ‘S:’ label before the word definitions).

3.2 Chunk Down

If each problem is part of a greater problem, it also means that each problem is composed of many smaller problems. It turns out that decomposing a problem in many smaller problems — each of them more specific than the original — can also provide greater insights about it.

“Chunking the problem down” (making it more specific) is especially useful if you find the problem overwhelming or daunting.

Some of the typical questions you can ask to make a problem more specific are: “What are parts of this?” or “What are examples of this?”.

Just as in “chunking up”, word substitution can also come to great use here. The class of words that are useful here are hyponyms: words that are stricter in meaning than the given one. (E.g. two hyponyms of ‘car’ are ‘minivan’ and ‘limousine’). WordNet can also help you finding hyponyms.

4. Find Multiple Perspectives

Before rushing to solve a problem, always make sure you look at it from different perspectives. Looking at it with different eyes is a great way to have instant insight on new, overlooked directions.

For example, if you own a business and are trying to ‘increase sales’, try to view this problem from the point of view of, say, a customer. For example, from the customer’s viewpoint, this may be a matter of adding features to your product that one would be willing to pay more for.

Rewrite your problem statement many times, each time using one of these different perspectives. How would your competition see this problem? Your employees? Your mom?

Also, imagine how people in various roles would frame the problem. How would a politician see it? A college professor? A nun? Try to find the differences and similarities on how the different roles would deal with your problem.

5. Use Effective Language Constructs

There isn’t a one-size-fits-all formula for properly crafting the perfect problem statement, but there are some language constructs that always help making it more effective:

  • Assume a myriad of solutions. An excellent way to start a problem statement is: “In what ways might I…”. This expression is much superior to “How can I…” as it hints that there’s a multitude of solutions, and not just one — or maybe none. As simple as this sounds, the feeling of expectancy helps your brain find solutions.
  • Make it positive. Negative sentences require a lot more cognitive power to process and may slow you down — or even derail your train of thought. Positive statements also help you find the real goal behind the problem and, as such, are much more motivating.
    For example: instead of finding ways to ‘quit smoking’, you may find that ‘increase your energy’, ‘live longer’ and others are much more worthwhile goals.
  • Frame your problem in the form of a question. Our brain loves questions. If the question is powerful and engaging, our brains will do everything within their reach to answer it. We just can’t help it: Our brains will start working on the problem immediately and keep working in the background, even when we’re not aware of it.
  • If you’re still stuck, consider using the following formula for phrasing your problem statement:
    “In what ways (action) (object) (qualifier) (end result)?”
    Example: In what ways might I package (action) my book (object) more attractively (qualifier) so people will buy more of it (end result)?

6. Make It Engaging

In addition to using effective language constructs, it’s important to come up with a problem statement that truly excites you so you’re in the best frame of mind for creatively tackling the problem. If the problem looks too dull for you, invest the time adding vigor to it while still keeping it genuine. Make it enticing. Your brain will thank (and reward) you later.

One thing is to ‘increase sales’ (boring), another one is ‘wow your customers’. One thing is ‘to create a personal development blog’, another completely different is to ‘empower readers to live fully’.

7. Reverse the Problem

One trick that usually helps when you’re stuck with a problem is turning it on its head.

If you want to win, find out what would make you lose. If you are struggling finding ways to ‘increase sales’, find ways to decrease them instead. Then, all you need to do is reverse your answers. ‘Make more sales calls’ may seem an evident way of increasing sales, but sometimes we only see these ‘obvious’ answers when we look at the problem from an opposite direction.

This seemingly convoluted method may not seem intuitive at first, but turning a problem on its head can uncover rather obvious solutions to the original problem.

8. Gather Facts

Investigate causes and circumstances of the problem. Probe details about it — such as its origins and causes. Especially if you have a problem that’s too vague, investigating facts is usually more productive than trying to solve it right away.

If, for example, the problem stated by your spouse is “You never listen to me”, the solution is not obvious. However, if the statement is “You don’t make enough eye contact when I’m talking to you,” then the solution is obvious and you can skip brainstorming altogether. (You’ll still need to work on the implementation, though!)

Ask yourself questions about the problem. What is not known about it? Can you draw a diagram of the problem? What are the problem boundaries? Be curious. Ask questions and gather facts. It is said that a well-defined problem is halfway to being solved: I would add that a perfectly-defined problem is not a problem anymore.

9. Problem-Solve Your Problem Statement

I know I risk getting into an infinite loop here, but as you may have noticed, getting the right perspective of a problem is, well, a problem in itself. As such, feel free to use any creative thinking technique you know to help. There are plenty to choose from:

You may want to give yourself an Idea Quota  – committing to have a predetermined number of ideas  – of problem statements. Or write a List of 100 problems to solve. SCAMPER your problem definition. These are just some of dozen techniques you can try.

As a conclusion (for today)…

Of course, how much effort you invest in defining the problem in contrast to how much effort you invest in solving your actual problem is a hard balance to achieve, though one which is attainable with practice.

Personally, I don’t think that 55 minutes of defining a problem versus 5 minutes acting on it, is usually a good proportion. The point is that we must be aware of how important problem defining is and correct our tendency to spend too little time on it.

In fact, when you start paying more attention to how you define your problems, you’ll probably find that it is usually much harder than solving them. But you’ll also find that the payoff is well worth the effort.

References:
• Einstein’s Portrait: Yousuf Karsh.
• Einstein’s Quote: Cracking Creativity.

Social networking… How?

It’s been a few weeks that while discussing with people at conferences, meetings or even lunch… “Social Network” topic come up on the table quite often. Is it because of me, raising the topic or not? That I cannot say. Anyhow, due to these discussions I decided to share this article with you, even if, at the first glance, it might seem not fully in-line with my usual topics on this blog, in a way it is.

Goal

The goal of this article is to share what I call “My social network strategy”, even if I know that “strategy” might sounds a bit presumptuous in this context. But, to my defend, I always prone a vision + a meaning (which we can call “strategy”) to whatever we start to do (otherwise, why doing it?). So even for social networking, I think it is needed to know what we want to do and set a strategy, principles to follow… even our own borders to not cross. Of course, we all do that, unconsciously at least, but like some philosophers would (better) explain than me: it is always better to be conscious of what we want to do!

My social network strategy / principles and a few more…

For the ones who already know me a bit, guess what, yes, all is described in the mind map below! 🙂 I hope you will enjoy reading!
Of course, don’t hesitate to react on the comments if there are things that are not clear to you after your map reading.

Please, find the downloadable mindmap version (.mmap) on http://www.biggerplate.com :  http://www.biggerplate.com/mindmaps/DDMCQJZf/my-personal-social-networking-strategy

Opening

There we are, time to conclude this article. As usual, I would like not to close this topic but more give it an opening. As you might see, I gave you some of my strategies / principles for personal social networking. I do believe that most of these principles apply to Social Networking in the Enterprise as well… The generation Y effect (increasing amount of generation Y people in the enterprises) might help us to give it a kick, but as usual, this should not be done through the technology only (even if it is attractive) but with a real strategy! (Again!! 🙂 ) When it comes to “Enterprise social network”, I think some additional principles have to be taken care of. Of course, a meaning is (as always) needed, but in addition to a personal initiative, this meaning (e.g.: “Why do you want to establish an “Enterprise Social Network” at your company”) has to be explained / communicated / anchored with the whole enterprise. And this is another challenge to be reach!

Next generation of Enterprise Architecture

Early this morning, while glancing through the latest tweets on my iphone, I was attracted by last post from Richard Veryard on slideshare:

Preamble

Good slideshow though, but since I felt that it is going a bit in many different directions, I felt that I had to react on this one, directly on my blog to reflect my own thoughts regarding: How should we deal with enterprise architecture in big companies? Richard starts his slideshow by exposing 2 historical views of Enterprise Architecture: the “Simplify and Unify” view and the “Differentiate and Integrate” view. Structuring the begining of his presentation through this split, Richard starts quickly to mention ancient approaches such as “Information Engineering” structure versus the well-known “Zachman framework“. then, he also mentions the different trends / challenges the EA is facing to… But, finally, what is the main stand-point that comes out of this presentation? To be honest, I miss a bit Richard’s stand point at the end of the presentation. So here is mine (stand-point):

My point is…

I would say that, in general, I try to learn from history and experimented people such as John Zachman and Roger Session, but at the same time, I don’t want to follow them blind. I think times change and EA has to change as well (even quicker).
To me, such approach as Zachman’s framework, which is a 198x’s vestige (see my article: Top Four Enterprise Architecture Methodologies) or trying to simplify the IS way too much, when if fact we, as Enterprise Architect must admit/deal with this complexity (up to a certain point). We (EntArch) have to make this complexity manageable and introduce enough flexibility in it to better support the business objectives.  Not saying, as I mentionned earlier that we should forget the previous frameworks or structures, but more to know them, understand their points, why they raised when they did and look at today trends/issues to make our own opinions.

Then, let’s re-invent the wheel again will you tell me… No, sorry I am not this kind. I looked for a real EA methodology for a while before finding one that suit the best to my personnal beliefs. To me, the Praxeme methodology is the EA methodology that suits the best to my personal perception of what the EA should be/do.

There I think that Praxeme is fully supporting the EA challenges Richard is pinpointing. (see fig. 1)

My Conclusion

I would quote Richard when Richard writes:
“Not suppressing complexity but managing complexity”

This is exactly what I am trying to do when practising EA. EA should not be done for the “beauty of the move”, but for the whole-of-the-enterprise sake and benefit. To add to Richard’s presentation, I would say that in order to “manage the company IS complexity and support business objectives“, we need both the theory and the practice. There,  it’s time to mention Emmanuel Kant that is underneath the Praxeme’s approach:

Theory without practice is useless; Practice without theory is blind.

Let’s come back to the title: “Next generation of Enterprise Architecture”. To me the next generation of Enterprise Architecture and as a consequence: Enterprise Architects :D, where I expect from myself to be a key player ( 😉 french humor) is based on a true Business approach. We, as Enterprise Architects, have to get our key business decision makers to understand the value of spending money on EA to gain money on the maintenance (IT costs), reduce the project failure rate… stop re-doing project to achieve the same goals without succeeding each time.

Once your top management is convinced, then it is time to go to work. Start from the semantic level to keep the flexibility in the whole enterprise system. Break the silos, avoid hard-coded business rules that have lead us to where historic companies are entangled in today. Complex and frozen Information System that is not anymore able to support the always moving targets of our companies, neither the economical volatilities that we are currently facing or the increasing competition (to mention a few…). Our companies have no choice to evoluate or die. This is pure evolution theory.

  • If you are lucky and work for companies like Google or Apple, then you have not much to achieve in the first hand (convinced your management), mainly because the top management is already convinced and they have trusted the vision I described above. In addition, they didn’t have to manage the complexity coming from all the heritage of ages (usually called “Legacy”).
  • In case you’re not working for Google or Apple, then you are even more lucky! Look at all the interesting job you have in front of you! I use to quote Booker T. Washington when saying:

“You measure the size of the accomplishment by the obstacles you had to overcome to reach your goals.”

So, let’s go to work!

How to recover the Gap between Business & IT?

Why does the Gap between Business and IT exist?

I’m sure you will find people who will try to convince you that there is no gaps between business and IT. But, I can give you my piece of advice, it’s been quite many years now that I am working in this context and I can tell you, there are gaps… I am even use call to call it a schism sometimes. But let’s look at why does this schism exist? If we want to treat it, don’t we have to identify the origin of the problem? Since we are Enterprise architect, it is always put forward that we are here to “align the business and IT”, so let’s look at the “what do we have to fill to align them”.

When it comes to improving enterprise performance via technology, IT and the business usually approach the same problem from two vastly different perspectives.  As a consequence, on one hand, business people often lack an appreciation for the IT technical ramifications of adopting a new process. On the other hand,  technology and IT teams usually find business requirements unrealistic. Of course, if both parties are unable to bridge that gap in a highly collaborative way, the consequences can be significant.

As an example, consider the scenario in which the business makes what it believes to be a simple functional request: “I just want to have this function in my application. I would make my life easier”… Then, only to hear back from IT that this request will take six months to be delivered. While it may be true that there are substantial technical implications associated with specific business requests, IT should not expect business users to understand the full impact of all the IT management details – and it isn’t necessary for them to.

How to recover the Gap between Business & IT?

Better approaches would be:

  • For business, express and explain their needs, the reason why, benefits they are expecting… in two words: the Business Case (honest one, not a fake).
  • For IT to focus on translating the IT management details into business language, so business can understand what IT is saying.

A trap where business is too often ended in is to ask to IT a solution that they have already decided on their own. E.g: ” “I want to have this function in my application.” Doing that is starting it all from the wrong foot and can lead the whole project to huge consequences. My own analysis of this situation is the following: this is happening mainly due to that business doesn’t can/want to spend time to explain what their are already convinced at and that the trust between business and IT is missing from the beginning. So it requires some effort from business to express their needs and not the solution they want. But they are not the only ones who need to make some efforts…

IT has to make effort on its side as well. To start with, IT has to make sure that the thought solutions are really addressing the business real need behind.  Nowadays in many companies, it is quite usal to have IT having the mission to strive for commonality in IT solutions to support different business processes to be supported by the same service or at a lower level: function. Of course, the main goal here is to reduce IT cost. So,back to my first purpose here: to analyse business’ requests and identifying already existing/future services/functions which address the same kind of need is the IT mission as well. Of course, it will take more time to do it, but it is for the sake of the entire company, isn’t it? So what few months spent in a project compare to years of savings? This has to be evaluated and time/money spent to do this evaluation must be accepted by both parties.

So, to me it is a jointly (usually called “collaborative”) work to be achieved. If both parties succeed, first to work on themselves, change their initial behavior, then to work together, I do think that they will be both on a better shape to go for a success. Once IT fully comprehends what the business is trying to accomplish, it may be able to offer an alternative approach that meets the fundamental business requirements and it would even might be done in a shorter time frame at the end.

Opening

Working together on essential business capabilities instead of implementation details, IT and business can often identify solutions that blend the two perspectives. In fact, such collaboration often enables the business to leverage what IT knows about current capabilities or best practices in other parts of the organization. It requires both points of view to ensure that the approach will enable the business to meet market demands.
Further, this type of collaboration positions IT to lead the charge in looking for solutions that are synchronized with business needs. If IT can facilitate a shift in the paradigm to a form a cooperative relationship, both sides will gain in terms of efficiency and results. Rather than responding to requests from business, IT can proactively offer solutions and alternatives. Isn’t it what we are aiming for? So called, win-win situation…

Agile and Complex projects

Catching up with my posts… Here is the trigger of this post: an interesting twitter discussion with my #entarch fellow: @RSessions
mcgoverntheorymcgoverntheory: Most #CIO dont know how to deal with issues in #Agile projects. Troubled projects lead to a backlash against #agile approaches. Endless loop 12:17pm, Nov 01 from Web
RSessionsRSessions: @mcgoverntheory Agile methodology methodology doesn’t scale to complex projects. 12:37pm, Nov 01
enectouxenectoux: @rsessions Don’t agree. It all depends of the scale of the project and awareness of project members.
RSessionsRSessions: @enectoux The scale of the project is what I mean by it doesn’t scale to complex projects.
enectouxenectoux: @rsessions lol, ok then I agree :o) But “complex” is not equal to “large”, isn’t it? To me, a complex project can be a small ones as well and the #Agile issue is more related to scale (large /small) than complex
RSessionsRSessions: @enectoux But I believe Agile can be applied to large projects once we get their complexity under control.
enectoux: @RSessions Well, this time I fully agree.

@RSessions is much more knowledgeable about managing complexity as I pretend to be. If you are interested, you will find lot of interesting thoughts and information at his website: http://www.objectwatch.com/

My intention here is to dig a bit more into this “complexity thing related to Agile”. Basically, if we look at Agile’s manifesto, here are some of the main principles underlie in it (short extract):

  • Customer satisfaction by rapid delivery of useful software
  • Welcome changing requirements, even late in development.
  • Simplicity
  • Regular adaptation to changing circumstances
So, if we look at these principles, some of them will be very difficult to argue with when it comes to manage complex projects through Agile. Take the principle “simplicity” for instance 😉 or on the other hand, other principles like “adaptation to changing circumstances” are more in favor of managing the complexity.
My point is that we cannot state that Agile doesn’t scale to complex projects. It is all about how you can deal with complexity. How much you (as the project leader or project member) can deal with a complex situation. Are you afraid of complexity or are you comfortable with it? If you are comfortable with it, then Agile methodology can help you to manage your complex project, parallelizing activities, having short development loops, enabling you to validate your “still fuzzy” concepts by testing them towards reality quickly than if you were in a “not Agile way of working”. Agile methodology is, to me, very powerful. But, like any powerful tool, it has to be handled with care. It is very easy to get trapped when using Agile and then, blame the method. I’ve seen and I see it many times. Among the principles I mentioned above, two are missing in this list (but not missing in the full list):
Close, daily cooperation between businesspeople and developers” and “Projects are built around motivated individuals, who should be trusted“. these two might look obvious, but they are to me the fundamental ones. Without trust between IT and business in a Agile project, there is no way to make it a success. As enterprise architect, one of our challenge is to achieve “Business and IT alignment“.
There is many ways to try to achieve this alignment, but I think that one of the best one, when the trust is lacking, is to re-establish this trust by succeeding a complex project using Agile methodology. Then you prove what you prone  as “alignment of Business and IT” has a value for both and for the enterprise.
I have many examples of such projects, at different sizes. Some have failed and some have succeeded. But let’s me ask you about you’re experience. Try to remember, any good personal experience of using Agile methodology in a complex project and making it a success?