Episode 14 – EA strategy and capabilities

EA strategy development is not done very often, but has many benefits. In this episode of the podcast, we are talking with Carlisle Gunn, an experienced Enterprise Architect, who we’ve worked with on past projects.

Carlisle has worked in the Enterprise Architecture space for over 8 years with a focus on business and application architecture. He led teams through process discovery into documentation and improvement. Working with team members from a wide array of roles, his background demonstrates experience working with almost every type of functional member within an organization.

Carlisle received a Masters of Professional Studies in Enterprise Architecture in 2016, where his focus was on the establishment of Enterprise Architecture capabilities and usage of modeling languages.

We are talking about the following topics:

• Carlisle’s background (and some rugby geekery)
• EA strategies and that they need to be client-specific
• Stakeholders and the Enterprise Architect view (top-down) vs. the Solution Architect perspective (bottom-up)
• ARB /= implemented EA strategy
• Components of an EA strategy
  • Start with maturity assessment > identify low-hanging fruit
  • Communication is part of the “how”; EA strategy is the “what”
  • EA goals and how to measure EA KPIs
  • EA capabilities and services

Carlisle can be reached at carlisle.gunn@trace3.com and via LinkedIn here: https://www.linkedin.com/in/carlislegunn/. via LinkedIn here:

Please reach out to us by either sending an email to hello@whatsyourbaseline.com or leaving us a voice message by clicking here.

Additional information

• The process to create an EA strategy in an overview

• The 2×2 matrix of architect archetypes is discussed in this article: https://www.whatsyourbaseline.com/2022/01/the-changing-role-of-architects/

Credits

Music by Jeremy Voltz, www.jeremyvoltzmusic.com

• CP1 (Welcome)
• Be Loved In Return (Interlude 1)
• With You Knew Me (Interlude 2)
• South Wing (Outro)

---

Transcript

(The transcript is auto-generated and was slightly edited for clarity)

Roland: Hey, J-M, how are you doing today?

J-M: I’m doing great! You know, today is my birthday. I’m excited to be recording today and celebrating the things we really love, as I grow older in time!

Roland: Well, congratulations, you know. On the other side, I brought a guest to the party. I don’t know if you’ve noticed it. So we have one of my old friends, Carlisle Gunn, on our show today, and as a little trivia, he has a Masters degree in Enterprise Architecture, which, when I started working with him, I didn’t know that even existed. So welcome Carlisle.Welcome to the show. 

Carlisle: Thanks, Roland. Glad to be here and talk about a degree that’s borderline useless nowadays, but it’s fun.

J-M: Borderline useless? When I went to university, we didn’t have degrees in Enterprise Architecture. I remember the closest thing I was able to get in engineering was focused on process engineering / process improvement. We called it Industrial Engineering. No enterprise architecture. Tell me about that degree – how did you find an institution that was offering it, and what did it have?

Carlisle: So there were two universities offering it when I was looking into it. The first was Kent State and the second was Penn State, where I ended up going because of name recognition. Penn State had just started the offering – it was very new and it was definitely an interesting journey. My thesis was on outsourcing, offshoring and backsourcing, but it wasn’t a published thesis or anything – it was just interviewing some coworkers about what they thought.

Roland: That sounds interesting, Carlisle, but before we get into the meat of the conversation, talk a little bit about yourself. Who are you (besides the fact we know you have a master’s in Enterprise Architecture).

Carlisle: I am Carlisle Gunn, originally out of Alexander City, Alabama, which is a very small mill town that is now more of a lake town. It’s the birthplace of Russell Athletic, which is a very old textile company.

J-M: And you got out of there right quick and made your fortunes in Colorado?

Carlisle: Right! So after I graduated from the University of Alabama, my major was Management Information Systems; I only looked for jobs in Colorado because this is where I wanted to be for the rest of my life. I decided that when I was 12. A very hard decision-maker right there. Moving away from a hot and humid place – I had been around the mountains, and I was like “The Mountains are for me”. So I got a job with Verizon Enterprise (not the fun Wireless Side, who was getting all the money and being cool) as a college hire enterprise architect. So my very first job was being an enterprise architect, and I lept in. I learned as much as I could as fast as I could, but I learned in the end that we were mostly solutions architects. On the side we were enterprise architects. Your day-to-day, you’re not trying to rework your whole organization – you’re just trying to help people get from A to B. Got the master’s while I was at Verizon, then Roland hired me to KMPG as an Enterprise Architecture consultant. We did that for, how long, Roland?

