Welcome to episode 4 of the What’s Your Baseline podcast. We are talking about:

  • Types of architecture tools: drawing tools, implementation front ends, database-driven architecture tools
  • How users see things: data-driven visualization vs. visualization-driven data (tables vs diagrams)
  • Focus of architecture tools > niche vendors – your stakeholder needs drive the focus
  • What to look for when selecting tools:
    • How do you get started (personal equipment, existing information, etc.)
    • Selecting the tool – what to look for: modeling, dashboards, wiki, data ingestion + insights
    • Functionalities of architecture tools
    • Deployment and cost
    • People
    • Non-functional criteria (vendor, community, change readiness, etc.)

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

Ep. 4 – How to Select an Architecture Tool – What's Your Baseline? Enterprise Architecture & Business Process Management Demystified

Additional Information

Credits

Music by Jeremy Voltz, www.jeremyvoltzmusic.com

  • CP1 (Welcome)
  • Cowbell (Interlude 1)
  • Airplane Seatbelt (Interlude 2)
  • Wish You Knew Me (Interlude 3)
  • South Wing (Outro)

Transcript

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

Roland: Hey J-M, on this wonderful sunny day, how are you doing?

J-M: I’m doing alright, I’m doing alright, ready to rock as we say.

Roland: That’s great, because the topic of the day is to talk about how to get set up, which tools you use and which functionalities you need to set up your enterprise architecture and process management platform.

J-M: Yeah, this is a huge topic for a lot of organizations trying to figure out exactly what to buy, how to buy, how to introduce these things, what decision criteria you’re going to use, and well, there’s a lot to it, so we’re here to help you give you a couple of tips and tricks on how you might do that and direct you to some resources you might be able to use on, of course, our companion blog: whatsyourbaseline.com. Isn’t that a good plug, Roland?

Roland: That is an awesome pitch. I like that. So let’s get started. So J-M, what do you typically see as “architecture tools” in the market?

J-M: That’s a great question. Well, there’s a lot of different flavors of how people perceive architecture tools. Some people think of them as just drawing tools. What do I put pen to paper with and make visualizations with so I can understand my business and architecture a little better and communicate it to everyone else? People think of it as like the front end interface that you’re using. So literally the diagramming platform, or the modeling platform, or the data entry platform. 

They also think of it as the back end. What am I containing all this business process and enterprise architecture information in? So what kinds of databases am I using? Am I connecting information together in a relational fashion? All those sorts of things. And all that together becomes your architecture platform. So, a drawing tool or interface for all your users and a container for all of your information. You can conceive of things in a couple of different ways and, Roland, tell me a little bit about how you see this, and particularly how you see the idea of visualization versus data.

Roland: I see the structure, even though I would use the same words that you did a little bit differently, so when I look in the market, I really find a lot of drawing tools. It’s the Visio that’s on everybody’s computer, right? Because it’s free. So what you get is a piece of virtual canvas and you can put in symbols, boxes and arrows on it. But the drawback is that it’s just boxes and arrows. So there’s no method behind it, even though you might have a stencil that says BPMN. You know, you have different shapes, but there’s no enforcement of these shapes. You know what does it mean? Is my triangle your rounded rectangle or somebody else’s circle? And that’s more drawing tools, so I don’t want to dig on Visio all the time.

J-M: And I think we’re actually going to talk about that a little bit in a notations episode to come. So, for our lovely listeners, get ready for a future episode talking you through how you might represent information.

Roland: That is true. So, the second class of tools that I see, our front ends of implementation systems. So think about Bizagi as a business process management system.  Or think about the Software AG Designer as the front end of the webMethods runtime platform. Those are typically data-based. They have a method being built in, but they have a different focus. They capture only what is interesting for the automation aspect. So, for example, you can draw a process in that tool, but you cannot create data models or you cannot create application landscapes or whatever is outside of the scope of the tool.

J-M: Yeah, I see a lot of organizations kind of falling into not that trap, but rather that sort of “fixing it in the mix” by having this kind of tool established, but really not having any ability to scale it to the enterprise, it’s only ever really meant for the thing that it does, which is supporting the automations in the platform that it’s talking to.

Roland: Yep, Blueworks for example…

J-M: Oh, now we’re not here to crap on different platforms, but just to say these are concerns that you should have when choosing to implement a tool and making the choice is very important. Don’t just slip into whatever is convenient, make a good choice for your organization. This is about growing and expanding as a company into a business process and enterprise architecture practice.

Roland: Yeah, and the third class of tools that I see is then database driven tools. These are tools like Software AG’s ARIS, MEGA’s HOPEX, Bizzdesign’s tool. So those are tools that use the power of a database, a relational database in the back end to have an object-oriented approach to things. So, for example, if you have an object you can reuse it multiple times in your models. If you now figure out you have a typo in there, you just change it once. And it will be changed in a dozen other models where you use that object. While in Visio, if you figure out you have a typo, guess what you have to figure out “where do I use this shape” and then open dozens of Visio models and do it over and over again, right? That fix that you want, so that is obviously a time saving thing. The other benefit of it is you have relations there. You can report on and we will talk about all those functionalities that you would see in that class of tools, a little bit later in this show.

