Nagesh V. Anupindi

Feb 22nd
Text size
  • Increase font size
  • Default font size
  • Decrease font size
Home News Articles Technology Podcast with Jonas Lamis on Architecture & Governance Magazine

Podcast with Jonas Lamis on Architecture & Governance Magazine

E-mail Print PDF
User Rating: / 11

jonas_lamis_and_nagesh_anupindi_for_architecture_and_governance_magazine_podcast_2009Original article at: A & G Magazine

Podcast in MP3

Jonas: In this podcast, we are joined with Nagesh Anupindi. Nagesh has been working in the Enterprise Architecture discipline for more than a decade. He worked in several large organizations such as Qwest and Xcel Energy. Nagesh graduated from Indian Institute of Technology and received Ph.D. in computer engineering from University of Rhode Island.

Nagesh: Hello Jonas. Thank you for having me. I am happy to be part of this podcast. I have been living in Denver, Colorado for last 13 years. The field of Enterprise Architecture has changed quite a bit within the last decade. The same CIOs that I have worked for within the last decade are now looking at the Enterprise Architecture as an organization to help them reduce annual spend. The same Enterprise Architects that I know a decade ago are now have better tools from several software vendors.

Jonas: Nagesh, I have seen several articles and presentations from you on the topic of Enterprise Architecture. With these distinct experiences, what do you see as the common structure for Enterprise Architecture departments? What can you suggest to other Enterprise Architecture organizations on what works and what doesn’t.

Nagesh: Great question Jonas and I can probably speak for hours on this topic but, I will keep it short. Through my experiences and some friends that I know, I have seen varied objectives for different EA departments. Most of these objectives circle around four different things.

One, Few executives thought that Business Architecture or Business Functions for creating EA artifacts and producing large documents is important. Second, Some CIOs that I worked for thought that Technology Standards and Technology Roadmaps are important. Third, Some IT Directors think that implementing an EA tool is all there to building an EA department. And fourth, for those that came from projects and software development side of the house, they think that EA needs to play significant role in the Project Architecture because that’s where the money is being spent at any given time.

For any EA organization, I believe that all these four objectives are important. Being an occasional cook, I can say that a recipe needs all the ingredients for the dish to taste good. All these four objectives are necessary ingredients for an EA organization but need to be deployed in a specific sequence.

Jonas: What can you suggest about the sequence for deploying them? Should we start with Business Architecture, or Project Architecture?

Nagesh: The order depends on organization, politics, and budgets. For me to start any of these initiatives, I look to see “who are my customers” within the IT organization. I always go on a hunting to find who has the appetite to pay for it. Obviously, in any organization, there is always money that is being spent on the Projects for new functionality. So, Project Architecture is definitely the low hanging fruit. Especially, in a heavy capital budget organizations.

Jonas: Why does the capital budget make a difference?

Nagesh: If you look at the way corporate budgets are structured, they have the G&A component which stands for General and Administration. Then, you have the Capital component. These two budget components are treated differently by corporate accountants for tax purposes. The G&A budget is usually used for regular operations and break fixes within IT. Everyone’s salaries come out of it. Fixing your laptops and air conditioning bill for your Data Centers come out of it.

On the other hand, the Capital component of the budget is for building new things. For example, if we want a new billing system or if we want to upgrade the back-bone for a call center, the required funds come out of capital budgets. The capital component for building a new billing system cannot be estimated as accurately as the salary you are going to pay for a programmer that has been with the company for some years. This is because there are components that are new and unknown. Project Architecture supposed to untangle the unknowns and layout the design. So, there is the need and there is the money. Establishing good Project Architecture can save money for IT organization in short and long runs. What I mean by that is, you can come close to the budget for your project as well as you will leave less mess for the future generations because of good designs.

Jonas: What do you need for Project Architecture?

Nagesh: When I have deployed Enterprise Architects onto projects, I made sure that they are not just designers or just Subject Matter Experts. They need to represent Enterprise Architecture. They need to help the project teams to think enterprise-wide. It can vary from buying a server that IT ops can support. Or, designing an adapter for systems integration through an existing EAI environment. Or, simply mentoring project teams about a technology standard that has been in place.

Jonas: Besides the Project Architecture, how do you get to the other ingredients of the EA?

Nagesh: If we say that the Project Architecture is about today’s investments, we can say that the as-is architecture is about past investments. Similarly, Technology Standards and Roadmaps are about future IT investments. We can’t really define future if we don’t have some idea about our past. It is like people who didn’t know that I majored in Electrical Engineering go ahead and create a roadmap for my career to become a heart surgeon. I have seen many architects putting some new technologies and cool gadgets on their roadmaps just because it looks good. We have to watch, as an Enterprise Architect, what we want to shove down someone’s throat.

