As I noted in my previous post, before an organization starts spending a penny for EA, it should identify the real needs of EA from various perspectives and figure out subjectively the impact of having or not having EA and ways how EA can be sustained on a long run. Think about this: are there too many systems running to fulfill the business needs? If yes, then there are chances of inconsistencies among those systems and spending lot of budget on maintaining them. What is the justification for their existence? Perhaps an integrated solution such as ERP or CRM could replace many of those applications and save cost quickly – a critical output that can come from EA (there wouldn’t have been so many systems and move to an integrated suite after spending lot of money on maintaining for so long, had there been EA in the first place!).

  1. EA is a multipronged approach to optimize business operations with the help of IT and it is a transformational work, hence the business is likely to realize the EA ROI only after months or years.
  2. Let alone the immature and yet evolving state, unless EA is accepted and owned totally, ROI is hard to realize even after months and years – better stick to the rules!
  3. Identify all the benefits EA adoption/implementation will bring in and assess each of its values, which will ultimately tell you how successful your EA is. Example:
    1. Reduced manual work/optimized workflow/automated processes all saving employee time translating to per hour cost saving or quicker time-to-market
    2. Removing or linking redundant systems, saving associated hardware, software & maintenance cost
    3. Consolidation of business units to remove duplicate business processes, services, work force, etc.
    4. Buy/build a new system (additional cost) but will show the cumulative benefits (better ROI) in future
    5. Processes/tools/models for improved service quality/better customer satisfaction resulting in more revenue
    6. Risk avoidance, regulatory compliance for improved corporate governance
    7. System integration for real-time data/reports/analyses in order to enable the business to make strategic decisions on time before the competition gets there (strategic agility)
  4. Success criteria vary for each core organization dimension (business/strategy, IT, finance, operations, compliance, sales/marketing) because each one’s priorities, objectives and definition of success are different. ROI can be effectively measured only if the framework includes all stakeholder metrics/parameters.
  5. Determine when to measure the EA maturity in the adoption lifecycle and the depth of measure (project level Vs. function level Vs. division) for accurate depiction of the reality

Measuring EA’s success and validating ROI is not possible if its decisions do not result in tangible business benefits and measurable impact.

Weeks back I had an opportunity to watch a panel discussion on why businesses haven’t fully accepted enterprise architecture holistically (or why enterprise architecture discipline is in the way, it is today) and some top challenges around enterprise architecture/architects (EA) today. It was great to see some top folks from major IT organizations in the panelist group talking about their experience and knowledge in evangelizing EA in their own organizations as wells as their customers.

The Crux

The summing point of all is that almost every organization that has embarked on enterprise architecture journey are in the same boat: they know the problems surrounding enterprise architecture but do not know how to address them strategically and bigger than all is the lack of buy in from business for EA. Businesses don’t see EA as a value add but as just part of the IT organization and such a situation could prove costly for them down the years. One of the points made out in the discussion was that architecture is most often seen as an ad-hoc task: architect walks in, recommend architecture and solution, leave and that’s all. In order words, architecture is considered as a project management-like activity rather than a value-adding long term engagement. It’s partly to do with architects themselves:

  • They have different professional attributes and each one’s viewpoints towards problems vary (generally influenced by the organizational culture and technology disciplines they work with most) without willing to compromise
  • Often work in silos without engaging other stakeholders
  • Tend to not communicate well
  • "My way or the highway" kind of style – not every so often will you see architects coming to a common ground – if you talk to N number of architects about a problem, chances are that you get N different solutions
Enterprise Architect Qualities

What qualifies someone as an enterprise architect ultimately? The definition of "enterprise architecture" itself varies for every organization and so are its roles and responsibilities, let alone the human part. As a panelist noted (and I agree too that), enterprise architects need to possess behavioral skills and domain knowledge in addition to being technically savvy. The last part is sometimes optional, since enterprise architects involve with bigger scheme of things in enterprise IT including strategy roadmap, aligning IT investment with business and bridge IT and business. Nevertheless, he/she should be able to blend with upstream (business exec.) and downstream (technical/IT) crowd. Some view EA is something to do with IT and not the business, which is not the case by any means. Instead of giving fairy tale pictures of how things should work and the IT utopia, EAs have to work at detailed level (not coding), see through the ground reality (collect metrics, analyze & give constant feedback to the teams) and enable the business make informed decisions. EA is political too as it requires performing balancing act between multiple departments, divisions and stakeholders. Today, enterprise architecture looks arbitrary as opposed to be not being so!

EA Challenges

Is EA Required?

First of all, an organization should do a self-check to see if it really needs EA. Think about the cost of not having EA than funding it (or vice versa). If the organization is not looking for a "change", namely cutting cost, improving operational efficiency, service excellence, merger & acquisitions, etc. then it may not require EA at all. If deemed necessary, then the next hurdle is to get the buy in of all the stakeholders because people will not be ready to give up what they have owned to someone else, if EA requires it, for example. Next, there is no guarantee that EA will result in desired business success due to dynamic nature of the enterprise (people, process, technology, supply, demand and customer), thus delivering potentially outdated recommendations and unusable frameworks. Finally, who is responsible for "selling" EA into the whole organization and sponsors it? EA is marked for failure when the business doesn’t commit required resources (human, budget and time), faces resistance to change from the down-level, expects immediate ROI and lacks readiness for EA.

What about the "ROI" aspect of EI? Stay tuned.