Tania Dobbins discusses what enterprise architects can expect when a large enterprise confronting multiple challenges undergoes a transformation effort.
Interview conducted by Bo Parker, Karen Schwartz, and Alan Morrison
Tannia Dobbins is an enterprise architect with Advanced Micro Devices (AMD). In this interview, Dobbins talks about what enterprise architects can expect when a large enterprise confronting multiple challenges undergoes a transformation effort.
PwC: What were AMD’s transformation plans to begin with, and where is it in its efforts?
TD: We began our most recent transformation efforts here not long after Ahmed [Ahmed Mahamoud, CIO of AMD since March 2008] joined us. We had a model—a governance framework from the corporate executive board—that we relied on for goals and objectives. Among other things, the goals covered business alignment, service and project demand management, and portfolio management from a project perspective. The goals also covered a delivery capability, sourcing strategy, role alignment—internally as well as with those of suppliers and providers—retooling, and retention. The process was pretty prescriptive in terms of metrics, dashboards, monitoring, and minimizing risk to the business during the transformation process, and there was general agreement that this was a target state, if you will.
To move us toward the target state, our CIO said some things that were spot on. Things like: We need transparency. We need visibility into everything we are doing. IT is a black box.
But at the end of the day, everybody had their day job and they were trying to do transformation at the same time. So while we might have had somebody writing the transformation program, there was limited bandwidth. That was one challenge.
Another challenge was that nobody could really say, “What do I do differently at the end of the day? I understand my to-be state, and I understand where we are today, but I don’t know what that means as far as me doing my job any differently tomorrow.” In other words, we were not very prescriptive in helping the frontline people to do their jobs differently.
PwC: The implicit framing seems to be IT transformation, as opposed to AMD transformation.
TD: I separate what our business does versus how IT works with the business. What I discuss stops short of transforming our organization in terms of our markets, things like that. That’s really completely on the business side of the spectrum. There is a whole group of people that does nothing but that. But I can shed some light on what the business does in automation.
When I look at IT holistically, the challenge is really transforming ourselves to better look across our portfolio, prioritize or reprioritize our spend, and reallocate our assets to meet the needs of the business.
PwC: What metrics have you been using for this effort?
TD: We realized the metrics we had been using were overly narrow and didn’t provide a broad enough enterprise view. So we embarked on an initiative to look at our corporate KPIs [key performance indicators] from the board on down, and we ended up reducing the number of KPIs from 49 to 15. Those now include KPIs like customer share of wallet, turnover asset ratio, and costs of goods sold, many of which are pretty standard financial metrics.
If those are the KPIs, then what are the levers that can have a positive impact on those KPIs? That sort of analysis led us to review the data we had available, and that review in turn led us to take a fresh look at our systems.
Fundamentally, the systems should enable business outcomes. If we embark on a project, we need to answer the questions: What is the business going to do differently tomorrow? How are we enabling the business capability that they need? If it’s all from a technical perspective and we don’t know how to talk in business terms, we won’t know how to tell them what the project means to revenue generation or to the ability to get to the market 30 days sooner with a product.
PwC: You can’t make that leap unless you make those kinds of connections.
TD: Exactly. The good part about all this is that our organization realizes that that’s a problem. We have yet to overlay the KPI strategy with the people, the processes, and the technology that needs to happen to enable it.
PwC: At some level, this is a learning and knowledge development task, isn’t it?
TD: Yes, very much so.
PwC: People need to understand the problem and figure out the best way to solve the problem. What tools can help with that?
TD: Like most organizations, we started with the easy stuff, which was the technology stack. We looked at the problem from an architecture perspective—the enterprise view—from the strategic intent of the organization, down through capabilities and functions, all the way down to the IT stack supporting everything above.
We are a Troux shop. We have a very straightforward mapping and asset management effort under way, and soon we will understand where we are with the life cycle road map, where the vendors are in our space, and what risks are associated with our asset base. So in the application portfolio area, we’ve made a lot of headway.
In terms of strategy-level projects, or the capabilities being delivered, we are trying to define capabilities in a systematic way. But if you have five people in a room, they are going to think of capabilities differently. One of the biggest challenges is having different tools for our business process modeling and our business mapping. These two systems don’t integrate. Fortunately, our CIO recently made the case to get rid of one of them. Why that’s important is now clearly understood, so now there is just work ahead of us to bring all this stuff together.
It’s very, very difficult to take a topic like an architecture strategy up to a level where the aha moment occurs, so that the stakeholders can buy into the overarching strategy of what you are trying to do without getting bogged down in the details to make it happen. The topic is complicated, and it hits every part of your organization. You cannot underestimate the importance of communicating the value proposition.
PwC: You said that you are using Troux and that you had made some good progress on the technology stack. Can you give us some specifics?
TD: Sure. For the most part, we have all the components of the Troux suite. Troux also has a product called Standards, which provides standard categories based on a technical reference model, which in turn provides a view of the asset life cycle across the categories.
We have pretty much built out our technical reference model, and we have teams standing up or that have stood up to take advantage of it. We now are in the process of defining our internal life cycle of all our IT assets. We can determine which assets should be retired, including the percentage that hadn’t been articulated before. I would say we are about halfway done.
The next piece is to understand what the manufacturers are doing with those life cycles. So we really need a good understanding of the target obsolescence for their products, and whether those are still preferred products on our end. We need to make sure our road maps include that information, so that we can eliminate unneeded assets. This effort is maturing, but the ageold challenge is to keep it current, so we will need to maintain good focus there.
Then there’s the application view and understanding our application portfolios. We have focused on ensuring that all our application portfolios are well understood, so we can eliminate duplication in those assets. We have been working with our contractual people to understand what we really need to purchase, what the terms and conditions on the contracts are, how many licenses we have, how do we buy them, and are there opportunities for consolidation—at least contractually, if not by eliminating duplicate capability entirely.
We may have 1,500 applications defined in our repository today. Our leadership now is really focused on understanding our shadow IT pieces of our application portfolio. So in enterprise transformation terms—not just IT—we can take a compelling case back to our CFO and say, “You have 18 tools across your entire organization that do the same thing.” We are trying to get to that view, trying to understand the shadow pieces and the cost information associated with them.
Another piece that we are starting to work on is really about the data. This piece relates directly to the KPIs I mentioned. As you know, we sold off our manufacturing component, we are standing up a global foundry company, and AMD will become purely a design company. So huge efforts are under way right now to understand the interactions among companies. Our portal strategy is an example—how do work requests get to our foundry company, and things of that nature.
From an architectural perspective, we’re obviously concerned with what data do we have, what data do they have, what needs to be cleansed in our systems and their systems. That picture is being put together in the repository. As I mentioned, we can’t get the data on the business process side out of the tool, so we decided to eliminate that tool and replatform it.
PwC: Have you thought about what tools might be useful to tackle some of those issues?
TD: Well, from a road-map perspective for projects, alignment of capability, and the like, Troux will be our front door—from the strategies all the way down to adherence to policy—in our dashboards and things like that. In terms of a day-to-day project portfolio perspective, we are going to use Clarity [CA Clarity PPM for IT Governance]. This tool will provide a view of resources, the time-tracking components related to those resources, and skills. This view will help us realize, for example, that I can’t launch all five projects on this day, or if we slip one project a month, can we get more throughput? So we are looking at Clarity for that piece.
PwC: That’s the more comprehensive program management function.
TD: Yes. Program management from a project program portfolio. Then there is another initiative that I’m kneedeep in, which is all about our services portfolio. Spending levels here are very important, so one objective is to understand the minimum we need to keep our environment healthy, and yet be able to redeploy our resources to provide a new capability to the business.
So, we are now redefining those services. This is the part of the transformation where we talk about the business side. From the business side, IT is a cost center, so we have to address the question: why does IT keep costing so much? If we redefine our services in business terms and let the business side know it’s in their hands what to purchase from IT, we can talk about their objectives and resources. We can ask them, “Do you really want to close at the end of the year? That’s probably important to you, so you probably need SAP Financials, and hence here is the cost to you to close the books.” We are really trying to rewicker all that, and there are tools out there that do that.
PwC: Overall, what have been the key barriers to creating more value from transformation efforts at AMD?
TD: We talk about transformation at AMD holistically. On the journey we took during the last couple of years, we purchased ATI, the graphics processor [or GPU] company. We committed to the notion of an integrated board, in which you have a CPU [central processing unit], the GPU, and then the channels, and all of that has to come together on one board. Talk about transformation—we had to look at our engineering processes down to the nanometer. ATI had a foundry co-model, and we had a manufacturing model, and because ATI was very successful with its foundry model, we decided to go in that direction. So, if we talk about key barriers and the pace of change, for that journey it’s been from A to Z. But that’s another story.