Welcome to the inaugural episode of the new Enterprise Alchemists podcast! @GuyM and @Dominic introduce the podcast and start the conversation from the very beginning: what do we even mean when we talk about "Enterprise Architecture"?
A chapter list and a full transcript are included below for your convenience and to know what you are getting yourself into; the podcast itself lives here and can be found wherever good podcasts are downloaded.
Once you have listened, please do share your comments and feedback below! This is a new experiment for us, and we would love for you to help us make it as good as it can possibly be.
Chapters
- Introductions — who are the Enterprise Alchemists?
- What do we mean by "Enterprise"?
- And what do we mean by "Architecture"?
- Why might people not think Enterprise Architecture is relevant (any longer)?
Transcript
Dominic:
Hello and welcome to the Architect Alchemists, a new podcast from SnapLogic for our very favorite users, the architects who make all of this stuff work in practice at scale and production. I'm Dominic Wellington and I'm here with my colleague, Guy Murphy. Guy, do you want to introduce yourself?
Guy:
Yes, thank you, dominic. I'm Guy Murphy. I'm part of the Global Enterprise Architecture team here at SnapLogic. I'm Murphy. I'm part of the global enterprise architecture team here at SnapLogic. I've been in the industry now for sadly over 25 years. I've been focused on both data and application integration. I go as far back as when data warehousing was a trendy concept, where SOA emerged as a cutting-edge hype cycle, and I've transitioned through the on-prem large-scale architectures in banking and telco through to hybrid cloud, cloud-first and modern API-led style strategies and architectures.
Dominic:
Nice, thank you. I'm also on the global enterprise architecture team. I've only been in integration for a much shorter time, but I've been around enterprise IT for also over 20 years (shudder) and working from when we actually cared about individual servers, and servers were physical things that you could kick, all the way to nowadays with all of this cloud stuff where you can't even find a server to kick if you need to.
Guy:
Firstly will be between myself and Dominic, but we will also be reaching into the ecosystem within SnapLogic, our partners and our customers. The aim is to actually be discussing different topics around the architecture domain. Some will be around SnapLogic and SnapLogic's functional areas, others will be wider trends and discussion points. So so this is not going to be limited to a feature function capability of our public iPaaS platform. So the aim here is to be a more wide-ranging set of discussions and conversations.
Dominic:
So as part of those enterprise architecture conversations, we thought we'd start out just between the two of us for this very first episode and talk about what enterprise architecture actually means as a term. So let's split that into the two parts, enterprise and architecture, and we'll take turns on that one. So I'll go first. What does enterprise mean? So we bandied that term around a little. So from my point of view, there are a few things that make something enterprise. So one is simply scale.
Dominic:
Enterprise solutions work for large companies, large organizations, but with that scale it's not just bigness, it's also complexity. These are organizations that tend to have been around for a long time, and so they have layers of technology, all sorts of things that were implemented at one point to serve how the organization looks at that point, and then integrated with some later stage where the organization had changed somewhat, technology had moved forward, but the two things still had to operate together to let the organization do, you know, whatever it does. So the number of the existing systems, the technological generations of those existing systems, and that's one part. Then there's also the people side of things. So how many teams are involved in managing all of these different systems? What are they all trying to do? What are they trying to achieve by putting these systems in place or, potentially, by working around the limitations of the systems that they have?
Dominic:
As the old joke goes, people process technology, and the technology is usually the easy bit. The people in the process are where the complexity comes into it. But in the enterprise domain you can't skip that. Any number of promising technologies have been introduced into companies, into large organizations, and just sunk without a trace because they failed to take that into consideration. They didn't have a proper business case, the use case wasn't properly mapped out, the integration with the existing domain and the existing ways of working had not been properly considered, and so the whole thing was an abject failure. And that is not what we want to do as enterprise architects, and, we assume, not what you, our audience, are looking to do as well. So part of what we'll be talking about is how you avoid that, and that is by getting the architecture bit right.
Guy:
So, this might sound obvious, but it's a good starting point. So what is architecture? It's a set of principles, of design and practices around them to support the creation of something. So you work in architecture at the smallest level in software, the internals of a very simple app and application, and again you can go and Google it and there's thousands of pages of information on how to build an elegant mobile app. That's an architecture. You can then scale that up and think about then how does the actual phone be, the android, the, um, apple os work? That's another layer of architecture. Then you can scale it up again and think about how does the physical aspects of the phone work? And then, beyond that is the meta layer, which we normally don't care about, which would be how would the network come together to support the capabilities? And then there's a higher level architecture with, with 3g and 4g technologies that sit on the physical network and there's a combination of software and hardware, just like your phone.
Guy:
Now you might think why am I saying that? About when we're going to be talking about enterprise architecture? But these can be easily forgotten when we've been moving from total owned environments with the classic data center. But even that was an illusion because in my experience, you actually went to front office systems and you had people with the infamous servers under the desk, literally wired to a port in the wall. So the nature of an architecture used to be very clearly known. It was a physical thing. You could walk into a building, you could see them, you'd kick things and you could say there you go, that's the baseline from an IT infrastructure. And then you again would go up and say I have more than one data center. And I now have to start thinking about resilience because, going back to what Dominic was talking about, I'm a bank, I'm a retailer, so if there's an outage or a failure, how will these, this infrastructure, be resilient to maintain the software and the services deployed into it?
Guy:
Now, why am I talking about? The on-prem world of the history is, firstly, it's still there, but from a point of view of architecture, design, it's actually becoming a more complex environment, and I'll just touch upon that for a moment. So it's great for anybody on listening to this podcast who is a net new environment that has no legacy and therefore is 100% cloud only. You might think you have a simple environment if you standardize a one cloud provider, but for most large enterprises many of them still have physical data centers They'll invariably have one, maybe two, preferred cloud provider. The reality will actually be they'll have several cloud providers that they don't necessarily think about.
Guy:
I have been in many meetings with enterprises that say they are a AWS or an Azure shop until you go exit for marketing, because they use Google for marketing services and data storage for very specific Google-orientated capabilities.
Guy:
So the rest is the infrastructure and the hardware. Now, even though we're less conscious of it with cloud infrastructure, because the cloud providers take care of the network and the hardware management, it's still a complex environment. It's actually getting more and more complex as we go through. So the ability and the need to understand the landscape and understand how that landscape is going to support business requirements at scale and critically this is the bad news in a cost-effective manner to support a business case is still a highly relevant issue in today's infrastructure and strategies, and I'm actually positive that it's getting more complex with the rise of SaaS applications, mobile applications, niche specialist applications and the fragmentation of the application landscape. So you actually have more systems, not less. They are physically distributed around the world and you actually need to think about how you're going to work with them, how you're going to bring them together, how you're going to extract information from them all to achieve a business process and, most of the time, a customer outcome or a product outcome.
Dominic:
There you go. So that kind of hints into the next topic that I wanted to discuss. Now that we've defined enterprise architecture, we do sometimes hear people saying you know, that's something that was relevant back in the day when everyone had data centers, and these days, in the world of SaaS and cloud, maybe not so much. Not so much, and certainly I used to be a sad man in the old days and I did have to deal with people who literally hid PCs under their desks and ran services on them and then various shenanigans happen and that doesn't happen so much, not least because hardly anyone has that sort of PC that you can hide under a desk anymore.
Dominic:
But, as you say, say you know marketing, even if we're an all AWS shop. But yeah, marketing has Marketo and they have some Adobe thing and to support that, and some Oracle traceability, whatever, and that starts to make your life very, very complicated. So shadow IT these days no longer means somebody hiding a computer under their desk or getting an unofficial iPhone instead of the official company BlackBerry. It means that they swipe a credit card and they sign up for some service and guess what? Now we have to take that into account, whether it's from a security and compliance perspective, what data is being sent to that service and what policies should apply to it, and how can we enforce them. But also, how can we plug it into everything else so that we can make sure that the data that's going to that service is not obsolete, out of date, out of sync with other systems.
Guy:
What we're really discussing and highlighting here is the critical need for architecture to be relevant in the 21st century. Again might be obvious when you got two architects on a podcast. We believe the relevance of architecture is still critical today. Got two architects on a podcast. We believe the relevance of architecture is still critical today, in the 21st century. There was a period, though not so many years ago, that this was actually in question, and enterprise architecture has been uh, as dominic said, was uh hot in the 90s would probably be the best way to describe it from my point of view. A bit like us. Then Guy Indeed and then it got a bit of a bad reputation. And then there was almost a low point in 2010s where a lot of developers decided that they didn't want architects, and I'll quickly touch upon what the curve was and how we've been seeing a bit of a turnaround on the credibility and realization of the need for architects.
Guy:
So for a long time, the primary winner in the concept if you Google enterprise architecture was a set of standards called TOGAF, which is a very powerful set of tools for trying to capture, from the business strategy down to low-level components in an enterprise environment, how you would set up and run an environment.
Guy:
It has great principles and it's been around for a long time with TOGAF 10.
Guy:
Now a lot of organizations and I myself have gone through TOGAF certification twice in my career and it's very, very academic. You do a lot of paperwork and this is for. In some organizations it was very successful and in other organizations it often ended up being very academic and very bureaucratic. So you'd fill servers, specialist servers, full of potentially thousands of pages of artifacts and documents, but when it came to projects, how that really related was often highly opaque and also enterprise architecture teams were quite often seen to be very distant from the day-to-day projects. Then modern development came along and we saw concepts like Agile and notably microservices, with the whole stack development culture and an underlying view that almost architects aren't needed, because if you think about a microservice and a pizza box size team and separation of concern of capability and separation of concern of capability, there's a philosophy that said, the simplicity of this design would mean that you don't need to have lots of architects around the environment, and this was true for relatively small-scale landscapes.
Dominic:
Until you have to coordinate multiple small teams all eating their own pizzas.
Guy:
And this is where things started to change. So I saw organizations not that long ago, in both banking and telco disband their architecture teams because they decided the next wave of systems wouldn't need any of them. And then, 18 months to two years later, architecture teams were put in place, but they're not the same thing. So I guess this is the takeaway Modern enterprise architects have to be much more lean, much more close to the technology stacks, have to be more holistic in how they think and we'll talk about this in following podcasts about when we talk about operating models and working with communities, looking at how to maximize capability and the value that an architecture brings in a way that the development and the deployers and the administrators of a system can actually adopt them rather than feel that it's imposed upon them.
Guy:
You also nowadays can't be thinking in most industries three to eight years out, which was the traditional enterprise architecture window. You're actually now often working in the six to 12, maybe 18 months out. So again, being a lot more lightweight and less bureaucratic, allowing innovation in the right areas of the organization but then putting guardrails around it so you can also shift from a pilot and an innovation mode into production and success. All of these concepts need to be leaner and architectural design should be just enough architecture to onboard a new technology and then a maturity curve to achieve the type of business requirements. And you're going to hear security and business requirements time and time again on these podcasts, because these are at the heart of modern architectures and you can't ignore them. Hear security and business governments time and time again on these podcasts, because these, these are at the heart of modern architectures and you can't ignore them.
Dominic:
No, that's exactly right, and we'll be talking about things like pace layering and various techniques that you can use, uh, to kind of map out that landscape.
Dominic:
But the key point is you no longer have the glorious five-year plan, uh, that everyone is going to stick to because you know, five years ago the landscape was completely different and I'm willing to lay down large amounts of money that five years from now it's going to be entirely different again. It doesn't make sense of a rigid plan. What you can do is do you know, horizon one, horizon two, horizon three sorts of planning, where horizon one is what we're going to start doing right now, and so we have a pretty good idea of what we're going to start doing right now, and so we have a pretty good idea of what we're going to be working with. Technology-wise, organization-wise. Horizon 2 is a bit looser because you're allowing for inevitable change to occur, and Horizon 3 is broad strokes, high-level goals, but with the explicit understanding we're going to figure it out once we get closer to that date and it starts to look more like a Horizon 2, horizon 1 project. That is much more concrete.
Guy:
Absolutely, and another part we'll probably discuss later in a bit more depth is understanding the blend between the pure digital aspects of a company and what I term the physicalities of an organization. So some industries, you could argue that's dwindling. So you could actually posit that banking is going that way. So at least here in the UK for anyone who's an international listener we're seeing a remarkable drop-off of the number of physical banks. So again, when I grew up as a kid, every single town, every single, even some small villages had banks, and then you had, obviously, the ATM networks were everywhere. You move forward today and in the UK we're seeing the retail industry is shutting down at an incredible pace, the assumption of a physical bank, even in sometimes large towns.
Dominic:
Even the ATMs are getting pulled. Yeah, it's amazing.
Guy:
Yeah, with the assumption of mobile payments or touch-and-go payments through a card if you're still rich enough to own a card. So banking services and we've seen this with fintechs are now starting to work in a 100% digital environment. There are other industries because we are physical beings, have to actually square off the blending of fast-moving digital with physical capability. So one of the large accounts I work with is a top global manufacturer. So they have to build products that have warranty life cycles in multi-decades. That's very enterprise. While they are still wanting to maintain innovation in multi-decades that's very enterprise.
Guy:
Yep, while they are still wanting to maintain innovation, adopt AI, adopt high-end digitally-driven environments, but they've also got to develop a level of physical, consistent machining in their core products. That means that they've also got to be, paradoxically, incredibly careful in how they think about change requirements of infrastructure and software. So it would be great if we could say everything's going to be easy and it's all going to go into 100 digital, but I still drive a physical car, we still wear physical clothes, most of our infrastructure is actually physical and this has been a issue that I've been seeing over the last decade on how far can organizations push the ultimate speed of the dream of being an amazon or a netflix where you can be, uh, doing change cycles in minutes and, paradoxically, of course, amazon and and Netflix and the organizations operating at that scale, are extremely concerned about physical aspects.
Dominic:
The speed of light is the ultimate constraint for them, and so they try to make sure that they're close to their users so that they're giving a good video streaming or whatever experience to the end users. But yeah, experience uh to to the end users. But yeah, these are some of the concerns that we are hoping to discuss on this podcast again, and not just between the two of us, um, but also inviting more of our snap logic, colleagues and customers, partners, practitioners from the industry who can tell some of those concrete stories about the real world applications of this stuff. Because the bottom line is, you know, we think SnapLogic specifically and integration in general.
Dominic:
It's very important that we take all of this into account, that we span the cloud world and the on-premises world, the SaaS world of dematerialized swipe, your credit card and the extremely physical world of where is this thing actually running? And not forgetting those human factors of who is it running for? Who is actually going to be doing the work, who cares about the outcome and the result? That is ultimately what defines the success or failures of these projects. We need to be lean, we need to be flexible and provide just enough architecture. Not be rigid, not provide a straitjacket for our friends and colleagues on the more operational side of things, but give them the roadmap so that they can get to where they need to go.
Guy:
Absolutely, and so in future podcasts there's going to be a number of different topics we're going to be talking about. Some of them will be more structured discussions about modern best practices around operating models. Others will be a little bit more contentious. We'll be discussing the convergence of application and data integration and the entire concept of domains, about how we think modern IT leadership needs to think about this in a very different way again, compared to how it's been done for the last 25 years in large enterprises. What the impact of this is and how does a IT strategy support a multi-speed environment that is, by its very nature, fragmented or part of an extended network that will support everything from information on your mobile app or at the edge of your business networks down to large-scale centralized environments where the business process and large-scale data processing is taking place. So we are looking forward to continuing this conversation.
Dominic:
And if all that sounds interesting, like and subscribe, as they say, tell your friends who might find all of this interesting, and you can follow along with the conversation and add your own comments on SnapLogic's Integration Nation community site, which you can find on communitysnaplogiccom. We'll be putting the link in the show notes for this episode. In particular, if you're listening to this podcast, there's an area in there which is for the Sigma framework and this is where we put those more textual, more specific best practices around how best to implement the SnapLogic platform specifically as part of your integration architecture. But with that, thanks for listening and we'll be talking to you again soon.
1 Comment