J-M: So that’s a good way to start with things, and I think we also want to talk about how people see information. And you know, I like to group things into two categories, really. They’re kind of one thing flipped on its head, which is data driven visualizations versus visualization driven data. So, when you think about types of architecture tools, let’s start with the easy one, visualization driven data. Those are the tools where you put a model or you create a visualization in order to represent your business, and in doing so it captures and supports a sort of structural data layer underneath that’s representative of what you show in the page. What that does is it means that you’re creating rich data structures, making rich connections, being able to report and understand, but you’re doing it from the perspective of sort of flowcharting, visual modeling, structural modeling. Easy kinds of things you can get your hands dirty without having to get a lot of experience, or know that data structure at a detailed level. 

The opposite of course being data driven visualization tools, as in you create a set of data and that could be a hierarchy that you’re bringing in yourself or creating from an import from another source or however you wish to, and it renders that information in a format that you can understand and communicate. We see that a lot more in things like IT structures and tools like Alfabet by Software AG, where it’s about creating automatic visualizations based off of the underlying content of data, and that’s very handy. But each has their own strengths and weaknesses, which we’ll get into in a little while. But I do see those as sort of one turned on the head of the other, and they’re both relevant and important for their relative groups. For instance, the lowest barrier to entry is always the winner when it comes to the business. But it’s also important to be able to understand what you’re buying when you’re looking at making a tool selection.

Roland: Agreed, and it depends on your potential audience. You know, business people typically like diagrams, and IT people like tables. And when I look into the market there’s a couple of tools mentioning, for example, Mega’s HOPEX, which brings everything into one tool. There are other tools that have separate tools that synchronize with each other, but either way the challenge will be to identify who’s your audience that you’re going to try to sell a tool to, and what do they prefer. So, like in any architectural project, have a look at your stakeholders and see what their needs and their wishes and their objectives are and how you can support this.

J-M: Yeah, and obviously we’re going to talk about that when we talk about readiness for a platform. But just to introduce this idea, the people you have, the team you have. Though your most valuable resource, you know the old adage, “a fool with a tool is still a fool” and you want to have the right people in place to be able to leverage whatever platform you choose and be able to put it into practice. You can do repeatedly and scale and grow and sustain as your organization adopts it. The other thing we want to talk about is the focus of different architecture tools. Now, Roland, you know you’ve seen different types of architecture tools with specializations. These are sort of the niche players that come into this is like this is the one thing they do really well, but what sort of flavors have you seen of this architecture tool were represented by smaller or more niche kind of vendors?

Roland: Well, it depends on how you define niche. You know there’s obviously tools like a Sparx that is a UML and BPMN modeler., On the other hand, you have a small vendor like Adonis with their tool, which I thought the first time I read it: oh, these are some old IDS Scheer colleagues from way back when, who wrote this? When I looked through the method model, the method manual and in the visualization – it was just like other colors. So, different things for different purposes. I think there’s a couple of tools that are big and we will talk about when we say OK, how do they interact with others? But at the end of the day, what you need to think about is what is the focus that you look at? Do you want to do more business architecture – so modeling processes, capabilities, orgs,  these types of things? Do you look for a specific customer experience modeling? Or do you look more for risk and controls, or data, or applications, or technology? 

And I think this is when you look at your stakeholders. This is what will determine what the flavor of the tool will be, and I hope it became clear it should be a database-driven tool, so forget the other two classes. It’s one of those, but then it comes to a couple of other criteria that we will talk about in a second.

J-M: Yeah, and so you know, thinking about these things, whether or not you’re looking at a tool that’s focused on one of these avenues or the process capabilities, experience, architecture, risk, data technologies, those sorts of things. Whether you’re taking a look at modeling tools that are data driven, or visualization driven. Whether you’re talking about drawing tools, front end database tools. Our question for you today to start us off on this journey is: “what are you doing right now”? 

Think about a new organization and your team. Even yourself. What kind of experience do you have? What tools have you seen? Are they working for you? And if you could have your druthers, as they say, what would you love in a future state of any platform? Just as a conceptual idea? What kinds of things drive you to feel like: “yeah, this would make my organization and my role even stronger”? We’ll leave you for a moment and come back with our answers.

J-M: Ah, and hopefully you’ve had a chance to think about what you’re doing today. I remember the first time I had a chance to think about that, I was working with an education supplier and trying to figure out how I could model their buying process that we’re using a pretty major buying platform and all we did was throw it on the wall with sticky notes and with white board markers and the first time I got introduced to a database driven tool man, my heart just soared. I thought, wow, this is a way we could actually connect all this information in and of course somebody else had done that tool selection for me, which meant that I got to have an easier job because of the thought that went into it. And today we’re going to look at that in this section. 

What kind of thought do you need to go into when making this tool selection? And we’re going to cover five different topics. The first thing is what you need to get started. How do we get started with selecting the right platform for you and then second, of course, what to look for when choosing that tool? Third, we’re going to dig into some functional criteria you might be looking for things you should be evaluating. The fourth is we’re going to talk a little bit through deployment and cost considerations. I know that a lot of organizations are very cost sensitive, not a problem. We can help you get the most out of your dollar. And then lastly talk about the people. As I said at the beginning, you know the people are the most important. How does this decision align with your team? So, Roland, why don’t you get us started with? How do we get started?

