There have been quite a few publications recently on the role of the enterprise architecture and the importance of its alignment with business strategy. According to Chris Curran:
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.
Discussing 16 Enterprise Architecture Strategies Learned the Hard Way, Curran notes that:
Strong credibility and trust amongst Business and IT partners is a predictor of EA success. Credibility has typically been gained via joint strategic planning efforts, one project at a time.
Curran goes on discussing 5 most common architectural myths:
- Enterprise Architecture is what IT Uses to Plan its Technology. According to Curran, technology is only one of the components of the enterprise architecture:
... 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 a business and technology blueprint and plan.
On another hand, he cautions against trying to spend too much time building such a blueprint:
An exhaustive enterprise level blueprint is virtually impossible to build - it’s too big and no one will buy-in... The best strategy blends a direction-setting enterprise blueprint and business unit and domain blueprints.
- One Can’t Measure Enterprise Architecture. In Curran’s opinion, the only enterprise architecture that can be measured correctly is a business driven one:
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.
He then continues by saying that EA should be measured in 2 ways: business capabilities delivered and costs of core services:
Measure EA as an asset - what does it cost to provide the service and what return does the business get from the business capabilities delivered?
- Architects Only Pontificate, They Don’t Work. One of the byproducts of the technology-driven approach, notes Curran, is an architecture group spending most of its time meeting with vendors, writing whitepapers and implementing technology prototypes that never see the light of day:
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.
He even goes as far as defining percentage time that an architect should spend (on average) doing project work:
Architects must be assigned to projects as core team members (60%+ of total EA FTEs) rather than "advisors"
- Enterprise Architecture Doesn’t Work with an SDLC. According to Curran:
Methods and governance must be integrated into existing work processes (eg, project approvals, SDLC) rather than a new overlay
Otherwise architecture processes will live by themselves, rather than being integrated into day to day enterprise activities:
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.
In Curran’s experience:
High performance groups maintain consistent, formalized EA involvement in the SDLC to translate blueprints into sufficiently detailed starting architectures for each project as well as accurate cost and resource estimates.
He also notes that:
Mature organizations target 40% EA resource time for strategic planning and 60% on SDLC tasks, and typically err on spending more time on SDLC tasks.
- If You Subscribe to SOA, You Don’t Need EA. Curran explains that some of the companies are trying to adopt a particular architectural style, for example SOA or cloud computing to jump start their enterprise architecture. As a result they often end up with "one size fits all" and have this style dictate every architectural decision.
... 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.
Curran’s observations go to the heart of many problems that enterprise architecture groups are experiencing in many companies. Following his advice can make life easier for both enterprise architects and management.
