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.
- Know what the strategies are, and what goal each strategy is trying to achieve
- Know how strategies align to one another, from the top all the way down to your application’s business sponsor
- Determine how your application supports one of those strategies. Describe the support.
- Get the executive who is accountable f
or that strategy to agree that the application is necessary
Now, wasn’t that easy?
2 thoughts on “How to know if your application is “strategic””
Hmm… Just because your application is necessary for some GM's business strategy doesn't make it strategic. Even then, I'd argue the the application is merely "sufficient", not "necessary".
Take CRM for example. Even if your in one of the most sales driven driven organisations on the planet, your CRM solution is not strategic. (In fact, you could probably turn your CRM off for a day without too much of an impact on sales. Unless you've integrated everything, including the kitchen sink, into it. But that would be a mistake, wouldn't it.) Or come at it the other way, electricity must be strategic, as without it your GM can't deliver on his strategic goals.
The days when we'd consider an application strategic are long gone. Any COTS solution is – by definition – commoditized and undifferentating and should be treated as such. And if you have and bespoke developments large enough to be considered an application that are consider strategic, then you need to be seriously considering a migration strategy, as 90% of the application will be just baggage which prevents you from efficiently leveraging the bit that does matter.
Capabilities are strategic. Your sales GM might be measured on customer service and satisfaction. They'll be focused on increasing their share of customer wallet and reduce the number of visits before close. (And there's the net promoter score worries.) This might make a jointed up approach to mobility strategic, ensuring that the sales team have the right information and functionality at the right time to close the deal over whichever channels are most convenient (portal, mobile web, voice portal, IVR …). But then individual technologies within that solution are not strategic, or even necessary, as any "good enough" component will do. There's similar stories for decision support, etc.
The reality is that neither technology nor applications matter much any more. Business proceses have some importance, but ultimate it's decisions and capabilities that rule the roost these days. And these only matter if they:
<li>create a new product, service or market</li>
<li>change the cost of operations or production</li>
<li>create new interactions between customers and the company</li>
This is what the business cares about. Everything else is overhead.
There's a lot in your response that makes sense, but the overall logic is, IMHO, flawed.
You said: "But then individual technologies within that solution are not strategic, or even necessary, as any "good enough" component will do"
A capability is an abstraction. It does not exist. No person "uses" a capability when they go to work in the morning. A capability is a planning tool. The decisions you make with capability modeling are specific decisions on how to manage and control the business processes, information, applications, and technology necessary to make that capability function.
So, yes, we can treat an application as "strategic" if a strategic capability requires it. Even a "good enough" component is strategic if it improves the maturity of a strategic capability.