Roland: Yeah, that’s obviously the first question. I think you obviously need some equipment, and I’m not talking about servers right now. I’m just talking about your personal setup. The first thing is you need a computer – that sounds super strange, but obviously you need to access it. You need a computer and but in the end it doesn’t matter which type of computer you have. If it’s a Windows computer or Macintosh or even a Chromebook which is more than sufficient with modern systems. The more important thing that you want to look at is to buy a big monitor. The bigger the better, right? So look at whatever – 4K, 5K monitors so they have enough room to create big diagrams. Nothing is more confusing if you have to scroll sitewards, upwards, downwards and so on. Of course, zoom in, zoom out to get your model over the point. The next thing that you need is, in some form of fashion, an office program. Because those database driven tools that we just spoke about, they spit out reports you want to see them. It doesn’t have to be Microsoft Office. It could be Libre Office or your office program of choice as long as it can open the Microsoft file formats. The next thing that I would recommend is obviously some ergonomic setup. Have a comfy chair. You will spend a lot of time in your chair. Have a good desk, maybe one that you even can raise and stand on and make yourself comfortable.

J-M: Are you a standing desk man, Roland is that where you are you love that?

Roland: No, I’ve never tried it. No, I’m sitting on… well… I like to walk around when taking phone calls, but I’m not working on this. The other thing is, you might also think about having like a little chair with a coffee table. Because you will read a lot of documents and you might not want to read this on your desktop. So have a little coffee corner where you do this, And speaking of which, I also would recommend to have a tablet for this and it can be a cheap tablet like in Amazon Fire or something like that. You don’t have to buy the high spec iPad or whatever the Samsung equivalent of it is. You would just want to have the opportunity to have a second monitor that you can access the Internet with that you can have, for example, a diagram of your legacy tool being there while your model on your computer that has the big screen attached and you don’t have to switch between applications. To make that easier for you, I have assembled a list of items that I use, and I posted that on whatsyourbaseline.com so you can have a look at these things that I’m personally using.

J-M: Yeah, I know that personally, having a large monitor available, particularly when you’re working with process models that have a lot of objects on them, you’re going to want to see the whole picture and then zoom into what matters. That’s a really good piece of advice, and hopefully you’ll check out that equipment list. The other thing, Roland is, you know, besides the physical stuff, there’s one thing I wanted to make sure you talked about is that you do also have information. As you are preparing to introduce something like this into your own personal workflow, make sure you’ve captured information you might have from existing documentation. Or make sure you’ve got subject matter experts ready to facilitate the interviews to help get information into it. You’re getting the physical information, physical gear and you’re getting the digital information ready to go. So when you’re ready and you’ve got something installed, you’re able to stand up a real repository right away. 

And talking about repositories, where do you put those? Are we looking at this on your desktop? Or where should we looking for an implementation for this to go?

Roland: So now comes the hard part, and every tool vendor will obviously tell you: what we have is exactly what you need. One stop shop, just buy from us. The reality is a little bit different, so typically you want to look for different functionality and maybe a vendor has all that functionality built-in. But what I see is at least four big topics that we want to have a look at. 

One is you need that modeling capability. You need to be able to create the artifacts and manage the artifacts and all these things that one would expect an architecture tool does. The second big feature that you want to look at is dashboards. Can you create something that’s easily digestible for your higher level / C-level stakeholders? Because I can promise you, none of those guys will ever go into your repository and drill down on the lower level and open that diagram that you just spent three days creating. 

The third one that I would look at is something like a wiki, so think about a Confluence. Think about Notion or any of those wikis, because you will have to create some documents at some point in time when you follow TOGAF, for example – they are very document focused, which I think is a little bit outdated, but on the other side, if you use a wiki, guess what? It’s online, you can do changes there. It’s accessible by multiple people. You don’t look for different versions of word file and whatnot.

J-M: Just as a note for you, you know, while you can do things with just a wiki, we’re also just talking about it as a collaboration platform. You know that includes document management and knowledge management, which means you’re wanting to have some sort of interactivity and some capacity to post, be notified, and ultimately respond and engage with the platform you’re working on, right?

Roland: Or even just coordinating. So for example, we use Notion here in our podcast to just put in our episodes and having little pages that have the outline of the topics that we want to talk about. It’s easy to transfer this into a setup where a bunch of architects, a bunch of modelers to, say, import a batch of existing models into your architecture tool. 

And that the last thing that you want to have a look at is tools that help you to record input. So, what I’m talking about are things like process mining tools where you take data from your runtime systems and you put it in a process mining tool, and it creates the as-is process. What actually is going on versus what you might have seen or heard in a workshop with your SMEs because that’s obviously a limited audience. The point is to get some data insights that it can use as an accelerator as a starting point for your architecture development.

J-M: I think we’ll have a whole episode focused on process mining, or a couple episodes even. That’s certainly a part of how organizations get there as is, and continuously monitor how the deployment of processes is going. So that’s a really good feature to have, but I wanted to hone in on the actual functional criteria. We’ve talked to the high level of the things you should be looking for. Let’s talk about the Third Point here. You know, what stuff am I evaluating? What are the pitches that are presented to me based off of? 

I think the first thing I think about when I think about modeling tools, architecture tools, database-driven tools, even though there’s a lot of power behind them, the first thing’s got to be the user interface. What’s the look and feel of how it is to work in this platform? And you’re looking at something that’s going to be your day-to-day. What’s the day in the life of a modeler? What’s a day in the life of a viewer? What’s a day in the life of somebody who’s doing architecture and controlling this and that user interface is going to be the really the controller of everyone’s willingness to work in this, because if it’s too hard, they’re going to walk away. So how does it work?