Roland: 2 years? 3 years? It was all downhill for you from there.

Carlisle: I didn’t even make it two years before I decided to jump – some fun politics. I worked on just a couple enterprise architecture projects while I was there. The rest was management consulting.

J-M: And now you’re at Trace3!

Carlisle: Yes, because Trace3 is a very interesting company. They are traditionally a value-added reseller, so they’re out there slinging hardware and software. But then they said “Hey, we need to figure out how to offer services, because we need to connect all this, and there’s a value proposition in connecting our software to our hardware to services and an overall strategy”. So they started having that bigger vision and they built up the management consulting practice which I have been a part of. But I’m now transitioning away to become a principal consultant for our financial services group.

Roland: Well, Carlisle, that sounds interesting. But maybe we go a little into the past – how did you discover the EA discipline, and what made it interesting for you to do this kind of work? And, of course, you mentioned your master’s degree, but what kind of training was required to get started with this?

Carlisle: The great part about being a college hire enterprise architect is that it was just my undergrad program which had what they called a capstone, so we actually worked for companies for “scholarships”. A company would pay $10,000 to have 5 undergrads and one master’s student working on projects. So I pretty much got the job by just talking about how IT supports business – that was my major talking point. Hammering in the fact that IT is just a supporting factor in the business to make money – your IT should never be detrimental to you. That resonated with my boss, who is an awesome person.

J-M: So it seems like a lot of this was on-the-job training, coming from an engineering mindset combined with circumstances at a client that would allow you to explore and use that analytical and structural-based thinking, right?

Carlisle: Right. They leveraged me pretty nicely into what they needed, and that was my A-to-B day-to-day existence for a while, but then training me about how to think about things from an organizational standpoint instead of just thinking about the day-to-day.

J-M: That’s cool, then my next ask is for you to tell me about some of your specific experiences. Your favorite or most infamous experiences and project experiences you’ve had so far in your discipline.

Carlisle: I think my favorite experience was being stuck in the middle of Pennsylvania with Roland, working for a client where we didn’t actually have a stakeholder. We were making Enterprise Architecture in a vacuum. So there was just one guy who knew nothing who was approving all our deliverables. Roland would sit him down and just hold out the deliverable and explain to him what it was, walking him through it. He’d be like “mhmm, mhmm”, and I remember just watching this man nod and nod and watching Roland speak and speak. He had no idea what was happening.

Roland: That is true, but he was the lead architect for that organization, which is kind of sad…

J-M: So they absolutely needed you, otherwise the lights would be on with nobody home.

Roland: Well, the interesting thing is they also ran out of budget – the project ended for us as planned, and the reasoning behind that was: “yeah, we’re going to hire that person and you whatever train him or do some introductions on the job. And then he takes over and he builds that EA team.” And then we rolled off, and literally the Tuesday after we rolled off they fired him, which is a little bit sad. 

J-M: Oh No! All the work you’ve done! I feel like this is one of the things we talk a lot about in the podcast – sustainment. You can’t just leave it with an individual; you need to leave collateral, organizational knowledge, and a practice that can be picked up. And when you have the ‘no-stakeholder’ or ‘single-threaded’ conversation happening, boy, you’re putting all your money on that one horse. What if they don’t come in first.

Roland: Which we did – we left deliverables behind, but that wasn’t the point. But before we get into this, Carlisle, tell us a little bit about you as a person – what are your hobbies, interests and bucket list items?

Carlisle: Let’s see, so I would say my primary hobbies are skiing and snowboarding, as well as camping and hiking. I used to play paintball semi-professionally and game semi-professionally, and then I played rugby and was definitely NOT semi-professional – I was very bad. Nowadays I’m a little too broken off to play rugby, so I stick to skiing, hiking, and camping.

J-M: What position did you play in Rugby? What number?

Carlisle: I was 7 – the lock.

J-M: I see, I see. I was a 3, because that’s my size. 

Carlisle: I’m not big enough to be a prop and not small enough to be a hooker, so here we are.

J-M: Someday I’ll organize a little pickup rugby when we all go to Colorado and retire there.

Carlisle: It might have to be a game of touch at this point in my life, if I’m being honest. 

J-M: Well, this is some fantastic information, you sound like a really interesting person, and we’re excited to be chatting with you today. And in particular, chatting about EA strategy and capabilities. So Roland, why don’t you take us into the first part of our interview and conversation, all about the “Why”.