One time, I have seen a roadmap for the DBA organization at one of my employers. They are heavy on Oracle and we have used an excellent consultant as our Architect to create this roadmap. With all the good intentions, this consultant suggested that we should standardize and deploy all our Oracle databases onto Sun’s Solaris hardware. Apparently, Oracle seems to have built code that is optimized for Sun’s platforms better than the others. But, the consultant missed one thing. This organization was heavily outsourced to IBM. So, operationally, I wouldn’t have anyone in IT Ops that knows how to build and maintain Sun’s hardware and operating system. On the other hand, everyone that needs to play along with this roadmap is from IBM – talk about a de-motivator. So, we need to watch the roadmaps that we put together. It is not about how cool we are going to make IT. It is about how we can make things better for collective-IT.

Jonas: There seems to be debate about the as-is; whether we need it or not. What are your thoughts and how do we create this as-is architecture?

Nagesh: I agree with you Jonas. In the last decade, we have seen several mistakes that have been made trying to build the as-is architecture. We have also learned few lessons while building the as-is architecture. Without much details, I can say that the as-is architecture is a requirement component but we should try to deploy the bare-minimum. We will always have time to come back and do more of it. But, even for doing the bare-minimum, we need funds and we can’t get monies just to enlighten the IT environment. Many organizations think they know what’s they have. To sell the as-is, we need couple of things.

One, the timing has to be right. There should be some movement happening elsewhere about the common infrastructure. Examples that fit the bill are Virtualization efforts in Data Centers, upgrade to an EAI environment, or changes to the DBA organization. Second, you need a tool to ensure that what you have captured can be documented and widely used by others.

When these two things are played correctly, building the as-is can be budgeted. The information collected from the as-is can be put into daily usage for decision making. One of the organizations where I have used this technique to implement a tool now uses the tool every day within the data centers for outage management and change management.

Jonas: Any tools that you want to suggest?

Nagesh: There are several tools out there. I have used Troux and did good work with it. Troux was easy on our Architects and it fits the way they think in their mind. I have also used Popkin. I have to see what IDS’s ARIS got. For the daily usage of tools, I would suggest to throw away PowerPoint. Get used to Excel and Visio. It start moving us from strategy to tactical.

Besides joking, one of the places that I worked, we created our own tool. Surprisingly, IT operations wanted to use an architectural tool that they purchased and they didn’t want to give away the ownership of Popkin to us. On top of that, they didn’t want to store anything more than servers and systems. We had to run around and get information from Popkin as well as lot more places. So, tools are important and knowing what we want to accomplish with them is more important.

Jonas: Then, how do you merge the as-is tool about the past with the Project Architecture where we are investing today? Do you create designs out of the tool?

Nagesh: Thanks for that question. It enlightens two of my objectives on the operational side of the Enterprise Architecture. One, in organizations where EA exists as a department, no project is built in isolation. Every project and system where money is being spent today requires to be integrated with systems that already exist. So, designing a new system requires the knowledge of existing systems. Since the as-is tool can help an Architect understand that, designs become more closer to the reality rather than just a simple Visio diagrams. My second objective is to maintain the quality of the designs across the Architects. In the absence of an as-is tool, I had to depend on the knowledge of my Architects or the network of their friends within the organization to get a good design out. If one of my Architects moves to a different part of the organization, I have ramp-up issues. The as-is tool reduces lots of those pains.

Jonas: When do you get to the Technology Standards and Roadmaps that define the future?

Nagesh: In my experience, this is the most complex thing to accomplish.

First, the political realities need to be understood and played very carefully. Any time the EA organization tries to set a standard, it has to be in sync with what’s happening in the IT Operations. Otherwise, the traditional rumor that “EA sits on an ivory tower” quickly becomes a hindrance to EA to define the future.

Second, the cost-model needs to be understood. If you are sitting in an outsourced organization, you probably have the future defined and handed over to you because the outsourcing vendor wants to put-in the technology that they are familiar with or that they sell.

Third, you need the necessary depth of technical expertise within the EA department. When we say that EA would recommend particular brand and model of a server, that recommendation should be backed with the necessary technical knowledge.

Lastly, EA needs to walk through these dangerous mines but most importantly it needs to watch itself not to become stagnated. What I mean by this is that EA should start producing standards and roadmaps as quickly as possible. Excuses won’t be too famous in the long run. Once again uninstall Power Point from your computer and start using Excel and Visio. You want to start working with people, not preach to them.

Jonas: What are you currently working on?

Nagesh: Right now I am working as the Chief Architect for a large effort in Smart Grid technologies. I am looking after bringing together several aspects – few that we are familiar with and few that are new for us. The challenge here is to think beyond traditional IT. Compared to the Enterprise Architecture that works with IT stuff like data-centers, legacy systems, and projects, the technologies in Smart Grid throw an extra wrench into the game. I feel like I am on the next-level of a video game. We now have components from the business side. We have new meters, new information from substations, and new updates to legacy systems that are more frequent than before. Large, huge data sets. Getting them all together and architecting things so that they respond to the customer’s electricity demands is a good and exciting challenge.

Jonas: That sounds exciting and I am sure you will have stories to tell after it is said and done. Thank you Nagesh for your suggestions. For the sake of listeners, if anyone has questions for Nagesh on their specific situations, you can send him an email at This e-mail address is being protected from spambots. You need JavaScript enabled to view it or visit Good luck with your cooking Nagesh.