Roland: And that also includes the management of different databases or folders within the database.

J-M: Your structure.

Roland: Yeah, so that people don’t have to hunt for content, but it’s easily structured or it’s easily understandable for a modeler or stakeholder to go in the database and say: “Yep, this is where I find it”. And I’ve seen, unfortunately, independent of the tool, I’ve seen a lot of implementations where people were just lost in getting their content structured right?

J-M: Yeah, it helps you to find things and helps you contextualize things, so you want an organization within the tool that brings things together, and that’s going to be important and something that’s accessible in that fashion. 

Second thing I always look for, and you talked about a little bit before, Roland, is different perspectives based on different types of users and their needs, and the biggest one is of course dashboards for management. Does it have the capacity to evaluate its own data, so dashboards focused internally, and does it have the capacity to hybridize that or look at external data? A perfect example of a use case for that is a customer experience management tool that allows you to bring in NPS. Your Net Promoter Score from however people are evaluating our processes gets hybridized with the actual models you’re designing about how your customer journey is going. That’s important and that gives you a lot of insights on where to go next, what to do, and how to improve. 

We also want to look at the workflow around the control of the environment, so are you able to allocate management tasks for different users? You know this could become a very cumbersome process to create a modeling system. That is everyone’s manual task to go and figure out “hey, what do I have to do next?” Well, if you can prompt them, it’s a lot easier.

Roland: And I think this is a success criteria for the tool, because when you think about your different stakeholders, say you have an approval process and you have different stakeholders there. The owner of the model, your risk folks, the SOX folks who need to sign off on it. You have the technical QA people who want to check your model if it’s correctly modelled according to your standards and so on and so forth. I doubt that you get the owner and the risk people to say: “oh yeah, it’s easily found on the 7th level in your structure in the database”. 

So what you want is to have a workload functionality where you can create custom GUIs and you can do the routing of the messages so people get email notifications and they see a screen that’s “designed just for them” and it gives them exactly those features that you need to accomplish that task. Things like “click here to open the model”. “Click here to enter your comments”. “Click here to do a comparison between this version of the model and the one that you approved six months ago,” right? So make it easy for your end users, your stakeholders, who play a role in those processes. 

And another thing that you might want to think about is when you remember the last episode that you heard about how to implement your architecture tool is the process governance part. Map out your processes and see what you ask your stakeholders and your roles to do. And then, once you’ve done that, and you’ve socialized it, take a step back and think about “what can you automate with your workflow tool to make it easier for the people to play a role in those processes”.

J-M: Yeah, another thing that I think goes along with what you just said a couple seconds ago is a configurability. That’s a functional criteria for a lot of the platforms that I’m evaluating. Can you make it look the way you need to make it look? And that comes in a couple of different ways. One which will speak about, very shortly, but really the most technical way of looking at this is: can you change the face of the tool and how do you change it? Is it a business user configuration? Is it very difficult to do and can you make it tailored for user perspectives? That’ll make it, once again, easier to get into and most importantly right for you.

Roland: Yeah, that brings us to the second point. Obviously, changing a portal, changing the landing page that a user comes to when he opens the tool, that’s one thing. 

The other thing in the background is obviously what is the method that’s built in. So, how can I change the architecture views, the model types, the object types, all these types of things? Does that tool have a flexible metamodel which then gives me the capability to put reporting on top of it that gives me exactly that information that I was asking for. And when I look at that metamodel, and we spoke about briefly also in the last episode, it obviously then becomes critical that your tool also has some scripting capabilities. 

So that you can, for example, create interfaces to other systems. Say you want to bring in an application landscape that’s hosted in your CMDB, like a ServiceNow for example. Obviously, your idea is to go and get the information from the source of truth and not make up an application landscape in your architecture tool. To do this, you need to be able to create an interface between the CMDB and your architecture tool. So the question is does it exist out of the box? Because the vendor did a good job and was thinking about this and it was feasible to do commercially. Or do you have to do this by yourself? So a good tool, in my opinion, would have an integrated development environment. That way you can do the development, the debugging, the testing or these types of things and also has an API, a well-documented API, where you see which functions are available and what can be done. And while doing this, ideally the programming language is nothing that’s tool specific. Some vendors do this, some don’t, but it’s more standard programming language like JavaScript for example to create those reports because that obviously opens the potential pool of candidates for a developer role significantly.

J-M: Also, you’re not going to end up having to pay that vendor for the consulting services all the time to maintain your tool. You’ll be able to bring it in house, maybe use existing talent and ultimately be able to better support yourself at a lower cost.

Roland: Agreed, agreed, and then when you look at this, and now we’re speaking about developer types. You’re also going to want to have a look at the more advanced end users / the power users? What type of analysis do you give them at hand? That obviously could be a report that was created by your developers or pre-packaged with the tool. But it’s also interesting to see: does your tool have an easy to use query language or can you create a report as a power user without having to learn a full blown programming language, but you have like a wizard that helps you doing this? Or can you as a power user create those dashboards? Those process mining analysis visually without having to go into code. 

So those would be also things not only think about when we talk about scripting. Not only thinking about the developer type of person, but also think about the power users or the end users who just want to have a visualization of what they found.

J-M: Yeah, it also means you can decentralize a lot of the control and management of the environment. You don’t have to have just a specialized team, you can release it to your business units who are eager to get to work. And if you give them what they need, then ultimately you can give them a lot of power to make a change with the platform without having to go back to you every time and they’ll feel more involved. Ultimately, they’ll do more.

