Below is the link to my profile as IBM Champion for 2011.

http://www.ibm.com/developerworks/mydeveloperworks/profiles/user/NachiketDesai

This is a great article on management styles between west (mainly USA and Canada) and India. A must read/see for all executives and managers. Cant wait to read the book.

http://blogs.forbes.com/karlmoore/2011/04/18/what-american-executives-can-learn-from-indian-ceos-about-great-management/

My testimony for IBM’s Smarter Planet movement.

http://www.youtube.com/user/nachiketdesai?feature=mhsn#p/u/0/LOSqccc9dX4

 Watch the video.

Gartner every year publishes their report on technology trends. I was wondering if anyone has analyzed how many of these actually make it into ‘real’ projects within organizations.  Here is the article

http://www.gartner.com/it/page.jsp?id=1454221

Wikipedia defines Enterprise Architect Role as follows: 

“Enterprise Architects work with stakeholders, both leadership and subject matter experts, to build a holistic view of the organization’s strategy, processes, information, and information technology assets. The role of the Enterprise Architect is to take this knowledge and ensure that the business and IT are in alignment. The enterprise architect links the business mission, strategy, and processes of an organization to its IT strategy, and documents this using multiple architectural models or views that show how the current and future needs of an organization will be met in an efficient, sustainable, agile, and adaptable manner. 

Enterprise architects operate across organizational and computing “silos” to drive common approaches and expose information assets and processes across the enterprise. Their goal is to deliver an architecture that supports the most efficient and secure IT environment meeting a company’s business needs.” 

This is a good place to start. Several definitions and descriptions for the role exist. The fact of the matter is that the role of Enterprise Architect gets defined by the understanding of the organization of the role and initiative of the Enterprise Architect. What I mean, is that the role is an all encompassing role. As mentioned above, this role requires working across ‘silos’ and in order to align with business, and this can result into contributions in every aspect of the business. By individual initiative, I mean that the person in this role has to at times pull back from certain areas and dive deeper into others. 

The objective of this blog is however to help Architects starting with multi-branded companies ‘hit the ground running’.  In order to do so, I have put together the following approach. Each part of this approach has to start based on the sequence below, but not dependent, and will have to run in parallel: 

1. Establish relationships with business stakeholders and educate them on the role.
2. Understand Current Technology State
3. Learn the business (e.g. if retail, spend a few days in the store and warehouse).
4. Identify crucial Business Processes.
5. Study strategy plans, Capital spend and Operating Spend for IT from 3 previous years.
6. Define framework
7. Layout the roadmap

I will attempt to break each of the above items down. However, these are extensive discussion and initiatives. 

Relationship Building and Role education

This is a key aspect to the success of this role. Meet all stakeholders; grab a sandwich or a coffee with business partners. Use the time to understand their roles as well as educating them on yours. Most of the business stakeholders perceive technology as an inhibitor to growth and so this exercise is very difficult. However take advantage of being the ‘New Kid on the Block’ and forge as many relationships as possible. This exercise will also help determine, which of the stakeholders are ‘Tech Savvy’. 

Understand Current Technology State

Most of the organizations do not have updated technology documents. Learning about the deployed technology (both Applications and Hardware) provides insight into several low hanging fruit. Also, if one is new to the organization, this will help generate a fresh perspective. This exercise should be used to document the technology stack across the enterprise. Examining data flow as part of this exercise will help the second item as well as understanding the existing business processes. 

This exercise should be conducted by brand or business area and then collate as Enterprise View. 

Learn the Business

Technology team designs and implements business needs and this sometimes leads one to believe that one understand the business. There is a certain amount of truth to this aspect, however, interacting as a customer and working within operations is the 360 degree view of the business. Based in the organization one is with, spend some time with business operations. Transact with your organization as a customer, and talk to your friends and family and gather their perspectives and perceptions. This exercise will lead into the next item. 

Crucial Business Processes

Most businesses depend on key process to work right at the time of ‘peaks’. These fundamentally drive the bottom-line. Understanding these will be easy, because a lot of operational support will be built on these processes. Most organizations strive to improve customer experience. Focus on customer service aspects, since those areas are most neglected. For ecommerce companies, the focus on web store fronts shadows every other process. Its natural tendency of everyone involved to only focus on the web channel, since there is more recognition politically around it. However, there are quick wins in other aspects. 