Roland: Yeah, happy to do so. So Carlisle, as you and I discussed before, obviously the question is, should an organization develop an EA strategy? I’m not only talking about a document, and as you mentioned before, we’ve done that before. What would be a good example of an EA strategy that you have?

Carlisle: So with the EA strategy, I’ve seen quite a few approaches of how people want to entertain that idea, but what I go down to at the end of the day is your EA strategy should be very home grown (in my opinion). You can take bits from here and there and put them together, but the benefits of bringing it all together is that you have that direction (or North Star, which is a fun term used by organizations). Something to drive towards / lead everyone towards, and something to drive the true value of Enterprise Architecture, which I think is a struggle sometimes. It’s hard to prove that hard dollar figure around Enterprise Architecture.

Roland: So if you don’t go that homegrown route, what do you see organizations doing? Because I haven’t seen a shop on Etsy that sells EA strategy documents.

J-M: Not yet, Roland, but What’s Your Baseline is only in our first season, so…

Carlisle: You want to start canning EA strategies? Let’s see about that. I think TOGAF already tried to do it, and they made it a very wide can. So starting from scratch is something that’s very rare nowadays. You and I have only seen a few of those. So when you don’t have a homegrown architecture and you start to really define it on your own, I think that there’s a lot of different disciplines that you can start with. My personal favorite is growing from solutions architecture upwards. So if you’re sitting there and you’re creating these one-off solutions for individual problems, sooner or later you’re going to start running into the same problems over and over again and start being able to reuse your existing solutions – if you’ve captured them properly. And this is the start of your Enterprise Architecture group / process / collateral, whatever you want to call it. But I think that one thing that Roland has always hit on very heavily is the need for a repository to hold that information and be able to relate back to it consistently.

J-M: Yeah, the interrelation of things relies on the creation and dissemination of those things. And you have to have some capacity to tie to those things; otherwise they’ll become islands. And in being islands, they’ll go somewhere to die. 

Carlisle: Right, and that’s when we talk about having a centralized enterprise architecture group or architecture strategy in general.

Roland: So when you start developing this, who do you involve in those conversations? Who are your stakeholders?

Carlisle: So with the stakeholders, a lot of times you end up being at a much lower level, right? So building from the ground up instead of starting with these executives, which is typically what people think about top down.  I really love to make fun of enterprise architectures commonly being an ivory tower. And so that’s when you have that top-down ‘everyone consume what I do believe in me’ kind of mentality versus the solutions architecture approach that I like to pitch is more so directly on the ground that the engineers directly on the ground with the people working the processes and what they need, and then trying to enable them from the bottom and move up from there. 

J-M: Right, but how do you get that done if you don’t have that ‘mandate’? One of the things we talk about a lot is that for change management you need to have accountability. And often times, executive alignment and support is how you achieve that accountability. Without that, people can do whatever the heck they want – there’s no consequences.

Carlisle: Right, and I think that, to your last point, sponsorship is always going to be one of the most important things. Sponsorship still has to be there, right? But I think that necessity is the mother of invention, and that’s when you start seeing Enterprise Architecture come from a grass-roots place.

Roland: So Carlisle, when I look at the implementation of EA strategies, I see the phenomenon of people equating EA to the ARB – the committee of “No” that we’ve spoken about in this podcast ad nauseum. Is that your observation as well?

Carlisle: Oh yeah; I love it, because anytime you ask “do you have an architecture group”, they say “yeah, we’ve got an ARB”. So then you talk to them about it, and it’s either head-nodding or someone making life really hard, which is where you get that “office of NO”.

Roland: If you were the master of the world, what would be your recommendations to resolve these situations?

Carlisle: The way the world has changed so much in that now, DevOps is this big thing, right? So everything has to move faster. So if you’re the gate ,you’re not providing value. So where I see it as the ARB needs to be fully ready to have things loaded and ready about here’s how you can get to the point we need you to be at. Here’s what we can do to support you. Here’s documentation that has been previously used. Instead of saying “you need to stop right now and figure this out”.

J-M: So you’re saying they should operate as a “guideline creator”, and then people can follow those guidelines as they move quickly. Rather than being a stop sign, you’re kind of like a seatbelt.