Roland: And having said that, you obviously should have multiple environments where you do this. So, I see one mistake that clients do is they buy one instance of their modeling tool and think everything is fine. In all reality, if you build some complex scripts like interfaces for example, you do not want to build this in production. You want to set it up like any other IT project and have a DEV environment and a TEST environment and production environment. And only if your test is successful, and the script does what it’s supposed to do -and remember every software has bugs – only then you bring it into production and you think about what happens if in production your script fails. How do you mitigate that destruction or hopefully not destruction that impact that this might have on your database, right? Or on your production environment? 

So think about from a governance perspective, what do you allow end users, power users and developers to do and that should be obviously part of your process governance that you’ve defined as part of your implementation approach.

J-M: Yeah, that makes a lot of sense. Well, youI also touched briefly about integration capabilities, but you talk about RESTful APIs or other types of intersections of data. I mean you also want to think of this just as a conceptual item as the connective tissue of your organization, right? You want to see it as the hub and spokes being all the different sources of truth. These sort of golden standards of data feeding into it. The ease and the frequency and the and the ability to do data interchange goes along with that is really important to consider and make a decision because it’s hard to do or it’s asynchronous, or there’s chances of data getting lost, or the it’s not a bidirectional interface. If those platforms aren’t able to do that, then you could lose a lot and have to do a lot of rework as a result of data not coming over.

Roland: Agreed, but one misconception that I also see is where people look at it and say, “Oh yeah, it must be real time.” This is typically on the list of criteria for an interface the last one that I see because architecture tools are not runtime systems. So in all honesty, it doesn’t matter if you import or update your application inventory (to stick with that example) once a week, and not in real time. Because at the end of the day you’re creating designs, right, and if you model and then you figure out oh there’s something missing. Well, there’s enough time to call your CMDB folks and say, hey, I’m missing that application and they fix it. And then with the next batch update within a week, you get that object, so typically it’s not that time critical and I would put this very low on the list. 

On the other side, one of the highest items on the list for interface in my mind is: being open to as many formats as possible. So if you create your dashboard you want to be able to add maps for example. You want to be able to grab an XML or RSS feed from somewhere and embed it in your dashboard. It doesn’t matter how often you use it, but your tool should have those technical capabilities there, and I would choose this over real time integration at any point in time.

J-M: Well, I agree and speaking about choosing things I wanted to touch a little bit about in our next topic about cost and deployments, because those are obviously important things to consider when you’re looking to make a purchase or you’re looking to evaluate a platform. 

We talked a little bit before about the idea of on premise versus cloud, but you know there’s a lot of different types of pricing models that organizations will go into / vendors will go into on how they sell their platforms. Some will offer you something like a SaaS model of per user per year. Some will have a base cost for how much it costs to just run that server, so particularly if you’re looking at a SaaS hosted solution for you, they’re going to have that base cost built into it, plus those user costs. Whether or not you’re doing a subscription model, as in you’re deploying it on premise, but you’re paying a yearly subscription fee or a perpetual licensing model. And remember, you also need to take into consideration, if you’re deciding to deploy it on premise, your internal hosting costs and the timelines associated with servers. I was talking to a client a few weeks ago and they said: “listen if we want to get an internal server for our deployment, we’re looking at a six month wait time to grab that.” And he said it’s not uncommon in that company to wait six months to get a little internal instance. He says: “”you know, listen, if we’re going to deploy on premise, I’m not going to see the benefits even after purchase for at least six months. That’s crazy.” So, you know, going to SaaS as an option, that makes it a little easier. So thinking about that deployment consideration.

Roland: And it’s also the scalability as you said, how fast can I add new people to this? Or when you think about the process mining example, typically the billing there is slightly different, not by user, even though that also might play a role, but typically the driving factor is how many cases do you want to push through the process mining system and the different tiers of number of cases that are that are in the different price plans. One thing that I notice overall, and maybe the old guys like you and I will have to take a step back from what we’ve seen in the past, I think the on-prem hosting is on its way out. I think organizations have accepted cloud. The other thing what goes out of the door is perpetual licensing. It’s just subscriptions because it’s so much easier. You have it in your OPEX budget and it’s just a run-through cost that an organization has to carry. So when you look and you go shopping for your systems, be comfortable with cloud and be comfortable with subscription.

J-M: I wish more of the folks I talked to work were comfortable with that idea and with that approach, but I do know that some organizations have a pretty hard and fast “Can’t be on cloud” and for data privacy considerations I know a couple of governmental organizations and a couple of major financial institutions that simply won’t let things out the door – that isn’t the way it’s going to work. And I get that.

Roland: Yep, and it will be harder for them going forward.

J-M: Oh yeah, and to deploy on places it last couple things to think about is: what types of users are you looking at bringing in? How many of each of those? And so generally vendors tend to price things based off of people who are looking at stuff and people who are making stuff and people who are controlling stuff. That’s sort of three bucketed categories. Some might spice it up with different types of names, or different breakdowns of what they can do in each and functional decomposition. It really comes down to those sort of three ideas, so the looky-loos, the makers, and the controllers and how many of those are on your team. What does it look like and how much does each cost? You don’t want to get caught up in a surprise when you’re ending up buying all of the most expensive license rather than sort of splitting them in a way that makes sense for the organization. 

