How do we take EA governance from a “push” model to a “pull” model? In other words, how to we create a system where people want to do the same things that EA wants them to do, without calling it governance, and without the political battles that ensue?
I have an idea, and it relates to the process of creating a budget forecast. That’s right… it’s boring… but at the same time, this is where the rubber meets the road: money. People do what you pay them to do. That truth is immutable, and quite useful. While a small number of people don’t do what you pay them to do, the wild majority do. Correlary: If you make it easier to fund well-aligned projects than poorly aligned projects, then more projects will be well aligned.
Based on this theory, and this theory alone, I suggest that EA should focus their efforts in two ways. First: create and get approval for a future-state model describing what the future should look like, and second, get the IT funding process to encourage projects that align with the future.
That’s it. Who needs governance when people will only do what you pay them to do, and you control the purse strings? This is exactly the model that Corporate America, and their friends in the Republican party, have used to take over the news media and fire every progressive anchor and reporter they can find. They didn’t ban progressive thought… they just refused to pay for it.
If we do the same with Enterprise Architecture, and we take the long-term view, we can get the future vision to appear without raising a single ‘red flag’ or “governing” a single project.
I call this idea “honeypot funding.”
It works like this.
Business goes through a cycle of ‘strategy’ setting where they create a list of their strategies for the coming period (hopefully five years, but in many companies, you are lucky to get more than 9 months…). Business architects map the strategy to business capabilities. They ask, “What capabilities will the business need to improve upon in order to meet these strategies?” They create a list of “hot spots” where specific capabilities are weak and need to improve.
Application architects come along and map the “hot spots” to “logical platforms.” A logical platform is a technology-neutral description of an application or system that encompasses specific features, exposes specific services and is not tied to any particular line of business. App architects ask, “what features will the IT platforms need to improve upon?” (Note: our term for a ‘logical platform’ is “Solution Domain”)
All this happens within a few weeks of the creation of the strategy documents.
The budget office then takes a look at the work of the architects. The areas where the platforms need improvement, or areas where maturity is needed but it doesn’t exist… these areas get the honey. When creating the initial budget plan for NEXT cycle, finance works with the application architects to set a priority. Projects, when submitted for funding, have to tie to a particular ‘logical platform’ and they are considered for funding in the order of the priority of the platform in the budget system.
The priorities are published as soon as possible.
When IT projects are proposed, they are inevitably aligned to the highest priority platforms, because the business folks and IT folks who see those priorities will naturally spend time and effort on projects that they believe are likely to be funded. Why propose a project aligned to a tiny budget when you can propose a project that is aligned to a larger budget? People will go where the money is.
To add to the mix, you can stipulate that an IT project that wants to be able to get a budgetary extension later on, must sign up to EA requirements at the time of initial funding. Now, if you think you can deliver your app on the original budet timeline, no need to sign up… but the only projects that fall into that category are doomed for failure anyway, so who cares. The rest of the projects will gladly sign up to EA requirements, just so that they can get permission to extend their project deadlines later on down the line.
Gotta think about this one some more.