8 Enterprise Architecture Risksposted by Anna Mar, June 18, 2016
Enterprise Architecture (EA) is intended to help manage IT risks — but is it possible that EA itself introduces new risks?
Many enterprise architects believe there is only one EA risk — the risk that EA will not be properly adopted across the enterprise. The truth is, EA is fraught with risks.
8.Security vulnerabilities and exposuresIn theory enterprise architecture should provide common security frameworks that reduce enterprise security risks.
In practice, enterprise architects are seldom security experts and tend to shy away from security issues. Even large enterprise architecture frameworks such as the Federal Enterprise Architecture have failed to cover security.
What makes matters worse is that many popular architectural approaches such as SOA can complicate security and introduce new risks.
7.Distracting critical staffStakeholders often complain that Enterprise Architecture is cumbersome. Meetings, document reviews and training can distract critical staff from their core business responsibilities.
When EA fails to be focused, lean and results-focused it can end up being a massive waste of company resources.
6. Low adoption ratesThis occurs when the enterprise architecture is defined — but then is largely ignored by IT managers, solution architects and other stakeholders.
It is much easier to define a enterprise architecture than to implement the governance required to implement it. EA programs often suffer from a lack of executive, project and departmental stakeholder support.
This is the most common EA risk but it is probably the least destructive.
5. Increasing solution costsCommon solutions are supposed to simplify things — right? Not always.
Enterprise architecture programs are often guilty of over-engineering. Enterprise architects tend to recommend enterprise-class solutions that provide architectural benefits such as scalability, re-usability etc.. While these solutions may be architecturally ideal they are often expensive — they may be overkill for the business problems at hand.
4. Decreasing user acceptanceEnterprise Architecture with its focus on common solutions introduces additional user acceptance risks.
Users often complain that common solutions are less adapted to the needs of their business unit. Departments often enjoy complete control over their silo-solutions. When they are forced to transition from a silo-solution to a common solution they are often unhappy.
Common solutions generally have a higher risk of user rejection.
3. Creating dependenciesCommon solutions also introduce new dependencies between business units:
|a.||Change requests from multiple business units need to be prioritized.|
|b.||Business units have different business cycles and may all request different change windows.|
|c.||Change requests may conflict - there may be a lack of agreement on the roadmap for the solution amongst different business units.|
2. Project delaysEA governance processes add additional project check points such as compliance reviews. In theory, such check points validate the solution architecture and help avoid implementation roadblocks. However, in practice it is possible for EA processes to delay projects and add excessive overhead.
1. Be careful what you measureEA often introduces business performance metrics. When these metrics are used to evaluate departments, teams and staff — there are sometimes unexpected and counter-productive results.
When people know they are being evaluated by metrics it dramatically changes their behaviour.
For example, consider forecast error metrics. Let's say a department manager is given a target to be within %5 +/- of a budget set at the start of the year. If the manager is under budget at the end of the year she may engage in wasteful spending to conform to target. In fact, the easiest way to hit this target is to underspend all year and then spend exactly the required amount in the last month of the year.
Enterprise architecture programs are increasingly under pressure to show tangible business results. Many EA programs now make metrics one of their key selling points — a way to bridge the gap between business goals and IT spending.
Metrics in themselves are not bad. They can provide business visibility and highlight operational bottlenecks and issues. However, metrics often introduce risks.
ITIL implementation is no cakewalk. ITIL impacts your entire organization — your business, your IT department and your inflight projects. |
Yes and no. There's no ITIL certification process offered by ITIL itself. However, an organization that's reached ITIL maturity can generally be ISO 20000 certified.|
Technology doesn't have to be complex. Guides that break technology into nice bit-sized chunks. |
How to tell if your Enterprise Architect is doing her job.|