Studying the Past

It is very important to review past strategy plans. This provides insight into how the organization has done in terms of long term planning.  If the organization’s focus is next quarter, presenting or talking about ROIs on 3-5 year plans will be mute. On the other hand, if the focus is not on the future, that’s the hole, this role has to fill it.  Studying the strategy plans of the past and by combining the current state will result in an emerging picture of the organizations execution capability. This is key aspect to keep in mind when defining the roadmap. 

Another important parameter to presenting the roadmap is ROI. One will spend a lot of time in demonstrating ROI on future investments into the roadmap, but demonstrating the amount of money spent in the past years and the returns on it need to be surfaced as a perspective on defining the roadmap. This will help change directions if needed or to propel mindset change. 

Defining Framework

Many Enterprise Architects spend a lot of time evaluating frameworks and how they apply. Below is my definition of a simple framework that applies to most of the multi-branded businesses. 

Framewok by Nachiket

The idea here is, to centralize organizational assets (Master Data Management). Most of the other aspects depend on these assets and should be built/integrated around it. This is not a new or novel idea, rather just a simplistic representation of a well established paradigm. I will publish a more detailed thought process around this framework at a later date. 

Layout the Roadmap

The previous items help chart the technology roadmap. This roadmap will need a lot of selling and socializing amongst business stakeholders. Before engaging the business side, ensure that the technology team understands the approach. Especially the veteran, their buy-in is needed on the technology side. Naming the program helps. Avoid acronyms and compose an elevator-pitch. 

And most importantly, grow extra-thickness on your skin. Every meeting going forward will be harsh and hard. I suggest an opening line for all meetings:

 ‘Don’t shoot the messenger!’ 

Without debate, the key item on every Enterprise Architect’s task list is to understand the business, the genesis and vision.  I do believe that the journey of laying down a technology roadmap starts with understanding how the business started. Business evolves, no doubt, but it is important to understand current state. Thus, how it started and where the business is, will help charting the technology roadmap. The name/brand of the business says a lot already.

Dealing with Legacy

Enterprise Architect has to deal with the little problem of legacy systems.  These systems are often the reflection of how the businesses have progressed and evolved.  A very interesting insight will dawn when one reflects on the naming of these legacy systems.  I have come across names like ‘Legacy’, ‘Maya’, etc.  Most of these legacy systems were built 20+ years ago and the intention was always to build a ‘do-it-all’ grand system.  This also reflects on the thought process that existed within business stakeholders at that time.  Enterprise Architect is responsible for aligning with these mindsets.  In the age of SOA (Service Oriented Architecture), which is a contrasting concept to ‘Legacy’ or ‘Maya’, it’s an uphill climb on the onset.  Early on I had to abandon using terms like SOA and use simpler words like ‘Centralization’, ‘Standardization’ and ‘Shared Services’.

Another interesting aspect is naming of the transformation program.  This name has to be something that resonates with everyone clearly and at the same time describes the principal of it. There is a certain amount of value if you can avoid acronyms. Acronyms tend to get ridiculed in my opinion. Along with the name having a tag line helps. Enterprise Architect has to ‘sell’ the program and the challenge is no simpler than brand building.  

Having said all this, there are many companies / brands / products whose names were derived from strange circumstances. Below is something I received in one of spam emails, and I preserved it.

Mercedes
This was actually the financier’s daughter’s name.

Adobe
This came from name of the river Adobe Creek that ran behind the house of founder John Warnock.

Apple Computers
It was the favorite fruit of founder Steve Jobs. He was three months late in filing a name for the business, and he threatened to call his company Apple Computers if the other colleagues didn’t suggest a better name by 5 O’clock.

CISCO
It is not an acronym as popularly believed. It is short for San Francisco .

Compaq
This name was formed by using COMp, for computer, and PAQ to denote a small integral object.

Corel
The name was derived from the founder’s name Dr.Michael Cowpland. It stands for COwpland REsearch Laboratory.