And that also goes with the functionality modules. Note that a lot of organizations tend to split their product based off of what it can do for you. So, for instance, you might not get process mining. You might just get modeling. You might not get, you know, simulation. You might not get integrations and APIs for the same one price. It has a sort of different modularized buildup of what the final product is going to be. 

So make sure you carefully consider your use cases today, your use cases in the near term, and use cases in the long term and scale out deployment for those companies and get a real price based off how much you’re going to be paying each year, based off what you need. That’s both the users and also in modularized price tag functionality. Does that make sense?

Roland: It does and at the end it’s also a negotiation tactic to say, “hey, I might buy tool A that doesn’t have feature Y (say process mining)” and you say “hey if I buy you a tool I see you’re working with a partner, another firm that provides the process mining capability that I want. Well, your competition gives everything in one hand right? They have the modeling aspect of the process mining aspect in one thing.” So now you can start negotiating and say: “this is obviously a disadvantage if I have to bring in a third party to the party. Can you can we talk about the rates that you charge me? “Versus you could go to the other vendor who gives everything out of one hand and say hey “yeah, but I could get it cheaper if I split it and I’m willing to take the potential friction that comes here. But if I take yours, your deal will be bigger, but obviously it would be great if you could accommodate our specific needs, cost-wise.” Have a look at this and become clear about if you want to have everything from one vendor in one hand and you sell your soul a little bit to that vendor. Or if you want to get the best of breed approach and then you obviously have the disadvantage that you have to deal with multiple people and eventually with integration problems.

J-M: Yeah, that’s something that we see a lot of organizations think they can get away with which is buying niche tools – buy six or seven niche tools, each one doing its tiny little thing and try and Frankenstein them together. That can work in certain circumstances where you have very divided business groups that are doing very different things and are totally isolated and they just need occasionally to let each other know what’s going on. But the truth is, you really do want an integrated environment. You really do, and the best way to do that is to go is to minimize the number of vendors. That’s an Enterprise Architecture principle as well. Consolidation and harmonization and rationalization of architecture, right? You want to do the same thing with the tools that you’re trying to get the rest of the organization to follow suit with, right? Makes a lot of sense.

Roland: I agree. Again, just think about the big blocks that you want to look at. You want to have the modeling capability, you want to have the dashboarding capability, you want to have the wiki capability and you want to have the data ingestion capability just like a process mining tool or other interfaces that we spoke about. 

And if you can find a vendor that gives you all four, awesome! But if not, try to limit them to a manageable number because, remember, your focus is on creating the architecture artifacts. It’s not managing technology, it’s not managing the vendor, looking at roadmaps and the promises that you hear.

J-M: Yeah, that’s true! And the last piece of the puzzle I wanted to touch on is alignment with team. You know, Roland and I, we’ve had a lot of opportunity to talk to people. As much as you know, there are clients and there are, you know, sale of software. It is people at the end of the day you have to work on that software day in and day out, and you want to make sure you’re making a purchase that aligns with the people you have and the people we are going to have. So, what skill sets and backgrounds do you have on your team? Are these people modelers? Have they done modeling in the past? They have an expertise in business process analysis. Are they architects? Do they know structures of enterprise architecture? Do they understand the way in which the organization decomposes, how they historically used platforms to do this? So, knowing what their background and skill sets are means you’re not buying a platform that they’re not going to be capable of using or blind buying something that they’re not going to want because it isn’t capable of meeting their expectations. 

You also want to understand your size and composition of team. How many people do you have in those roles I talked about before the looky-loos of viewers, your doers (your creators) and your architects or controllers. How many people are architects? How many people are BAs? How many people do you have in QA? What sort of size of team are you looking at, ’cause a lot of these platforms aren’t going to be able to accommodate larger teams. Or maybe they’re designed specifically for very large organizations and if you’re a small team, maybe they’re a little bit of an overkill, so seeing who and what you have. 

Also understanding how much these are need to be digital collaboration tools so if you’ve got a very divided team across the geographies you want to make sure that the virtual collaboration really brings people together with you know what was talking about before about this Notion, this wiki, this collaboration, this document management together needs to happen even stronger. Whereas if you have a lot of geographic colocation: you’re in one office, you’re one team put together, you can go into a single room, you might need a little bit of a different tool, something where facilitated sessions are much more easily captured in person, so you know something with big whiteboards and things like that.

Roland: But is it still a question, you know, after 2020 and the coronavirus situation? I think everybody is virtual. So when you look for a tool, what you want to look for is a central repository where people can access this from different locations where the different roles can create their different artifacts in different areas. And basically those are the deliverables that you expect your roles to do. And obviously what we want to have handy as well is some collaboration platform like a Microsoft Teams, like a Google Meet. You know, where you can do screen sharing and you literally look at the same screen even though you’re in different locations.

J-M: You’re talking about things we want to have, I want to put it back to the audience here. And you folks are listening in thinking about how these are all things. A lot of things to think about. A lot of features. Which ones matter to me.?

Well, think about in the next little while as where you take a quick break, what capabilities and features do you think are valuable things we’ve spoken about? And maybe things we haven’t spoken about? And this is a good opportunity to talk about, you know, sending us feedback. This is something you might want to take after the show and put to us through an email or through a voice message on any of your lovely podcasting platforms. We’d love to hear from you, but we’ll take a quick break. And when we come back, we’ll be thinking about that too.

