1700

First Group CIO Chris Boult and I are speaking today at the CIO Executive Summit in Cincinnati about enterprise architecture. As its adoption continues to challenge many, Chris and I decided to discuss and bust these 5 myths:

1. EA is what IT uses to plan its technology
2. You can’t measure it
3. Architects only pontificate, they don’t work
4. EA doesn’t work with an SDLC
5. If you subscribe to SOA, you don’t need EA

Enterprise Architecture is What IT Uses to Plan its Technology

A few years ago, I worked with an insurance company to review its enterprise architecture strategy. The acting CIO was led to believe that they were ready to embark on a multi-year business process and technology replacement and asked for an independent blessing. Their chief architect and team had spent almost a year developing a report that charted their technical architecture standards Web technologies, integration standards, development tools, databases, etc. without any business input, business priorities, business functions, or even hard schedules!

First thing’s first - a good EA program starts with a representation of what the business units and functions want to do (objectives, metrics, a strategy of some kind) and uses it as a basis to understand what business capabilities are needed and then build an business and technology blueprint and plan.  It’s much more than technical planning and standards.

When technology leads, it’s not enterprise architecture.

You Can’t Measure Enterprise Architecture

Why don’t your constituents get excited with your EA dashboard that reports things like number of gates passed and number of applications using our ETL standards? Maybe it’s because they don’t care?

What can and should be measured is progress in delivering the prioritized business capabilities developed during planning. Once the capabilities are delivered, the relevant business metrics are also measured.

If your approach is properly business driven and you measure and report against those business capabilities, not only can you measure the delivery of them, your business partners will demand it. Not to say that the other internal EA operational things shouldn’t be measured, just keep them to yourselves to learn about and tune your processes.

When EA is not business driven, you can’t measure it or what you measure is meaningless to the business.

Architects Only Pontificate, They Don’t Work

Another by-product of the technology-only approach is that architects don’t become critical resources that drive new ideas and solve business problems. In one financial services company, this led to a team of over 20 who only met with vendors, did some technology prototypes and wrote white papers. Many of these architects had deep knowledge of the business and legacy technology environments but were wasted in a function that few knew about or got value from.

The companies that do architecture best staff the majority of the architects to projects as core team members. This way, they are on the ground adding their expertise every day.

Enterprise Architecture Doesn’t Work with an SDLC

Much of the value of the formalization of enterprise architecture by organizations like The Open Group and the US government are in the frameworks and processes that help us boil down extremely complex business models into more manageable pieces. The risk with yet another set of processes is that they exist off by themselves, rather than integrated into our day to day work.

EA processes should live in 2 places, right after the high-level business strategy directions and priorities and embedded in the program, project and SDLC management processes to ensure that the cross system blueprints are implemented in each initiative as envisioned.

So, for EA to work, it MUST not only work with the SDLC, but all other program and project level processes and methods.

If You Subscribe to SOA, You Don’t Need EA

It is tempting to try to adopt an architecture model like SOA (or cloud computing for that matter) and try to have it dictate many of your architecture decisions. But if business leads in EA, it will dictate the appropriate styles and models of computing. Choosing an SOA model will only address a small portion of the overall technical architecture and may not be needed or relevant for some business areas in the overall EA blueprint.

These myths highlight two primary errors in attempts to apply EA:

1. Technology, not business driven
2. Separate, not integrated set of processes, people, tools

EA often fails to reach its potential because so much emphasis is put on EA itself and not on its outcomes. Focus more on solid, collaborative business planning and let EA fade into the background.

cc licensed flickr photo shared by AMagill

1700