Operational View

• The Operational aspect of Architecture describes what runs where (component placement) and includes the network topology (hardware nodes,locations, etc.)
• It ensures the achievement of the solution's service level characteristics (performance, availability) and describes the management and operation of the IT system.
• Functional requirements, keep on changing, but non-functional/operational requirements remain constant.
• Realising non-functional requirements is platform engineering, it's about performing, prioritising operations. For example, how that will be sent to a consumer via download, screaming, document, HTTP, images, et cetera..
• Functional systems must be deployed operationally using new or an existing infrastructure/cloud services.
• Fanout technique is used to scale an architecture, non-functional requirements.
• Following concerns are resolved during operational modelling
• non functional requirements like performance, availability, manageability, security
• Constraints like affordability, standards compliance, existing Infrastructure
• Detailed design: capacity planning, software and data distribution, network, hardware, service management.
• Commercial: planning, pricing, procurement, service level agreement.
• Designing for performance and capacity
• Designing for security
• Designing for availability
• Designing for system management
• Assessing Viability
• Having edge servers/nodes,cache, for a video streaming site, a examples of non-functional requirements.
• Other examples may include in memory storage for geospatial coordinates in a map application.
• Operational modelling is used to achieve these non-functional requirements.
• Operational Modeling helps ensure the system’s non-functional (NFR) requirements are delivered, within all constraints.
• Operational modelling is derived from system requirements, system, architecture, system constraints.
• The operational model describes how components are supported to meet the service level requirements.
• The Operational Modelling technique consists of multiple steps
• Understand the non-functional requirements
• What NFRs need to bet met?
• Conceptualize from an Application Layer operating model (ALOM)
• Identify application level nodes and their placement.
• How the logical design maps onto actual application/data/infrastructure building blocks — i.e., which systems, services, and integrations realize the logical capabilities.
• Conceptualize the Logical Operational Model (LOM)
• Determine where all of the logical application components are deployed.
• Determine what logical technical components are required and where they will be deployed to support the logical application components.
• Capabilities are decomposed into solution-level detail (what functionality is needed), still technology-agnostic.
• Logical operation model shows the static relationship between nodes, data units, connections and interactions on a geographic background.
• The LOM documents the placement and interaction of the application’s Deployment Units onto nodes distributed across the system’s locations.
• Identifying potential locations and nodes where deployment units might end up being placed, and establishing where the system’s actors will be located
• Placing deployment units onto application logical nodes in locations, based on a variety of considerations such as service management
• Presentation Deployment Units
• Data Deployment Units
• Execution Deployment Units
• Installation Deployment Units
• We derive connections from the relationships (interactions) between deployment units.
• The overall structure of the LOM is largely based on the locations over which the solution will be deployed.
• The location is based on the information found in
• Business Roles & Locations
• System Context Diagram
• Current IT Environment
• Regions and stores with in the regions
• Then we identify the candidate logical nodes that is where we deploy our deployment units.
• System context
• Use cases
• Non-functional requirements
• Component model
• Transform into the Prescribed Operational Model (POM)
• Determine real technologies to deliver all of these specifications.
• In a prescribed operation model, we put the prescribed business context straight.
• It is a part of middleware
• The POM transforms the logical system architecture into a set of product and technology specifications
• Identifying your role in the product selection process and the definition of the selection criteria
• Performing the necessary product selections for the nodes and connections
• Defining the solution details and describing how technologies will be put together to deliver the specific SLAs
• Rationalizing the solution architecture to get to a sized POM
• Product selection based on components can build the prescribed operational model.This is called an unsized POM.
• Identify the “Givens”
• Usually defined in the client’s IT standards, existing Technical Architectures or current IT environment. 
• In all cases, from the beginning be ensured the LOM is capable of being implemented in these technologies
• Identify the approved products.
• Spot the “Obvious” products
• “Easy to choose”, such as
• “Only one product/vendor meets the specs."
• “We all know this will be product/vendor ABC"
• “We could do a full vendor evaluation study, but it is more efficient to choose this product/vendor now"
• Look for the monitoring and backup products. There is no need to redefine them. They are already in use in other applications.
• Look at the “Adjacent” components
• The ones that are the most difficult to choose.
• We need to deploy them in the client environment, which is a long process and may require several approvals.
• Products selection based on configration gives us a more sized POM.It defines the size(quantitative) details of the solution, including the way these technologies will be put together in order to deliver the specific SLRs of the specification
• Performance and capacity
• Availability
• Security
• Service management
• Rationalizing the design involves a process of sizing the POM, so that Performance & other characteristics can be achieved.
• We create a sized operating model for an unsized operating model.
• What is captured in a POM
• Prescribed Nodes
• Hardware technologies and products
• Overall hardware configuration
• Hardware specifications, such as processor speed, memory, disk configuration, etc.
• Software technologies and products
• Software product specifications for operating system, database, middleware, directory services, security, etc., including versions
• Detailed configuration of software, such as the need for multiple instances of a software product on a computer
• Prescribed Connections
• Prescribed networks, protocols, network bandwidth, latency, etc.
• Cloud deployment model
• Public
• Shared infrastructure that lowers the cost per unit for all customers.
• Private
• Dedicated infrastructure configured for flexibility and scalability.
• Infrastructure management and maintenance tasks.
• Hybrid
• Mix of using shared infrastructure and dedicated infrastructure depending on NFR’s.
• Most of the customers use hybrid cloud model.
• Cloud services model
• IaaS
• Infrastructure as a Service - provides raw infrastructure resources in a virtualised environment.
• We have control at virtual machine level.
• We define following constraints at client side
• Business process
• Application
• Data
• Run time
• Middleware
• Operating system
• We define following constraints at cloud side
• Virtualisation
• Server
• Storage
• Networking
• PaaS
• Platform as a Service - provides an container/runtime environment with supporting services to build solutions.
• Example, cloud foundry
• We define following constraints at client side
• Business process
• Application
• Data
• We define following constraints at cloud side
• Run time
• Middleware
• Operating system
• Virtualisation
• Servers
• Storage
• Networking
• SaaS
• Software as a Service – provides application functionality as a service.
• Example, gmail
• Lower the control, lower the cost
• We define following constraints at cloud side
• Business process
• Application
• Data
• Run time
• Middleware
• Operating system
• Virtualisation
• Servers
• Storage
• Networking
• Nothing is defined at client side
• BPaaS
• Business Process as a Service – provides a means to increase organization efficacy by outsourcing business processes to a automated runtime
• In a traditional in-house deployment with time the architecture becomes old, tough to manage.
• We have higher control, but higher is the cost.
• We deploy the following constraints at client side
• Business process
• Applications
• Data
• Runtime
• Middleware
• Operating system
• Virtualisation
• Servers
• Storage
• Networking
• Nothing is deployed on the cloud.
• Prescribed operating model replaces real technologies and provides additional details, making it complete.
• Conceptual Layer Operating Model(COM / CLOM) 
• What value streams and business capabilities the org needs, with no tech detail. This is where strategy connects to the operating model.
• Transform into Physical Layer Operating Model(PLOM)
• The fully actionable, implementation-level model built with specific deployments, configurations, and infrastructure.
• To achieve this goal, we have a structured, formal language to describe the elements featured on the Operational Model
• The Operational Model represents the “infrastructure architecture” using elements like
• The geographic structure of the locations and their borders, over which the IT system will be deployed and operated
• The placement of the system’s nodes into these locations
• The deployment of the system’s components across these nodes, using deployment units
• The connections between nodes
• The organization of the system’s elements into zones
• In addition to this description of the deployed system, the model also documents
• The overall prescribed configuration of the technologies and products necessary to deliver the functional and nonfunctional requirements of the IT system
• Sizing and other hardware specifications for all the computers, storage devices, and network technologies
• We can define specific notations to define operational model.These can be divided based on non functional components and their behaviours 
• Actors & Infrastructure
• Location
• Node
• Node is represented as a physical layer
• Human actor
• System actor
• Connections
• No permitted connection
• External intermittent connection
• Internal high-speed connection
• External high speed connection
• Cloud
• Offering
• Support
• Data
• Deployment Units
• Presentation
• Entry point used by actors to access a components functionality e.g. live web interface.
• Execution
• The runtime execution aspect of a component e.g. 3 instances of a word processor running in 3 different user accounts on the same mobile workstation
• Installation
• Files required to install the component e.g. executable, configuration and data.
• This includes installtion mdia,repository etc.
• Data
• The data used by components e.g. user profile
• Technical
• Operational Model inter-dependencies with other artefacts
• Component model
• It is used in deployment unit model
• Architecture,functional and non-functional requirements
• Used in node model as well as deployment unit model
• Node model defines where we should deploy things for example, lambda, ECS, EC2, container, virtual machine.
• Deployment unit model defines what we need to deploy. These contains artefacts which helps us to build operational model.
• Deployment model defines what we need to deploy for the deployment of different layers.
• Location model defines where we can put things, for example, cloud, on premise,region,which region etc.
• It can be office, remote, secure such as Development Centers, Cloud.
• Deployment Units represent all the bits required to bring an application component to life within the operational model
• Deployment unit model contains non-functional requirements.
• From the component, we can define the deployment units.
• We can define a component into deployment units
• Deployment Units can be classified into following two paths.
• Using an asset where Deployment Units are associated with a predefined node model and nodes are deployed into their locations.
• Forward engineered where Deployment Units are placed into locations where they are accessed by Actors
• We have to understand what it is we need to deploy, via the Deployment Unit Model
• Deployment Unit's give us a mechanism for:
• Understanding the nonfunctional requirements placed on the system’s components
• Deciding where best to place the various aspects of the system’s components
• Tracing the system’s requirements to its design
• The nonfunctional requirements of the component’s interactions are described in terms of relationships between Deployment Units.
• Typical relationships analyzed include
• Presentation - Execution
• Execution - Execution
• Execution - Data
• Presentation - Data
• For example, a component which on boards, suppliers can have following deployment units
• Deployment units can then be described using their non-functional requirements, which determine their placement and grouping
• Presentation deployment unit
• Due Diligence can have an actor, which checks for compliance, it may require an IT skill level, which needs to be trained, location can be mobile, and maybe we do not have a frequency and type for this.
• SMS can have an actor which receives SMS, it may not require an IT skill level, may not have An location may have a frequency and type.
• Data deployment unit
• Due diligence can be a data store with high volatility, small size, infinite lifetime.
• Supplier details may contain its product range, may have low volatility, large size, long lived and a master system.
• Execution deployment unit/runtime deployment unit
• Supplier checks can have an yearly frequency with a low processing load.
• Supply details may have a weekly frequency with a heavy processing load.
• Logical node model
• This defines all the nodes/platforms where the application can be deployed.
• A supplier may access the application through a mobile workstation or notebook
• A scrutiny, personal may access the application over a secure hand held device.
• Personal from a team which uses supplier information may access it on a secure desktop/environment only.
• There are many ways to deploy a sinbgle component into a simple system in this case we will have access to listed components.
• Running on Virtual Machine Standalone
• Presentation
• Execution
• Data
• Installation
• Data on Remote System
• Presentation
• Execution
• Running on remote system
• Presentation
• Data
• Entirely running on thin client with remote Data
• Presentation
• Example deployment of components in a Niche Market Systems
• The counter person can acess Information on a Point of Sale to generate cash memos.
• Market Owner can use system on mobile device/laptop anywhere to generate reports.
• The Accountant can create documents in a prescribed template for taxing purposes.
• So our Logical perspective can include
• Niche Market System - Functional Component
• Authorization Unit,Financial Unit - Technical Component
• Market,Owner System,Accountant System - Location
• Invoice Generator and Sales Analyser - Deployment Unit
• Point of Sale,Authorized Laptop/Mobile,Prescribed Public Systems - Nodes
• We may get following logical units
• Presentation
• Offline
• Online (POS)
• Data
• Financial Sales Data
• Tax Templates
• Execution
• Sales Processing
• Installation
• Accountant System
• Owner's System
• POS
• LOM to POM transformation
• Traditional LOM to POM transformation was based on Component Selection and Configuration.
• Cloud LOM to POM transformation
• Plan
• Review the Cloud reference architectures and determine if one is a good match for the NFR requirements or tailor as required.
• Refer the constraints while planning.
• Refer, the cost, certifications.
• Selecting a cloud reference architecture helps leverage lessons learnt and best practices but we may still need to tailor to our needs.
• Plan what kind of cloud is required for the solution.
• Object Management Group - Cloud Standards Customer Council
• https://www.omg.org/cloud/deliverables/
• IBM hybrid architecture’s 
• https://www.ibm.com/think/topics/data-architecture
• Define
• Define the type of cloud deployment model (CDM) i.e. public, private, hybrid, that meets the solution NFR’s and constraints.
• Logical Service Models e.g. IaaS, PaaS,SaaS, BPaaS
• Logical Services e.g. Middleware, Database, Storage
• Ibm rational Solution architect is used to design such solutions.
• Architectural decisions need to be made to select the required deployment and service model(s) based on the NFR’s and constraints while balancing value for the Customer.
• They can be defined as SaaS,PaaS,IaaS,Traditional In-House these are discussed before.
• Select
• Select a cloud provider that meets NFR and CDM requirements with a sizing/pricing model that provides the best match for the solution.
• We can use a cloud assessment model.
• Availability of the cloud platform within the client’s jurisdiction.
• Enterprise strength of the services offered by cloud providers, in particular security, availability, backup and disaster recovery.
• The level of support offered by the cloud provider.
• Not all clouds support every business process.
• Network connectivity to the cloud provider’s data centre.
• We must check the nearest available data centre
• Content of the cloud provider’s service catalogue.
• IBM has acquired Txture to help resolve this issue.
• https://www.ibm.com/consulting/txture
• Configure
• Configure the cloud to meet the NFR‘s.
• Using NFR’s, LOM and cloud reference architecture as inputs
• Configure the required Prescribed cloud services offered within the chosen providers CDM.
• Configure performance, capacity, and availability by configuring Prescribed cloud services sizing/service level requirements (SLR’s)
• Understand licensing model including enterprise level agreements for software/services installed within IaaS and PaaS.
• Need to select a Prescribed service for each logical services identified in the LOM.
• Define the size of the cloud services using a T-shirt sizing model and consider the NFR’s to select the “T-shirt” the best fits the solution.
• We define T-shirt size based on our application.
• T-shirt size is based on how much RAM, CPU, storage is required.
• We should know the catalogue and the T-shirt of the cloud.
• Netflix was just a media player initially. Adding capabilities of scaling and connecting from anywhere to it was a part of operation modelling.
• While creating an operational model, always start with the reference architecture.
• Try to reuse the existing templates.
• The review process test's the solution’s robustness
• Analyze each transaction from start to finish following the flow of information through each Prescribed node and connection
• Transaction workflow help to determine faults.
• Visualize what would happen if there was a failure on some part of the system:
• Would the failure be detected?
• Would the end user be notified of the failure?
• How will the transactions and data be recovered?
• Who will be responsible for repair of the component?
• Analyze how the failure would impact Service Level Agreements.
• Operation modelling, walk-through diagram is a powerful means of verifying whether the operational model will work.
• Converting our previous niche market, example to Perscribed Operating Model
• We can have a virtual cloud where we host our POS system, authorisation service, a service to manage taxation.
• We can have a database in our virtual cloud.
• References
• https://www.omg.org/cloud/deliverables/
• https://www.ibm.com/think/topics/data-architecture
• https://www.ibm.com/consulting/txture