Google
The name started as a joke boasting about the amount of information the search-engine would be able to search. It was originally named ‘Googol’, a word for the number represented by 1 followed by 100 zeros.
After founders- Stanford graduate students Sergey Brin and Larry Page presented their project to an angel investor, they received a cheque made out to ‘Google’

Hotmail
Founder Jack Smith got the idea of accessing e-mail via the web from a computer anywhere in the world. When Sabeer Bhatia came up with the business plan for the mail service, he tried all kinds of names ending in ‘mail’ and finally settled for hotmail as it included the letters “html” – the programming language used to write web pages. It was initially referred to as HoTMaiL with selective uppercasing.

Hewlett Packard
Bill Hewlett and Dave Packard tossed a coin to decide whether the company they founded would be called Hewlett-Packard or Packard-Hewlett.

Intel
Bob Noyce and Gordon Moore wanted to name their new company ‘Moore Noyce’but that was already trademarked by a hotel chain so they had to settle for an acronym of INTegrated ELectronics.

Lotus (Notes)
Mitch Kapor got the name for his company from ‘The Lotus Position’ or ‘Padmasana’. Kapoor used to be a teacher of Transcendental editation of Maharishi Mahesh Yogi.

Microsoft
Coined by Bill Gates to represent the company that was devoted to MICROcomputer SOFTware. Originally christened Micro-Soft, the ‘-’ was removed later on.

Motorola
Founder Paul Galvin came up with this name when his company started manufacturing radios for cars. The popular radio company at the time was called Victrola.

ORACLE
Larry Ellison and Bob Oats were working on a consulting project for the CIA. The code name for the project was called Oracle (the CIA saw this as the system to give answers to all questions or something such). The project was designed to help use the newly written SQL code by IBM. The project eventually was terminated but Larry and Bob decided to finish what they started and bring it to the world. They kept the name Oracle and created the RDBMS engine. Later they kept the same name for the company.

Sony
It originated from the Latin word ’sonus’ meaning sound, and ’sonny’ a slang used by Americans to refer to a bright youngster.

SUN
Founded by 4 Stanford Universitybuddies, SUN is the acronym for Stanford University Network. Andreas Bechtolsheim built a icrocomputer; Vinod Khosla recruited him and Scott McNealy to manufacture computers based on it, and Bill Joy to develop a UNIX-based OS for the computer.

Yahoo!
The word was invented by Jonathan Swift and used in his book ‘Gulliver’s Travels’. It represents a person who is repulsive in appearance and action and is barely human. Yahoo! Founders Jerry Yang and David Filo selected the name because they considered themselves yahoos

Scape Goat

Article in the CIO magazine about the role of Enterprise Architect.

Enterprise Architecture: From Incite comes Insight…

http://duckdown.blogspot.com/

Increasingly, businesses have perceived that a quick-to-market solution is in hiring a vendor. There are many aspects to this, but mainly because software is commoditized.  Most of the time, vendors who are hungry for business, provide the initial phase at rock-bottom prices, or even free, to capture future business prospects with the client. It has become quite a common occurrence when a business stakeholder says ‘Let’s look for a vendor that can meet our time-to-market, budget and timing needs’. In other words ‘Show me the vendor’!

Generally speaking, most businesses suffer paralysis because of their dispersed, diverse and legacy systems. These inhibit any rapid time-to-market initiatives. However, no amount of self-reflection suggests that these may be due to their insatiable pursuit of ‘instant gratification’. Often, ‘ill-conceived’ projects, which are created based on focus groups or ‘gut’ of a veteran executive, are implemented with a vendor. And yet, I can’t seem to recall any path breaking business venture succeeding on those lines. Is reactive business a strong business? In my opinion, innovation affects consumer behavior, not the other way around. The object of this post is to point out what seems like a quick-to-market strategy, is nothing but ‘quick-to-lose’ ground tactic.