Carlisle: Right, right. I’ve been on too many calls where people were like: “you can’t move forward until you figure this out”. And their stakeholders are like, “why did I ever come to you guys, just so you can tell me no? You’re not helping anything, you’re just making my life worse”. So where I try to put in architecture review boards nowadays, or councils (whatever the term that people like to use) is that I make sure that they’re fully prepared to be locked and loaded, ready to go and supporting the organization, providing the value and not being that gate in a DevOps pipeline. When today you’re asking people to rip through and deploy, have multiple deployments in a day, you can’t do that if you’re sitting there just trying to walk everything through a board, trying to get on to their weekly meeting. 

Roland: Which is interesting because that has an impact on your EA strategy. How do you set ‌goals for an EA organization? That also brings up the question: how do you incentivize people if you don’t have the committee of NO? So, dear listeners, let’s take a quick break and I have a couple of questions for you. So, for example, where do you interact with your EA strategy, assuming you have one, and how does it influence your design activities that you do? What information do you provide or require from your users and how is that information communicated? Where is that working? Does it break down? Is it leading to a better result? So we’re going to leave you alone for a couple of seconds, play some nice music and you can think about it. And remember, don’t take notes while you’re driving and we’re going to be back in a few. 

Musical Interlude; “Be Loved In Return”, Jeremy Voltz

J-M: Alright folks, well thank you so much for taking a couple of seconds to think about how you might be involved in EA strategy and design. But now with our guest and expert Mr. Carlisle, let’s get moving. Talk about the how. So Carlisle, tell me more about the components of an EA strategy. Where do you start, and how do we build from there?

Carlisle: Well, where we typically like to start is with a maturity assessment. This really depends on whether if you’re starting green-field. If you have nothing, of course you don’t need the maturity assessment as much, but you’re still putting that line in the sand – that starting position. So you have to realize where you are before you can get going – what your true value is going to be. Step 2 is setting the goal. What is that North Star that you want to drive towards? And picking: “this is what we’re going to get done, this is what are value will be, this is what we’ve been tasked to do”.

Roland: Which is a very interesting question which I think is outside of this podcast episode. Like how do you measure success and what is an industry-acknowledged value creation KPI model for EA, because I don’t think that exists.

J-M: That’s a good question to ask, and hopefully one we can answer to prove the value of the groups we’re working with and the efforts we go to. And as you were talking, Carlisle, I thought that perhaps the first question you might ask would be… What’s Your Baseline? Pitch for the podcast and website… 🙂

Roland: So say you did your maturity assessment right, and obviously the results can vary. You can have a very formal structure being set up and defined artifacts and a repository in place, and everything is nice and tidy up to a point where there is nothing of that. There are no governance processes being defined. There’s no repository. There are no standardized artifacts or whatever, so there’s a full bandwidth there. You come to a conclusion to say, OK, we have maturity level – whatever 1 or 2. How do you take this and then say, OK; I bring to paper a strategy that will allow us to grow from the current as-is maturity level to a higher maturity level. Maybe in a year or two or three from there. So what would you look at to get started? 

Carlisle: When you’ve got an organization reading in at that 1 or 2 (maturity level), and you’re already acknowledging that we need to make growth, it’s then that you really start to set the strategic objectives you need to meet. At the same time, those should be aligned to your stakeholder needs. And then from that, you define clear objectives that “this is what we need to support the business”

Roland: Can you give an example where you’ve seen that in the past – those three areas?

Carlisle: So with an IT strategy, everything should roll downwards, right? So you should have your entire organization aligned upwards to those objectives and be supporting those. If you do not have an IT strategy, I would first suggest you get one of those. But otherwise, you can start thinking about what is the easy low hanging fruit that you can support and drive value towards. I think that if you’re really in that 1 or 2 area, what we’ll see a lot of times is the fact that you’re just once again having an ARB. And that’s about all you have. Maybe you’ve got the repository, maybe you don’t, but that’s the thing you should start driving towards, is reusable standards that people can take and leverage and say ‘thank you’ for. And just talking and spreading the good word of your architectural, reusability and your process simplification or optimization.

J-M: Yeah, that sounds like a really important part of the puzzle is communication, because as much as what you’re doing is strategic and it’s structural and it provides capabilities to other groups, those die on the vine if no one knows about them and if no one believes in them. So I can assume that Change Management is part of this conversation – being able to evangelize and being able to earn buy-in and work collaboratively to serve needs. Am I right here?

Carlisle: Definitely, definitely. I mean, we can harken back to mine in Roland’s little engagement that we had fun on. EA in a vacuum is the right term, right? 

