In many organizations, EA is a sidelined process or a last thought. It is hard to be effective in that case. In other organizations, EA is a core part of IT planning and delivery. It is difficult to imagine EA having anything less than a pivotal role there.
The benefits of an Enterprise Architecture program are clear:
- Fewer applications
- Simpler applications
- Fewer places where the same data was mastered in multiple locations
The longer term benefits are the really compelling part:
- Drop in the cost of ownership (not the cost of development)
- More rapid development of business capabilities
- Better business intelligence
Sounds good, doesn’t it. If you are still in the “I’m thinking about it” stage, then consider adding a step, about a year or two in, that looks at whether you are having the effect you should be having.
If your program is established and running, consider a process every 18 months or so to ask the same questions:
- Is Enterprise Architecture, as it is currently practiced in the organization, producing the benefits that it should produce?
- Has the existance of Enterprise Architecture fundamentally changed the way people do business in the IT teams?
- Have the technologies developed or consumed changed in a fundamental way?
- Has the organization actually adopted, and rolled out, a major change in the technical platform that was overdue but needed EA to exist before it could occur?
- If things go the way they are going today, will the enterprise end up with a simpler portfolio, with fewer, better integrated, more configurable applications?
- Will it happen soon enough?
Why add this step? Because, as a change agent, you have to, first and foremost, believe your own story. You have to convince others to change by first believing that change is necessary. This is an elemental part of the conversation.
However, if you believe your own story, day in and day out, you are very likely to miss one aspect of critical thinking: self reflection. So, you need to force yourself, and your team, to self-reflect. Otherwise, you may think you have the best program in the world, only to wake up one day to find your program marginalized, reorganized, or dispersed.
If EA is a new bird at your company, or has been tried before with limited success, you must know that your ‘hall pass’ has an expiration date. You cannot expect to spend a decade ‘experimenting’ with changes to the processes needed to get EA off the ground. You don’t have that long.
Focus on some key areas:
- Your architects are trained and buy in. Spend heavily but wisely. Spend not one red cent on technical training. Spend on process improvement, leadership, collaboration, communication, and how to drive for results.
- You have control and ownership over the planning and development processes that need to change. Make sure that you can measure the adoption of process changes.
- You have templates and procedures in place to get the most important activities done. You have a mechanism to change them, and you don’t wait until the last minute to do so.
- Use 6-sigma on your own program. Ask “what must you improve to change the results?”
I know that this advice is general, but everyone’s problems are different. At the end of the day, a truly effective EA program, added to an average IT organization, should ROCK THE WORLD. It can happen gradually. It can even happen in fits and starts. But know this: if you are running an effective EA program, the impact will be huge.
What is your impact? If it isn’t huge, in terms of the kinds of systems you have or will have, it’s because you aren’t being effective.