Roland: Welcome back. Well, we spoke a lot about the functionality, the features, the capabilities that tools should have in the next section. There’s another thing that you might want to think about, which is all the non-functional requirements around your tool. So, J-M, talk to me a little bit about what are the typical areas that you want to look at and non-functional decision criteria.

J-M: I think about things like “tell me about the vendor”. I want to understand the vendor history, their future, what kind of support can I expect with this? What kind of people am I looking at to help me get my product to work in case something goes wrong? What kind of ecosystem, what kind of user community or am I looking at? The acceptance in my organization.? What’s going to make me successful and my organization successful using this platform? And how will I embed it into my way of working? And then lastly, what’s the business case I can create for this selection because ultimately I need to prove and justify that we should make this selection and make a purchase of a tool. So, Roland, tell me a little bit more about what do you care about when you think about the vendor in their profile.

Roland: Well, there’s a couple of things. Obviously you want to have a vendor that is stable. So questions would be “how long has this company existed”, right? Are the products that they build, built in house? Or have they acquired technology from somebody else through an acquisition, right? And how long, if they’ve done this, how long is that ago? So think about it more like are they reseller of something that they actually do not support or own or develop? Or is it grown for years and years and years in their house and has shown market viability? 

The other question that I would have is how frequent do I get updates from a product. I think nowadays it’s completely not acceptable to wait months and years to get a new update, right? And we will talk in a future episode about Agile and Scaled Agile and how that affects architecture, but I think nowadays you would expect frequent updates of your product – every three months for example. So look at when was the last update, what major release version are they on? Do they have intermediate updates? Security updates, feature updates and whatnot in between? 

That also leads to what is the vendors product roadmap? How long do they plan their road map right? Is it really just the next iteration, three months or do they have a plan that stretches a year 2, 3, 5 and you can see whether the ship is going? How do they integrate new features, and how do those sync up with industry trends? You know if you read the Gartners and Forresters of the world, they obviously have an opinion on what tools should do. Well, ask your vendor when you read those things and say: “how do you tackle this? What are your plans on this?“

J-M: And you know their product management would love to tell you that… if they’re good.

Roland: I agree. And then lastly, I would have a look at how likely it is that this vendor is there around in the future, or how likely is it that as part of market consolidation which will happen anyways in all markets. How likely is it that they will be acquired or acquire somebody else?

J-M: Yeah, I can see that being a huge issue. If you have a vendor who has been recently acquired or is in the process of being acquired, or is setting themselves up for acquisition, and we all know what that looks like. The kind of support that you might get from them? Well, that’s not guaranteed. You’re going to be at the mercy of the new company. The new owner of this product to either support it or desupport it for years to come, so it’s always good to be investing in a stable partner in the technology vendor you go with. And that’s really important as part of the evaluation. 

I also care a lot about is this vendor in my geography? Where are the development services out of? Where are my actual support services out of? Are they local to me? If I’m working in a multinational, can the vendor that I’m working with support a multinational? I think a lot of vendors have different development shops in different parts of the world, but 24/7, 365 global? That’s a really important model for both support and also for helping to shepherd and provide services, and strategic consulting and all those sorts of things. Can they do that around the world? Where are they located? 

And then of course, you know magic quadrants, waves, matrices all those sorts of market research reports. You can massage your placement in these analysts reports, but the truth of the matter is they’re evaluating the quality of your products and they’re evaluating the feedback from your users. And if you can find organizations with products listed in the top rights of those quadrants or the good parts of the waves, or in the top of the matrix, those are really good starting points for conversation in evaluating platforms.

Roland: I agree! And the next topic you might want to have a look at is what is the support that you have, and J-M, you just mentioned it when we’re talking about development, but think about your support. What happens if something goes South, you know? Is it a commercial support? Does the vendor provide this? Or is it like in an open source project where you go and have a website and with a little bit of luck somebody answers your question?

Or on the other hand, how do you do the training? How do you get your people up to speed the different roles? Is it? Does the vendor offer trainings, that offer free trainings, commercial trainings? How do they do this: classroom versus virtual or do you have to go to your consultant of choice? Does your consultant of choice offer you training for your end users? 

And lastly, I would have a look at the user community and the ecosystem and let’s start with the ecosystem, right. Those are typically partners or additional vendors, when you have a mixed set of best of breed, that have out of the box integrations and so on. How large is that? How big are the shops in that ecoystem, is it like a ten person shop or is it 100 person shop? How likely will they react when you come to them with a request and how expensive will it be? 

Or on the other hand you have the question is there a user community? What happens if you have a simple question? You know all those, quote unquote, embarrassing things that you don’t dare to ask. Well everybody has those questions so maybe there is a user community that has a portal, right? How many people are there? Have a look at this. How fast do they react to a question that you posed there? What is the information that you see there? Is it just a big cry fest like “oh, I can’t make my tool work”, or is there advice, valuable content, tips and tricks, videos, reusable material available for you which obviously will accelerate your implementation? 

And lastly, look at other user group meetings. Virtually or in person on a regular basis. Are those user group meetings if they’re in person in your geography? If you’re a multinational, are there across all geographies? Because nothing helps more to talk with other people who are in the same boat. Or, ideally, who are a step or two ahead of you and have gone through the “Valley of tears” in implementing the tools right and implementing and creating the architecture artifacts. Learn from their war stories. And that would be part for me to say, “Yep. What is the support? What is the ecosystem? What is the user community? Where do I go when I need help?”

