Enterprise Architecture – 10 Soft Skills – Part 1: Story and Metaphor

September 13, 2013

Enterprise Architecture – 10 Soft Skills – Pt 1

A new architect will quickly realize that simply applying an EA framework will not be very effective without effective communication. These next few posts will discuss some “comm-hacks” that may not be so obvious.

1)      Story and Metaphor– As discussed in a previous post, an architect can use the business motivation model (BMM) for the “strategy architecture”; goals/objectives/strategies/tactics – and how they depend upon each other. The BMM is a GREAT way to structure strategy! But, does it light the fire in the hearts and minds of the team? Maybe/probably not. It’s a very analytical, left brain approach to defining strategy.

What about the right brain? The right brain is equally, if not more important (according to me) in setting strategy because it’s easier to directly access the heart – of a person, a team, or an organization. The abstract, right brain is directly tied to lighting a fire in the heart!

How does one light a fire, in the context of a cold, analytical EA strategy (BMM)? Through metaphor and story! Metaphor and story are abstract and often indirect – the message of the metaphor or story need not be stated directly. Instead, one is motivated and unconsciously directed, through the context set by the metaphor, to search for meaning. The meaning that one finds on their own is far more powerful and motivating than the quantitative side of things. Often, the best stories and metaphors are those with very large scope (e.g. the purpose of entire project, mission of the organization etc..)

EXAMPLE – Let’s say a key project is well underway and an Enterprise Architect is now in a governing role for this project. There are some challenges with the project while others parts of it are going fine. If we were to ask a few key managers in the office and extract their metaphor for the overall status of the project, what could we hear?

Manager 1’s metaphor: “Rome is burning”

Manager 2’s metaphor: “This project is like a roller-coaster, you scream every-time there is a bump or throw your hands up and enjoy the ride!”

Manager 3’s metaphor: “This project is like having a baby. It’s coming out all bloody but in the end you get something beautiful!”


Which metaphor is most useful? People often have unconscious metaphors that can be “read” by what they say and do.

And, here is the coolest part: You can choose your own metaphor! Choose one that is most helpful for the outcome of the project – and communicate it to everyone! You will be surprised at how effective this can be.

Application Portfolio Management: Maximizing Value

March 11, 2012

Application Portfolio Management (APM) is about maximizing the value of the applications running your business.  The goal is to achieve beneficial changes that improve the balance of value to supported cost and risk.

Without an APM practice, the unmanaged portfolio of applications grow stale. This may be in the form of higher operating costs to “keep the lights on” for the application, weak service level and support, or obsolete technology – to name a few. The key here then is to methodically and pragmatically assess all or a subset of the applications top-down in the business in order to devise strategies and define projects and request funds.

We begin the process by assessing key factors of each application in order to categorize each application. Ideally the scope is the entire application inventory but it may be segmented based on current strategic business initiatives with a process, risk, cost, or value perspective. There are various methods to categorize the applications. A popular format is based on the 2X2, 4 quadrant matrix. An example is the “TIME” (Tolerate, Invest, Migrate, Eliminate) method as defined by Gartner.

T – Tolerate applications that provide good enough business value but may have an old architecture or not be well integrated. Without APM, this is probably the largest category.

I – Invest in strategic or newer applications in order to increase value and use.

M – Migrate technologies that have high business value but have issues the with people, data, or technologies that support it. The technology may be unsupported or people may be on the verge of retiring with a declining pool of replacement skills.

E – Eliminate applications that no longer provide sufficient business value.

Once each application has been categorized then define a strategy and high level set of actions, and create a business case and project charter. Also, add these newly defined strategies to the overall future-state enterprise architecture plans and roadmaps.

Over time, the application portfolio balance should shift to a greater percentage of “invest” applications with a lower percentage of tolerate and eliminate applications. This will result in a greater proportion of IT spending to business value and growth based projects  – and that’s the goal.