Hello and welcome to this lecture on IT architecture. We will start out by taking a look at why IT architecture is important and how we can use technology to support a business and its business model, its vision and its goals. To start off, when you look at IT architecture, IT architecture allows a business to make sure that it's investments in technology align itself with the business and its business model. The second part, the second reason why IT architecture is important is that it allows businesses to have a standardized set of hardware, software, networks, and standards. Which means that they would be able to adapt and change the IT capabilities of the organization very quickly based on business needs. From a cost standpoint, IT architecture means that having a completely known and structured architecture enables the organization to realize cost savings both in hardware, software, and other kinds of technology investments like networks. So when we start thinking about IT architecture, it's extremely important to start with the business and the business model. We can define the business model as a company strategy for creating value for their customers, right? To put it very bluntly, the business model is how does the business actually make money in order to understand or to support the business model? You have multiple components that come together. One would be the process architecture. So this would be the architecture of all the business processes, right? How do you actually engage your customer? How do you actually manufacture a product? How do you actually design new products? Then you've got the organizational architecture, which looks at how the enterprise itself is structured in terms of the locations where they operate, the different business units, how the organization is managed. And finally, we've got product architecture. Allows a company to have a commonality between the product families that they manufacture, sell, or produce. That allows them to actually reduce the cost of production of various variants of the different products that they have. In order to support the business model, every business needs to have a set of business capabilities. These business capabilities essentially are a way of designing key business operations, key business functions, such that they actually support that business model. This would mean understanding and creating capability models for different business domains. It could mean creating a business object model at an enterprise level. Or to create workplace models that show how people actually are involved in creating value for the organization. When we think about those business capabilities, those capabilities are created by IT applications. So this could be enterprise systems such as ERP, system supply chain management systems, product life cycle management systems, so on and so forth that actually allow the organization to do things such as produce product or get the right thing to the right place at the right time to support the business capabilities, we have to have an IT application landscape, right. In a large organization, you could have hundreds, maybe a few thousands of IT applications. In order to make sure that these IT applications all work together, we need to have a reference architecture for the software. This reference architecture basically looks at how do you actually build software in such a way that it can actually integrate with the other software that is used within the organization? That integration itself creates an integration landscape. If you've got a 200, 300, whatever number of applications that you have in many organizations, it'll be an ERP system or some kind of a large scale enterprise system and a very large number of applications that basically enhance that underlying enterprise system or add additional capabilities to that enterprise system. So we need to figure out how are we actually going to create that integration for that as well, we need a reference architecture so that we understand how the integration can be done. These reference architectures, the word reference here basically means that they are guidelines on how to do it. It's not necessarily something that is a commercial product, rather it's a framework. It's a conceptual understanding of how we do that particular. Technology capability. Then of course, to support the IT applications that are now connected through that integration platform, we need to have infrastructure services. This is where all of our, we get hardware services like computational capabilities. We have storage services in many organizations. Today you're starting to look at this and say, maybe we need to think about all the different IT services that are provided to the organization as a catalog of IT products. Underlying all of that, we have the IT infrastructure itself, which is essentially all the servers, the laptops, the routers, the ca, all of the nuts and bolts, if you will, that support the capabilities of the organization or actually create the IT capabilities of the organization here as well. We need to have a reference architecture such that we can make sure that all of the hardware and networking devices and services that we bring into the organization can seamlessly work with each other. Now we have talked about IT architecture and its importance from a business context, but we really never defined, we define IT architecture as a mechanism that provides a structured approach to designing applications on the cloud and even on premise that are scalable, resilient, and highly available. Ultimately, from our perspective, the architecture really starts at that IT applications level where we are building software. And then we work our way down until we get to our IT infrastructure with everything that we've said. The biggest benefit of IT architecture is that it provides consistency. And standardization, that is, we understand exactly what we have and that standardization means we know that they will all work together. As you start looking at IT architecture and saying, okay, how does the cloud play into this? In many ways, you have to actually design applications for the cloud. Now we refer to cloud native applications. And these are applications that can actually run directly on the underlying cloud run time in the cloud. We also need to make sure that the application can be managed by automated tools. A lot of AI is used to manage applications that are provision in the cloud. You must be able to get a predictable mechanism to actually deploy, manage, and if necessary, sunset applications. Many organizations experience organic growth. That is, they grow as their markets grow, as the customers grow, as the products get more popular during that growth phase of the organization. A lot of times IT architecture doesn't get the attention that is necessary. Which means that as the organization grows, we could end up with a situation where the architecture looks like what we have here on the left side of the screen. That is the architecture. Some what happens that right, it might all work together. But then when you look at the way the business capabilities are provisioned by IT systems, you may have something large, like an ERP system. You might have these silos which are highly specialized applications. Now on the back end, you need to create a whole bunch of connectivity and interfacing, which then has to support significant capabilities with business intelligence and reporting. The problem here is when something goes wrong, it becomes very difficult to actually figure out where the problem is because you could blame the software, you could blame the integration. And if there are multiple pieces of software, you get into which particular piece of software is the cause of the problem, you really cannot pinpoint. When you look at this from a user experience standpoint, users don't have a consistent way of accessing any of the systems that they might need to use on a regular basis. We look at the image on the right, Now we have all of our users interacting with one unified user experience provided through a browser, right? It's the same web browser that we use. Using the browser, they will connect to a portal. The portal serves as a repository of all the different IT applications that are available within the enterprise. Now this is important when you think about organization with hundreds of applications. One of the challenges that we have is how does the organization and the employees, or rather the employees within the organization, even find the applications that they need. The portal gives them the ability to do just that. Then we have the Enterprise service bus, which basically connects all the different applications together and provides that integration capabilities. And then we have the server and the backend, which is basically all of the hardware software infrastructure and the network that connects all of it. When you look at the well designed architecture here on the right, we can clearly see how that IT architecture will provide the organization with consistency and standardization. For example, when you think about standardization, all the users are accessing all the applications initially through a standardized web browser, which then connects to an enterprise portal. From there, the user experience might change depending on whether the user is bringing in sales application, a shipping application, or maybe they are managing their own HR benefits. Let's get down to specifics and look at IT architecture components. We have software, hardware, and network. Software would be either application software or an operating system if we had to think about a model here we have applications underneath the application, we have the operating system. Underneath the operating system, we have hardware. Below that, we have the network. These are the hardware layers, and these are the software layers. This model that I just drew here is very important to have as a mental model at all times. Essentially, we have the hardware layers on which the operating system runs. The operating system essentially serves as an intermediary between the application and the underlying hardware, including the network of the organization. Let's now take a look at application architecture in that layered model that I just showed you in the previous slide. We are going to start with the top of the layer, which is the application architecture. Let's start there. Let's now take a look at an application architecture. With application architectures, we build what is called a layer design, or a layered logical design. We look at all the different functions are, all the different capabilities that applications need to have. And then we implement them as layers. We have our users here, right, so they are external to the system. The presentation layer will provide all of the user interaction capabilities. That is the user interface interact with the users on one side and then it interacts with the business layer on the other side. The business layer brings together all the different business logic that needs to be implemented within that particular software application. The business layer interacts with the data layer. The data layer takes care of the logic for storing and retrieving data from internal and external storage. And it also has connections to external services that might provide it with data capabilities. When you look at these layers, they help differentiate between the different types of tasks that need to be done by the components of a software application. So this means that we have a mechanism whereby we can actually re, use the components, right, if you build. Some kind of business logic in an application, You could potentially re, use that logic in another application. Or if you create a presentation layer, we can use that in all the applications that we have within our enterprise so that we have a consistent look and feel. Now when you look at each of these logical layers, they are made up of a number of different components that are grouped into sub layers. Each of these layers can actually be split up into sub layers. And each of those sub layers could have a specific task. For example, in the data layer you could have a sub layer or a component that is responsible for making sure that you have a continuous back up of the data, right? You might have another component that would be responsible for restoring data, in the case of data loss or data corruption. You might have another component that takes care of the performance of the retrieval and the writing of data. Want to provide a little bit more examples in terms of these services. The external data services could be something like an exchange rate feed that comes in into a bank. Or in a bank you could get daily interest rates. These are data that is required by the data layer and needs to be stored within the application systems. But the data itself originates from an external service. In the context here, a service is just another software application that our data layer can call over a network and get the data that it needs. The external systems that are up here, these external systems, the one on the top right of the screen right. These external systems are other systems, such as, let's say, one that provides tracking information for goods that have been served to a customer, right, that have been sold to a customer. So if this is the example of software that is used for an e commerce website, that external system could be UPS or Fedex, DHL. That is providing tracking information which the application then present to the users through the presentation layer. Students always get a little bit confused between these two external connections. When you think about external systems, these are other organizations, typically, that provide services, business functions that are internal to their organization that we need within our application to provide users with capabilities such as tracking a package. The services down here at the bottom, these are data services that brings in specific elements of data into the data layer. For example, looking at the credit score of an applicant for a mortgage Lo go out to Expedient or Equifax and get the credit score. Bring it in and then we are going to store it. The external systems like at UPS or Fedex or whatever their business logic is coming into play with the services coming into data layer. They're just putting in raw data that the organization needs in order to perform the business functions that the software is designed to do. Let's take a deeper look at each of the layers. The first one is the presentation layer. The presentation layer has two sub layers, or two sets of functionalities. The functionality together help manage user interaction with the system. The presentation layer basically serves as a bridge between the users and the underlying business layer. The presentation layer has two sub layers. One would be the user interface components and the second one would be the presentation logic components. For example, when you are watching this video, you have the video playback controls, right? You've got the play button, the stop button, the past, maybe a skip button. Those buttons are the UI components. And of course, you've got the minimized, maximize and exit buttons on the top right as well if you're on a Windows platform. Now, the presentation logic components define what happens when you click on a button. For example, if you have a skip button. Does it skip 20 s? Does it skip 30 s? Does it skip to the next chapter? Does skip to the next bookmark, whatever that might be. That logic is built in to kick off when you click on a button. So another example would be clicking on the exit button triggers a warning or a question saying, are you sure you want to exit, right? That warning is triggered by the presentation logic component. The button itself is created by the UI component, right? The button is a UI component and what happens when you click the button is a presentation logic component. The business layer is one of the most complicated layers of an application because it implements all the capabilities that are required for the business to actually run at a broad level. That could be an application facade. The application facade provides the interface between all the different components of the business layer and the presentation layer. All right, it connects all the different components of the business layer to the presentation layer that allows the presentation layer just to connect to a single unified component, which then connects to all of the other components within the business layer business workflow. It basically looks at all the different step by step operations that, that might need to be done as part of a business process. For example, you get a purchase order that has some kind of an exception and it needs to be escalated to the purchasing manager. Maybe because the agreed upon price has changed the sequence of steps that need to be done in order to execute some step in a business process. Those are the various business workflows that would be built into the business layer. The business components looks at a broader set. Like for example, you could have a human resource component to manage the people within an organization. You could have a sales component to manage the sales process. You could have a planning component for material planning or for capacity planning. The business entities reflects all of the different legal entities that the organization has in each other countries where they operate. This could be like, I've got a plant in Bloomington, Indiana. I've got our headquarters in Indianapolis. We have a warehouse distribution facility in St. Louis, Missouri. All of these business entities need to be represented because they have to be consumed in all the different business processes that we are going to perform in the system. Next we have the data layer. The data layer essentially provides access to all the data that is hosted either within the boundary of the system or it could be data that is exposed by other network systems. Recall that I talked about this. Services that can bring in data that is required for processing all the business functions that are implemented in the business layer. If you look at the data layer, it interacts up here with the business layer. The data layer has data access components. These are the routines or the capabilities that will go out and get the data, write the data, apply user logic. Does this person have access to this data? This person have the rights to change the data. It connects to an external, maybe identity and access management system. Identity and access management system essentially at an enterprise level, allows users to connect the systems and then defines what they're allowed to do with the application and with the data. The data help Ers and utilities are those back ups, restore, shadowing, mirroring to make sure that our data would not get lost, that the service agents here connect to those external services and pull in data that is required for the performance of our business logic. Or data that is required in the day to day operations of the firm. And I gave you some examples of that. We talked about systems being able to interface with other systems through services. A service essentially hides the business logic. Behind a standardized interface. When you think about software, we have very large software implementations or software applications, such as Oracle's Enterprise Business Suite or SAP's Four Hana, both of which are enterprise level systems. You also have the applications or the apps that run on mobile phones. You have things like Microsoft Office 365. Within these applications, each of the components in the presentation logic, each of the components in the business logic and the components of the data logic can each be implemented as separate services. Or can be implemented as a service that interacts with other services to collectively perform the function of the larger application. Whether we look at a large, monolithic enterprise application, or a small service, such as the spell check in Microsoft Word, The architecture of software, irrespective of how big it is from a reference architecture standpoint, would be the same. A service based solution is made up of multiple services, each communicating with the others that are part of that application by passing messages. Basically, these services become components of the overall application. Internally, each service is actually made up of software components that follow that reference architecture. The huge advantage of the service model is that other services can make use of the services inside an application without knowing anything about how they are implemented. When we look at the service based solutions, each service actually follows the layer design principles that we just discussed. Looking a little deeper into this, if you had to say, hey, instead of all of these different services communicating with other services, why don't we actually bring all of the services in the business layer together, the interfaces of these services together and expose them both internal and external systems through defined interfaces. That then becomes a services layer. The services layer basically brings in all of the services that are implemented in the business layer and exposes them either to internal preservation layer components or to external systems, depending on what the intent of that service is. The services layer has two subcomponents. It has service interfaces which essentially allows other services to connect and consume the service. A message type which basically defines the format and the structure of the data that should be used to communicate with the service, right? The standard here for most communications between services in today's world is XML, or rather, it's a set of protocols that are based on the ML, or the Extensible Markup language. That's what allows us to have standardization. I also want to call out here that we've really not talked about things like security, managing the application itself, like running it, allocating more resources to it, stopping it, updating it. Operational management and communications such as TCPIP are what are defined as cross cutting functions. That is, we need to have security in the presentation layer, we need to have security in the services layer, we need to have security in the business layer and the data layer, right? And the same thing goes for tools to actually manage these components as well. As of course, we use network protocols, TCPIP and the family of protocols to actually enable the communication between services, right? So the service interface is what a service would connect to. The message type defines the format and structure of the data, and an underlying communications protocol allows that communication to happen. So looking at this deeper, basically, the service interface is a facade that exposes the business logic that's implemented in the application, right? So that would be the logic that's implemented in the business layer and we expose it to potential consumers. And the word consumer here is just implying. That whoever is on the other side, whether that is a presentation layer or it is an external system, uses the service, right? So that's where the word consume is coming from. As I mentioned earlier, the message type, when you exchange data across the service layer. These data structures are wrapped by message structures that support different types of operations. That is, the services actually perform logic based on the input coming in from external systems that has data pieces to it, which is the data that needs to be consumed or used by the service. And then it has message structures which would say, hey, update this record or add this particular item to a product catalog. Of course, again, we have the cross cutting systems. If you were to step back and say, how do we actually define good software? Our first task really is to think about the highest level of abstraction and say this application has a lot of functions. So let's go in and group together the functions related to interacting with the user, that becomes our presentation layer. We look at what's all the business logic that we need to implement, that becomes the business layer. And then you have the data layer which implements all the logic required to read, write, and manage data that is actually stored in our Datastore over here, right? And then of course, we have the external data services that feed data into the data layer and external systems or external services that may make calls or make requests through the business layer so that it can actually use the capabilities that we have built. In summary, we talked about the importance of IT architecture, the single bit, two things being consistency and standardization. We talked about the importance of making sure that we always start with the business strategy. Understand how we need to build business capabilities to support that strategy. How we need to build IT application capabilities to support the business capabilities or to enable the business capabilities. How we need to deploy I infrastructure and the hardware software and networks itself to ultimately provide the computing storage and networking capabilities that is necessary for a large scale IT system. In the next segment, we will look at how we go from this logical architecture and map it to physical systems. Right, that is what we'll do in the next segment. Thank you.