Roland: I think Org Change Management is important, yes, but it’s the ‘how’ that comes in the second phase. I think that the EA strategy is defining the ‘what’, and the first step is to identify the stakeholders. Because people think EA = the ARB, but that’s too short. Once you find out people’s needs and objectives, and you can derive your EA objectives from that, you’ve got a great start. You also need to think about what you’re going to put in place, and speaking of that, Carlisle, what is the next step once you’ve figured out what the objectives are?

Carlisle: So once you’ve created your capabilities, this goes back to being able to measure it. And so with that, nowadays as a consultant, everything has to be visible. If you walk out of an organization without anyone seeing what you did, you’ve essentially done nothing. It’s both sad and true, but that’s where we are. So the KPIs help you prove what you’ve accomplished, show your value to the organization, and keep you funded.

Roland: That sounds lofty – can you give some tangible examples of how you would measure the KPIs, or which KPIs to choose?

Carlisle: Yeah. The KPIs that I prefer to go after are typically around process. So it’s process improvement of getting projects from A to B faster and faster. The issue with enterprise architecture, since it doesn’t exist on its own, in a vacuum, any sort of standalone, everything should be intertwined. If you’re not intertwined, you’re going to fail. But people can take your value and put it towards themselves. So if you start putting in all these great processes to enhance the DevOps pipeline to, in general, just speed up any sort of process in general. It’s like that organization that you ‘ve worked with typically takes the value and puts it on their paper. So you have to actually capture it beforehand to say,’ Hey, we went after this, Hey, we were the catalyst for this driver, et cetera’, because if you don’t, it’s their paper, they own it.

Roland: Which brings me to something we spoke about in a previous episode – the various roles of architects. You might recall the 2×2 matrix with degree of specialization and involvement, and there are obviously two quadrants where you see the architects as part of the strategy group to define the “what”, then enterprise architects being the transformation agent defining the “how”. “How do we get there?”. And I think most ‌EA groups just don’t do that because they understand that they’re part of IT and just have to deliver – cables, boxes, etc.

Carlisle: I once interviewed with a company. And so I got in there and I started talking about my enterprise architecture experience and asked, “what do you do about APIs?”. He said “a majority of what we do is make sure that people are following our API standards.” I was like, “as an enterprise architect that’s your primary job is to review APIs and integrations?.” And I was immediately just like, I need to leave this place right now.

J-M: Yeah, they’re not interviewing for the position you want, or should be there. And I think, Roland, you’ve been quietly pitching (with reference to graphics) the website. Remember, folks, that a lot of the things we talk about on the podcast become graphics that you’ll see at whatsyourbaseline.com under the episodes. For today’s, I know we’ll be publishing something about architecture strategy development with the different boxes we talked about. So not only do you not need to take notes, but we’ll give you a handy guide after the fact that will let you take this knowledge and actually put it into practice with a little bit of guiderails to get you there. So the next question I have for you, and this is going to be an important one – I know some of my clients are actually asking about this right now, is when we take a look at capabilities and capability hierarchies and we connect them into processes and our business architecture, how do you make that connection? What levels do you make that connection and how do you leverage that for reporting and analysis which you’ve been talking about before? 

Roland: I would look to see what capabilities the EA group needs to develop. It’s not the capabilities of the organization – e.g., how am I able to write an invoice to a client. That’s not what we need. What we need is to ask “what are the capabilities the organization needs to build to be able to run an EA group”?

J-M: I’m thinking about this as a service architecture or a capability hierarchy. 

Roland: That comes next, because in my mind, services are capabilities with an SLA attached.

Carlisle: Yeah, but I mean, no one’s going to create a hole for you. It’s the same with any organization. You have to, you have to find your place. And there has to be that need that you’re fulfilling. It’s not a capability you’re fixing something. I mean, they’re not going to support you and create this pedestal for you. You have to solve a problem. That’s why enterprise architecture is created.

Roland: But if you take it a step back, you will see, oh, you build up certain capabilities. That you then can transform into services to say, “Yep; I do have whatever dashboarding service I do have an integration service. I do have an analysis service for you.” Or you build up process mining capabilities because you want to have a data driven as-is analysis of your processes. So these things. So I think in the strategy document you should have a section talking about capabilities. What do we need to build? What should we be able to do? And then, based on that, you prioritize and derive your products and services, that you hold the EA group accountable for.

J-M: Alright, so Carlisle, tell me a little bit more about the idea of your organization’s capabilities. Your enterprise architecture organization. What do you need to build up to give yourself the ability to execute on it, and resilience to get through challenges presented by the business?