Most of the hurdles in business are perceived to be in the technology department. To quote someone I met recently, “IT bashing is a national sport”.  To most, IT is the biggest hurdle to every grand scheme the business has. Rarely the comprehension exists amongst business stakeholders, that the said paralysis from  diverse, disperse and legacy systems, were in the past, similar initiatives like the ones on their priority lists today. In one of my previous jobs, I spent most of my time running around the world fixing a system that was chosen by a business exec against all resistance from IT. The said system was central to the multi-national business and key component. The system was developed by a vendor in Brazil, and then was implemented in countries like India, China, Australia, Korea, etc. The Brazilian vendor at that time, suffered extreme communication challenges and, relatively speaking, the technology space was not as matured. So, a software system was imported to India, a country which exports 90% of the world’s software. Can you imagine the frustration of the engineers working on the project? Needless to say, the project was a huge debacle.  All the problems were attributed to the internal IT department and, to this day, Indian IT maintains that they could have done it simpler and better, and so does every IT department the system was implemented in. A noble business thought of standardizing a system for international operations, but lacked basic comprehension that the business rules were different in different countries. This is classic, a decision taken without the right level of partnership with IT. Similar parallels can be drawn within multi-branded, national companies. Needless to say, this many times also leads to’re-invention of the wheel’.

In time of ‘milk and honey’, every business executive is an innovator. Grand projects are launched and many of them fail. However, only the successful are remembered, and failures are absorbed by the bustling financial situation of the company. During such times, there is very little or no interaction between different business units.  This situation changes rapidly – as it did – when the economy took a dive.   And as business folks start talking to each other, perceptions get generated. Statements like, “oh we did THAT in close to NO TIME, using a VENDOR…”. That’s it. The chase is on. Internal IT is the stumbling block, since they said it can’t be done in the said timeframe. Business folks with minimal IT experience and lack of comprehension think that a vendor can fix the problem that internal IT cannot. Even if the vendor can implement it, since the vendor is not burdened by lights on activity, it only adds to the paralysis. Diverse solutions are put in place in name of meeting a particular goal and the maintenance of it is thrown over the wall to IT. IT usually is providing the view to the business with two primary objectives:

1.       Enhancing the systems opportunistically (remember how we always promise to come back and fix it?)

2.       Implementing a technology in the right Architectural framework.

Both of the above are complicated and require business comprehension and support. As important as it is to get ‘it‘ in front of the consumers/customers, we fail to acknowledge that everything we put in front of the customer does not succeed, and yet, every initiative is imperative.

Having done vendor management in half a dozen countries, across cultures and language barriers, the one thing that I have learnt is that, without placing the trust in a vendor, there is no success. Many times I have been the obstruction for a vendor to deliver, and many times I have failed to realize the ‘lemon’ that gets delivered by a vendor.  Businesses that resort to vendors for quick-to-market initiatives miss the future by a mile. So many examples come to mind, where the first deliverable is shiny and the business is stuck with a solution that cannot be extended or scaled. We all have been there, done that. And yet, we don’t learn from our mistakes. Even with the smartest of folks managing a vendor, one cannot guarantee the right results, without the investment of trust and partnership. Without trust and partnership between business and IT internally, there is little hope in success, even if an external vendor is hired. Most of the vendor-run projects succeed because of the internal IT efforts. I would be so bold to say that this is the case 90% of the time.

Vendor can fill in the cracks in the walls, but will not re-enforce the beams of the structure. Working on the foundation is not a matter of preference or priority, but an inevitable task we need to undertake. A very wise man told me, that trust is a choice. It took me many days to fathom the concept. So simple and yet deludes the smartest of people. Either you trust your IT department or replace it. But a vendor delivers to a contract or Statement-of-work (SOW). Internal IT department delivers to the future of the company. This distinction rarely dawns on business executives.

In no way, am I implying that good vendors don’t/can’t deliver, but the work required to make a vendor succeed is more than the work required to make your internal IT team succeed.  We have an Indian saying ‘Ghar ki murgi daal barabar’. India is mostly a non-beef eating nation and chicken is ’fine dining’ (simply speaking) and lentils are cooked at home every day.  The phrase means that chicken dish cooked at home is compared to common lentils cooked daily. Remember that every vendor is an IT department to their business with the same challenges. It serves no value to discount home grown competency.