Welcome back to the Better Business Analysis podcast with your host Benjamin Walsh. And today we dive into a topic that I had on a probably a weekly basis and I tried to frame it under the heading Connecting all the bits and pieces. And what I mean by that is that we need to connect our systems and our processes to generate value for our business. That's part of the reason we are business analysts and why we are business professionals.
And it will requires 2 mindsets, the business mindset and the technology mindset and that comes under what is classified generally as enterprise architecture. But today we're going to dive in why and how and what you might want to integrate across your business and how you can explain why this is valuable to AC Suite and a Better Business Analysis Institute presence. The Better Business Analysis podcast with Kingsman Walsh talk to business leaders all the time
about this. Most of my day involves doing some kind of technical advisory, even though I'm a a business architect and analyst and it is around explaining that there isn't really an easy solution to all their problems. As in there is no one box that will solve their problems. And I'm going to give you an example. So ERP systems or enterprise resource planning systems are great for manufacturing, right? And there are business models which suit that one platform to rule them all.
Very few businesses that I deal with necessarily require multi $1,000,000 ERP. But even if you do have that and you're big enough to need that kind of system for your industry or your size, there are other systems you have. You have e-mail clients, you have Microsoft Productivity Suite or Google Productivity Suite, or you have some custom apps and AWS. All of those things are part of what's called your architecture. And I talk a lot about business architecture. That's the game I play and
enjoy. But today we need to think about how does the processes and the people and our environment, how does all of that relate to our technical architecture? And usually what you will have in an organization is someone called an enterprise architect. And that name sometimes is given to more than one person. But the idea of enterprise architecture is to do both the business side and to connect the technical side. So your technical architecture.
And you'll find that people that usually have the term or the job title enterprise architects are actually enterprise technical architects. And so they look at this Indian state and they draw these really high level solutions, which is fantastic. We need these. We need to make some decisions around our technical architecture, and I'm just going to say architecture for the rest of the episode. And you need to just assume I'm talking about technical architecture here.
So if you have your ERP system, you need your productivity suite. So you need, you know, your Word and your Excel and you need your Teams and you need your Outlook. You need all those underlying functions regardless of which vendor provides. But generally you buy them bundled and you can't ignore that. So you're buying the Microsoft suite, or you're buying the Google suite, or you're doing some kind of open suite. There aren't actually that many options.
So you're using that, especially in a corporation. And that is where your data's flowing, your data is flowing and living in those systems and you're producing the, that's your interface, right? Then you might have an operational system or an ERP, as I talked about before, our CRM system, you've heard these terms and you are storing information in a structured way in those systems, which may integrate with your website, which is another interface, a touch point
for your customer. And then maybe you've got a reporting suite like Power BI or Tableau or something, which is connecting to your operational systems, usually more than one because you've got a financial system and a CRM and something else. And that all needs to come together in a case of way, ideally in an easy way, ideally in what we call kind of single storage of data. So you're not storing the data in more than one place.
So that costs money. When you store things, especially in our cloud environment, you have to move data, you have to integrate these systems and it all becomes complicated. So the first thing that I see are CTO or CIO more so or CEO will think about the C-Suite. We'll think about especially if they're not hugely technical or haven't come from that background is they don't understand the inner workings of that.
They may not care, but the reality is they to operate, you need to get you as ABA and you as a architect, and it needs to be efficient. And if these systems can't send the information back and forth and don't talk to one another, then your business process is inefficient and therefore your business is inefficient. So I'm going to cover off quite a few ways here that you can think about this problem, how you can connect the bits and pieces. OK, Number one is the digital glue.
So why do we care about connecting these systems? I've gushed on it, but data, primarily data. So to get rid of all the complexity of systems. C-Suite executive or a person on the street can understand this, that data, a piece of data is only powerful when it flows just
like water to reverse system. If you have disconnected systems, then you have an efficiency, you have duplication, you have data solos, you have risk, you have potentially trust issues because 1 area of the business doesn't know about what's happening in the other in the era of the business, or they come up with two different results from AB as perspective. Disconnected solutions break processes, they frustrate users and they create blind spots for
decision making. So a great solution regardless of what it is. So you know, a sales force or a or whatever you're putting in the widget that you're putting in that's not connected to the rest of the ecosystem is like a smart person talking to themselves and like a soundproof room. Doesn't matter how smart that one component is, if it can't talk outside of that to the rest of the systems. The data's not flowing.
You really haven't got any further in terms of what your enterprise needs into a little bit more detail here. Business functions are really isolated. So the functions that support your processes are really isolated. So a customer journey crosses multiple systems. Customer journey is what your customer's trying to do to get their job done. And so that will go from CRM, maybe a CRM system to your ordering system to fulfilment to billing support.
Most organizations will not have that all in one system for good reasons, which we'll touch on in a minute. So therefore your customer journey experiences and and has touch points with all of those areas either directly or indirectly through phone call, e-mail, website. So when systems aren't connected, it's not just an IT problem, it becomes a business performance issue in these silos. They kill visibility, reduce agility and create inconsistent data stories, which is where
this trust issue comes. So an example would be in education, a student record might live in, I don't know, the tenant system and might exist in say the ministry's financial aid system. It could exist in the reporting platform, it could exist in a learning management system. And if they're not all connected, tracking a student's well-being or performance becomes manual or error prone. OK. And that's that's kind of the word I'm living in at the moment in in some ways.
And then we'll jump on to the number 2 point. So we know that it's important to have this glue, but why can't we just put it in one system? Why one system to rule them all kind of fails in reality. So it's it's it's really tempting, especially for executives. You'll get this in your life. I have on an executive team. We are. It's easy to imagine 1 mega platform that does everything OK, but it creates complexity,
it's rigid. You end up probably spending a lot of money on customizations because those, because those systems are so big and they have to have such a wide scope. They're not really focused on one doing one thing well. And therefore, to get the differences you want for your business, you have to customize it.
And then it's longer delivery timelines when you want to change something because you're generally going through 1 vendor and then you're, you're locked into that vendor and your data's locked in. Sometimes even if you, even though we're getting better at having some policies and decisions out there worldwide that allow you to get your data out. So one system to rule them all becomes one system to slow them all. Does that make sense? So that's kind of a a good
analogy there. And I know from my experience that if you're a smaller business, it might be really great to have one system. But number one is don't look at necessarily spend your time looking at all the features of
that system. Look at it, it's integration ability, OK. And if you, if it's got great integration ability with other systems that that vendor doesn't own, so it uses an open system AP is all the rest of it you know connects to Zapier or whatever other integration platform that's out there, then that's a good sign, OK, compared to one that doesn't, it doesn't mean you should buy it.
It could be really crappy in terms of how it fulfils the use case, but it definitely has one of the attributes you need to worry about, which is integration. And I guess the other point about that is that these systems have this romantic notion of simplicity, but actually really comes at the cost of agility. And they're quite hard to evolve. And even systems which are behemoth or monolithic like Eips, like SAP for example, would be one of the world's biggest.
The ones that do well and don't have this problem the most have actually started to create the various areas. So, you know, customer management or inventory management, they have created those as separate apps that didn't live on a platform. So a platform with various apps that talk to one another is much more preferable than a system which has tightly integrated modules that are that cannot be
pulled out as separate apps. If you want to know more about that, it starts to get quite technical, but there are a few systems out that they're built that way. So I'd say a Microsoft Dynamics 365 and a sales force are more of what the latter where there are modules and it allows optionality for choice. An example would be here.
If you take a large public agency, they will try and consolidate all their data into one massive ERP or a data warehouse or a whatever and years and millions later they had a slow rigid system no one liked and ended up kind of layering smaller tools on top just to make it usable. They haven't a lot, especially if you are locked into a vendor and that vendor doesn't upgrade their system or that system has decided to invest in function but not experience user
experience. So it's really hard to use from AUI point of view. So it looks like doesn't look very nice, but it happens to be feature rich. Again, SAP comes to mind. OK. So what's the other end of the spectrum? The other end of this spectrum is something that became really popular a few years ago and you may have heard the term it's called microservices. So you can go to the other end
and go, well, that's bad. Having one system, why don't we just have lots or thousands of Microsystems or microservices? Sorry, and that isn't the answer either, but I'm going to explain why. Micro services, they promise agility and scalability, but only when governed well, OK, because you could still have many disconnections, right? And you have to create these kind of mini solutions.
So you end up with chaos in the integration layer and you end up with like kind of a bit of a dependency problem between the systems and then you have to manage the security and the maintenance he'd actually get across. So I would say that micro services done badly are just as kind of dysfunctional as one behemoth.
And but in saying that, if you are a custom product shop or you really understand it and you own your understand your architecture well and you don't have lots of micro services, just a few that are manageable, it is a better option than just having one behemoth. However, that isn't the sweet stop spot. Let me just give you one kind of example of what where you might use micro services in a good way because I don't want to. It is quite new and it is better
than what we've had. And that is when you're doing kind of scathing large systems, but it only works if you've got governance and orchestration and documentation. So you everything has to have high levels of integration, which is what a ideally the the reason for having a micro services that that's what it allows you to do because it does one thing really well. And you need to be able to have kind of API gateways which are managing all that.
And you need to have kind of a service mesh to manage the communication and you need kind of like document interfaces. So a fintech start up might be good because it's got different services that do things well. But if you don't invest in service discovery or contract versioning and your deployment processes, then it's really hard to work out where and what services are breaking your processes if something breaks.
So what I would suggest for most businesses, and I like I said, there's no one rule to kind of fix your problem is really when you're looking at the sweet spot. And that is just integration done right in, in my simple terms. And that is when your solutions are modular and loosely coupled. So they're not tightly coupled, but they're tightly aligned not to necessarily each other, but to the business capability and the step in which your users and your customers are wanting to perform.
So you need to focus on business driven integration. So you can connect where data flows, but only if it's valuable. So another way of saying that is to connect where value flows through value streams and you need to think about what I would defer affirm we over use this word actually argument about what this word means today, but it's around prefer platform thinking over point to point hacks. So platform thinking being something where you've got your base services platform for me
isn't necessarily Azure, AWS. It is having these consistently used services you want across your organization as a base and then building these kind of areas which have value in their own space as separate systems or services. So let me say that another way. If you were like for example wanted ACRM system, most CRM systems out there now will integrate you know Hub, a HubSpot, Microsoft CRM or it's Dynamics 365 and Salesforce. They actually have really good
integration layers. And if you love that tool and system, it's probably OK to use it because it integrates well and it's decoupled for CRM and it makes sense to do all your CRM in one place. So all those processes are tightly coupled from a business process point of view and a value point of view. Now what makes sense for example, is have that as it's own system, but then any of your authentication layer or maybe your web content or anything that's shared would be on the plat.
So it's OK to have that as it's own system and to use integration to move data around. But I would say you wouldn't want more four of those big things. Does that make sense? You wouldn't want to break that CRM system down to lead management and then have another interface which was managing your customers, managing your opportunities. Had those as separate services or systems, it would become chaotic, right? That's why we have CRM systems in the 1st place.
But you don't necessarily want to grow that system out, so it does everything. So you can use things like integration patterns and you can use things like business capability maps, which is a business architecture term to really anchor the integrations that you need and where the
value flows. I would suggest that what you could do to figure out if you should maybe buy a kind of a package system like ACRM system to fill your needs, or an ERP or both, or which systems you should look to integrate more closely. All which ones you could specialize in and have a a tiny micro service widget to the side is to map out the information flow. So map out the information flow across business processes, where data starts, where it travels, and where it's consumed.
Use the data management life cycle to do that. Identify the integration pain points. So where is manual re entry? Where is inconsistent data? Where do you need to reconcile? That's always a bad word. Or you've got kind of what we call swivel chair operations. Where are the touch points for your customer? And start speaking the language of integration, like understanding what a web hook is. Data contracts AP is REST, AP is integration tools like
zapiermake.com. 8 N 8 N which is a free tool and then collaborate with architects to shape integration patterns that make sense for your business, not just IT. And if you drew it up and you work with your enterprise architect, then when you make a decision about what systems you should introduce to your ecosystem, it becomes way easier. OK. And and and then there is some insights you can and some
patterns you can draw. So for for example, if you are using the Microsoft Office suite and you have Microsoft Dynamics 365, it probably makes sense for you to use Azure, which is under all that to do some small services for various reasons, cloud cost moving a data, the way it stores it contracts, authentication, it will might not make sense for you to go, oh, there's something great in AWS. Let's just change our pattern for that because it's going to
cause you headaches. These are all the world's of architects, but it's a great example. Again, if you're using the Google suite and you're a startup company and you're doing everything fast and custom, maybe on AWS, maybe on Google Cloud, introducing Microsoft offer, sorry, the Microsoft Teams, and then using that to save your documents doesn't really make sense.
You should use Google Drive. So you can start to generalize some of these patterns and that they are, you will see if you're working on the space, you start to have these same conversations again and again, especially with management. So is your business more like Frankenstein or Ironman? Frankenstein, which is stitched together with no plan or Iron Man, where there's modular components that are seamlessly connected. As a BA, your job is to help build Iron Man. I'll see you next week.