Carlisle: And I think that coming in at a ground level and defining those base capabilities, it should be very simplistic. So you’re going to say that we need an ‘X’ process. We need an ‘X’ repository. We need a council, so to say. We need to start making this visible. We need to put down on paper the things that we can help with. I think that I should apologize to your listeners, because everything I talk about is at a high level, which is the same as what TOGAF does. Because until you’re in an organization and truly staring at each individual process and their organizational needs, it’s going to be high level because EA should be something that is customized to a certain client.

Roland: So if I understand you correctly, Carlisle, you would have for example, a situation where a system implementation is struggling because you have a bunch of techies trying to configure the tool without the context of an underlying process. What will the user do? So if I take this and transfer this, you would need your EA to build up a capability to capture processes to provide that context so that in the next project you have this as part of your development process. And you build up that capability of capturing a process as a part of developing your business blueprint. Is that right?

Carlisle: Yes. And I think that if we should dive in, Roland, and start thinking more into examples. So let’s take an ERP. A lot of times when organizations implement an ERP, they’re just trying to get it stood up. So you have these SAP implementers come in, and they DO configure it to what you’re asking for. But the thing is that most organizations don’t know what to ask for because you do an ERP implementation once every 20 years, maybe. Maybe 10, if you’re trying to be cutting edge, but really you should just be keeping it up to date instead. So your drive in that ERP implementation should be the same as another implementation of a smaller tool. What is the end goal? What do I need it to do? And how do we provide business value? So it’s very simplistic in how you approach it, but your goals should be written out and clearly defined so that you can follow through and you can call it truly done or successful at X or Y points.

Roland: That makes sense, and then you can take a step back and abstract it. What have I done in this project? What is the capability that I have? And then I think the next step is to package it to say, OK, we take our capability that we’ve seen and then we package it as services to the organization. How does that happen? How have you seen organizations do that? 

Carlisle: They typically don’t.

Roland: Well, that’s a quick answer.

J-M: That’s quite the Eeyore EA!

Roland: Well, then, let me rephrase that. In a wonderful world, now you’ve mapped out your capabilities. In my little example, you have the capability to capture processes as a means of getting the context of a system implementation. What would be a service derived from that?

Carlisle: So let’s just take the overall outcomes that you’re trying to get. So at the ERP we need to. Timesheet capabilities. We need to support expense reports and let’s throw in manufacturing processes for funsies, right? So when we write this down as the next services and packaging them up, what we’re looking for is that overall goal that can be reused, that agnostic goal. So what is the true value of the manual manufacturing process being implemented? Well, we’re looking at a 10% reduction in supply chain costs, or we’re looking at a 5% increase in manufacturing time, et cetera. So when we take these goals with the manufacturing process, with the overall supply chain, et cetera, how do we make those goals agnostic? Well, we start looking at them and reviewing the fact that we originally thought we would get 10%, but we only got 7% or we originally thought we were going to get 5% and we got 10%. So that helps you kind of go forward in a service of goal setting. So everything becomes iterative inside of your enterprise architecture practice. And that’s how we should view the world nowadays; everything should be incrementally improved. You should never call it something done unless you truly believe it’s perfect. I think that that becomes a variable thing for some people. I think that Roland’s ideal perfect scenario has a lot higher quality than mine.

J-M: Roland Woldt, the Master of quality. The question is: you’re trying to build it in an EA strategy and you’re trying to build documentation. You’re going to build processes. How do you know that those processes are ready for primetime? ‘Cause you’re not looking for perfect, you’re looking for good enough.

Roland: Your internal processes, like how you run your EA shop.

J-M: Exactly. How do you know that those are ready to go? What stakeholders need to sign off on them? What sort of work do you need to have seen done and what markers can you look at too, if you’re an architect that says: “OK, I think I’m ready to show the community what my requirements are, what my practices that I’m pushing are.” And they’ll be able to consume them and use them effectively. 

Roland: I would do this agile. I wouldn’t create, as we did in that project, that Carlisle mentioned, a Word document. I would put it on a Wiki. You know, a Confluence, a Notion or whatever, and then say: “OK, this is our first shot and this is what we’re going to do and we’re going to try it. And if it doesn’t work, we’re going to change it.”

J-M: Where do you find the challenge between iterative design (as in, releasing information early before you’ve had a chance to fully validate it) vs. the authoritative design (when we say something, it’s coming from a place of knowledge, a place of experience. You should follow what we do.). How do you balance that?

