Steve JobsThe whole Internet is buzzing with Steve Jobs’ resignation as Apple CEO and the possible effects it might have on Apple and its products. There are people who hate, admire, get inspired and feel hatred about him. But, someone who shaped and revolutionized the digital world with his products not in the seat of CEO doesn’t mean of his company doesn’t mean end of all. In fact, he will continue to be with Apple but might not be in the same capacity and not so close to the team, due to whatever reason and I respect. In my opinion, Apple will continue to amaze the world because Steve has sown the seeds already.

  • It’s not Steve who designed iPhone, iPad, iPod, etc. all by himself but his talented engineers he assembled, motivated and inspired for so long. The core skills he has implanted for decades in Apple makes him the leader.
  • Simplicity & user-centric design: Steve and Jonathan Ives (VP of Design) have created for Apple better than anyone for any company. I would say simplicity is Steve’s signature style. Form-factor and design of today’s many Apple consumer products will tell the success of Steve & Jonathan!
  • Not many have given so much importance to usability as Steve & his team have.
  • The culture of always looking for better things without settling for what they are, that he has infused into the organization and imbibed by many in Apple today will go a long way.
  • Of course, it was not with failure also (Steve is good in accepting failure too)! Apple had some not-so-great products but as everyone else it learned the lessons, recognized the potential and applied both in future vision!
  • In my perspective, Steve is a leader of innovation: from the bare metal lab to consumers’ heart, he has paved way for unique "experience" in everything in between. Innovation is not always about new things, but doing things differently too!
  • With due credit for other companies and individuals, Steve has set the standard for today’s mobile devices, be it a phone or a media player. Not just the devices, the applets on them, developing those applets, bringing them on to devices, advertising and making everyone profit from the whole ecosystem was the result of Steve and his team!

I am always inspired by this man of "innovation for simplicity"! Hats off to Steve!!

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.