Collaboration and innovation will take center stage at the ASUG Best Practices: CoE and EA conference later this month.
Attendees at this four-day joint event (April 18-21; at SAP Headquarters in Newtown Square, PA) will have the opportunity to connect with SAP customers and leaders within Center of Excellence (CoE) and Enterprise Architecture (EA) functions, both of which possess key capabilities for driving digital transformation and optimizing customer experiences across ASUG members’ organizations.
Uniquely positioned to speak to the importance of the enterprise architect role is Jason Porterfield, VP of EA for SAP North America. An industry veteran, Porterfield leads a team of customer-facing EAs for SAP North America, enabling the planning and delivery of large transformation projects. He describes his purpose as “to provide clarity and guidance to customers in their transformation journeys.”
Porterfield will be a strong presence throughout the event. On April 19, as the CoE conference winds down, he will participate in an interactive keynote discussion that explores the relationship between CoE and EA, detailing how these essential business areas can deliver value together. On April 20, kicking off the EA conference, Porterfield will provide another keynote address, “Making the Case for the Changing Role of the Enterprise Architect,” that will explore the EA’s changing position and business value within an organization. Finally, on April 21, Porterfield will lend insights to a closing “Ask the Experts” keynote, joining a panel of SAP professionals to address challenging situations that SAP customers face.
Throughout ASUG Best Practices: CoE and EA, Porterfield will discuss his work at SAP, the growing relevancy of the EA role, and his point of view on what skills contribute to success in the field. Below, he sat for an interview about key areas of interest and concern to ASUG members.
Question: The title of your keynote address is “Making the Case for the Changing Role of the Enterprise Architect.” In recent years, we’ve heard much about bridging the synergy gap between business and IT, about the importance of EA to every area of the enterprise. Why is this role so essential?
Answer: Architects within customers’ IT shops are not new. They’ve been around for a long time. What varies is how they're viewed, how their role is defined, and how they're used. Sometimes, they're the smartest person in the room, who’s been there the longest and knows all the systems in play. Sometimes, and I think this is a better fit for the role over time, they’re a strategic thinker who's trying to string it all together with a forward-looking view. And, sometimes, architects and our teams are viewed as the standards police, which is probably the least favorable view and value add of the role. If they're really doing their job right, they're communicating why standards are important and bringing people along on the journey versus just being an enforcement mechanism, which nobody likes.
Architects have to be a bit like ping-pong balls, bouncing back and forth between the two extremes of “lost in the weeds” and building an unattainably perfect “ivory tower” of systems and information flows. The ivory tower is not achievable, and getting too lost in the weeds means you lose sight of the larger business goals that somebody might be trying to achieve. You diminish your ability to be strategic if you’re always working down at the ninth level of hell. Even if you know what you're doing and somebody is needed, that shouldn't be the enterprise architect’s role. While there’s always a desire to rationalize and reduce the number of tech stacks and apps at major corporations, it's not just about reducing; it's about being smart about it and making sure you're not sacrificing any capabilities to do so.
I will come back to communicating the “why.” Why is this so important that we do this? Look at what happened at Southwest over the holidays. They had an antiquated piece of software that any architect worth their fighting weight would have said needed to be looked at a long time ago. And I bet you the number one reason it wasn't was because it worked, so why mess with it?
Q: If it’s not broken yet, we don’t have to fix it.
A: Exactly. I have a customer who calls out their quote system as the number one risk. When I asked why, they said, “Well, because we only have one person who knows how it works. It was custom-built. And there’s a betting pool on whether or not the heart attack or retirement is going to get him first.” That is the wrong way to manage your risk, folks, when it comes to your technology. It does mean that sometimes you have to go invest in systems that aren't broken or that appear to be working, because most people really don't have any idea that the only thing holding that system together are a couple of rubber bands and a piece of bubblegum.
Q: How do you plan to address the importance of the EA being seen as an evolving role within digital transformation? And do you see the role as substantially changed today from where it was, say, five years ago?
A: I think there’s a recognized importance of the role overall and of it being more strategic and business-oriented. And it’s not that it wasn’t. If you talk to a lot of people who work in IT shops at different companies, they know the business. They understand how it works. It’s amazing to me how often that is glossed over. “Oh, well, he's an IT guy. He doesn’t get the business.” He probably does. Whether he can communicate it in the same way as you is a different story. But I think that’s sometimes overlooked.
The EA has been evolving to be more of that bridge, that communicator, translating between the two. Again, the best ones can tell good stories, and they can help provide context on why the CFO or VP of sales should care about this or that. The “why” is what should help drive some of the investment, not just “we’re out of maintenance” or “we’re behind on patches.” It’s about demonstrating that the reason you need to invest in this upgrade is so we can get you the new capability that lets you get to this customer segment or drive costs of goods sold down another two points. That “why,” that context, is the number one topic that architects are getting better at communicating.
Q: Communication is such a key aspect of the EA role. When communicating value to C-suite executives or technical practitioners, how is that communication adjusted?
A: People are getting better at being able to adjust the message to different departments. If I go in front of a C-suite executive, I have a couple of slides that summarize the message and the ask. I’ve got all my backup if they want to see it. Given their schedules and how much is thrown at them, they’re paying my team and me to do a job, and they expect us to have done it. As you get into the lower ranks, they might really need to see the additional detail to be comfortable to do what they need to go execute and operationalize.
Q: You need to know your audience and the best way to reach them. As an EA, you need an extraordinary amount of situational awareness, that ability to read a room.
A: I’ve lost count of the number of times I’ve gotten in front of an executive, even with a small deck, and not gotten off the first slide. So, I’d better be ready, I’d better have the talking points, and I have to be able to make sure we can get their attention, so we can keep it for the time when we have it so that we can present and hopefully get the answer we're looking, whether that’s a decision to move forward or a decision to stop. Whatever the action is, we need that executive to take in support of what we're trying to do. We need to convince them, and we're going to have to do it with as little content as possible because it’s not going to work for the majority if you go in with 100 slides.
Some are going to want to see the strategy. Some are going to want to see numbers. You really have to know who it is you’re talking to and how they’re wired. Without fail, I will go with visuals and numbers over bullet points almost any day of the week to set the stage and drive the “why.” I’ll come back to bullet points when explaining, “Here’s what we’re asking to do.”
Q: At ASUG Best Practices: CoE and EA, you are also participating in a “fireside chat” about the relationship between the EA and the CoE. How do you see their connection related to the EA’s responsibility to connect different parts of the business?
A: At all our SAP events—whether it’s by ASUG, SAP Insider, ourselves, or some other partner or third party—we always advance a very heavy SAP view. SAP CoE, almost without fail, is tasked with shepherding the SAP environments: break/fix, change requests, projects, and managing the entire lifecycle of that environment. They may or may not have one or more CoEs on that team or a separate enterprise architect team. I think it's very important for that CoE to be tied into the overall enterprise architecture organization if it’s separate. Whether it's centralized or decentralized, they need to be plugged into where the company’s going, the role we play, and the processes or capabilities we provide.
There needs to be an understanding, easier said than done, of where SAP is and is not going to play at a particular company. As much as I’d love every one of our customers to be wall-to-wall SAP, none of them are. That’s okay. If a customer decides, “Hey, we've already gone a different route,” any SAP CoE should welcome the opportunity to earn the right to shift that to SAP. But, to do that, they’ve got to have the right relationships. They've got to lead with fact-based arguments, to be willing to earn it, to go through an internal bake-off of SAP versus somebody else. If a customer has an SAP-first strategy that says they have to prove SAP wrong, that’s great, but you can’t take that for granted. You have to continue to prove that you understand that and respect it. Otherwise, somebody will eventually rise up through some other part of the org who is hell-bent on taking you down and doing anything but SAP.
Collaboration is key to that—between the CoE and whatever the architecture organization at a customer’s company is: tight collaboration, strong relationships, and a mutual understanding of how we evaluate when we do need new capabilities. If they already own something from SAP, you should have to prove that it doesn't work. You already have the rights. If not, but SAP has the capability and you just don’t own it yet, they should immediately be on the list to be evaluated. But then you have to set the criteria. You have to be objective about it. The more entities you introduce to an end customer, the more your sprawl can get crazy with more customers and vendors. Managing that is important. How do you do that? What are those rules for how you do it? Will everybody hold hands and behave properly? A lot of that will come back to how the relationships have been established. Have they been maintained? Are people playing stupid political games and stabbing each other in the back? It’s absolutely critical that the CoE and the architect organization are aligned and collaborative in how they work.
Q: Enterprise architecture is a scarce skill set in strong demand. What are the skills required of the EA role, and how can organizations upskill their employees to take it on?
A: Internally, you groom people for it by getting them exposure and moving them around. If they're in IT, move them around, so they can see different systems in different parts of the business and understand how they work together. That is one of the best ways to do it. The other thing you have to consider and not lose sight of is the need for soft skills. The best architects have to be able to communicate. They have to be able to understand their audience. I joke that my organization of architects is like “The Big Bang Theory,” minus all the witty humor.
The reality is, I’ve got a couple of Sheldon Coopers on my team. They're brilliant, but sometimes we have to set them down and say, “You can’t say it that way. That is not going to work. You’re absolutely right: this is the only way to do it. But if you make them feel like they’re stupid, you’re screwed.” You need to build relationships with communication and storytelling skills. IT people pride themselves on their expertise and what they know, whether it's a language, a package, or the support of a particular part of the business in the company they work for. They're not unique in that. I would say a lot of people, in almost any role, pride themselves on the expertise they develop But if you can't turn around and communicate it, that’s a problem—especially in the enterprise architect role where you have bigger responsibilities.
Q: What recent industry trends are most relevant to the role of the EA today?
A: With companies getting out of the business of managing their own systems, whether they're buying software as true SaaS offerings or paying to host their systems in various private cloud models, almost every customer I talk to has some form of hybrid landscape. Security is key. No one wants to be in the news. Period. No matter what, there’s no such thing as an un-hackable system. If somebody wants in badly enough, they will find a way through a vulnerability in code or through social engineering. You have to understand security; you have to be able to communicate why this is important. You have to be able to make sure that you're building secure, you're running secure, and you're ingraining that attitude across your people's culture. In some industries, that’s more critical: the United States government, other various defense contractors, pharmaceuticals, healthcare, right. Some of the focuses there shift from security around information or the propriety of product data to security around customer or patient information.
I do believe sustainability is very important. We need to continue to drive that wherever we can. In technology, hardware needs electricity. Whether it’s coming from a coal plant, a nuclear plant, or solar or wind farms, the technology doesn’t care. Any reasonable person would say, “Yes, we should be greener.” I also don't see the overwhelming majority of the consumer base out there saying, “I’m okay if my Starbucks app is only up two hours a day, so I can order my coffee.” In some cases, some of the technology is not quite there yet. It’s hard.
Q: Given its centrality to connecting the business and IT sides of organizations, do you see enterprise architects as relevant to driving sustainability missions?
A: I see it now more than I previously did. It depends on the nature of the business they’re in. All the major oil and gas players are customers of ours. Internally, I’ve seen comments saying, “Should we be supporting these companies?” I would argue, “Why not? They’re investing a lot of money, trying to be greener, in alternative forms of energy, trying to lose their reliance on oil and gas to become energy companies.” That’s not going to happen overnight. The available capabilities from electric cars and batteries, and that whole supply chain, are nowhere near mature. But EAs are trying to move that forward. They know about it. They get it. But it will take time.
Q: Anything else, either specific to your journey at SAP or what you’re hearing from customers around EA, that you plan to share at the conference?
A: I’ve mentioned communication and storytelling. It’s not just about being a good presenter. You have to go back to “How do I craft the message?” I plan to talk about some of the tools and techniques you need to familiarize yourself with how to build good slides and how to choose visuals to communicate a particular message. Everybody always goes to “great executive presence,” that they can tell a story and it can own the room. But what is the process they went through to get to the four or five slides that support that fantastic presentation? How did they build that? That gets overlooked. I’m going to refer to different books by Nancy Duarte, [who wrote “slide:ology,”] and Dan Roam, who wrote “The Back of the Napkin,” to stress that EAs have to focus on this area. It’s not just about getting up in front of a room. It’s about crafting the story that’s on the screen behind you.