Carlisle: So, this is where it gets difficult because enterprise architecture as a whole is you sticking your hand into other people’s buckets and trying not to get bit. Bit, pinched, whatever whatever’s in the bucket, right? You want to stay away from having that issue come up. And when you get into engineering or application development, moving their cheese, right? You’ve got a high chance of getting bit. So that’s where it starts to become more collaborative. So it’s when you both agree that it’s ready to go forth or ready to be presented to a team and start being pushed, you know, iteratively improved.

Roland: So thank you, Carlisle, for the steps we discussed in creating an architecture strategy. Just to summarize what we’ve discussed: the first thing would be to figure out who your stakeholders are. And then you evaluate what their needs are. Who are they, what are their needs, and what are their objectives. And that is obviously more than just the IT group. And then you would derive the objectives for the EA group. Where do we want to improve, what do we have to bring to the table, and how do we get better? And then based on that, you would go and look at ideally a KPI reference model if you have that. Or, as Carlisle said, you could take the bottom-up approach where you would derive the capabilities from your experience, and then package them as services. The last thing would be to define what success is. What are the KPIs that you measure? That’s an iterative thing. My question to you, Carlisle, is what have you seen as KPIs? Do you agree with my assumption that KPIs are the hardest part of the strategy development process?

Carlisle: I a hundred percent agree with you on that. In terms of the KPIs that we’ve previously created, it once again goes back to that process improvement more so than anything else. Cause that’s the easiest thing to prove. I mean, if you tell someone to build their application better and start giving them more fundamental architectures they should be following, it’s hard for you to stand up in front of an executive and be like, “I told him to use this better architecture, that’s my doing”, right? You’re going to be sitting out there looking like an idiot. So where we see the true KPIs that you can measure are those process improvements, process simplifications. So if you look at your business and really look at their fundamental processes, or a lot of times ITSM processes is where I ended up finding a lot of success, simplifying those, making those clicks go down, making the handle time go down, then that’s where you can find easy value.

Roland: So that is all business architecture. Have you seen some KPIs in the more technical areas? If you try to sell standardization or reduction of apps? Or is that an IT pipe dream that nobody cares about?

Carlisle: No, I think that what you see is just more so in the standards portion of it which is this year, we have defined the configurations that can be used by our organization for Linux, Mac, windows, et cetera, for your servers, whatever you need.

J-M: Interesting, and I wanted to talk about this because it comes up a lot. How much are you talking about KPIs when it comes to measurable, specific, numerical stuff vs. how much can you talk about goal achievement or KPIs that don’t necessarily have a number tied to them. We can tell that we have improved our operations – the way our teams communicate, but that’s difficult to measure. Where do you take that and try to quantify it, or do you? How do you prove that value has been achieved?

Carlisle: It also depends on what you view as your value add or your KPIs that you’ve given. I’ve seen organizations essentially say that, hey, we talked on 10 different calls. That was a great metric for us. And so, in terms of KPIs, they are what you set them as, but the ones that find value are typically saying we did X for standardization, we did Y for process.

Roland: So Carlisle, that is interesting, because I have also seen the situation where people just shrug their shoulders and say “meh, I don’t care about the x% higher reusability of applications or that we reduced our apps by so and so”. Most clients I’ve seen just look at the degree of budget I can free up so that I don’t spend 85 or 90% of my IT budget just to keep the lights on but have a higher percentage of doing some innovation in that field.

Carlisle: Everything has to drive back to a dollar, right? And one thing that you brought up that I hadn’t hit on yet was the fact that application rationalization is one of our biggest moneymakers in terms of enterprise architecture. It’s something that is quantifiable very easily. You can show what each app is costing if you’re tracking it correctly. And then what does turning off A, B and C provide you in terms of budgetary free-up. Right?

J-M: Yeah, but it can’t all be application rationalization. That is an end to the execution of the EA strategy, but it isn’t the only goal. It can’t be, otherwise you’d be spending all your time paring down and paring down the company and missing a lot of the components that would allow you to build it.

Roland: Simplification is the keyword here, right? You try to get clarity in what the organization is supposed to do, and you try to minimize the degree of complexity that you might have built in your technology versus satisfying whatever egos of people who have said “I want to have THIS tool”.

