13 years, 7 months ago

How to know if your application is “strategic”

Link: http://blogs.msdn.com/b/nickmalik/archive/2010/10/21/how-to-know-if-your-application-is-strategic.aspx

Enterprise Architects get involved in some pretty hairy discussions.  One responsibility that tends to fall to Enterprise Architecture is to steer the evolution of the business and/or business infrastructure away from needless complexity and towards effective, agile, and efficient operations.  Sounds good… rolls nicely off the tongue. 

In reality, EA is sometimes a fistfight. 

If an EA is supposed to “steer towards a more simple future” that means steering away from the complexity that we are living with today.  That means change.  And with most change, someone is going to be uncomfortable.  Someone is going to be inconvenienced.  Someone is going to have to give up a little control or take a compromise.  Someone is going to have to spend money.  None of this is easy.  Sometimes it is downright hard.

The “Strategic Alignment” Game

One trick that EA uses to accomplish this function is called “strategic alignment.”  In other words, we identify the areas of the business (capabilities) that are “strategic” and then we identify applications that are “strategic” and then we start carving up or killing off the processes, systems, and corporate structures that are impeding success for those strategic processes and applications, and we add new features only to the most strategic applications.  Carve and Kill. Carve and Kill.  That should be our motto.  Just in time for Halloween. 

Why carve up and kill off?  Because complexity breeds inflexibility.  Complexity is the nemesis of Enterprise Architecture. 

I had a manager at IBM, a long time ago, who once told me that “you could walk down the hallway of this place (IBM Boca Raton) and fire every third person, and productivity would go up.”  I don’t know if he was right, but the concept has legs: fewer systems means fewer connection points means fewer projects means fewer investments.  Simplicity in the system produces simplicity in the governance of the system.  Sometimes, Simplicity is a numbers game, and the “strategic” application wins. 

Of course, this trick works both ways.  If you want your application to be declared “the winner” in the battle for simplicity, you would be well served to figure out if the application is “strategic,” and if it isn’t strategic today, find a way to make it strategic before some goofy EA comes along and suggests shutting it down.

Hence this post.  You own an application.  You love your application.  You think your application is the “bees knees,” “best thing since sliced bread,” and “total awesomeness” all rolled up into one beautiful bundle of software.  You want to protect your precious gem from that awful Enterprise Architect who keeps digging up embarrassing facts about reliability, scalability, features, and cost.  What can you do?

What it means to be strategic

An application is strategic if the requirements and demand for an application originate in business strategy.  That’s it in a nutshell.

Saying “this app is strategic” is not the same as saying “the business wants this,” or even “the business needs this.”  There are LOTS of things that a business may want, and many of them may even be needed.  Only a tiny subset of what they want and/or need come from business strategy.  The rest comes from “good ideas” or “continuous improvement” or someone’s commitments to their manager.  Sometimes that stuff is aligned with strategy.  Many times, it is just work. 

There are some interesting implications of this definition.  Look carefully

  • Within an app, it is possible for one feature to be strategic, and the rest to be useless.
  • An app can be strategic in 2009 and not strategic in 2010.
  • An application can be strategic even if there is no positive “return on investment” for changes to that app.
  • A change request can have a strong “return on investment” and not be strategic.
  • It is normal that a strategy impacts many applications even if those applications are used by different people and share no data at all.
  • Strategy often requires integration, but not every time.  Integration is not a universal solution to every strategic requirement. 


Is my application strategic?

Find the actual words spoken, written, and disseminated from actual business leaders within your business.  Ignore the trends from outside.  Ignore the stuff that competitors are doing.  (If you want to know why, that’s a different thread).  Ignore the suggestions for improvement coming from your customers.  Look at the business strategies of the business.  Trace the business strategies down through your organization, from the CEO all the way down to the business person who “owns” the application.  Collect all of those strategy statements.  Line them up.

Now link them together.  Make sure that it is clear (to you) how the organization is attempting to meet the strategic needs of the company through measurements, commitments, and business initiatives with measurable goals. 

What will you see?  You will see a hierarchy of strategies, one derived from another. 

At each level “down” an organization, new strategies may appear that are NOT linked to the strategy of senior staff above.  That is because the senior staff is assuming that specific operational imperatives will be maintained, even if they are not stated at upper levels.  Just because a senior manager doesn’t state something obvious (like don’t screw with the customers), that doesn’t mean that there won’t be strategies, at a lower level, to make the customer happy.   

For example, if a business has a tradition (and brand) of providing “customer-service focused” solutions and the senior leaders describe business strategies around “increasing market share in Trinidad,” the assumption is that the products sold to those customers in Trinidad increase their value through a heavy dose of customer service.  In most cases like this, there is a business leader who is accountable for maintaining a high level of customer service, even if there is no announced business strategy from the CEO to do so. 

So you look at the business leader that “wants” your application, and ALL of the strategies above that person.  That is panoply of business strategy that motivates that person. 

To be strategic, your application must be necessary to cause, support, or enable one or more business strategies to succeed in meeting their objective goal. 

Find the strategy that your application ties to, and advertise that tie.  Then, go to the business leaders who announced that strategy and convince them that your application is strategic.  Convince them that your application is necessary for them to meet their business goal. If they agree, congratulations, your application is strategic.

Note that last step. Simply stating that your application is necessary to meet a strategic goal is not enough.  You have to get the business leader who dictated that strategy to agree with you.  Until they agree, your application is simply an application.


  1. Know what the strategies are, and what goal each strategy is trying to achieve
  2. Know how strategies align to one another, from the top all the way down to your application’s business sponsor
  3. Determine how your application supports one of those strategies.  Describe the support.
  4. Get the executive who is accountable f
    or that strategy to agree that the application is necessary


Now, wasn’t that easy?