J-M: Yeah, I feel like if you run into, you know international user groups you can get so much insight on not only the product itself but also the vendor. How does it treat its customers? How can you work together with other users? How is that facilitated and how can you learn from their tough lessons learned? As you said, the Valley of Tears and come out the other side in a ray of sunshine. 

And that led me to another point that is really important here. When you’re thinking about this, besides all the tool features you want to look once again at your people and you want to get acceptance in your organization. So, are you ready for this kind of platform? And you need to ask the tough question: do you have things like executive sponsorship or at very minimum executive alignment? Have you built a clear value proposition for how a platform like this might be brought in? Do you have that for adoption? Do you have a business case? Have you socialized this? Have you gotten feedback and being able to incorporate that and buy-in from key stakeholders? 

And then thirdly, have you thought about change management, if today you’re using whiteboards and sticky notes and nothing, nothing digital at all. What’s it going to take for you to move into a new way of working? And how are we going to develop those new practices and what sort of people do you have in place to help socialize that? And get the learning, development and guidance and handholding done within your organization to make this really stick? 

Lastly, how does it align with your organization’s road map and strategy so as they’re evolving as they’re looking to transform their business? What does having this do for them? So what is a platform like this – a drawing tool, a modeling tool or database tool? What does that kind of give them? What capabilities will that enable in them they wouldn’t have had before? That’s going to feed into everything else, and the closer alignment you have, the more friends you’re going to make, the more allies you’re going to make, and ultimately the better deployment you’re going to be able to get.

Roland: I agree, and this also brings us to another, more internal aspect of it. You should have an opinion on how to embed your tool into your current work. So not only aspirational, as you just said, J-M, you know how does it fit in the roadmap, but how does it fit into the day-to-day work? How does it fit into your software development lifecycle? How does it fit in your current process improvement approaches? How does it fit into the state of your agile transformation? And so on and so forth. That is (going back to the previous episode), one aspect, if you haven’t done so, that you should put in your process governance work package when you implement your tool, think about in which contexts will it be used, and then you might see more things opening up, more opportunities where you say: oh yeah, it would be helpful if we had this at a very early stage in our whatever software development process like budgeting for example, or scoping out future projects work. Getting the idea for an improvement.

J-M: Thinking about the word budgeting, the last thing I want to talk about here is (and I mentioned it briefly before) we do want to help make a business case for buying this professional tool, and to do that we think about it in six really simple buckets to put things in so you can even write these down, or we’re going to talk about them more in a companion at whatsyourbaseline.com, but we want to see the value proposition for buying a tool to include: the initiatives you’re working on, what you’re doing today, your current state, what you’re going to be doing tomorrow (so what that future state is going to look like –  what’s your Nirvana look like?), your obstacles (as in, what’s going to prevent that future state from coming to life). What are the gaps that are created by the current technology solution you have in place / the current organization you have in place / the current people you have in place, and then what will this new platform enable? What are the enablers you are creating by introducing an architecture tool? 

And together that gives you a strong value proposition? What am I going to change by bringing this in? And you can start to do things like put dollars and cents to it when you take a look at measuring the amount of time you spend making process improvement initiatives come to life. The amount of time you spend maintaining an application architecture library. The time you spend reworking and reworking new deliverables every time because you don’t have a database driven visualization tool for process. And together that business case will give you a strong path to the future. 

So our call to action at the end of this section is to have you think about some things we’ve been talking about, and most importantly, what are your reasons for establishing an architecture discipline, and supporting this by acquiring a tool? Why are you listening to this podcast? What matters about it to you? This particular episode. You’re going to select an architecture tool, so why? We’ll give you a couple of seconds to think about that, and then we’ll be right back with some thoughts and conclusions.

Roland: Hey, welcome back after the little break. What we spoke about today was three things: What are the different types of tools you want to look at the architecture tools? The second topic that we spoke about today was, what are requirements for the different tools that you might want to choose. Remember, not one size fits all, and then the last point that we spoke about was the non-functional requirements. How do you do the adoption in your organization? How is the vendor? How do we get support in all these types of things? 

What we did is we published two blog posts about how to select an architectur tool on whatsyourbaseline.com, so I hope that you didn’t take notes while driving in your car – as always. So you can go (and I will put the links in the show notes), you can go to whatsyourbaseline.com and read all those criteria again. I will also put the list of things that you might want to think about purchasing to get personally ready on the show notes as well and you will also find, in that blog post, a nice little Google spreadsheet that helps you accelerate your selection. Because it has all that criteria listed and you can just read it there.

J-M: Oh yeah, isn’t that convenient? Look at that folks. You listen to a podcast and you get a free evaluation tool.

Roland: So in closing, thanks for listening to our podcast. As always, you can reach us at hello@whatsyourbaseline.com, or (and I put a link in the show notes as well) you can leave us a voice message so just click on the record message button and we’re happy to bring your questions into a future episode and answer your feedback. Also, please leave a rating and review in your pod catcher of choice. If you like the podcast that’s great – give us five stars. If you want to give us zero or one stars, please don’t rate us. No, I’m just kidding. Also give us the negative feedback so that we learn something. And last but not least, you find the show nodes at whatsyourbaseline.com/episode4.

J-M: Once again, folks, thanks so much for listening. I’ve been J-M Erlendson.

Roland: And I’m Roland Woldt.

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