J-M: Well, we’re getting to a good point where we can cap off the thoughts we’ve brought up today, but I think this is an ongoing conversation. The key thing I’ve learned from this podcast is that we aren’t settled as one global approach. Carlisle, you started the podcast off by saying “this is going to be a high level discussion, but your circumstances are going to drive the actual execution. Your organization, the way in which you work, the things you need to have are going to help it hone into what’s going to provide the most value to you”. So we’re going to leave you, our listeners, with a question specifically about that. 

Tell me about your organization and the architecture strategies you’ve seen, implemented. What components of what we’ve talked about have you found valuable? Which ones are still struggling to be implemented or not giving you what you need? Most importantly: if you could flip a switch tomorrow and have things changed, what would you change? And how can you, today, help enable the creation and execution of those pieces of our EA strategy and capabilities? We’ll leave you for a second to think about that, then we’ll be back with our conclusions and thoughts about the next show.

Musical Interlude: “Wish You Knew Me”, Jeremy Voltz

Roland: Welcome back. So in the last 45 minutes or so we spoke about the challenges and the task to create an EA strategy, right? What is an EA strategy? Should it be that big document that maybe nobody reads that doesn’t even make sense to write any strategy? But I think we agreed on that. It’s helpful to have something brought down that shows the objectives, that shows the KPIs; that shows the capabilities and services that an EA group can bring to the table with all the complexity of how to develop those either bottom up or you take some reference stuff. Or you look at maturity assessment as a baseline. I also think we all agreed on the KPIs being the biggest problem. How do we measure success? And I think this is where EA as a discipline is struggling with, even though it’s 30/40 years old.

Carlisle: Oh, definitely. I mean, I think that even when I sit down and try and write out what my KPIs should be for my current clients, it’s still very difficult. It’s because I am in that silo, so to say, a lot of times. I’m brought in under one little area of the organization, whereas you need to be way up top to try and do the true enterprise architecture KPIs.

Roland: Yeah, I think you need to have a seat at the table when the ‘what’ will be defined, right? And say, ‘oh yeah, this is the benefit that we get on either of those views. And you mention the processes because it’s easy to measure, but also on the more technical views of an architecture. 

J-M: It feels like a catch-22, where you want to get a seat at the table by showing that you have the value to deserve to be there. But you need a seat at the table already to achieve the value to get that seat. If I could take one point forward, for anyone out there who has the opportunity to advocate for Enterprise Architecture, to be an ally to folks who are trying to do the right thing for the right reason, it’s to open up space. Invite folks in the Enterprise Architecture strategy group to sit with you, and let them define the value they’re going to provide. Let them set those KPIs and expectations. Help them help you deliver that value back.

Roland: Yeah, that makes sense. J-M. But to come back, if people find that whole conversation interesting and they say: “hey that Carlisle guy that’s a smart guy. I wanna have more conversations with him on this.” Where can people find you? 

Carlisle: They can find me at carlisle.gunn@trace3.com or LinkedIn. I don’t have Facebook funnily enough. So don’t look for me there. I’m working as a principal consultant for the financial services group here. I actually don’t do too much enterprise architecture directly anymore. Instead, I just apply the architectural vision to my overall projects of ITSM and, well, kind of whatever comes up in my mind or kind of whatever comes up on the radar nowadays. So I just finished up some infrastructure strategies and then just doing general tool selection, frameworks, and assessments there. So it’s still that Jack of all trades.

Roland: And we will definitely put your contact information, email and LinkedIn in the show notes.

J-M:  Ah, and speaking about the show notes, Roland, first and foremost, thank you to our wonderful listeners. We’ve had a great conversation between Carlisle, Roland and myself, and would love for all of you to join in? We can’t say thank you enough. It’s great to have that wonderful community of folks out there. 

And speaking of our community, feel free to reach out to us by sending us an email at hello@whatsyourbaseline.com or even leaving a voice message on our system Anchor which will give you a chance to interact with us directly. Speaking about other ways of interacting, if you haven’t had a chance to leave a rating or review for our podcast on your podcatcher of choice, please do! You know those nasty algorithms, they love when the audience gives feedback, and they emerge this to the top of your podcatchers. 

And of course we’ve mentioned a couple of different graphics you can catch that at whatsyourbaseline.com for all the companion articles, or specifically for this episode at whatsyourbaseline.com/episode14. Well, thanks again to my wonderful host and guest. For now I’ve been J-M Erlendson.

Carlisle: I’m Carlisle Gunn

Roland: And I’m Roland Woldt

J-M: And we’ll see you in the next one.