April 16, 2025 • 22 mins
In this BA Bites episode, we tackle a foundational question:
How do we connect all the bits and pieces of our systems without creating chaos?
We explore:
🔹 Why “One System to Rule Them All” sounds great—but usually fails
🔹 How too many microservices can lead to micro-mess
🔹 The importance of modularity, interoperability, and smart integration
🔹 Tools and techniques BAs can use to drive connected solutions
🔹 Real-world examples of integration gone wrong (and right!)
Whether you’re working in government, education, health, or fintech—this one’s for you.
Don’t let your systems become silos.
Tune in now and help your business build integration the right way.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:01):
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
(00:21):
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 arebusiness 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.
(00:42):
But today we're going to dive inwhy and how and what you might
want to integrate across your business and how you can explain
why this is valuable to AC Suiteand a Better Business Analysis
Institute presence. The Better Business Analysis
podcast with Kingsman Walsh talkto business leaders all the time
(01:11):
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 toall their problems.
As in there is no one box that will solve their problems.
(01:35):
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
(01:55):
$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
(02:17):
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?
(02:37):
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 thatusually have the term or the job
(02:59):
title enterprise architects are actually enterprise technical
architects. And so they look at this Indian
state and they draw these reallyhigh level solutions, which is
fantastic. We need these.
We need to make some decisions around our technical
architecture, and I'm just goingto say architecture for the rest
of the episode. And you need to just assume I'm
(03:23):
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 yourTeams and you need your Outlook.
You need all those underlying functions regardless of which
vendor provides. But generally you buy them
(03:44):
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, especiallyin 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
(04:06):
operational system or an ERP, asI talked about before, our CRM
system, you've heard these termsand 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 orTableau or something, which is
(04:26):
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.
(04:48):
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
(05:10):
haven't come from that background is they don't
understand the inner workings ofthat.
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,
(05:32):
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?
(05:55):
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 onthe 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
(06:16):
systems, then you have an efficiency, you have
duplication, you have data solos, you have risk, you have
potentially trust issues because1 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
(06:41):
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
(07:05):
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.
(07:29):
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 tobilling support.
(07:52):
Most organizations will not havethat all in one system for good
reasons, which we'll touch on ina 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
(08:14):
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 insay the ministry's financial aid
(08:40):
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 momentin in some ways.
And then we'll jump on to the number 2 point.
(09:03):
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.
(09:25):
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 haveto have such a wide scope.
(09:46):
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
(10:08):
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
(10:29):
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
(10:52):
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.
(11:14):
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
(11:34):
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
(11:55):
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 muchmore 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
(12:19):
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
(12:41):
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
(13:01):
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.
(13:22):
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?
(13:45):
Sorry, and that isn't the answereither, 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
(14:10):
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
(14:36):
really understand it and you ownyour 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
(15:02):
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 anddocumentation.
So you everything has to have high levels of integration,
which is what a ideally the the reason for having a micro
(15:23):
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
(15:45):
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 hardto work out where and what
services are breaking your processes if something breaks.
So what I would suggest for mostbusinesses, and I like I said,
(16:08):
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,
(16:29):
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 businessdriven integration.
So you can connect where data flows, but only if it's
(16:53):
valuable. So another way of saying that is
to connect where value flows through value streams and you
need to think about what I woulddefer 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
(17:14):
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
(17:37):
own space as separate systems orservices.
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
(17:58):
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
(18:19):
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
(18:41):
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
(19:01):
does everything. So you can use things like
integration patterns and you canuse 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
(19:26):
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.
(19:47):
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.
(20:08):
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 isintegration tools like
zapiermake.com. 8 N 8 N which isa free tool and then collaborate
(20:31):
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
(20:55):
patterns you can draw. So for for example, if you are
using the Microsoft Office suiteand you have Microsoft Dynamics
365, it probably makes sense foryou 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,
(21:17):
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 doingeverything fast and custom,
(21:40):
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
(22:00):
again and again, especially withmanagement.
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.
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
(00:21):
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 arebusiness 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.
(00:42):
But today we're going to dive inwhy and how and what you might
want to integrate across your business and how you can explain
why this is valuable to AC Suiteand a Better Business Analysis
Institute presence. The Better Business Analysis
podcast with Kingsman Walsh talkto business leaders all the time
(01:11):
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 toall their problems.
As in there is no one box that will solve their problems.
(01:35):
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
(01:55):
$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
(02:17):
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?
(02:37):
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 thatusually have the term or the job
(02:59):
title enterprise architects are actually enterprise technical
architects. And so they look at this Indian
state and they draw these reallyhigh level solutions, which is
fantastic. We need these.
We need to make some decisions around our technical
architecture, and I'm just goingto say architecture for the rest
of the episode. And you need to just assume I'm
(03:23):
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 yourTeams and you need your Outlook.
You need all those underlying functions regardless of which
vendor provides. But generally you buy them
(03:44):
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, especiallyin 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
(04:06):
operational system or an ERP, asI talked about before, our CRM
system, you've heard these termsand 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 orTableau or something, which is
(04:26):
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.
(04:48):
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
(05:10):
haven't come from that background is they don't
understand the inner workings ofthat.
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,
(05:32):
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?
(05:55):
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 onthe 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
(06:16):
systems, then you have an efficiency, you have
duplication, you have data solos, you have risk, you have
potentially trust issues because1 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
(06:41):
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
(07:05):
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.
(07:29):
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 tobilling support.
(07:52):
Most organizations will not havethat all in one system for good
reasons, which we'll touch on ina 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
(08:14):
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 insay the ministry's financial aid
(08:40):
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 momentin in some ways.
And then we'll jump on to the number 2 point.
(09:03):
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.
(09:25):
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 haveto have such a wide scope.
(09:46):
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
(10:08):
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
(10:29):
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
(10:52):
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.
(11:14):
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
(11:34):
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
(11:55):
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 muchmore 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
(12:19):
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
(12:41):
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
(13:01):
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.
(13:22):
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?
(13:45):
Sorry, and that isn't the answereither, 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
(14:10):
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
(14:36):
really understand it and you ownyour 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
(15:02):
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 anddocumentation.
So you everything has to have high levels of integration,
which is what a ideally the the reason for having a micro
(15:23):
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
(15:45):
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 hardto work out where and what
services are breaking your processes if something breaks.
So what I would suggest for mostbusinesses, and I like I said,
(16:08):
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,
(16:29):
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 businessdriven integration.
So you can connect where data flows, but only if it's
(16:53):
valuable. So another way of saying that is
to connect where value flows through value streams and you
need to think about what I woulddefer 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
(17:14):
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
(17:37):
own space as separate systems orservices.
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
(17:58):
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
(18:19):
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
(18:41):
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
(19:01):
does everything. So you can use things like
integration patterns and you canuse 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
(19:26):
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.
(19:47):
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.
(20:08):
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 isintegration tools like
zapiermake.com. 8 N 8 N which isa free tool and then collaborate
(20:31):
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
(20:55):
patterns you can draw. So for for example, if you are
using the Microsoft Office suiteand you have Microsoft Dynamics
365, it probably makes sense foryou 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,
(21:17):
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 doingeverything fast and custom,
(21:40):
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
(22:00):
again and again, especially withmanagement.
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.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.